RallyDev.com
Mon 1 Jun 2009
Does Agile Need Its Own Process Maturity Model?
In the last couple of months, IBM (via Scott Ambler) has blogged, hosted webinars and talked to the media about an Agile process maturity model (APMM). I am sure this will hit a new height today with the start of the Rational Users Conference and the release of the e-book. I have been asked to comment on this work by a number of press and analysts. Since my perspective will be published shortly, I thought I would go on record.
IBM splashes its way into Agile development
As the Agile market grows and takes hold in truly mainstream audiences, everyone is looking for easy, step-by-step guides to smooth Agile adoption. IBM is proposing one option under the name “Agile Process Maturity Model.” I think it is a nice marketing strategy for selling IBM’s Rational Team Concert products to companies that want to adopt the Jazz platform, copying their 90’s success with RUP. But I don’t believe it is actually an Agile process maturity model, and further, Agile doesn’t need one.
IBM’s proposal for an Agile Process Maturity Model
Scott says, “The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need).”
He continues, “Unfortunately, the term ‘maturity’ is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integration (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another…”
I am confused by the title and the orthogonality, so let’s peel the onion on this one.
What is a process maturity model?
The origins of process maturity models come from the manufacturing industry, but the software version was created in the 1990’s by Carnegie Mellon’s Software Engineering Institute (SEI). It is well known as three Capability Maturity Models – CMM for software, CMM for people and CMMI.
If you read Watts Humphrey’s work, you will see this is a management framework that measures the level of discipline of your organization. In essence, organizations that are certified Level 5 have implemented continuous improvement and have the disciplines and practices in place to effectively manage large complex projects with effective controls. The framework does not say anything about how the software should be developed. I make no claims to being a CMMI expert, but you can read a few of the “CMMI agile” search results to see how they work together.
Though not the stated intent of the framework, it has been closely associated with waterfall development and used to defend heavy process approaches. I disagree with that belief and prescribe to Jim Collin’s model of blending discipline and agility together to move from good to great. I think the CMM framework is a great checklist for organizations measuring their level of discipline… and we don’t need another one.
The 3 levels of IBM’s APMM
Scott’s APMM post describes three levels:
- Core Agile Development
- Disciplined Agile Delivery
- Agility at Scale
I struggle to see how these three labels or the supporting details provide a framework that helps categorize and understand Agile processes. These titles grow in scope and scale, but do not speak to increasing agility. (Faster cycles, less waste, less work-in-progress, more value.) When you look deeper, it smells of a cookbook of when to apply processes and tools from IBM. That is fine, and I agree customers need this. However, I would argue this should not be used to guide companies in their Agile adoption.
By mashing size, scope, increased agility and disciplines on one scale, the APMM does none well. In addition, it will lead to amateur implementations where continuous improvement mentality never sets in. Where adopting scaling software agility is thought to be just a transition from A to B. To me that thinking is very limiting and will lead to gains followed by declines.
IBM in the Agile space – all good
I am thrilled with IBM’s entrance into the Agile space with their Jazz platform and related products – really. When I was at BEA/Weblogic, I can tell you that we did not have a market for Java Application servers until the industry’s gorillas, IBM and Oracle, entered for real.
During this year, Jazz and its supporting products will actually manage the workflow of projects in a way that works with Agile development instead of against it. This is huge change from the ALM 1.0 point products that actually reinforced the silos and phased approaches that created queues, caused hand-off delays and kept quality as an after-thought.
The IBM gorilla in the software development space will make the Agile sea rise and help break down major organizational barriers to bringing the benefits of Agile practices and tools to the mainstream development community.
There is no cookbook for adopting Agile
I believe that enterprises need an adoption model that helps them balance discipline and agility in an incremental fashion that creates incremental success and fuels continued investment and improvement. The enterprise Agile adoption model Jean Tabaka and I have synthesized is based on Lean concepts and is rooted in Deming’s work, just like Watts Humphrey 
and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly, maturing before scaling and working incrementally.
This transition planning framework focuses on attaining benefits of agility by moving to lean states of flow, pull and ultimately the perfection of continuous innovation before adding the disciplines necessary to scale. It discusses the general steps, but does not prescribe a change approach to organizational, technological, process or strategy transitions. Your approach is dependent upon your corporate and technological situation. We recommend an iterative approach, facilitated by experienced coaches and peer support.
What does the Agile community need from IBM?
Mary and Tom Poppendieck’s new book called “Leading Lean Software Development” (out soon) has tremendously strong stories, models and insights from bringing lean concepts to software. In chapter six, they highlight a success story from working on lean with Sue McKinney at IBM. This success story, along with the Eclipse success stories, are critical for IBM to be telling the market regarding the impact of Agile and Lean in the large inside IBM.
In 2008 and four years after IBM started developing Jazz, we talked to IBM about integrating Rally’s award winning Agile Lifecycle Management solution onto IBM’s collaborative development platform, called Jazz Foundation. They said no, you have to wait until the GA release of Jazz. This would be a similar integration that we provide to Microsoft Team Foundation Server for managing code check-in’s and automated builds with a slick interface into the IDE. I am hopeful that IBM will GA the 1.0 version of the Jazz Foundation for partners to actually integrate with. They are saying all the right things on the Jazz.net site, here is hoping for some positive news at this week’s Rational User’s Conference. Finally, I am very excited about IBM’s global dialogue on Building a Smarter Planet. IBM needs to do a better job telling the story about how software agility is a critical component to building that sustainable planet. (It was nice to see the smarter planet splash at the front of the ebook, but it still represents a huge missed opportunity.)
What do you think? Does Agile need its own process maturity model?
Again, I was surprised by the title of IBM’s Agile Process Maturity Model and hope they will consider changing it before more marketing dollars are spent. It does not improve on the CMM, nor in my opinion does it help CMM certified companies adopt Agile. I assume IBM has a huge role to play in helping those CMM certified companies add agility and innovation to their highly disciplined organizations. If they don’t, we are glad to help today.
About the Author: Ryan Martens is a happy father, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.
A maturity model might have some value, but I do not see the IBM APMM being of use as it seems to be defined on their website. I just see a few “levels” described by a sentence or two and a few methods that are stated to ber examples of those levels.
Compared to the detail in the CMM/CMMI, the APMM is almost nonexistant. So I really don’t see it, as it now stands, as helping any.
Now, to be fair the SEI’s models use the term “capability” and this IBM agile one uses “process.” The former describes processes (with associated goals) and a definition of levels based on (a) a set of processes (CMM) or (b) a scale of process maturity (CMMI).
It would be hard to imagine that the spirit of the agile approach could be codified to the level of detail the CMM or CMMI models have been. Even though the SEI models (at their process and goal elements) are not “prescriptive” from an implementation perspective, they are in terms of what is considered a relevant process and associated goals.
Indeed, the addition of numerous processes in the move from CMM’s KPAs to CMMI’s PAs suggests that, regardless of the extensive effort and public review the CMM went through, people felt much more detail was needed to move to the CMMI. So it is hard for me to think an agtile “maturity model” could spring forth, whole cloth, from a single course and be a useful model for the entire community.
Again, a model could be usefuil, but only because it would come from a very public discussion of what consitutes valuable and useful elements of an agile approach. The IEEE standards effort, whatever people may think of it, has been an effort to do this.
Scott,
Thanks for your reelections on what it might take to actually get an “Agile” Maturity model using and IEEE approach.
It seems we are going to have to let this bake for another 5 years before that could make it through a process like this.
I appreciate your support and feedback.
Ryan
What amazes me is the lack of grounding in empirical models / thinking. Anyone doing complex product development work without a foundational understanding of statistics, science and behavior is simply not properly trained. It requires discipline and a deep appreciation for extremely hard to predict system development and the funkiness of people working together.
Overly abstract models, as proposed, lead to a belief in models and people stop asking important questions for themselves. User of these models believe that someone smart figured it out for them and all they have to do is follow a simple receipt. When the model of thought that they can no longer see around is failing them they do one of two things. Either people fall to blaming each other for being sloppy or worse increase the fidelity of the overly abstract complex process model using. So, we see elaborate prisons of process and/or cultural dysfunction.
We must move into an era of process mastery that originates from people fearless responding to empirical evidence.
- Doug
http://doug-shimp.net
Doug,
I assume you do not support agile certification unless it is experience based and prescribed by the agile alliance?
http://www.agilecertificationnow.com/agile-alliance-certification.html
This is the a meaty topic associated that SEI was trying to address; the “skill” level to build complex systems. Have you experience with using CMM to help certify a team ability and mastery?
Ryan
(Also posted on linkedin)
Large enterprise product development organizations who are used to cmmi/iso type process driven development may actually benefit from a model like this when driving their Agile adoption.
My thoughts are that there are so many facets of Agile and many changes that organizations need to make that give us real challenges when introducing Agile and reporting progress to stakeholders.
In these situations we need to find novel ways to introduce a culture shift to those who have spent 20+ years in heavily controlled and metrics-driven environments.
Training stakeholders and sponsors out of habits and expectations developed over an entire career needs more than an evangelist alone can often provide and a consistent industry framework may be a means of providing this.
One obvious option is to use Agile to deliver Agile – if this approach is used, a “stock” backlog of prioritized items could be developed by the community.
Tuning this would be team/org-specific but a stock list of agile practices and solution sheets may be achievable. (Is this similar to the Eclipse Process Framework?). Unfortunately process frameworks and practices are still hard to condense into an executive summary that makes sense alongside “traditional” metrics presentations.
A maturity model could provide a similar concept.
What level of granularity can we provide to show where we are, where we want to get to, the journey we’ve taken and what the next step should be?
This approach would allow organizations to benchmark themselves, their teams and others to allow a comparative view. (Something that in itself stirs unrest in some camps).
A roadmap that provides Agile champions and leaders with support on prioritizing, how to “level up” their teams and how to track and report to stakeholders seems a great idea to me however this should be coordinated by a non-profit organization and driven by the whole community.
Agile adoption could also be measured less formally using the concept of teams running an “Agile 360″. This approach has the benefit of engaging the full team for their input and allowing them to formulate their own levels however once again, a framework with supporting levels, categories and concepts would be of broad industry value.
Simon,
Thank you for your comment. I agree with many of your points. Jean and I wrote the Lean IT whitepaper to use agile to rollout agile. I see it as an adoption framework, but not a maturity model. Many of the concepts you comment on in this post are addressed in that paper.
I am hard on Scott for the use of a Process maturity concept, I think Lean gives us the notion of Flow, Pull and Perfect. I think that is the general answer, from there the unique situation and continuous improvement start to govern.
Love to hear your thoughts on our Lean IT: Moving to Program Pull whitepaper.
Ryan
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.
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?
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).
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
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.
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?
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
Classic graphic – of course the rabbit always wins:O
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