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.
Related articles
- Why Agile is failing (dupdob.wordpress.com)
- Agile is a business thing – not just an IT thing (nofluffjuststuff.com)
- Agile Maturity – How agile is your organization? (blogs.atlassian.com)
Many Cores 
So this is the next article 🙂
By the way, I am not naive. I have already work on more than a dozen projects in a dozen big clients. I know well the problems at the tree (project) level.
I am not an Agile methodologies (and really not for Scrum). I am worse .. I believe in Lean Startup and Design Thinking 😉
http://hbr.org/2013/05/why-the-lean-start-up-changes-everything/ar/1
I am strong believer that a company of the 21st century should learn and adapt fast because they can be attacked from many points.
http://www.technologyreview.com/view/519226/technology-is-wiping-out-companies-faster-than-ever/
http://www.businessweek.com/chapter/degeus.htm
Now some direct responses:
“In an era of continuous improvement, most organizations” have a lot of difficulties to learn and adapt.
“current Agile hype will lead to a great hangover”
Sure because so many avoid the principle to turn their projects into ‘Scrummerfall’. I have worked in one of the first Scrum project of a big French Investment Bank (yeah you know it 😉 ). Scrum methodologies, no principles applied.
“With ‘plan based’ project methodologies”
Ah plans, the best things to lessen the fear of the unknown, hoping that nothing will change. Like martial art’s kata doesn’t even survive the first street battle.
Plans are great to give you a strategic level map but you have to know it’s not the reality and it must be possible to throw them fast.
“No Plan Survives First Contact With Customers”
http://steveblank.com/2010/04/08/no-plan-survives-first-contact-with-customers-%E2%80%93-business-plans-versus-business-models/
Now to answer you quest of tools:
“We need to make sure that actionable information can flow from the project to the strategic view.”
Impact Mapping, Kanban from Portfolio management to project management
But you have also:
Ethnology to really understand your users
Service Blueprint to create a great shared vision of all contact points with the customer
Lean Canvas to create a vision, to know what value you’re creating and for who at the product level (yeah stop doing project)
Automatised BDD (Given/When/Then stories) to make a shared understanding with functional teams and make this specification by example a real functional testing harness
Create a great but simple model representation of the business with DDD principles/tools.
Don’t make you team surpass 80% of utilisation and use the 20% to respond to change, learn and make improvement on them, the team, the project.
By the way, the fact to do not go over 80% of utilisation of your “ressources” comes from an Operation Management course (not really the hippies from Agile).
I stop here but if you want check my presentation here (in french) and I you want I can do a BBL around it 😉
LikeLike
Hi I’m a bit late to the party…well here my little contribution 🙂
Agile is failing when…
– it is brutally forced by top management upon a population of developpers who don’t know and clients who don’t care. Change management curve would be something like 1 year of tactical coaching and the next year 100% of agile projects (in a 50% turnover environment…clients included !). Change that doesn’t manage to leverage on inner motivation (e.g at least a use case) and that doesn’t consider time to grow on people just doesn’t happen. Hint : when “agile control” budget replaces “agile coaching” budget this is not a good sign.
– deployed within an inexperienced team, e.g team with too many inexperienced developpers or that has not yet began to “jelly” (as Tom DeMarco would’ve said). Agile requires a team with maturity and skills far above average. Human skills (capacity to interact, open oneself and consider failure as a way to improve), Technical skills (capacity to take risks, anticipate issues and switch seats), client management skills and at last self-imposed discipline. Agile lightens the overarching structure to go faster, meaning team members should already be able to do their “standard” job blindfold, with an excellent grasp of IT constraints and client expectations.
– it is implemented in very chaotic organisations. Internal competition or lack of strategy (or perceived strategy) just calls for agile failure : by removing existing constraints and boundaries, highest-skilled PM will row for themselves only (diminution of cooperation) and lowest-skilled PM will get lost (lack of guidance and ultimately of motivation)
– agile becomes a religion. This seems obvious but honestly most coaches I know behave that way. Being IT at heart, they quickly loose client interest (and fellow developpers shortly after)
When I take step back I just wonder if Agile can be implemented successfully in big structure. Since dawn of time successful and creative companies (or civilisations…) have inflated until they became bloated and incapable of adapting. This is almost like a full lifecycle…the question is : at what phase of the company lifecycle did you land ?
LikeLike