CMMI version 1.3 and Agile


Well, the Software Engineering Institute (SEI) just published the newest version of the venerated CMMI and there are many side notes in the CMMI-DEV version that touch on using an Agile methodology with CMMI.  I’ve always thought this was possible and I’m glad to see the SEI has taken the lead.

For example, here is the “Agile note” in the configuration management section:

In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done.

I especially like this one from the Requirements Development section:

In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. (See ―Interpreting CMMI When Using Agile Approaches‖ in Part I.)

Download the latest CMMI-DEV and enjoy!

An updated Word version of the MSF for CMMI Process Improvement v5.0 Process Guidance


Hi Folks,

This has been a very popular download on the site.  I’m starting to do some more work around the CMMI template, so I thought I’d update the word version.  Much cleaner in the table of contents.  Only thing missing is some info on the dashboard reports, but stubs are there for each one.  Weighs in at 216 pages!  Enjoy!

MSF for CMMI Process Improvement v5 – Process Guidance

MSF for CMMI Process Improvement 5 – Process Guidance in Word format


Well people loved the MSF for Agile Word doc that I posted so much, I thought I’d go ahead and post my Word doc of the CMMI process also.

I think the CMMI process gets a bad wrap because, well, it has the CMMI name in it. CMMI has become synomous with heavyweight, formal processes that developers hate, but this process is still iterative and lightweight. Plus it provides you with rich Work Items such as Change Requests (an almost necessary evil). So give it a go too, you never know… it might fit better than the Agile template!
MSF for CMMI Process Improvement v5 – Process Guidance

Updated it on 12/13/2010

MSF for CMMI Process Improvement v5 – Process Guidance