Sunday, November 12, 2006

Is CMMI worth doing?

The Certified ScrumMaster Trainers list is discussing the Scrum CMMI Level 5 paper and raise good questions:

Does CMMI provide any benefits? Some have worked on CMMI projects that just generated more overhead with no benefits. What do the authors think about this?

Systematic Software Engineering finds CMMI to have strong benefits and would not do without it.

1. Strategically they want to get large contracts in the U.S. and Scandinavia that require CMMI Level 5.

2. It gives high predictability. Contract date completions are over 95%.

3. It provides a better engineered product for scalability, maintainability, adaptability, etc.

4. It eliminates 80% of rework (which includes bugs). Scrum then cut the remaining rework in half so now they have eliminated 90% of rework. The average Scrum only eliminates 40% of rework without CMMI.

Systematic would do CMMI over Scrum. However, they find Scrum to provide amazing benefits to CMMI Level 5. I think the cost of going to CMMI Level 5 starting with Scrum could be reduced by 50-80%. This would allow more companies to achieve the benefits. We believe everyone can provide better engineered products with much higher quality and very high predictability on dates. The process overhead of CMMI Level 5 with Scrum is 4%. Most Scrums have far more waste in them than 4%.

Of the Scrum's I have seen, early implementations typically average about 50% waste, the CMMI Level 1 number. However, even a bad Scrum improves productivity so total waste is less than Scrum. Yet most companies can't show metrics that demonstrate they more than doubled productivity. This is so easy to do with Scrum I'm starting to think that we should say that a company hasn't implemented Scrum yet if they cannot show real metrics that demonstrate they have doubled velocity using their burndown charts. Failure to do this means they have not been tracking their burndown so they haven't implemented Scrum. Or it means their implementation is so riddled with impediments that they have been unable to implement Scrum effectively.

A lot of companies are going through the motions while disfunctional management is so bad they can't really implement Scrum. CMMI Level 5 will require managers to remove impediments or lose CMMI Level 5 certification. We have agreed on this with the CMMI Level
5 auditor, who says the management role must be clear and must be enforced. High maturity means that management aggressively eliminates impediments surfaced by the teams. They should start doing this now even if they are going to remain at CMMI Level 1 (where most companies are). Failure to do this means management sucks.

In some companies I work with, particularly the multi-billion dollar companies, the cost of developing software is so small compared to the rest of the company budget, that they do not have the incentive to remove software impediments because it requires change, and change is hard. They have bigger problems in other parts of the company. This just means the management is doing a worse job elsewhere than they are doing in software development. At least, they should insist that the software development managers clean up their act, even if they can't provide them with much higher level management attention. Scrum metrics and Scrum transparency of data will help them clean up what is essentially a middle-management problem with very little effort.

They should then ask development managers why they can't operate at CMMI Level 5 when the process overhead is 4% or less with Scrum. Management wants firm dates they can count on. They want higher quality and more scalable and adaptable implementations. Good CMMI implementation can provide this. The only thing preventing progress is the cost of change. That cost should be carefully analyzed. A roadmap should be build for process change and resource requirements should be mapped out with a timeline. Once this is done, a clear business decision can be made and execution of a rational plan becomes much easier and more effective.

The bottom line is that most companies will never find an ROI that justifies going to CMMI Level 5 with a waterfall methodology. The cost is just too high and the benefits too remote. With Scrum, the cost is dramatically reduced, and the speed of implementation could be radically accelerated. The ROI could suddenly look pretty good for a lot of companies.

In the final analysis, some process experts say that a well implemented Scrum across a company cannot be done without being at CMMI Level 3. Essentially you get that for free by implementing Scrum well. Going to Level 5 won't cost you much more with Scrum.

6 comments:

- said...

From what I've read, Scrum implementation is possible when at least CMMI Level 3 is already certified. Is it possible the other way around? Start implementing Scrum...and over that scenario start with CMMI?

Jeff Sutherland said...

Scrum can be implemented at any CMMI level and will help improve any process environment no matter how disorganized. An "institutionalized" Scrum in the CMMI sense means everyone in the company in on board including management. This is one of the key requirements of CMMI level 3 and tremendously improves velocity (more than doubles software throughput) and will radically reduce the cost of moving up the CMMI ladder of maturity.

gamsjo said...

In my experience the CMMI Level 3 companies do have a very rigorous and detailed process documentation. You may not need that, but the documentation tends to get very large and hard to evolve. When going for Scrum they must take a tough decision: Should we throw it all away and make a light-weight Scrum oriented process description, or should we try to adjust what we have. The last option is very likely to become a hybrid of "the worst from both worlds" - a heavy weight Scrum.

The CMMI level 4 and 5 companies tends to have a maintainable, light weight process description that easily adapts to Scrum.

My advice is, do not wait for CMMI certification unless you are very close to Level 4 or 5 - and have an adaptable process description.

fantasy said...

CMMi never tells how you need to achieve any level. It just tells this is what is required to reach any level. So it’s up to the management to choose their approach to achieve the desired level. Management can choose to use Agile approaches for various CMMi requirements. Like pair programming can substitute for code reviews, daily stand ups can substitute for status reporting , product backlog and sprint backlog can easily stand up to the requirements of Requirements management process area. It’s false to say that CMMi requires more documentation. It’s organization which chooses to implement it like. Because they carry the legacy of earlier ISO models or waterfall approaches and they don’t want to bring in a drastic change.

Jeff said...

Having developed and implemented CMM/CMMI compliant processes since the early 90's I can assuredly state that the CMM/CMMI is nothing more than a model for process improvement. There are no requirements and the different levels of maturity are nothing more than measurements. Measurements are crummy goals.

The bottom line is that unless a firm is doing process improvement to improve productivity, decrease time to market or to improve the quality of employees lives, then the whole effort to reach the hallowed "levels" is a screen door on a submarine. Scrum is a very nice way to improve quality, time to market, and employee lives. If what you're doing supporting your business, continue doing it. If it doesn't what are you doing it at all. If Scrum is effectively implement, you’ll have no problems with any maturity model assessments as long as subcontract management sn’t an issue. Even then a scrum or Scrums could address this aspect of the model with no problems.

Thus endth my rather late 02 cents.

Jeff Jones
Jeff.jones@smeartonline.com

Jeff said...

Having developed and implemented CMM/CMMI compliant processes since the early 90's I can assuredly state that the CMM/CMMI is nothing more than a model for process improvement. There are no requirements and the different levels of maturity are nothing more than measurements. Measurements are crummy goals.

The bottom line is that unless a firm is doing process improvement to improve productivity, decrease time to market or to improve the quality of employees lives, then the whole effort to reach the hallowed "levels" is a screen door on a submarine. Scrum is a very nice way to improve quality, time to market, and employee lives. If what you're doing supporting your business, continue doing it. If it doesn't what are you doing it at all. If Scrum is effectively implement, you’ll have no problems with any maturity model assessments as long as subcontract management sn’t an issue. Even then a scrum or Scrums could address this aspect of the model with no problems.

Thus endth my rather late 02 cents.

Jeff Jones
Jeff.jones@smeartonline.com