Mike Cohn posted recently about "Deciding What Kind of Projects Are Most Suited For Agile". In that post he writes,
In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them.
I've seen statements very much like this for a number of years now. Others have been more focused on the project management quadrants:
Depending on where your project lies in this map, you may select a different project management approach to delivering the solution:
This suggests a very nice, even distribution of projects among the 4 quadrants. That, of course, is complete and utter crap! I've been building software professionally since 1988. In that time I have yet to see a project that truly fits the Linear (i.e. serial, phased Waterfall) approach. I'm sure those exist somewhere in nature, but they're exceedingly rare.
Perhaps it has just been my personal experience, but I've found that in reality most projects have been much further down the Uncertainty axis than most people thought. Even rewrites of existing systems where we've been told "the old system IS the requirements!" contain uncertainty, and almost always have higher complexity owing to changes of language or platform.
I haven't yet mentioned Mike's 3rd criterion: urgency. So, um, has anyone ever worked on a project where there wasn't pressure to deliver? Seriously.
Mike goes on to state later in his post,
The only missing variable that can preclude using an Agile approach is the one with the greatest impact - People. If the people involved aren't interested in transparency, visibility, accountability, collaboration and soliciting and acting upon feedback, then an Agile approach will not work. In those cases, any approach will find itself challenged because the issue isn't the approach but rather the people using it. What Agile will do in those circumstances is make the pain of the dysfunction tangible and acute.
What separates good people and organizations from the rest is how they act on reducing the pain.
Perhaps it has just been my personal experience, but I've found that in reality most projects have been much further down the Uncertainty axis than most people thought. Even rewrites of existing systems where we've been told "the old system IS the requirements!" contain uncertainty, and almost always have higher complexity owing to changes of language or platform.
I haven't yet mentioned Mike's 3rd criterion: urgency. So, um, has anyone ever worked on a project where there wasn't pressure to deliver? Seriously.
Mike goes on to state later in his post,
So let’s see how these three factors–urgency, complexity, and novelty–mix on various projects, starting of course with software projects. There couldn’t be a better fit. Software projects are notoriously complex. Each software project is largely a new endeavor. And in today’s world, there is almost always a sense of urgency.Absolutely. Agile approaches can be applied easily to 3 of the 4 quadrants above.
The only missing variable that can preclude using an Agile approach is the one with the greatest impact - People. If the people involved aren't interested in transparency, visibility, accountability, collaboration and soliciting and acting upon feedback, then an Agile approach will not work. In those cases, any approach will find itself challenged because the issue isn't the approach but rather the people using it. What Agile will do in those circumstances is make the pain of the dysfunction tangible and acute.
What separates good people and organizations from the rest is how they act on reducing the pain.
Comments