This post, Does Agile Need Its Own Process Maturity Model caught my attention. Now there's nothing wrong with the article or some of the concepts, but I feel compelled to throw in my two cents on maturity models in general and especially applied to agile software development.
In general, I've only seen maturity models used in one way - to sell enterprise executives either software or services. They sell expertise in a simple one page diagram and essentially say, pay me to develop your process. As far as maturing practices or educating teams, these tools are usually useless.
Bottom line, if you want to mature a process then roll up the sleeves, learn your organization, recognize what process improvements are needed to meet business goals, set process goals and align your teams to improvement. This is especially true with agile practices since the choice of what processes to establish and areas to mature needs to fit a business need and priority and these improvements can be managed through the scrum process.
Now the evolution described is reasonable; (1) Core Agile Development (2) Disciplined Agile Deliver (3) Agility at Scale - but what is called "core", "disciplined" and at what "scale" is going to differ by organization.
Here's an example. I know one development team in an enterprise that's perfectly happy managing their backlog in a web accessible spreadsheet. Their team is in one location and they are largely working with independent development teams. They will be the first to admit that a spreadsheet is not sufficient, but it's good enough given their size, location, and process. Now one day they may have greater needs; they may have to make stories more verbose, or perhaps they need better story tagging or metrics capture. It's at that time they can write a story "Identify tool options for agile project management" with acceptance criteria based on their needs. This can be followed with additional stories "Develop POC with tool X" and later "Rollout tool X".
My advice: Keep it simple, and build process maturity (agile, software delivery...) into an agile process.
The one quote that jumped out and caught my eye. Was "In general, I've only seen maturity models used in one way - to sell enterprise executives either software or services."
ReplyDeleteso very very true... And this works especially well when the goal by those same executives is to spend money!!
- Doug
http://doug-shimp.net
The concept of model use is largely misunderstood, maligned, and mis-used. The worst case is the "sales technique" mentioned -- a truely horrible example.
ReplyDeleteModels are different. They have a specific value and appropriate use over and above methods and techniques. Models are used for comparisons.
We all do this every day -- use models for comparison -- in a wide variety of different ways and the internal models we use are constantly evolving.
Structured models are especially useful in evaluating products or services from vendors. When all suppliers are assessed by an accredited outside source based on the same model, some idea of their relative capability is achieved.
Are models perfect?
No.
Are they better than nothing?
In some cases, Yes. Especially in organizations dependent on accurate vendor assessments for the majority of their acquistion and development efforts. The use of models allows a structured way to narrow the field.
Any other use is simply mis-use.