Don't fear the CMMI monster
Lots of shops have "gone process" and "Gone CMMI" (Capability Maturity Measurement Model), and many folks have gone berserk when it happens. Well it happened to us, and it was not the worst thing that could happen. It actually helped in a number of areas. Maybe we did it right. Maybe we did it light.
Disclaimer - I am not a process wonk. I am the fastest coder you ever met. Cause I don't sleep at night, I lie there paraniod about my deadlines and outline my code over and over for hours - so when I hit the IDE in the morning, its 2 to 3 hours of straight 60++ wpm typing of code into the IDE. (Ok, none of this is true anymore, its how I came up thru IT, and my wife will attest I sleep at least 3 hours every night.) Now I type memos and PPT for hours straight when I come into the office, if not giving live presentations....
Our Parent Company, (One of the largest corporations in the world) "suggested" we switch our evolved software and version management to CMMI. And it worked. Here is a short discourse on how we did it and what worked well, and (I think) why.
First - training - as CTO I attended a good bit of CMMI training and did a lot of research ("Distilled" and other titles). And I learned what this thing is, and where it helps. I produced a lot of samples for folks, and held in person PPT walkthrus of different aspects and processes. I vetted them against myself and other tech ringers. Then we used Camtasia to produce in-house video reminders of those sessions, showing mock up updates to those tracking documents, etc. (Train thrice...)
Then, we moved our current methods into it, not replacing them. Also, we used excel spreadhsheets for tracking. I liked that approach since its not as scary as a closed on line system, and since we were still very dynamic during the learning phases, we could change them often. I wanted things "compellingly convienient" for everyone.
We have a Wiki to place and update our policies, and links to our project documents. We went to a strict V Model BUFD (Big up front design.) No coding until all requirements are in and approved by the business side. Well you can be granted an exception with the proper paperwork, but that low cost hassle is enough to keep the process on track. You are allowed on all our policies to violate them, with minor paperwork and we track the violations. That was our overall philosophy.
We have been "switched" to level 2 and level 3 processes for CMMI now for over 6 months. Productivity, as best we can tell is up - the statistics from before don't compare well. Business leads are not complaining they are not getting thier applicaitons constructed fast enough, if thats a measure.
We have much higher transparency into what we are working on, and when it will finish. We have fewer people working OT.
Some of the best anecdotes are when we work on large projects for clients - we have a formal methodology in place and nothing special changes - its not new and different, we just use our normal approach to those projects and the customers are happy we are planning our work and tracking it. People like to know what they are paying for.
The complaining of all the process overhead dropped off very quickly to the usual level of corporate crankiness, once people learned how-to in the new methodology. My memory is about the 3 month mark, when some versions were wrapping up thier first shipping modules under the new methodology.
And the business people have learned how to drive in this new system - push to baseline - that magic point that we have all the requirements detailed and signed off, and construction (and testing) can begin. So they push to baseline, they actually tell us what they want, they actually cut features if they can't tell us, and they don't yell "type faster" to the coders as an approach to getting higher quality software out the door faster.
Quality is up on every formal and informal measure. We are spending far less time on a dot-zero (8.0, 9.0) shipment fixing things. The traditional "quick patch version after a dot-zero version" is a thing of the past, which yields a 30% savings right there, if my old project plans are any measure.
And one quote from my CMMI training I will never forget is already true. "Once you work at a level 2 or level 3 shop, you will never work at another shop that is not that level". We have our business people educated on where they can lever software, (feature selection, feature cuts, select the ship date) and where they cannot (don't try to drive estimates lower, the tech side owns those - thank you xtreme planning...)
It was a lot of work to switch over. And we are not done. Our next CMMI rating will be about a 2.5, some of our level 3 processes are not perfect, some of my teams are not even doing 2.5 consistently.
But its already worth it. And I did not think that 6 months would be the point I would be saying that.
Reminder of my success points
Its also like a detailed home-quicken (or MSFT money) budget - be careful what you ask for, the details can be scary.
If your software shop is large, or getting large, this thing scales - its the way to go.
If your shop does outside (custom work for clients) then this is really really the way to go.
(Even if only some of your work, like our shop, is that way).
Someone once told me (in referring to sales pitches, but it applies to IT processes as well)
"You may as well write the script down, cause by the time you do it over and over, you are following a script anyway, you just never wrote it down and refined it".
Thats CMMI in a nutshell.
Well, at least our version of it.
Disclaimer - I am not a process wonk. I am the fastest coder you ever met. Cause I don't sleep at night, I lie there paraniod about my deadlines and outline my code over and over for hours - so when I hit the IDE in the morning, its 2 to 3 hours of straight 60++ wpm typing of code into the IDE. (Ok, none of this is true anymore, its how I came up thru IT, and my wife will attest I sleep at least 3 hours every night.) Now I type memos and PPT for hours straight when I come into the office, if not giving live presentations....
Our Parent Company, (One of the largest corporations in the world) "suggested" we switch our evolved software and version management to CMMI. And it worked. Here is a short discourse on how we did it and what worked well, and (I think) why.
First - training - as CTO I attended a good bit of CMMI training and did a lot of research ("Distilled" and other titles). And I learned what this thing is, and where it helps. I produced a lot of samples for folks, and held in person PPT walkthrus of different aspects and processes. I vetted them against myself and other tech ringers. Then we used Camtasia to produce in-house video reminders of those sessions, showing mock up updates to those tracking documents, etc. (Train thrice...)
Then, we moved our current methods into it, not replacing them. Also, we used excel spreadhsheets for tracking. I liked that approach since its not as scary as a closed on line system, and since we were still very dynamic during the learning phases, we could change them often. I wanted things "compellingly convienient" for everyone.
We have a Wiki to place and update our policies, and links to our project documents. We went to a strict V Model BUFD (Big up front design.) No coding until all requirements are in and approved by the business side. Well you can be granted an exception with the proper paperwork, but that low cost hassle is enough to keep the process on track. You are allowed on all our policies to violate them, with minor paperwork and we track the violations. That was our overall philosophy.
We have been "switched" to level 2 and level 3 processes for CMMI now for over 6 months. Productivity, as best we can tell is up - the statistics from before don't compare well. Business leads are not complaining they are not getting thier applicaitons constructed fast enough, if thats a measure.
We have much higher transparency into what we are working on, and when it will finish. We have fewer people working OT.
Some of the best anecdotes are when we work on large projects for clients - we have a formal methodology in place and nothing special changes - its not new and different, we just use our normal approach to those projects and the customers are happy we are planning our work and tracking it. People like to know what they are paying for.
The complaining of all the process overhead dropped off very quickly to the usual level of corporate crankiness, once people learned how-to in the new methodology. My memory is about the 3 month mark, when some versions were wrapping up thier first shipping modules under the new methodology.
And the business people have learned how to drive in this new system - push to baseline - that magic point that we have all the requirements detailed and signed off, and construction (and testing) can begin. So they push to baseline, they actually tell us what they want, they actually cut features if they can't tell us, and they don't yell "type faster" to the coders as an approach to getting higher quality software out the door faster.
Quality is up on every formal and informal measure. We are spending far less time on a dot-zero (8.0, 9.0) shipment fixing things. The traditional "quick patch version after a dot-zero version" is a thing of the past, which yields a 30% savings right there, if my old project plans are any measure.
And one quote from my CMMI training I will never forget is already true. "Once you work at a level 2 or level 3 shop, you will never work at another shop that is not that level". We have our business people educated on where they can lever software, (feature selection, feature cuts, select the ship date) and where they cannot (don't try to drive estimates lower, the tech side owns those - thank you xtreme planning...)
It was a lot of work to switch over. And we are not done. Our next CMMI rating will be about a 2.5, some of our level 3 processes are not perfect, some of my teams are not even doing 2.5 consistently.
But its already worth it. And I did not think that 6 months would be the point I would be saying that.
Reminder of my success points
- train senior IT managment - this is not "a staff problem"
- evangelize / train senior business manament
- impossible. So have your trained IT senior management at all early project meetings, which turn into training sessions
- make the new processes "compellingly convenient" - no new online closed system that people "work around"
- explain what data you are gathering, what its used for, and how its anonomized
- admit process errors early and often, fix the descriptions and process on the wiki in seconds and broadcast the fix
- Keep helping your IT staff
- Go light on process punishment for quite a while, give people time to learn.
- Tracking - what you don't track, people eventually stop doing and go back to old habits.
- Track everything, conveniently.
- take attendance at training.
- We use electronic sign off (your initials and date). No one has tried to cook the system. But its real convenient
- We use wiki for fast process documentation and adaption, and easy surf and search for newbies
- train everyone in 4 modes
- wiki process reading
- live walkthrus
- movie files for offline walkthrus
- lots of 1on1 support anytime they need it
- Never shoot the messenger - you will never get valid data again
- Never harp on dates - harp on what features should be in our out to make that date
- update plans as soon as we think an estimate is too low or too high
- Estimates are soft until baseline
Its also like a detailed home-quicken (or MSFT money) budget - be careful what you ask for, the details can be scary.
If your software shop is large, or getting large, this thing scales - its the way to go.
If your shop does outside (custom work for clients) then this is really really the way to go.
(Even if only some of your work, like our shop, is that way).
Someone once told me (in referring to sales pitches, but it applies to IT processes as well)
"You may as well write the script down, cause by the time you do it over and over, you are following a script anyway, you just never wrote it down and refined it".
Thats CMMI in a nutshell.
Well, at least our version of it.
Comments