Tag Archives: software architecture

The Root Cause of Water-Scrum-Fall

Posted on by
5

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.

Advertisement

Central Spin – January 24 2012

Posted on by
2

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.

Old Houses

Posted on by
Reply

Legacy software, in some ways, is like an old house. There are features that one might consider defects, errors or poorly implemented designs. A badly hung door. A sink in the wrong spot. Not enough outlets in a room. But the inhabitants adapt, cope and even harness utility out of the malfunction.

They implement patches, fixes, and add-ons to address the *issues*. But they never truly fix all of it. Instead they run more extension cords, tighten the hinges every month, or modify their behavior for washing, cooking or cleaning. They work with the old house, and the legacy software….accepting it as incomplete and adequate enough. A sort of perfection in imperfection.

Just as with software, houses have features that are too costly to fix, too embedded within the culture to remove, and too risky to replace. Is this acceptance of mediocrity or recognition of reality?

The plateau of legacy software is marked by this adaptation and acceptance of what is. There is no more striving for a better, greater product; there is just a kinship with the present. The power user rules this lifecycle. He or she knows the tricks, short cuts, bugs-but-also-features, and data rules of the product. They become one with the development team and a common bond forms.

Old software is the stock of the enterprise IT shop. Reliable, if only because we know how it doesn’t work. Dependable, if only because we know how and when it will fail. Usable, if only because we’ve learned to accept its flaws.

What Techniques Do You Use Most To Deliver?

Posted on by
Reply

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

Software Feature Dilution

Posted on by
Reply

Introduction

Business analysts, requirements managers, and project managers will find the greatest interest in this article.

Software Product Planning

It occurred to me last week during one of our weekly iteration planning sessions that one of the most esoteric methods around product planning is deciding which requirements to turn into software features.  The more rigorous approaches look at the cost of the feature, the potential impact to ROI ( assuming there is one ), and the demand.

What’s wrong with this approach is that it considers the features and resulting requirements in isolation from one another.  By not considering how each new feature affects the existing product as a whole teams can and do end up with products in which the original feature set, that made the software successful, become diluted.  Those of you who’ve worked with me know my favorite example is CA’s Remedy product, but I think one could find other examples: the Microsoft Office suite of products may be in this camp.

Feature Dilution:  A Formula

So how would one go about constructing a measurement for feature dilution?  First – some assumptions:

  • You know or can retrieve the cost associated with the original marketable software release.
  • You know or can calculate the benefit ( ROI ) for the original marketable software release.
  • You have an estimated cost and benefit associated with any potential new software features.

Ok, so knowing these let’s construct a model for software feature dilution.  We’ll adapt a formula from the world of finance.

V – Value of sofware after Feature dilution =

((O x OP) +(N x (∑ IP1, IP2….IPn))) / (O + N)

where…….

O = original number of features

OP = Current NPV of product ( could use ROI too )

N = number of new features to be added

IP1, IP2, IPn = NPV of each new feature.

If you run this formula through some examples in time what you’ll find is that as a product matures new features need to continually generate greater returns to justify value to the original product and ultimately diluting the existing feature set.

This is exactly what should happen if we want to avoid the fate of an overly complex and unmanageable software product.  Just like stock market share dilution the product management team needs to justify that further feature dilution will grow the value of the product in terms of existing functionality…..not just that it will add to revenue.

Summary

Simplicity in software design has always been something great software architects knew yielded great products.  With this formula I hope I have provided at least a start to measuring simplicity in software.