I recently had an interesting discussion in the office about why Agile fails - or more specifically - differing views of Agile, its pitfalls and successes, and thought I would take the chance to articulate mine. Let me know if you agree (or not).
Because Agile adoption has increased so rapidly, it seems that more failures than successes have been documented. It has seemingly resulted in Agile becoming a dirty word in our industry.
But, before this adoption becomes just another piece of discarded history, I think it's important to understand why Agile fails. At the same time, perhaps the opportunity exists to reverse the view that Agile is just a fad that will ultimately become yesterday's news, says Murray Silber, Senior Consultant at Ovations.
Before we start the discussion, a critical question to consider is: Do we 'really' know what Agile is?
Agile can be defined in countless ways, but for the purpose of this discussion, I have used the principles of the Agile Manifesto as my point of reference.
Many organisations fall into the trap of thinking that Agile is something that IT departments do, because hey, "isn't it related to software development?"
Implementing an Agile approach demands the commitment of the entire organisation. Both business and IT jointly share the responsibility of delivering solutions that will enable their competitive capacity.
It starts with a move from 'me' to 'we'
Similar to a new marriage, the transition from 'me' to 'we' can be quite difficult. Often there is a resistance within the organisation from individuals who are concerned about the effects of Agile on their 'personal brand'.
Fear of change and the uncertainty of their place in the new world often drive the individual to make Agile a political issue. In my experience, this originates in one or two places - either with the product owner, who feels that the Agile process will mean that development teams need to invest more time than they ordinarily would, leaving little time for their customers (this is not the case). The second instance sits with the development teams, who don't really understand Agile, and feel they are being pressurised to estimate time to complete a piece of work, without knowing what they are supposed to do.
The result? Mistrust created between business and IT
Guidelines for incentives such as annual bonuses, pay increases and promotions, are typically geared towards task-driven delivery by the individual, which is in conflict with the notion of delivering value as a team, which Agile typically brings. An individual who is unhappy with a smaller annual bonus than expected, even while delivering value, might attempt to ensure his tasks take precedence over the needs of the team.
Beyond the individual, within the organisation, the business is nervous of sharing the risk of delivery with IT, particularly if IT does not have a sterling record. Without the commitment from the business, which typically results in no clear product owners, Agile will fail.
Are we doing it right?
Contrary to what we typically hear - where the buzzwords and stories of rampant success drive us to implement an agile method such as Scrum, because it's 'easy' - Agile is difficult to put into practice.
Organisations might be burning because their methodology is not working, and just like each of us with our new year's resolutions, we implement our new method with zeal and soon realise that it's not that easy to do properly. What happens then? We 'leave something out', because 'it's easier that way'.
Can we reverse the trend?
Can we reverse the growing chorus blaming Agile for their failures? I am not sure. How do we take the 'fad' out of Agile? Proper education of all stakeholders is a start.
Trying to put a square peg in a round hole is not going to work - Agile is not a 'one size fits all' approach. We need to start being pragmatic about its application and we need to do this soon.
Share