Friday, March 12, 2010

Keep your stinkin' Maturity Model - prescriptive vs. adaptive

I keep seeing the same question appear in many forums lately- "How do we create a CMMi-like Maturity Model for Agile?" Sometimes this is a global question for the community, sometimes it is a question focused on a specific organization.

A couple of thoughts:
  • Not all problems can be solved by the same solution
  • Not all teams have the same problem
  • Not all teams have the same dynamic and ability to change
  • Thus, not all teams will succeed with the same set of instructions
  • But, all teams can be aided by an experienced mentor/coach
Whenever I hear of Maturity Models, I foresee an environment where the desired process is documented and stable, and the steps to evolving to it are prescriptive, standardized, and audited.

The problem I have with this is that it will most likely constrain the teams ability to explore new ideas and solutions to their problems. Their continuous improvement will most likely be driven through a canal that is managed by lock keepers and limited to the waterway. Kanban has had a refreshing influence on the community, but it is not for everyone. Does an organization create a maturity model that takes in every new idea? Does it have the capability to create a choose-your-adventure pathway?

Yes, I think an agile transition maturity model is possible. But I also think it is improbable to have the right outcome. And, it might be less work to allow the teams to find their own way with a centralized coaching/mentoring staff. What do you all think?

From a recent LinkedIn conversation I was having:
I would suggest that a first step is to inspire the PMO group in your organization to get out and observe the teams. Start documenting patterns. When there is a catalog of "for this problem, here are solution patterns that have worked", you not only have teams learning and growing from each other, but teams of like need mature towards a converged point.

Personally, I'd prefer this over a CMMi approach because it is a mentoring/guidance solution instead of a prescriptive/directed solution. The minute you demand teams follow a certain path, you limit their ability to explore and uncover great ideas. I believe that creativity and exploration through retrospectives is a key part of continuous improvement.


  1. I can't help but feel this misses the point of CMMi - The model doesn't associate practices with maturity levels, but outcomes.
    In my experience agile teams tend to be more able than 'traditional' dev teams to answer questions such as "how are you tracking against your plan", "how do you know what to do next" and "can you trace your outputs to the business need they ultimately enable".

  2. Based on how people in the community ask their question, they don't seem to get this.

    Based on the CMMi audit I went through after going agile in my last shop, I'd have to disagree with you a little bit. There was a focus on explaining the practices per level as a way to verify the outcomes.

    Is it possible that many of us have had the wrong experience with CMMi?

  3. Jurgen agrees: