The Root Cause of Water-Scrum-Fall

Introduction

Water-Scrum-Fall is the norm in many organizations today.  Despite the attempts of scrum coaches and consultants, the weeds of waterfall grow back into the agile garden.  What causes this?  This article looks at the root cause for the water-scrum-fall phenomenon and makes a suggestion about how to address it.

The Root Cause

Water-scrum-fall’s reality is not the result of people being unwilling to adopt scrum.  It’s not the result of a lack of passion for agile processes and practices.  Nor is it caused by a lack of executive support.  The cause?

Capital budgeting

In companies that produce software for internal use water-scrum-fall finds it’s greatest adoption.  Internally used software is strictly accounted for by the regulations in SOP98-1 and this financial machinery is what guides the need to plan up front.

Capital projects are investments.  To determine an investment’s return you need to know the estimated initial cost, and estimated revenue ( or savings ) the project will create.  These things are estimated up front so that a decision can be made on whether or not to pursue the investment.  The up-front nature of capital budgeting compliments waterfall and BDUF. It is a core financial business process guided and regulated by FASB.  Think about that for a moment…and then read on.

Scrum practitioners run up against a wall with capital budgeting.  It doesn’t fit their operational practice for developing software.  Under scrum….we shouldn’t be designing, estimating and crafting the project up front.  Instead we should approach it incrementally.  The problem with this? It ignores how enterprise software development projects ( capital investments  ) are funded.  The result is that everyone compromises and innovates.  Water-Scrum-Fall is the child of this compromise.

The Challenge

Scrum and other agile practices pose a challenge to enterprise software development efforts and the capital budgeting process.  Indirectly they say “Why are we funding this as a capital investment?  It’s not.  It’s an ongoing operational cost and should be accounted for that way.  If we don’t plan on funding this software development effort for the long haul…then why are we doing it?”  Funding a software development effort as an operational expense, as is done within software companies, does fit the scrum operational practice better.  But again…the difference between a software development effort being labeled CAPEX or OPEX is guided by FASB.  It’s not up to the company.

How Do We Fix Water-Scrum-Fall?

I don’t think there’s a silver bullet here.  But in my last article, Is There a Better Way to Estimate Capital Projects? , I threw out a suggestion for how to estimate a capital investment using tolerances.  This bypasses the need for an up-front detailed analysis of what the the LOE ( Level of Effort ) would be for the project, but still gets the business what it needs: an initial funding point and resulting NPV that augments decision making.

Summary

So water-scrum-fall is a pragmatic reaction by agilists and IT professionals to work with the business and its financial processes.  Did the originators of scrum not understand the capital budgeting process?  Were they oblivious to the financial architecture of the businesses around them?  Maybe…but to their credit; they weren’t trying to address this.  Their focus was on how to do software in an adaptive fashion so that it more organically addressed the operational realities of manifesting a complex vision.

Advertisements

Stoos – Some Thoughts

Much of what has been written about Stoos is nebulous.  For those of us looking to latch onto something concrete….we’re left befuddled.  Rather than a deliberate bullet list of actions; the Stoos group posted a wishy-washy communiqué that seems more like a summary of their meeting and a regurgitation of their personal feelings and war stories.

So what’s the point?  Is there one?

References to the agile manifesto abound with Stoos.  And like the agile group….they were meaningfully vague.  In this lap dance of ideas it appears their point was just to get us all thinking again about how organizations work.   Fair enough.  Things start with questions and wonder-ings.  Nothing wrong with that.

Perhaps the only shrivel of ideological meat that provided some sustenance for us definitive types was this from Jurgen Appelo:

For me the most concrete outcome is the core idea of seeing organizations as “learning networks of diverse individuals creating value”

This gets the wheels rolling a bit.  Maybe he’s onto something here.  Perhaps, with social media, mobility, and agile thinking its time for a new type of organization.  A virtual one where human ingenuity is rewarded handsomely  and it’s not about doing a job….but seeking, driving and growing value and profiting from it.  Meaningfully.

