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.

About these ads

Is There a Better Way to Estimate Capital Projects?

Introduction

“I don’t understand why you keep asking us to estimate the work. With all the time we’ve spent estimating we probably could have completed the first few requirements already. This is a waste of time!!” Ever heard something like this before? It comes across a little naive with regard to capital budgeting.  But there’s a good point in the vehemence…. Waste.

In this article we’ll rethink estimation.  We’re going to look at the machinery above estimation that catalyzes the need to predict effort and then propose a different way to target capital funding for projects.

Backgrounder

I don’t want to lose anyone here so I’m going to go over some basics of capital budgeting for internal use software projects and how that relates to estimating.  If you know SOP98-1 already then skip to the next section. Estimating can seem like a game.  At best it’s an educated attempt to predict the future using formulas and experience.  At worst its a W.A.G.  So why do we do it?  It all starts with how we account for the expense of developing internal use software. Internally used software is classified, for accounting purposes, as a fixed, long term asset.  In accounting speak: a capital expense.  That means it can be purchased for a set price and has a useful life greater than 2 years.  Capital expenses, like internally used software, can have their cost depreciated ( amortized ) over the useful life of the asset.  What does that mean?  It means that instead of realizing the entire cost of the custom software effort in one year…..you realize it over the useful life of the asset.  So if we intended some custom built workflow system to last 5 years and the entire cost of the initial development effort was $312,333.04 then we’d ( in a simplistic amortization schedule ) realize, report $62,466.61 in expenses per year for 5 years on each annual income statement.  Further the software’s depreciated cost would be listed as an asset on the corporate balance sheet each year until the full value had be amortized. The ying to the capital expenditure yang is the operating expenditure.  Operating expenditures are incurred, realized as they are spent.  There is no depreciation of cost.  If I have $125,000.00 in operating expenditures this year then $125,000 in expenses shows up in the income statement.  Operating expenditures are not considered assets and companies routinely seek to minimize their cost and flatten their growth.  How do they do this? Well….one way is by investing in capital assets that can help increase productivity.  So if I invest in some custom workflow system that will reduce the number of FTEs ( full time employees ) I need by 10% then that’s a potential long term realized gain in operating expense reduction: a.k.a. more profit for shareholders. Capital expense accounting can seem like magic if you’ve never heard of it before.  But there’s a very real justification behind it. What is that?  Simply put: if you’re capital asset increases profits each year after it’s implemented then those profits should be offset each year by the cost to develop that asset. Fundamentally, capitalization of IT expenses is an immense part of why companies invest so much in new technology.  The accounting allows us to derive value from capital investments.  Yes, technology is wonderful, but if internally used software expenses weren’t capitalized you’d see IT budgets shrink drastically.

Estimating

Awesome.  So how does this relate to estimating the effort on a software project.  Remember this line from above: That means it can be purchased for a set price and has a useful life greater than 2 years?  A capital project is an investment or a series of investments.  Knowing the price up front each year creates two things:

  • The funds needed to purchase that investment.
  • The cost basis to use in constructing a model of investment return.

Each of these capital investments are compared against each other using a % return ( IRR ) or more commonly using NPV ( Net Present Value ).  Some are required and ‘must be done’.  But the rest are optional.  So leadership uses the projected investment return to determine which ones will benefit the company most.  That becomes a short list of capital projects to fund for the fiscal year. Now, when these projects are initially compared developers may have been involved in the estimation process or they may not have been.  But regardless the estimate is usually classified as a ROM ( Rough Order of Magnitude ).  Once the project is funded another round of more detailed estimating occurs with the development team for the strict purpose of validating the ROM.  If our detailed estimation shows we have inadequate funds then we need to make a decision:  cancel the project or increase the investment.  But if we increase the investment…how does that affect our return?  Should we do a different project instead?  You see where it’s going.   Estimation is a fundamental part of determining the capital project landscape.  It’s the basis for determining the initial and subsequent investment to achieve an estimated return.  Software is just a means to the real end: increasing organizational productivity.

Capital Budgeting Hasn’t Kept up With Agile Practices 

The astute among you will recognize how this financial model of capital budgeting doesn’t fit what you’re actually doing in agile software development.  Big shock…right?  Agile techniques are operational practices.  They aren’t financial, business practices.  Estimating each iteration using planning poker or whatever method has no applicability or affect on the overall investment.  Just because the development team boosted the number of story points in the release…doesn’t mean someone magically added more money.  Capital budgeting doesn’t take place every 2 weeks.  It’s usually an annual event in corporations, although some companies will extend their capital planning for longer horizons ( 2 or 3 years ).  Accounting is the architectural tool that builds business models.  It runs in annual and quarterly cycles.

But It’s Wasteful

Ok, so back to the top.  It may be fundamental to determining the annual capital project garden for XYZ Inc., but the estimates are usually inaccurate and they waste precious time in construction.  Regardless of method…capital projects rarely hit their exact mark.  This pushes many companies to see IT as a money pit to minimize.  Isn’t there a better way for determining our cost basis for capital projects?  Maybe one that doesn’t require us to estimate anything? Everything about capital budgeting is hard to change because it isn’t up to the company.  It’s regulated by FASB.  They define all these rules, and help to police them.  The government recognizes FASB’s standards in lawsuits and for that reason they have the affect of law.   Creative experimentation with accounting standards inside companies is something that people go to jail for. So change in accounting practices and standards is slow and carefully considered.  After all you’re monkeying with the monetary machinery of global industry.  There had better be a good reason for any change. So the next section proposes an idea for change to FASB’s capital budgeting rules.  Do NOT exercise this idea in your company.  There is no provision for this idea in FASB’s standards to my knowledge.  I offer it up simply for conversation and debate….not actual practice.

