Documentation <> Process
There have been some interesting comments about my last blog post on CMMI so I thought I would do a follow-up post to put more of my interpretation on these.
One of the biggest criticisms around CMMI is that it is considered as a heavy weight process. Actually, it’s not really a process that you can follow like a map and isn’t comparable to something like RUP. In fact, you can use RUP to achieve certain levels of CMMI. You can use MSF 4.0 to achieve CMMI levels as well. CMMI is not a process declaration – it’s more like rules that suggest what the process should address.
What I hear continually is how people think that CMMI is there to burden the developer – make their lives less enjoyable, less creative. Actually, CMMI has more to do with the business. In fact, almost all developers, except for the hobbyist (in all of their forms) develop software to meet some business need. CMMI is intended to help a business be more effective through improved quality and reliability of its operations. Um, that’s good right? The problem is that an increasing number of businesses are not undertaking the risk of developing their own software because of the risk it poses. Businesses like to have repeatable and predictable risks and in many cases, software development just hasn’t demonstrated itself to be safe, regardless of the methodology or amount of documentation produced.
Another criticism is that CMMI just means more documentation. This isn’t really true either. In many cases, all CMMI is suggesting is to track stuff. Track it in a document? Sure – however, I absolutely HATE document based artifacts – and think they should not be used except for high level charters and vision scopes – things that people need to sign, and even then I would prefer to generate them from a more raw data form. I like simple lists – something easy to create and more importantly, easy to consume (Law of Consumption of Artifacts) – and I can’t see anywhere in CMMI that suggests that lists don’t accomplish the same goals. Take for example the CMMI Engineering Requirements Development and Requirements Management Process areas…no where does it say that we have to create lengthy documents – all it says is to develop product requirements. If you can do that with a user sitting right next to you – go to it!! You’ll likely write some stuff down somewhere even though the user is continually involved… so, write the requirements down in some sort of list that you can use as a developer to better track what you need to get done and when you should probably do it. Sticky notes? - that’ll work too. Let’s think about the Project Management process areas – as most projects need some high level logistics and control. One of the practices is to manage risk and to monitor the project against “a” plan. Even Agile development has some level of a plan (it might not be overly specific, but it’s a plan) – and it doesn’t need to be in a thick document. CMMI doesn’t tell you to write more documentation or to follow certain templates. It may be thought of in that way because many CMMI practitioners have implemented CMMI improvement strategies that focus on document driven processes that help to govern and control process (“When this document is done, go to step 2”). In fact, CMMI SCAMPI Distilled (a book I accidentally read once) suggests that as 400 document types and 1000 artifacts are required to facilitate an appraisal. GOOD LORD – that’s a whole lot of documents. We should not confuse the collecting and tracking of valuable information (and the information that can be further interpreted from it) with the creation of documents. Ultimately, we need to track information – the manner in which we persist this information should best suite your organization based on how that information will be consumed – and documents rarely fit the bill. To meet levels of CMMI a company only needs to demonstrate that goals are being met not that certain documents are being filled out.
When my teams start using lists to manage work that needs to get done, ultimately moving away from document based artifacts, we’re still achieving much higher levels of maturity according to CMMI while maintaining a fair amount of agility. We stress working software over documentation, stress continual customer involvement, stress continual builds, focusing on high customer satisfaction, welcome changing requirements (but that doesn’t mean we don’t track the changes), stress the interaction between business and developers, keep things simple, and more importantly make sure that the team continually works together to see how they can become even more effective. In fact, if you look at CMMI level 5 it states “Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements.”
The most important aspect of CMMI is the continual process improvement aspect of it. It will force you to look at your processes and say “Yeah… that didn’t work, let’s try something new” instead of, like many organizations, simply keep on running off that cliff like those poor little lemmings. If you find you are doing too much documentation and that you or your customers aren’t finding value in this – CMMI promotes you to change to help ensure the highest degree of value flowing through and out of your team. That’s what gets my ticker going. CMMI stresses gradual maturity – it is very difficult to simply pop into existence at a particular level and most organizations will want to gradually improve their process areas, depending on their needs, over time and in a way that conforms to the corporate culture around change.
Glen Alleman has a good insight into this. David Anderson also has a fantastic presentation that you NEED to read from beginning to end. Stephen Swoyer has a fantastic article on this as well.