The Agile Misunderstanding
Let me start with this: Agile as commonly understood isn’t agile.
Huh? Yep. The Manifesto was written by well-intentioned folks who couldn’t have realised how it would be interpreted. It’s easy to see why there’s a misunderstanding given the phrasing which tends to focus folks on the frequent delivery of working software. It naturally leads to a mindset of “Right, lets start doing sprints and ship software quickly and we’re Agile.” Less attention is paid to other elements such as “valuable” or “people over process”.
Before going further we need to review some basic software dynamics.
From left to right:
- The risk of problems post release increases with prior development time because untried code piles up. Problems can be bugs but also other things including worthless functionality (customers don’t always like what they get).
- Investment in a release rises over time. You’re paying for your team and assets they consume (software licenses, servers, electricity etc) for starters.
- Software degrades over time. There’s technical debt certainly but also technology becomes out of date thus unsupported, skills and knowledge of the codebase are lost etc. This increases the complexity of software delivery and likelihood of error.
These dynamics drive us to do short iterations. Delivering software is inherently risky, there’s no way to avoid it, so the sensible thing to do is limit the size of impact when we get it wrong. Crucially, we also need to learn from our mistakes and this is where it gets tricky.
We tend to confine our identification and analysis of mistakes to the software delivery elements alone, rarely looking further upstream. Instead we attribute the root cause(s) to execution of the process or miss the culprit entirely. This is fatal as it rules out isolating and eliminating key impediments such as:
- Management and leadership failings such as too much distance from ground truth or poor performance management practice.
- Organisational impediments such as communications, recruitment, budgeting, audit processes and structure.
- Errors in requirements handling and market understanding.
- Poor strategic planning discipline. Projects for example tend to be rarely reviewed, fixed long-term commitments with unchanging plans and budget.
Delivering software involves the whole organisation. It must learn and adapt in its entirety if it is to truly master the software dynamics covered above.
Wait, I hear you cry, what about all the success stories where software was delivered faster etc? There is no doubt adopting Agile basics and principles such as continuous testing can deliver improvement. They can bring greater discipline and help tune away some of the simpler inefficiencies. The result will be faster delivery but there’s a ceiling one cannot surpass like that. Efficiency is not the same as effectiveness. You can deliver software quickly but is it the right stuff, is it valuable?
Value is not profit. It’s many things including customer happiness, brand loyalty, motivated employees and organisation longevity. Profit is a consequence of an organisation’s effectiveness in achieving these other things not it’s speed.
Effective organisations learn and adapt in response to the results of their actions. Enabling that requires a mindset of continuous experimentation and change across the entire organisation going far beyond mere improvement of local process which is so often the motivation for Agile adoption as commonly understood.
Bruce Lee said: ”Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back.”
So it is with Agile. We must drop that name, stop confining ourselves to its common interpretation and seek to grasp the essence of what we’re doing. An ongoing effort of learning and adaption.
[A few days after I wrote this, Mary Poppendieck published The End of Enterprise IT. The article provides a great example of the kinds of change that must be wrought to make an organisation perform better.]