Agile methodologies have become mainstream in recent years because they provide a better fit to the modern, changing software world. However, they have been very often perceived as incompatible with the CMMI, since CMMI is usually seen as a way to execute software projects in a formal way.
In 2008, Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad and Sandra Shrum published CMMI or Agile: Why Not Embrace Both!, opening a window for those organizations that wish to keep their processes under control while experiencing the flexibility that agile processes provide. CMMI practices are perceived as hostile to agile, self-organized teams because CMMI and agile teams have evolved into different cultures, which drives misunderstandings more often than expected. As an example, agile teams rarely use the word “predictability”, which is critical to the CMMI model.
On the other hand, CMMI is a cross-organizational approach which has proven successful in terms of quality assurance and cost when executed properly, despite the high activation energy that is required for CMMI in an organization.
When an organization decides to go with CMMI, mostly sponsored by upper management, it often collides with self-organized teams who see CMMI as a hazard to their objectives. So how can a big organization achieve technical maturity levels (2-3)?
Removing language barriers
The first problem to be addressed is language barriers. An evangelist or a process engineer needs to deal with teams that use different techniques by speaking the same language. That’s what modern technical communication approaches call metalanguage. By following a metalanguage, you can be sure team members will be able to translate it into their natural lifecycle words: for example, a PMP fan will love talking about “functional requirements” but an agile team member will prefer the term “user stories”. They are talking about same concept, but the way they apply this concept is what it makes it different. In this example, you could use the term “specification” to make both happy and establish a common understanding.
Metalanguage is the first key to success. If you as a CMMI evangelist can sit with an agile team member and a project manager and they can talk with each other using the same metalanguage, you have the language gap covered.
Metalanguage Term |
Formal Methodology |
Agile Methodology |
Goal |
Functional Scope |
Epic |
Business Case |
Use Cases |
User Story |
Appliance |
Scenario Requirements |
Acceptance Conditions |
Review |
Periodical Tracking Meeting |
Retrospective |
Fig 1: Some requirement development classification for customer requirements.
Identifying and using a common metalanguage is how a CMMI evangelist can proceed to next phase, covering maturity gaps, but an evangelist must consider that working on a metalanguage is a never-ending task that will need to be extended and refined continuously.
(Click on the image to enlarge it)
Fig 2: Would you be able to identify whether this is a product backlog or a requirement catalog? The idea is that you can apply your own lifecycle model from common artifacts
Maturity gaps
No lifecycle is perfect. Teams are made of human beings who try to arrange daily work by applying a lifecycle model that often has been defined by someone who is not working and dealing with their problems on a daily basis. This drives many teams to experience maturity gaps, i.e. things that should be done but for some reason are not practiced. CMMI is very clear about good practices (specific practices and generic practices) that must be followed in order to implement a maturity level. When organizations try to achieve a formal CMMI level through an appraisal, they run a great risk that their CMMI adoption will fail. CMMI level renewals fail most often when organizations are working on heavy, bureaucratically implemented techniques, despite the effort made to deploy them in organizational units. Most people know cases in which documentation has been abandoned to be updated “as soon as we got enough time”, or how tests are lightly executed without proper guarantees.
Although often unaware of it, most teams use good practices in their daily work; at the same time, they tend to ignore others that could add value to their solutions. The main reason for failure is the first CMMI principle, known as establishing.
“Establishing” and “maintain” have strong meanings in CMMI, and they generally appear together. Summarized, the two terms mean that any involved artifact or practice shall be defined, documented, and used. All level 2 and 3 process-area specific goals contain one or more “establishing and maintain” practices.
The transfer of a team member from one team to another can lead to trouble (and that happens often in big organizations). New team members can need more time than expected to become productive despite their capability. The reason is clear: a new teammate will make mistakes when trying to fit into the team, and most of us know this can be a stressful experience.
Teams know how to do their jobs… that’s why they exist. They do enough right things in a right enough way so higher management often tolerates any maturity gaps. A team doing a bad job will vanish since they won’t be able to sustain the business. A CMMI evangelist should acknowledge that the practices any team is already following are sufficient to deliver value for the business despite maturity gaps. Evolution, not revolution, should be applied to teams that are working fine. Consider a CMMI-activation timeframe (the needed time to achieve a target maturity level) that can accommodate the effort to move to higher maturity levels.
The good-practices catalog
The assumption from an assessment point of view is that we only need to look at some teams/projects, that other groups work in a similar way and have the same capabilities, but this collides with reality more often than we would like. If we use the assumption to guide change, it can leads to one of the nightmares of any organization: the hell of partial implementation. In this scenario, teams are not able to adapt to the new way of working so they only partially adopt it while abandoning the old practices that enabled them to be good enough for business. This frustration can drive an organization to abandon CMMI implementation.
However, CMMI provides a wide family of good practices. CMMI for Development version 1.3 provides many good practices to cover generic and specific goals. Those practices are only examples of what can be done to achieve the required maturity level. Models can never dictate which practices an organization should follow. A CMMI evangelist or a process engineer must listen to teams. I have had good experiences with listening to team members about the way they perform their work instead of forcing them to change it.
A team that follows scrum on the book guarantees CMMI level 2 as they cover “requirement management” (REQM), “project planning” (PP), “project monitoring and control”(PMC), “process and product quality assurance” (PPQA), “configuration management” (CM), and “measurement and analysis” (MA) in their daily work.
A scrum team performs PP during a scrum planning meeting, they move to PMC during daily scrum, and they perform REQM when they elaborate backlog. Most of the time they have a continuous-delivery environment that requires good CM. To add to this, they usually have some CMMI level 3 practices, as they perform retrospective meetings and often support their daily activities with platforms like TFS or CollabNet, which provide metrics for analysis.
However, integrated project management (IPM), part of CMMI level 3, requires scrum teams to change the production pipeline in a way that abandons pure scrum and so is difficult to implement. IPM offers powerful good practices to help a team meet virtually any need for a particular project. Imagine a stakeholder who requires a particular document based on a set of established templates from a team whose entire wall is covered by colored notes. This kind of thing used to be solved by the product owner, but CMMI practices make this work elegantly.
Countless agile teams adopt agile practices to come up with their own agile lifecycle. Remember that agile is only a manifesto and some principles enumerated with common sense. A process engineer working with a team entering the CMMI world could start by identifying those good practices and uncovering how they match equivalent CMMI practices. For example, look for the way in which they perform peer reviews. Team members don’t even need to know that this is part of the CMMI verification. Agile teams usually conduct demos for members of other teams to expose their weak points. Isn’t this peer review? The same demos also help the stakeholders in improving the backlog, which is requirement gathering at the end.
(Click on the image to enlarge it)
Fig 3. Suggested workflow to improve maturity in teams
Established practices can be gathered into a catalog of good practices using metalanguage. Analyzing this catalog with a CMMI evangelist or process engineer makes teams recognize that they are omitting specific practices in their processes. To cover a missing good practice, they could choose a practice already in catalog that would suit their purposes. Remember that CMMI can evaluate both maturity and capability, so the catalog should contain practices for all CMMI specific goals and CMMI specific and generic practices, which lead to a dedicated CMMI roadmap for the team (see also CMMI Roadmaps: Improving IT for the Business). Teams should be encouraged to take a practice from the catalog or add their own. To anyone who attended a CMMI appraisal process, this task strongly resembles elaborating a PIID (Practice Implementation Indicator Description) for each team, and classifying evidences into this good-practices catalog.
An example of a good practice is conducting a “pair review” - a mix of peer review, one of the most recursive concepts in CMMI, and pair programming - on the fly before committing any change to source control. A pair review requires at least two members. For example, Bob has fixed a bug and requires Joe to perform a pair review. After following a checklist (nothing more than common sense, passing tests, certifying style, and so on), Joe takes responsibility for Bob’s fix by uploading the source code into source control. According to ALM@ Team at Schneider Electric, pair review has decreased the number of bugs and broken builds by almost 70%.
(Click on the image to enlarge it)
Fig 4. A review artifact as set from Microsoft Team Foundation Server.
(Click on the image to enlarge it)
Fig 5. Appearance of an agile continuous-integration build from a released patch. Notice that one team member performs the change, and a reviewer uploads the source code. You can see it in the artifact assignation.
Another good practice derived from agile feedback is the need to document leaks. A leak is nothing but evidence of a broken process and follows the paradigm of a water pipe: there is no problem if a water pipe has a few leaks, until there are too many leaks to maintain desired water flow. When a team member needs to break a process in order to continue working, this team member submits a leak form to be analyzed as part of a retrospective and improvement process. Leak artifact analysis can provide opportunities to improve processes, or to identify risks (leading to corrective actions for example, training sessions). This fits the Agile Manifesto’s “Individuals and interactions over processes and tools” contention that a process is useful while it offers some value to final product in some way.
(Click on the image to enlarge it)
Fig 5. A leak in the project for which a user needed to upload source code into a source-code repository without reviewing. In this case, this leak was due to an urgent fix during a weekend from a maintenance team member.
Conclusions
Agile and CMMI are not opposites but complement each other surprisingly well. Traditional teams covering CMMI practices can learn some practices from traditional agile teams, but we need to use a common metalanguage to do this. A good way for CMMI evangelists to start is by identifying common elements in metalanguage. A good-practices catalog can help an organization standardize the way in which its teams develop by letting them help an agile coach to identify maturity level. The catalog can provide the necessary good practices teams may need to achieve higher capability that will inevitably lead to higher maturity.
About the Author
Nicolás Afonso Alonso is currently software-development technical leader and CMMI evangelist at Schneider Electric. He worked for several years in the space industry as QA team leader in integration projects. After that joining Schneider Electric, he has focused mostly on process engineering for software-development-leading Team Foundation Server activities and ALM foundation planning.