• Home
  • What Could we do Better?
  • Instituting a Management Improvement Culture in Your Organization
  • Find the Root Cause Instead of the Person to Blame
  • Good Process Improvement Practices
  • Management is Prediction
  • The Purpose of an Organization
  • Performance Without Appraisal
  • Manufacturing and the Economy
  • Practical Ways to Respect People
  • 10 stocks for 10 years
  • Deming and Toyota
  • Curious Cat Management Improvement Articles
  • John Hunter
  • Institute for Healthcare Improvement
  • Superfactory
  • Management Improvement Jobs
  • Deming on Management
  • Management and Leadership Quotes

    I am now using this blog to re-post some comments I make other blogs. For my full management blog see the Curious Cat Management Blog

    Wednesday, July 27, 2005

    Stretching Agile to fit CMMI Level 3

    Topic: Management Improvement

    Stretching Agile to fit CMMI Level 3
    by David J. Anderson.

    I highly recommend reading this article. My work happens to straddle both the management improvement and software development areas that this article covers. But, if you are interested in either area, this article offers some great material. And if you are interested in both, you are in for a treat.

    At Microsoft, we've adopted the teachings of W. Edwards Deming and stretched our MSF for Agile Software Development method to fit the requirements for CMMI Level 3. The resultant MSF for CMMI Process Improvement is a highly iterative, adaptive planning method, light on documentation, and heavily automated through tooling.

    Capability Maturity Model Integration (CMMI) is the process developed by the Software Engineering Institute (at Carnegie Mellon) that was heavily influenced by Quality Management. When I first ran across it (then called Capacity Maturity Model) in the mid 1990's, as I remember, I was struck that the model did a better job of integrating Quality Management ideas than most programs specifically calling themselves Quality programs.

    I was also struck that it was extremely documentation heavy. It was developed for large, complicated, critical software system (for the Department of Defense). While the heavy documentation focus made sense for that type of development it seemed to require too much overhead for less complex software development efforts but still had lots of good ideas that smaller efforts could benefit from. And the ideas in David Anderson's paper show how to get the benefits of CCMI without the normal drawbacks (including importantly, as he mentions:

    CMMI process implementations are often associated with conformance to plan, low trust environments, with command and control structures. These require a big design up front approach with auditing of conformance and by implication punishment for non-conformance.

    As the paper mentions this is not necessary even though it is often the result of using CMMI.

    This paper shows that it is wrong to associate these undesirable software engineering behaviors with the CMMI. It doesn't have to be that way.
    By embracing the teachings of W. Edwards Deming and understanding their relationship to agile principles and practices, it is possible to develop a truly agile full life cycle process which meets the requirements for all 5 levels in the CMMI model. Specifically by using agile metrics such as velocity, cumulative flow and trends in open issues, we have designed planning and monitoring methods which embrace variation and allow for postponed, late commitment and adaptive iterative planning.


    Post a Comment

    << Home