In the second of my column articles in the run-up to the Software-Centric Systems Conference, I’d like to see if I can provoke a debate about Agile development methods. Before people start flaming me for holding controversial opinions, I’d like to remind you of what I said in the first article. #1: my goal here is to seed a discussion that will enlighten us all and, #2: caring about whether you think I’m right or wrong is on my f**k-it list.
Back in the 90s, my first company made a healthy profit doing outsourced, fixed-price, fixed-deliverable software projects for customers. These projects were of medium size, ie tens of man-years of effort. We were very successful, to the extent that the company was acquired in 2001 for an excellent price. Apart from being run by a top team, the key to the success of these projects was a thing called Earn Value Analysis (EVA). The way to think of EVA is that it’s like paying off a mortgage with a continuously changing interest rate. With such a mortgage, the key figure is the amount you still must pay. With EVA, it’s work (value) remaining.
A project run using EVA is based on estimating the amount of effort, in terms of money, that the project will take to complete. Once the customer signs a contract, this becomes the project’s value baseline. From that moment on, two primary KPIs are tracked: work done and work remaining. Work done is based on timesheets. Work remaining is based on periodically estimating how much effort it will take to complete the current work in progress. From this, one works out how much value has been earned. This can be compared to the baseline, giving an estimate to completion (time) and variance at completion (money). We found this method to be highly effective. Deviations from the baseline became rapidly apparent and were immediately discussed with the customer, which essentially led to a predictable business outcome for both parties.
While there are many things about Agile methods that I admire, when it comes to the subject of achieving predictable business outcomes, Agile and I are not friends. A leading expert in the subject of Agile published a list of its disadvantages, including: poor resource planning, no finite end and the difficulty of establishing KPIs. When I challenge Agile aficionados about these weaknesses, the response is usually a load of bollocks about software development being a creative process and impossible to estimate. Rubbish. I ran a very successful business that was based on making value-based planning estimates and taking risks – which is of course the subject at the heart of the matter.
I recently took part in my first Safe Planning Increment at one of my customers. At some point, the team’s attention turned to estimating the effort associated with each feature committed for the next PI. When I was asked to contribute to the planning, I pointed out that I was new to the team and had absolutely no idea what work would be involved with each feature. Apparently, this was no problem. Then I was told that effort estimates would be based on T-shirt sizes: XS, S, M, L, XL and XXL. And so we went through each feature, assigning it a T-shirt size, based on total guesswork – at least on my behalf. And this way of working is supposed to lead to a company delivering predictable results? Achieving a profit? Returning on shareholder value? I laugh out loud.
While I’ll agree that the waterfall project methodology tilted the software engineering process (unworkably) too far towards the needs of business managers, Agile tilts the balance too far towards the needs and risk-averse nature of engineers. What’s needed is a better balance between the two. Ultimately, the power of any process is based on belief. Currently, it’s fashionable to believe in the holy efficacy of Agile. But Agile is an emperor with new clothes.
Main picture credit: Koninklijke Bibliotheek, CC BY-SA 2.0