Comments on: Does Agile Need Its Own Process Maturity Model?

By: Sonali

Sonali — Thu, 08 Sep 2011 18:13:46 +0000

Hi Sushil,

I am also researching on the similiar concept for AGile Maturity Model/framework. Would be good to also collaborate with you and discuss the ideas.

Regards
Sonali

By: Sushil

Sushil — Sat, 21 Nov 2009 09:50:10 +0000

Yes, I firmly believe that Agile needs Maturity Model. May be because I come from CMM backgroud. However since focuse of CMM is process that’s why it measure process maturity but Agile maturity model should not measure the process but Agility of the adoption. Not sure if it made sense, meaning it should measure more based on the outcome it produces rather than auditing process. Or I would say whole dynamics of the team rather than process followed by the team. Anyway I am working on Agile Maturity Model, and I want to publish more formally than on a blog and actually would be interested in collaborating as well if you are too. Can you please suggest me more formal way to publish it?

Thanks a lot.
Sushil

By: Ryan Martens

Ryan Martens — Thu, 17 Sep 2009 19:36:41 +0000

Classic graphic – of course the rabbit always wins:O

By: Mike Alber

Mike Alber — Thu, 17 Sep 2009 17:53:45 +0000

Related to this conversation, David J. Bland (aka 7thpixel) just shared his “in depth visual analysis of IBM’s take on Agile” via twitter http://bit.ly/1Yo8L4

By: Ryan Martens

Ryan Martens — Fri, 12 Jun 2009 15:14:00 +0000

If you are interested in this topic, make sure to check out the Agile Alliance Discussion area on Linked-in. There are another 15 or so comments there too.

By: Randall Stross

Randall Stross — Fri, 12 Jun 2009 01:15:36 +0000

If indeed CMM is sufficient, I wonder why IBM is making this moved? Are they trying to take ownership of mind share in this way?

By: Ryan Martens

Ryan Martens — Tue, 09 Jun 2009 23:22:30 +0000

Scott,
Well said on seperating the change process from the elements of the target state. I see CMMI as the states of process discipline necessary to handle increasing complex, large and life threatening applications.

I see IBM’s work as a strange combination of the two while confusing the situation with its name. Back to my post, it is a cookbook for tool adoption.

I believe most people are not trying to change their CMM level, but they are trying to increase their agility. Thus I see the concepts of Flow, Pull and Perfect/Innovate as measures of agility that work in conjunction with the CMMI levels. They are a framework for adopting and scaling agility.

I am a personal fan of Peter Senge’s Dance with Chagne, Otto Scharmer’s Theory U and Toyota’ PDCA cycle for change models.

Regards,
Ryan

By: Scott Duncan

Scott Duncan — Mon, 08 Jun 2009 13:53:21 +0000

In reading the comments above and thinking about other comments on maturity models for agile implementation, what strikes me is that a lot of adoption issues are about basic organizational change common to any effort to move from some current state to some other (desired) state. SEI has the IDEAL model for managing change while the CMMI exists to describe the state to which one, presumably, wants to move.

Keeping the change process separate from the elements of the target state is, I think, useful when discussing adoption of new practices since how you handle adoption is different from what you look to adopt (and why).

What agile adoption needs more at this time is an organizational change model more than a capability/maturity model to assess where someone is in the adoption effort. I am not yet convinced there is a uniqely agile approach to organizational change compared to the organizational guidance around for many years (decades, even).

By: Ryan Martens

Ryan Martens — Mon, 08 Jun 2009 06:26:50 +0000

Thomas,
Thanks for the comment on benchmarking and dependencies. In larger programs of teams, these are critical for understanding where the bottlenecks and risks are. I would suggest that using past data on iteration delivery versus commitments will give you a good understanding if this team is in in “Flow” and can make and meet its commitments. Teams that have a stable control charts, not wildly oscillating, of burn down’s and continuous build success rates are teams you can trust to make it. The clearly know how to estimate and commit as a team.

We use a team assessment to help teams gauge their level of practice maturity, but it is simply used to stir their thinking about where to go next to help increase their agility and discipline. When they are ready to do that; again not a cookbook, but a unique receipt based on each setting. The survey is not much a of a predictor of their ability to make and meet commitments. Do you agree?

By: Thomas Hellstrom

Thomas Hellstrom — Thu, 04 Jun 2009 07:59:38 +0000

I am working as an Agile champion/project manager in a medium sized development org and I think the maturity model is useful as a benchmark against other organisations and not as a tool for improving. It also highlights some aspects that an organisation cannot expect to be delivering in an agile fashion just because each team is working from agile methods. Dependencies between the teams, need for consolidation, system testing, uneven workloads, etc are things that needs to be resolved on a high level. I think a maturity model can be good at identifying your current state of maturity. The transition system is more useful when the organisation acknowledges that it is not working agile at a program level and wants to make changes to improve.