Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. I wrote a short spiel on Agile some time ago in an effort to clarify how I see it.
For quite a while I have been observing some interesting posts and discussions going on LinkedIn.
One of the topics that I recently noticed was Agile failing organisations. If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation, as we might understand and critique the failure of any other tool the organisation might use. A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just so you know, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can't think of at least three different interpretations of what you have received, you haven't really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”
When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
- We don’t know enough about Agile and we tried to “do Agile” rather than “be Agile”.
- We thought we knew about Agile and we implemented it the way we knew it. What we did didn’t work..
- We thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. We couldn’t deliver anything..
In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile (mindset) adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.
So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.
* The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully (https://www.amazon.com/gp/product/0932633013?ie=UTF8&tag=practhis-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633013)
Acknowledgements: Thanks to Paul Szymkowiak and Jari Laakso for their feedback and recommendations.