February 10, 2014
Every movement needs an enemy, it galvanises followers, gives a community a sense of some shared identity. Even if Group A aspire to nothing more than to not be like Group B that is at least something to rally around.
“The Waterfall” is increasingly becoming an Alamo for those who aren’t or don’t want to be convinced by talk of “Agile”.
For the Agile community the designated enemy seems to be “The Waterfall Model” and the command and control project management techniques that usually go hand in hand with it.
The anti-waterfall rhetoric from the agile community has been so strong and so consistent that it has created a backlash. “The Waterfall” is increasingly becoming an Alamo for those who aren’t or don’t want to be convinced by talk of “Agile”.
While the Agilistas and Waterfallers slug it out, there is a third way quietly going about it’s business. “The Happy Path Model” is the most popular software development model in history and still by some margin the most widely used.
“The Happy Path Model” is the most popular software development model in history and still by some margin the most widely used.
Adherents of the happy path are eternal optimists. This time it will be different. Requirements are solid, or at worst there will be minor issues that need clarification. Input data will always be clean, complete and easy to work with. No other priorities will get in the way, and even if they do, that’s why we build in contingency time.
Happy path thinking infects every aspect of a project. Project managers will often start with an end date in mind, simply because someone asked for delivery by that date, and regardless of the scope of the project, that date typically remains, chiselled into a gantt chart, because … happy path.
Developers will be asked for estimates and they will underestimate, because … happy path.
Managers will interpret estimates as commitments, because … happy path.
Even as developers realise they are unlikely to hit milestones, they will remain quiet, convinced they can close the gap, because … happy path.
Managers and developers will both allow the scope of the project to increase, or may actually drive the increase, because … happy path.
Happy path thinking infects every aspect of a project.
It goes deeper, to the very core of the product. Happy path thinking results in inadequate exception handling, logging, and even testing. It can result in entire usage scenarios being missed. The result is often brittle, code that is unfit for purpose and difficult if not impossible to maintain and enhance.
Deployment may be a manual process, but why bother automating it? On the happy path it will never go wrong.
Testing may be manual, but why bother automating any of it? On the happy path limited regression testing is all you need, nothing major will ever break.
To even consider Continuous Integration, Automated Build and Deployment, Automated testing, Environment Provisioning, etc is to allow ones mind to turn to the dark side, where manual mistakes are made and things go wrong and people have to work late. A place where features that used to work can break because some unrelated piece of code changed.
These people are not to be trusted, they are typically less productive than developers who get their head down and code the happy path. This academic “agile” bullshit is all fine for hippies in California, but here in the real world we have software to deliver, and the happy path is the path we follow.
Agility is simply the ability to stray from the happy path with confidence.
When stakeholders realise (as they inevitably do) that the happy path isn’t delivering what they actually need, they begin asking for changes. Any change, even a minor change strikes at the very heart of the happy path philosophy. Such requests can create enormous friction between the stakeholders and the development team.
I once worked on a project where a user came asking for a tiny utility that would dramatically reduce some manual work. It was a single form lookup utility, it was read only. It took less than an hour to build and validate. We were not allowed to release it because it was not part of the original specification of the system. Significantly more time was spent arguing to keep this tool out of production that would have been needed to build, validate and deploy it.
Agile teams embrace these practices not because they are how you DO agile, but because they provide the time and space to BE agile.
The reality is that “Agile” is not “Anti-Waterfall”, “Agile” is “Anti-Happy Path”. Agile is about recognising that at the start of a project we are at our moment of maximum ignorance. It’s about embracing the fact that the act of developing software shines a light into the domain and uncovers hidden corners and edges. It’s about realising that trips off the happy path aren’t exceptions, the happy path is the exception.
Agile promotes practices like Continuous Integration, Automated Build and Deployment, Automated Testing, the ability to spin up and destroy environments quickly and reliably. Many believe that these practices are the point of agile. “Doing” these things means you are “Doing” agile. This is a completely backward view of agile.
Agile teams embrace these practices not because they are how you DO agile, but because they provide the time and space to BE agile. Agility is simply the ability to stray from the happy path with confidence.