Newsletter Article - Handling "Potential" Weaknesses When Conducting a CMMI Gap Analysis in an Agile Organization

Software Quality Center LLC is a reputed partner of the CMMI Institute.  We have been using CMMI® to help elevate performance for over 15 years and have seen the value of the models to deliver measurable results for our Clients/Organizations. We look forward to continuing to work alongside the CMMI Institute to extend the reach of the CMMI® frameworks to enable individuals and organizations to reach their goals.

We are pleased to share articles written by our Consultants, few of them with you, over the course of next few months, which you will enjoy reading and enjoy as a take-away for your everyday meetings and knowledge. It is also a great way to reinforce concepts of quality in your organization's staff in everyday meetings!   

Handling "Potential" Weaknesses When Conducting a CMMI Gap Analysis in an Agile Organization

Based on material in book "Integrating CMMI and Agile Development" - by Paul E. McMahon (Sr. Consulting Partner - SQC).

How you should go about handling a "potential" weakness when conducting a CMMI gap analysis in an agile organization can best be described through an example. During a gap analysis interview eventually you will get around to the products produced by the person you are interviewing. At this point you will probably ask a question such as,"Does anyone else look at these products you produce?" Often, in Agile organizations, the answer is, "We do not do formal peer reviews."

When you hear this just note it as a "potential" weakness recognizing you will need to come back later and dig deeper to find out what is really going on. You could alternatively just report it to management as a weakness that needs to be fixed. You could say, "I heard you do not do peer reviews, and you need to do peer reviews because they are an expected practice within the CMMI model." While this would be the easiest thing to do, it would also add the greatest risk to the goal of maintaining a successful agile culture.

A better approach is to come back to this issue by asking "

the intent" question. This is an approach I learned from a CMMI lead appraiser I worked with many years ago. What she meant was, whenever you are dealing with a potential weakness, ask yourself, "What is the intent of this practice in the CMMI model?" Then ask,"Are we achieving the intent?", and "If so, how?" This may lead to an alternative practice, or a different "how to" approach. Keep in mind that the CMMI focuses on "what" you must do, and you have many options related to "how" you do it. Agile approaches provide potential "how to" options that may look different from what you are used to seeing in traditional organizations. Keep in mind that the "how to" options are not dictated by the CMMI model.

Another good question to ask is, "Is there a problem in the organization because this practice does not seem to be done?" If the answer is no, then keep digging for an alternative practice or a different "how to" option. You are likely to uncover what I refer to as a "local" practice. A "local" practice is something that is often not documented and is taken for granted in organizations, but is achieving the intent of a CMMI practice.

An example of a "local" practice that I found at one of my client organizations is something we referred to as "doorway" risk management. Risk management was ingrained in everything this organization did, which was part of the reason for their success. When a project leader had a risk he did not wait for a formal risk board meeting. He was in the "doorway" of his manager's office strategizing the risk mitigation immediately. We did not change this process, but we did document it and train it. Such "local" practices are common in many successful Agile organizations.

If, on the other hand, there is a problem in the organization, then the next step is to decide if the organization needs to "stretch" by changing their behavior to resolve the problem right now. If you decide the organization needs to "stretch" it is also critical to convey this rationale to the personnel in the organization that are affected so they understand why they are being asked to change their behavior. Behavior change is the hardest part of process improvement, but by providing solid rationale and digging for "local" practices first we can provide the best guidance to ensure our clients can continue to be "agile" while also providing the needed high quality products for their customers.

Paul E. McMahon (Sr. Consulting Partner -SQC): He has taught Software Engineering at Binghamton University, State University of New York; conducted workshops on Engineering Process and Management, and published more than 45 articles on software and systems development and management, including several in CrossTalk, The Journal of Defense Software Engineering. Paul is the author of two books, Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement (August, 2010) and a book on collaborative development, Virtual Project Management: Software Solutions for Today and the Future (CRC Press, 2000), and is a co-author of the recent new book: The Essence of Software Engineering: Applying the SEMAT Kernel (2013). 

Paul is a Certified ScrumMaster, a Certified Lean Six Sigma Black Belt, and has been a member of the CROSSTALK Editorial Review Board since 2004 and continues to serve on the board in 2013.  Past and current clients include Raytheon, L3 Communications, BAE, Alion Science and Technology, Northrup-Grumman, and the Department of the U.S. Navy. 

(R) CMMI is registered in the US Patents and Trademarks office