Relative Targets

When we’re looking at capital projects we need to know the expected revenue ( or savings ) generated by the project after completion and the expenses ( investment ).  Estimating, at least in IT land, deals mostly with the expense side. This is usually done in a very detailed fashion, but with relative targets I’m proposing we skip the estimation and just come up with a tolerance level.  How does it work?

1. Determine your expected revenues ( or savings ) if the project is implemented.

2. Determine your return thresholds.  There should be three.  You could do this with NPV or IRR.

  • The return you’d ideally like to get.
  • The worst return you’d tolerate ( yes it can be negative ).
  • The middle ground between these.

3.  Once you have these 3 thresholds you can then back calculate the capital requirements necessary to fulfill these return levels.  We’ll work through an example in a moment.  But here is the formula we’d use:

Formula to calculate investment for targeted NPV

C = NPV – R / ( 1 + r )

where

  • NPV = Targeted NPV
  • C = Investment required to reach targeted NPV
  • R = Revenue realized in each period
  • r = discount rate

4. Next you’d do a gut check.  Can we really do this project for anyone of the calculated capital thresholds identified?  If we can’t…then we shelve the project.  If we can then we would setup 3 tranches of capital per project correlating to the thresholds.  You’d start off by shooting for the ideal return scenario.  If that didn’t work…you’d make a decision to move on to the middle ground threshold or cancel the project and expense the loss.  The same would occur for the worst case return.

Example

So let’s say we have a project that we know will generate the following savings in years 1, 2 and 3.  Year 0 is our capital investment and what we’re trying to solve for.

Year             Cash Flow
0                 $???,???
1                  $200,000
2                  $300,000
3                  $200,000

Ok, so we know our estimated benefits from doing this project.  Now we need to figure our our three thresholds for year 0 capital funding.   Ideally we want to maximize our benefit.  So let’s say in consultation with the business we determine that these are our NPV thresholds:

  • The return you’d ideally like to get:  The most ideal return would be one that requires no investment at all and we receive the present value of the expected benefits – $580,015.02.  But this is unrealistic.  It does, however, give us an upper boundary to our ideal return.  So we’ll say that a more realistic ideal scenario is $400,000.00 in NPV.
  • The worst return you’d tolerate:  This could be negative.  Maybe you’re willing to lose money to get this software project completed. Good examples would be where there is a regulatory requirement associated with completing the project.  In this example we’ll say that the worst return we’re willing to tolerate is $100.000.00.  This is above zero, but shows that we’re looking for some monetary benefit.
  • The middle ground between these: I’ll just take the average between these two…..$250,000.00.

Great…now we just plug these values back into our formula to derive the initial maximum investment allowed to hit each threshold. We’ll use 10% as our discount rate.

Ideal Investment:

$400,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$180,015.02

This says that the most ideal return would require for our investment to not exceed $180,015.02.

Worst Case

$100,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$480,015.02.

This says that to achieve the worst investment return tolerable the investment must not exceed $480,015.02.

Middle Ground:

$250,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$330,015.02

Here we believe that to get a return of $250,000 we’ll need to make sure our investment does not exceed $330,015.02.

Now that we have our tolerances we can do a gut check and see how realistic it is to complete the project based on each level of funding:  $180,015.02, $330,015.02, and $480,015.02….or anywhere between them.

If our gut check tells us we can complete this project then we’d fund the tranches and start on the project.  If not then we’d drop this project altogether.

Summary

Relative targets take us out of the game of detailed estimating and instead push us to delivery within some tolerances.  This is a more natural way to manage a risky endeavour and affords us some built in cushion that everyone agrees is acceptable to the business’ needs.  We also pre-build fault tolerances, trigger points that force us to reflect on the project’s viability.  Here I suggest that there should be three of these tolerances, but there’s nothing preventing a company from setting up 4,5, or 10.

Central Spin – January 24 2012

Background on SPIN

The Software and Systems Process Improvement Network (SPIN) is a global organization, founded in 1991, of professionals dedicated to the improvement of software development and systems engineering. CentralSPIN, headquartered in St. Louis, Missouri, is the newest SPIN chapter.  CentralSPIN supports members from the Central US region, including St. Louis, Chicago, Dallas, Denver and Atlanta. The chapter is affiliated with the Software Engineering Institute at Carnegie Mellon University (www.sei.cmu.edu/spin) and is sponsored by Daugherty Business Solutions (www.daugherty.com).

CentralSPIN is the newest of 119 sister SPINs in cities across the U.S. and around the world. SPIN’s mission is to provide leading, practical, and timely content on various process improvement topics for the IT industry. The CentralSPIN organization serves as a source of educational and practical information for its members, other SPIN organizations and the general community of project managers, business analysts and software professionals. Membership is free and open to all. The goals of CentralSPIN are to:

1.     Enhance members’ knowledge and skills through an active program of networking, publication, recognition of excellence, and mutual support

2.     Help sustain organizational commitment to the improvement of software excellence, maturity, and system processes, with particular focus on enabling project management and business analysis capabilities.

If you plan on attending,  click here or use the Register link below.  Membership and attendance are free, so please feel free to forward this to anyone else that you think may be interested.

What Techniques Do You Use Most To Deliver?

The poll is multiple choice, and you can add your own too.

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.