- 4.1 What You Will Learn in This Chapter
- 4.2 BOND Case Study Background
- 4.3 What Is a Gap Analysis and Why Is It Crucial for Agile Organizations?
- 4.4 Keys to Conducting a Gap Analysis for an Agile Organization
- 4.5 Example of "Potential Weakness" Against CMMI in an Agile Organization
- 4.6 Running Process Improvement like a Project
- 4.7 TWG Approach for Agile Organizations
- 4.8 Revisiting the Goal and Challenges on the Process Improvement Project
- 4.9 Alternative Practices and Tailored Agile TWG
- 4.10 Returning to the Peer Review Example
- 4.11 Tailored TWG Techniques and Lessons at BOND
- 4.12 Preparation Work for Running Agile TWGs
- 4.13 Packaging of Processes
- 4.14 An Agile Organizational Process Asset Structure
- 4.15 Process Asset Guidelines Used at BOND
- 4.16 Different Organizations with Different Process Asset Structures
- 4.17 Agile TWG Roles and Responsibilities
- 4.18 Effective Techniques to Run an Agile TWG
- 4.19 Separating the TWG Work from the Lead Offline Work
- 4.20 What Do You Do When You Find a Gap?
- 4.21 Answers to Common Questions When Running an Agile TWG
- 4.22 Do I Need a DAR Process?
- 4.23 Do I Need to Verify Everything I Develop?
- 4.24 Do I Need to Make Sure the Steps in My Processes Are in the Right Order?
- 4.25 Do I Need to Make Sure Process Descriptions Are Not Redundant?
- 4.26 Can Requirements Be Captured in an Email or PowerPoint Slides?
- 4.27 Do Requirements Need to Be Captured in Single "Shall Statements"?
- 4.28 Formalizing Informality
- 4.29 Summary
- 4.30 Summary: How Agile Helps CMMI
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.5 Example of "Potential Weakness" Against CMMI in an Agile Organization
Somewhere during every interview as we are talking about how the individual executes his or her job, we get to the products they produce as part of executing that job. Eventually, I ask:
- Who else looks at these products you are producing?
This discussion leads to the question about whether they conduct peer reviews on their products. Often the answer I get in Agile organizations is:
- We don't do formal peer reviews on our products.
On the surface, this triggers a "potential weakness" against the CMMI model because peer reviews are a specific practice in the Verification Process Area of the CMMI model. We don't have enough time to dig into each area I identify as a potential weakness during the one-hour interview. In most areas where I find potential weaknesses, I just make a note that those areas require more investigation and probably further discussion.
As an alternative, I could just list as part of my report all the areas my client must fix to "comply" with the CMMI model. I could tell them I heard you don't do peer reviews and you need to do peer reviews because it is an expected practice within the CMMI. This is actually how I have observed the CMMI model used in many organizations. It is an example of using the model in a prescriptive way. This is not the way the model was intended to be used by its authors, nor would this approach help achieve the goal my client is looking for.
If I were to use the prescriptive approach each time I found a potential weakness against the model, I would "impose" something extra for the organization to do, and therefore add work on top of what they already do without fully understanding the value of that added work.
This approach, in my view, would be a huge mistake particularly in a successful Agile organization that is relying on their existing proven "Agile culture" to continue to bring them the success they have achieved in the past.
This approach may appear to be the most direct way to prepare the organization for a formal appraisal. It would also be the easiest thing to do as a consultant because it requires the least amount of effort.
However, from experience I know it is also the fastest way to raise the risk of driving this organization away from its Agile culture, leading it to a less efficient process than it currently has. Each time I take this approach to a potential weakness, I raise the risk of making this organization less competitive in the future.
I have observed that many process improvement professionals take this approach, and I understand why. It is natural to assume that people who developed the CMMI model are probably smarter than most process people are and the likelihood is that most organizations should be complying with whatever expected practices exist within the model.
What is frequently missed in this line of reasoning is the following implied myth:
This myth rests at the core of why we so often hear that Agile approaches conflict with the CMMI. When the model is used this way we are inappropriately utilizing the model to dictate implementation, or "how to" issues the model was never meant to address.
I will explain further how to handle these apparent conflicts as they arise, and why the vast majority turns out to be no conflict at all. First, we need to discuss the recommended plan to move forward subsequent to the gap analysis.