Tuesday, February 22, 2011

Are Level 5 CMMI Process Areas compatible with Agile?


After a quantitatively manage organization, the next objective is an optimizing quantitatively managed organization. An organization that is constantly improving. CMMI level 5 process areas deal with this. Improvement, change, should be done (otherwise, the organization is left behind by others) but it should be managed with care, not to overwhelm the organization.

The first process area is Organizational Innovation and Deployment (OID). Its goals and practices represent a measured way of selecting and deploying improvements. The second process area is called Causal Analysis and Resolution (CAR) and aims at resolving the root causes of defects for ever.

The specific goals and practices for OID are:

SG 1 Select Improvements
SP 1.1 Collect and Analyze Improvement Proposals
SP 1.2 Identify and Analyze Innovations
SP 1.3 Pilot Improvements
SP 1.4 Select Improvements for Deployment
SG 2 Deploy Improvements
SP 2.1 Manage the Deployment
SP 2.3 Plan the Deployment
SP 2.2 Measure Improvement Effects

and for CAR are:

SG 1 Determine Causes of Defects
SP 1.1 Select Defect Data for Analysis
SP 1.2 Analyze Causes
SG 2 Address Causes of Defects
SP 2.1 Implement the Action Proposals
SP 2.2 Evaluate the Effect of Changes
SP 2.3 Record Data


Both of these processes are designed to work in a quantitatively managed organization. CMMI states that if it isn’t quantitatively managed, it would work, but it wouldn’t be as effective. I wondered when I started reading the book if optimization wasn’t left for too late in CMMI. In one side, how would you optimize if you can’t measure? On the other, my experience with Agile is that optimization comes from the very first moments, at the standup and in the retrospective meetings where opportunities for improvement are detected. Of course all these optimizations are really subjective, as the improvement they provide can’t really be measured.

Another point that I wanted to make is that CMMI mentions that everyone should be empowered to propose optimizations. This goes very much in line with the lean approach to optimization.


I didn’t see any point of incompatibility in these areas. Having a framework in the organization to do Kaizen is very important for the organization as it allows to optimize with the organization’s objectives (i.e. with everyone aligned) , it allows to do it in an orderly fashion and it allows to really know what is been optimized and how much.

Saturday, February 19, 2011

Are Level 4 CMMI Process Areas compatible with Agile?


I merged the process areas in level 4, because they are really inter twinned and probably don’t make sense to do one and not the other. The first one, the Organizational Process Performance aims at “establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes”. Based on these baselines, the Quantitative Project Management process area sets the objectives and “quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.

The Organizational Process Performance goals and practices are listed below:

SG 1 Establish Performance Baselines and Models
SP 1.1 Select Processes
SP 1.2 Establish Process-Performance Measures
SP 1.3 Establish Process-Performance Baselines
SP 1.5 Establish Quality and Process-Performance Objectives
SP 1.4 Establish Process-Performance Models

The Quantitative Project Management goals and practices are listed below:

SG 1 Quantitatively Manage the Project
SP 1.1Establish the Project’s Objectives
SP 1.2 Compose the Defined Process
SP 1.3 Select the Subprocesses that Will Be Statistically Managed
SP 1.4 Manage Project Performance
SG 2 Statistically Manage Subprocess Performance
SP 2.1 Select Measures and Analytic Techniques
SP 2.2 Apply Statistical Methods to Understand Variation
SP 2.3 Monitor Performance of the Selected Subprocesses
SP 2.4 Record Statistical Management Data

Metrics? What metrics?

In CMMI Level 4, the organization reaches a level where the existing processes can be quantitatively measured. Objective objectives can be set based on these measures. Being able to measure is vital to being able to manage and optimize. Jurgen published a post recently that states “You cannot manage what you don’t measure”.

A very important point to keep in mind when selecting what to measure is that these metrics need to be compatible with the Agile values and practices. Wrongly selected metrics may create dysfunctional behaviours, detrimental to the organization’s objectives. Dave Nicolette has a very nice presentation regarding Agile metrics. Some of the metrics he discusses are “Running Tested Features”, “Hard Financial Value” and “Earned Business Value”. I wonder, with these metrics, how to handle at the organizational level the context differences among the projects. I mean, each project is different, runs under different circumstances, will deliver business value in a different way, etc. All these factors need to be considered to draw conclusions from the metrics.

These metrics need to provide the picture needed by upper management to take decisions and manage risk appropriately. Being able to visualize the processes used, detect and resolve problems is of utmost importance in mature organizations.

Can everything be measured?

There’s a nice quote by Albert Einstein in Dave’s presentation that says “Not everything that counts can be counted, and not everything that can be counted counts.”. Is there place for subjectivity in a mature organization? How and where would it work? Agile methods stimulate optimization since the very beginning and this is performed, in most cases, subjectively. Teams introspect on the previous iteration, try to determine how they feel and propose ideas that would optimize the process. At upper levels, it would be impossible to optimize this way. Managers need to see the broad view and the only way seems to be through measures.

Keep it light!

I must confess that after reading both process areas in level 4, I ended up a bit scared. It really sounds difficult and requirements seem pretty heavy. Agile processes are characterized by their minimum overhead. The machinery required to measure and optimize processes shouldn’t increase this overhead significantly. For this, measures should be taken in the most automatic way, only what is needed should be measured and when it’s not needed anymore it should be dropped. There should be constant improvement in the improvement processes.


Being able to measure, to understanding where it is standing allows an organization to set improvement objectives. These measures need to be align with the Agile philosophy. The improvement machinery should be kept light.

Wednesday, February 16, 2011

Is the Decision Analysis and Resolution Process Area compatible with Agile?


The Decision Analysis and Resolution process area, a process area at level 3, aims at “formal evaluation process that evaluates identified alternatives against established criteria.”

