Thoughts on Agile (Part 1): Fear and Loathing
Like a lot of software developers and architects, I have been working with Agile for much of my career, and while there are many things I love about it, there have also been times when I have felt like burying the next person within earshot who utters the phrase “that’s not Agile”. Whether you consider Agile simply a passing fad, another software buzzword or the solution to the Software Crisis, one thing we can be sure of is it is here to stay (at least for now).
After much rumination I have come to realize that my love-hate relationship with Agile has nothing to do with anything it actually espouses, but more with how people choose to interpret it. I am hoping that this short series of blog posts will help me clarify things in my own head and maybe give others some pause for thought.
The Rise…
To understand my approach towards Agile one first needs to understand a little about its background. While the Agile Manifesto was codified in 2001, one could argue that the spiritual birthplace of Agile (at least as a concept) was actually the early days of the Toyota car company. It was between 1948 and 1975 that the Toyota Production System was developed by Taiichi Ohno and Eiji Toyoda, and it was from their work that other techniques were developed and pioneered such as Lean Manufacturing, Kanban, Kaizen and Just-in-time (JIT); these methodologies were used in response to the gross inefficiencies seen in the Toyota manufacturing process, when compared to the contemporary mass production methods of the American car industry. By building on well-established American manufacturing workflows, Toyota was able to enhance them by adding their own ideas for flexibility and self-correction.
Standing back for a second, it is easy to see the parallels between mid-20th century manufacturing and early-21st century software development: in the years leading up to the Agile Manifesto there was a wave of new development systems popping up every few years as part of the backlash against traditional Waterfall-oriented methods, all of which had their share of pros and cons (Unified Process, Scrum, Extreme Programming, etc).
The driving force behind this backlash was an attempt to move away from the rigidity and poor quality that seemed to be characteristic of previous software development styles. If the car industry could build consistently reliable and cost-effective products with bare metal and blowtorches, then why could not the same level of efficiency be achieved when the only material being hewn was computer code? When the Manifesto was eventually published, with the business-savvy surtitle of “Agile”, the software community finally had a lean set of principles that everyone could agree upon; be they developer, architect, manager or stakeholder. It was this universality that was Agile’s great strength but also its greatest vulnerability.
…and Fall…
Unfortunately, as soon as a significant number of people begin to believe that the amazing new <insert-buzzword-here> technique/methodology is what they should all be using, then it is only a matter of time before confusion sets in over what <insert-buzzword-here> actually means. This is especially true if it encompasses practitioners across multiple disciplines with different traditions, expertise and jargon. As with any other form of engineering, there is no “silver bullet” to solve all problems; in each case a team must exercise judgement and caution in order to tailor their process to best fit their project, knowledge and skillset. This may well involve taking an à la carte approach in order to create a hybrid system of techniques.
Agile can (and has) fallen victim to the same ailments that plague any number of philosophies (engineering or otherwise), namely:
- Hi-jacking by people who use its roughly-understood principles as a mantra to push forward their own agenda
- Resigned acceptance of these secondary interpretations by the less-informed and credulous masses, and
- Overly zealous adherence to the (real or made-up) letter of the doctrine over and above all other priorities.
…and Redemption?
There are occasions when the mantle of Agile does get used either as an excuse to not think ahead or as a reason to avoid contingency planning (or any type of planning at all). A certain cross-section of the software development community seems to have an intrinsic fear of not being seen to be coding from T=0, as if stepping back and thinking about a problem for any amount of time is nothing short of wasteful. The misunderstanding surrounding Agile gives them the perfect excuse to indulge such fears.
The worst offenders are those who think that, as long as they are acting in a way that they would consider agile, then somehow they are doing Agile development. This, for me, is the single biggest problem with Agile: the fact that so many seem think that they need not read beyond the name to grasp its concepts. Agile is not simply a management-approved way of squeezing more man-hours out of your development staff, it is a rich and nuanced collection of ideas that extends way beyond how software can be created. Ideas that I look forward to fleshing out a bit more in Part 2.