By any measure we find that Agile can be more productive in software development (see, for example, the latest ISBSG Report), but some conversations I’ve had recently make me realise that businesses only get out of Agile what they put in.
Continual “fail fast” can be a recipe for ever-decreasing circles leading nowhere – i.e. total failure.
The concept of “fail fast” is touted by many authorities as one of the strengths of Agile. One can see that this concept works fine in a controlled environment, but taken to extremes, fail fast just becomes fail. I was recently asked to look at a major programme where Agile techniques were used and yet value-for-money improvements hadn’t materialised. The client wanted to know the delivered size of the final application, and it was large (a little fewer than 3,000 function points). They compared that with the cost and were horrified – costs were no better than Waterfall. That’s why we were called in. We looked at the whole picture and the developed size turned out to be approximately 7,500 function points. They discarded fully 60 percent of what had been developed. They failed fast all right, they just didn’t learn fast.
If you’re throwing away more than you keep, maybe you don’t know where your business is going.
In Agile you still need to know what you are planning to deliver.
A development company asked us to train their staff in functional sizing to assist with estimating and measurement of value. It is an Agile shop with two-week time-boxed developments. We trained the staff and then they tried to apply their knowledge at the planning stage, only to find that in many cases the input documents weren’t fit for purpose. Basically, time-boxed planning was a guess. The client was happy with the outcome of our analysis, as it made them tighten up their backlog grooming processes.
Time-boxed development works best when you don’t waste time working out what you’re supposed to be delivering.
If you don’t own your business product, you take what you’re given.
Another client has had difficulty with getting engaged, empowered business owners, so even though they use Agile techniques, and produce working software, the result is often greeted by the business with disappointment. “Well, it’s nearly what I wanted,” or “That’s not what I wanted at all,” are all too common refrains.
If you throw unclear ideas over the wall and avoid your responsibilities, you won’t get fit-for-purpose software, and the value that Agile brings is, at best, diluted.
Vision, communication and engagement are key.
Enterprises need at least a broad vision of what their business will look like when the developers have delivered their system. Effective prioritisation and refinement of the product backlog enables key components to be delivered and change to be absorbed.
Developers should be empowered to say, “No, we will not start this work because we don’t know what we’re being asked for.”
Clients who commission work have to stay engaged. Their business representatives in the team must be empowered, and the commissioning manager must accept responsibility for what happens if they don’t or they won’t remain engaged.
So, know what you want your business to look like, manage and groom your product backlog, don’t expect developers to start work until you can see where you’re going, and remain engaged and responsive throughout the process.
Garbage in, garbage out hasn’t gone away. With Agile, you just get it more quickly.
Managing Director, DCG-SMS