Those of us who work on the virtual cube-o-sphere today know that it’s not about showing up 9-5 and pleasing a boss.  If you’re a freelancer, 1099, contractor, inventor or entrepreneur you know it’s about finding your passion, networking and growing your value/brand.  Traditional organizations define what you should do for a salary.  Perhaps in the new Stoosian organization you define what you’ll do and share in the value it creates for the organization.  We dump stability for growth and a life’s mission.

The “A” Word

Over commercialized, overused and mis-applied the word “agile” has become synonymous with being better, faster, and cheaper.  The hype around the “A” word is nonsense.  Most of the software vendors, consultants, and marketers plastering agile on everything are simply capitalizing on the popularity of some ideas that aren’t even correlated with what their selling.

Agility is not a panacea. It’s not a software tool.  It’s not a product you can buy.  To my opinion it was a state of mind, a way of approaching problem solving.

It’s now lost that meaning.  It’s original luster is awash in a sea of hyperbole and advertising.  When someone says they’re agile or they practice agility….I no longer know what they mean.  It might be that they read a book, they use some self-professed agile software tools, they have a poker planning card set, they bought a CSM certification, or they recently attended some conference on agile software development.   Stop Agilizing Everything was written in protest to the fluff, and monetization of agility.

Will it stop?  I doubt it.

Instead it will kill itself through abuse. Eventually it will become the worn fad of the day.  In disdain and disgust we’ll turn our backs on the “A” word and seek something with more substance.

The Coming Breakup of Scrum

Introduction

Scrum, probably the most widely adopted agile software development practice, is cracking up.  The signs are evident and this article discusses the trend and what it means for agilists today.  If you practice scrum, are thinking of using it, or have used it in the past you’ll find interest in this article.

Oh yeah?  Prove it!!!

It’s a truism that rapid growth and popularity put a strain on organizations, movements, ideas…….or ,more fundamentally, the people comprising these very human vehicles.  As an idea ferments and then exponentially amplifies to encompass a wider politic of devotees and admirers there is the impending fog of dissent with the origin, the core.  From this comes splintering, debate and eventually more novelty and innovation.

Fine, but what about direct evidence for the rift in scrum?

03/05/2009 – Scrum But…Test.  Jeff Sutherland.

09/15/2009 – Ken Schwaber resigns from Scrum Alliance

06/15/2010 – Ken Schwaber establishes Scrum.org

04/20/2011 – The CSM certification wars

07/26/2011 – Forrester calls Water-Scrum-Fall the norm

08/02/2011 – Bloggers Suggesting Scrum Variations

10/06/2011 – Scrum Extensions announced – allowing modification to basic scrum.

As the agile movement hybridizes and evolves scrum is feeling the brunt of this pain. The forces of hybridization are ripping scrum into distinct camps whose views are aligned with their respective organizational needs.  Who are these camps and what will ultimately happen to scrum as this spider web is tugged from it’s anchors?

The Camps

The Enterprise – Most enterprises don’t build software as a core part of their operations.  Projects here are usually centered on delivering some base set of functionality for a fairly fixed price.  Stability and low cost of operation are prized.  The organization doesn’t usually see this as an investment…but as an expense to be managed and tracked.  The pressures enterprise software development groups face at the capital planning phase and the release phase have sculpted the Water-Scrum-Fall that’s prevalent.

The Software Companies –  In contrast to the enterprise, software companies build software as their core product.  It *IS* their operation.  Software companies see their products as an investment and it’s life cycle is fairly unlimited, or at least tied to the life-cycle of the company.  Pure scrum works in  these companies fairly well.  There’s usually still pressure to reduce the number of production releases but on the planning side managing features in a backlog fashion is workable, even preferable when you have a product that has a potentially unlimited lifespan.

The Startups – Startups face a different set of pressures from their venture capital investors.  The need to rapidly introduce new features and create value to customers and investors by gaining a competitive advantage quickly is paramount.  Startups are tearing scrum towards the Lean Startup methodology professed by Eric Ries.   The focus here is continuous delivery of new software: stability be damned.  Usually these startups don’t build software that’s mission critical or life threatening.

