My previous article raised quite a stir
and did get a lot of feedback, so thanks to every one that reacted. Some of those reactions were positive, some were not. But some of those made me realize that my message may not have been clear enough, so I will start by rephrasing it before moving on. When I say that Agile is failing, I mean that the current Agile hype will lead to a great hangover, the kind of hangover that could simply put Agile in the history books as yet another failed attempt to improve projects, next to RUP and others.
The signs are here: a lot of articles attempt to find the cause in non motivated developers, incompetent middle managers, hostile management, consultant selling scrum as the 21st century snake oil, locusts…
I mean, the end is nigh OK, but maybe no locusts yet..
In any case, I do not buy into these; I am not saying they are false either, but they can’t see the forest for the trees! In an era of continuous improvement, most organisations are able to address this symptoms. That is, assuming they are in a position to identify them. Otherwise, they will just see that Agile fails and be done with it. Alternatively, they will tolerate Agile if the team can establish a roadmap as well as an overall architecture design that can be reviewed and challenged. In the long run, this implies a slow death of Agile, turned into ‘Scrummerfall’.
I know that some of the radical agilists have said: we just need to beat them at their own game and be done with those who can’t adapt. This sounds both cynical and naive as a vision. Economy does not exactly works this way, Agile methods are tools in the toolbox, nice, flexible and efficient, but they are tools!
So how to survive the fad phase?
By keeping on delivering, which implies fighting off pseudo agile, but also by augmenting agile methods so they can be actionable at a higher level.
With ‘plan based’ project methodologies, the plan is a strong steering tool to ensure the project matches the enterprise strategy, and tracking progress on the plan is sufficient to control that.
But agile methodologies starts with a set of goals and a scope, maybe a bunch of user stories, nothing really tractable at a higher level. And when the project starts, the ad hoc reporting format used is not appropriate for dissemination. At that, at a strategic level, the project is more or less opaque so not really controllable. The main, if not single, link between the project and the strategy is the product owner.
We need to make sure that actionable information can flow from the project to the strategic view. Vice versa, we need also to have a clear view of the enterprise strategy at the project level too, so that the team can position itself into this strategy.
Of course, for small/simple structure, this is probably the de facto situation, but for larger organisations, tools must be identified.
That being said, all contributions are welcomed, and I definitely think Impact Mapping shows us the way.