I Really Hate CMMI
I came across a question on a usergroup asking the following (it’s condensed):
“In our projects we maintain product backlog and do high level estimates in story points. Then when we actually start the iteration we do estimates in the sprint planning meeting in story points and then when the story gets completed we mark the actuals against it. Our understanding of story point is one ideal day (i.e.6 hours). Our estimate for the story include analysis, design, coding and testing. Now the CMMI group is recommending us that we should divide our story into analysis, design, development and testing substasks and track estimated and actual efforts against them. Their argument is that by doing this, there can be some data available which will tell us on how are we doing on each of this area and where we need to improve. For example if the analysis tasks are taking longer then estimated then we should identify reasons and actions to handle it. My argument was that we can not go below the story level because in agile way of working analysis, design, development and testing is kind of merged into a story and since the story is a smaller piece its not possible to break it further in such a way. I told them that this will be too burocratic and there will be lot of administrative overhead. The CMMI group told me that in their previous implementations they have done it only this way even in organizations where they are using agile methodology (Scrum, XP etc.) and this was the only way they could find to handle this situation.”
There are so many things wrong here, I will just highlight a few. Having worked at a CMMI ranked company, from perspective of a contributor most of these rankings are pure bunk. The CMMI ranking had absolutely no impact on the quality of the system delivered or the timeliness of our delivery. In both aspects, the CMMI process produced a lower quality, more costly system than an Agile approach. As applied at this company, CMMI only served to reinforce all the bad habits and waste of waterfall (I really hate the term waterfall since it is SO pejorative. Just exactly who admits to doing waterfall? – CEN).
When I hear the phrase “this was the only way they could find”, it just sets off warning bells in my head. My only advice is to trust your instincts in resisting the mindset from the CMMI auditors. From the short description, it seems to me they are trying to create mini-waterfalls within an Agile process. As for the improvement the CMMI auditors are looking for, they are simply suboptimizing by focusing on tasks – that is such Taylorism. I am reading an excellent book by Craig Larman and Bas Vodde talking about using Lean thinking to scale Scrum to larger product organizations. This book provides the intellectual firepower to destroy the last vestiges of the waterfall in modern software development.
From my experience of CMMI and talking with some auditors, in many instances you only need to show evidence that a practice is occurring in order to pass an audit. There are many legitimate and creative ways to provide evidence your are following the practices described in CMMI. If your instincts are telling you the auditors are wrong, trust them. Learn what the auditors are looking for and work with them to provide the same information. Don’t let their intellectual laziness strangle real change and innovation in your organization.
As a practical matter, you need to placate these CMMI folks because they obviously have the attention of management. I would try to understand what management is looking for with a CMMI rating – beyond the obvious we need a ranking to get more and bigger contracts. What advantages would it give the business? How would you know that the organizational change caused by CMMI is producing the effect your company seeks? Then I would show your management how Scrum is helping in some areas and where it is deficient. In the deficient areas, maybe CMMI can help. Perhaps the CMMI people are right and the processes are unstable. Think about what you could be doing to make the entire system more predictable (hint – think Lean, not CMMI).