The Purist Methodologists – Among these are the various scrum trainers, agile coaches and general agile philosophers who profess a puritanical approach to scrum.  Their insistence on a dogmatic approach to scrum are rooted less in practice and more in theory.

What are they doing to scrum…where are they taking it?

These groups are doing what’s natural.  They’re catering scrum to their practice and profession of application life-cycle management ( ALM ).  But this tug of war for scrum’s future is changing it.  Instead of a simple, one-size fits all methodology, it’s becoming a framework of patterns & practices.

You can see this through the introduction of scrum extensions, which is a natural way of recognizing the various groups that have adopted scrum in some fashion.  With scrum becoming an umbrella concept, it’s importance is melting away.  It will devolve and eventually disappear. Instead the extensions, much like design patterns in software development, become the value added pieces that development teams will use and rally around.  Each camp will likely pool certain extensions, patterns as their ‘methodology’.   In time, these flavors of scrum will tear it completely apart.

Summary

Scrum’s popularity will likely be its undoing.  But is this something to be avoided or stopped?  Hardly.  Hybridization and evolution of scrum is a natural process that is both pragmatic and necessary.  Jeff and Ken’s baby is growing up and leaving the agile house.  The original agile manifesto signatories accomplished their mission; they broke the one size fits all ALM world down.  The new heterogeneous landscape of practices and patterns, while less clean than the bi-polar world of agile vs waterfall, is primed with greater opportunity for innovation.

Two Agiles

We all know this.  But it sometimes gets lost in the haze of execution.  There are two agiles.  The first is the philosophy, the belief system which is represented by the agile manifesto.  The second is the agile practices that were an outgrowth of the agile manifesto: scrum, xp, crystal, dsdm, etc.  Commonly, when people talk about agile…they’re talking about one of the practices that were an outgrowth of the manifesto.

What should be clear, but often isn’t, is that the agile manifesto doesn’t mandate the use of scrum, xp, waterfall, or one of the others.  In  fact, by blindly adopting one of these without considering the context of your project…you’re being anti-agile.

Stop Agilizing Everything

Introduction

Agile universities, certifications, agile consulting, traveling coaches, planning poker card sets, agile software products, agile modeling, agile arm bands, countless agile books and the crazed cycle of agile conferences.

WTF????

The buzz cycle is in overdrive and it’s electrocuted the business world with the promise of faster, better and cheaper.  This article is a plea to stop.  Stop all the hype, the opportunistic profiting, and the marketing.

Good Intentions Turned Ugly

What started out as a challenge to the software development community to think outside the box ( invent, create ), abandon a one size fits all model to approaching software development and execute your projects in a pragmatic fashion that takes account of the context you’re working in….has turned into a marketing machine of horrible dimensions.

There was a time when people talked agile and you knew they were on the vanguard; trying to solve the real problems.  They cared.  They were passionate, deliberate, and informed.  Now, when you hear a colleague professing agile…they’re most likely drinking the kool-aid poured by the snake-oil agile coach from Denver or San Fran.  The formulaic response to the core problems is all too familiar and draining:

  • Poor Requirements – You need user stories and iterations.
  • Defects in Software – Continuous integration and TDD will solve that.
  • Bad estimation – Use planning poker.  It always works.
  • Change Management – Break it up into iterations and embrace the changes given in iteration reviews.

I’m not knocking these techniques.  Many are novel inventions that do have their place in SD/AD.  But instead of being offered as potential options, patterns, techniques to solving a problem among many other potential solutions; they have become a sales pitch by the opportunist preying on desperate CIOs.  Buyer beware.  Bubbles pop and my gut says the needle to prick this balloon is getting very sharp and close.

Let’s stop agilizing everything. Good ideas, tools, and techniques don’t need the word ‘agile’ pre or post fixed to be worthwhile.

Come Back Home

So turn off the scrum-o-matic. Wipe the agile makeup from your face, and put the kanban sequin dress away. There are still problems to solve.  We haven’t unraveled this thing called software development.  It’s devilishly vexing and we need good minds focused on it.  Become neo-software-amish, come back home to the forest of software trolls and invent/create again.