Before you turn off, I realise that the term “agile” in the context of software development has been overused to death. My aim is not to write a buzzword-compliant essay. Rather, having endured many projects run under the misapprehensions of outmoded assumptions and having endeavoured to get the best out of so-called “agile” approaches to software development, I feel I have a worthwhile perspective to offer.
I think the crux of discussing “agile” is to acknowledge the differing points of view of the developer and the customer. This may seem obvious but, in my view, it’s a crucial point.
As a developer, I’ve had a lot of time to reflect upon shortcomings of the more traditional approach to building software. I well remember attending in-house courses on “Requirements, Planning and Estimating” and “Project Management” at IBM, early in my career, in the mid-80s. At the time there was much emphasis on documentation. The requirements, the external design and the internal design all had to be documented and formally approved before one line of code was written.
To be fair, in some cases, projects were divided into stages but, by and large, my experience of project management in the 1980s and 1990s was dominated by the waterfall model. The idea of iterative development had yet to hit the mainstream.
Central to the problems of the waterfall model is the difficulty in estimating accurately when grappling with initial requirements and designing an application. Usually, throughout the course of a software development project, understanding of requirements and design changes significantly. So it is very unlikely that an accurate estimate can be given at the outset. No doubt this is why estimation games have been well practiced in the software industry.
As described in Jonathan Rasmusson’s excellent book, The Agile Samurai, all projects are bound by four variables: Time, Budget, Quality and Scope. The problem with basing a software development project on the waterfall model is that this often leads to an expectation that all four variables will be fixed. Given the inherent difficulty in accurate software project estimation, this is obviously unrealistic.
The agile approach addresses these problems by treating scope as the only variable and delivering software in frequent iterations. As shown in Extreme Programming Release Planning, which I first experienced about ten years ago, requirements are broken up into “user stories”, each of which is estimated and prioritised.
A key point is the unit of estimation. In the agile approach, it is not a measurement of actual work hours which may be translated into a monetary amount. In original XP planning, the unit was an ideal week. The name of the unit may be arbitrary. It doesn’t matter what you call it. What really matters is that each user story is estimated relative to others. This enables allocation of user stories to releases more accurately as the developers discover roughly how many units they can complete in each iteration. Also, since iterations are kept small in duration, user feedback allows timely modification and exploration of user stories that will comprise subsequent iterations.
All the elements of agile planning make sense to me as a developer. However, a customer, not necessarily used to software development, may be less easily persuaded.
As a customer, speaking generally, I expect value for money. For most goods and services I am used to having a fixed-price quotation honoured for clearly agreed specifications.
Why should I expect any different for software development? If I ask how much it will cost for a specific software application to be built, why should I not expect the supplier to let me know in advance?
What’s this talk about estimating requirements in terms of arbitrary points? And what’s this I hear about pair programming Do you seriously expect me to pay for two developers working on the same piece of code at the same time?
At this point I should emphasise that I am trying to think of various customers that I have dealt with over the years and put myself in their shoes. As I do that I am reminded that these customers have had various degrees of acquaintance with the complexities of developing software. I think that this gets to the heart of the matter. As a customer, if there is a good reason why I should not expect a fixed-price quotation then the developer must be able to explain that reason clearly to me.
After all, the customer is paying the bills. Any argument for embracing an agile approach must be compelling in monetary terms.
When we consider the agile approach to software development, I think it is clear that there is a gap between what proponents see as benefits of this approach and the expectations of many customers.
If you’re still with me, you may be expecting that at this point I will reveal my brilliant answer to the conundrum. I am sorry to disappoint you. If there was a brilliant answer I am sure someone else would have capitalised on it before now. Obviously, it is critical for an agile software developer to clearly describe to their customer at the very beginning of an engagement what to expect. As with so much in life, setting expectations is crucial. It is a lesson I need to keep reminding myself.
Every customer is different. Every relationship will differ. And relationships change over time. I forget where I read it, but the essence of the quote was that “in a good agile relationship, trust improves with every iteration”. I like the spirit of that statement.
It is also important to allow your approach to evolve. As Ben Webster said recently, “embracing as many mistakes as possible on the job” is a useful resource as an agile practitioner.
To borrow from The Mythical Man-Month by Fred Brooks, there is no silver bullet. Making the most of the agile approach to software development requires an individual response. If you would like to share elements of yours, I look forward to your comments.
Previous post: Maintaining a Legacy Rails App
More recently: Committed Stand-Ups
© 2024 Keith Pitty, all rights reserved.