Below are the specific goals and practices:

SG 1 Evaluate Alternatives
SP 1.1 Establish Guidelines for Decision Analysis
SP 1.2 Establish Evaluation Criteria
SP 1.3 Identify Alternative Solutions
SP 1.4 Select Evaluation Methods
SP 1.5 Evaluate Alternatives
            SP 1.6 Select Solutions

Inclusive and Fair

The process should be inclusive and fair.

Inclusive: All stakeholders should be involved in the decision. With this, I am not saying that all stakeholders need to agree on the solution. Probably this is impossible or too costly. I am just saying that everyone should be able to participate in the decision process, express their opinions, being heard. A good facilitator will increase the chances of everyone being heard and of taking a good decision. Being included in the decision process provides great encouragement to follow through the selected paths. Collaborative decision making is of utmost importance in Agile.

Fair: the process should be fair. Every person in the team should feel that it was not an arbitrary decision imposed. The decision was taken using a process that they understand and consider fair. Of course, not everyone will agree, even if a very fair process is used. However, even not agreeing, if they consider that the process was fair, they will accept. On the contrary, if the feeling is the decision was imposed through a not so transparent process, the decision taken will be very difficult to accept. An excellent paper regarding this topic can be found here.


I believe it would be very beneficial to have a defined formal process that can be used to take difficult decisions. To be more Agile, the process should be inclusive and fair (which are really very inter twinned)

Tuesday, February 15, 2011

Is the Risk Management Process Area compatible with Agile?

The Risk Management process area, a process area at level 3, aims at foreseen risks so that they can be mitigated in case they occur.

Below are the specific goals and practices:

SG 1 Prepare for Risk Management
SP 1.1 Determine Risk Sources and Categories
SP 1.2 Define Risk Parameters
SP 1.3 Establish a Risk Management Strategy
SG 2 Identify and Analyze Risks
SP 2.1 Identify Risks
SP 2.2 Evaluate, Categorize, and Prioritize Risks
SG 3 Mitigate Risks
SP 3.1 Develop Risk Mitigation Plans
SP 3.2 Implement Risk Mitigation Plans

Is there the need of a risk management process area in an Agile organization?

I have heard this question a lot in organizations that transition to Agile: How does Agile handle risk management? This question usually comes from project managers used to Waterfall methodologies where maintaining a list of potential risks and how to mitigate them was of utmost importance. Why? Because these risks appeared late in the life of the project, when a good percentage of the budgeted money has been expended and there wasn’t much space to take decisions. Been able to deal with these risks at that moment decided the fate of the project. Agile approaches risk management differently. Agile tries to deal with risks as early as possible or as soon as risks appear. The risk that a user story entails is a decisive factor in the prioritization of this user story. If a new risk is detected, constant reprioritization assures that it will be dealt with soon. With this approach, the fate of the project is decided when there is still room to maneuver and money to do it. Instead of trying to foresee risks in the future and imagine solutions, risks are aggressively attacked. A side effect of this approach is the infrastructure needed to deal with risks is lighter than the one needed in Waterfall. Would you need a list of risks if you know that the top priority user stories are attacking the same set of risks? Not too sure. Would you try to imagine how to deal with them if they are going to be tackled by the team in the next iteration? No need to draw in the air, right? The processes and practices in Agile make up the risks management infrastructure.


Risk Management is embedded into the process in Agile. Therefore, I am not sure this area would be too valuable.

Monday, February 14, 2011

Is the Integrated Project Management Process Area compatible with Agile?


The Integrated Project Management process area, a process area at maturity level 3, aims at establishing and managing projects “according to an integrated and defined process that is tailored from the organization’s set of standard processes.”

Below are the specific goals and practices:

SG 1 Use the Project’s Defined Process
SP 1.1 Establish the Project’s Defined Process
SP 1.2 Use Organizational Process Assets for Planning Project Activities
SP 1.3 Establish the Project's Work Environment
SP 1.4 Integrate Plans
SP 1.5 Manage the Project Using the Integrated Plans
SP 1.6 Contribute to the Organizational Process Assets
SG 2 Coordinate and Collaborate with Relevant Stakeholders
SP 2.1 Manage Stakeholder Involvement
SP 2.2 Manage Dependencies
SP 2.3 Resolve Coordination Issues

Can the Organization knowledge model be more people oriented?

CMMI defines a level 2 organization as  one that can plan and manage their projects, but there isn’t a unified view (in the organization) on how to do it. In the next level, there’s a set of defined processes that individual projects use, tailoring them to suit their specific needs. Therefore, the company has a centralized, unified view on how to plan and manage projects. The flow repository -> project isn’t unidirectional. As the project ‘learns’, this knowledge is pushed back to the central repository. This model not only allows to have a unified view, but also allows reusing and learning inside the organization. I published in previous posts that I wasn’t sure that all knowledge needed to develop software could be contained in a central repository. I still recognized that maintaining a central repository that allows learning at the organizational level could be very beneficial. It’s hard for me put up in words what I think it would be missing in an Agile environment to complement and improve this learning model. I believe it may be this culture where more senior people seat with junior people to program or to resolve a difficult issue. Perhaps is just that the CMMI is a model centered around processes while Agile in centered around people. Should this learning process be shifted towards people in an Agile organization? How should it be done?


Having worked in many companies, I always have the impression that each project has its own life (use its own processes, tools, etc.). This shouldn’t be the case in a CMMI level 3 organization. The organization’s knowledge should be leverage inside the project, and the projects learnings should leverage the organization’s one. Can this model be shifted towards a more humanistic, not so process oriented one, to make it more compatible with Agile?

Other Areas 

- Is the Organizational Process Definition Process Area compatible with Agile?

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?