Jul 042011

People seem to don’t really know how they should handle the two contradicting approaches in the world of software development – the traditional way with CMMI on the one side, and the Agile methods on the other side. For those who can’t (or don’t want to) decide for one camp or the other, the diplomatic answer is: Do both! Does that make sense? Let’s check.

What is the core of the CMMI philosophy?

It’s a strong belief in the process.

CMMI itself is a model and agnostic to a specific process, it just defines requirements a process is supposed to fulfill. Implementing the Deming Cycle of quality control (“Plan-Do-Check-Act”), CMMI requires that the process is defined upfront (“Plan”) and then during execution (“Do”) checked for compliance. Reflection on the effectiveness (“Check”) and actions to improve the process (“Act”) are done after the process has been executed. Improvements are therefore aimed to benefit the next project using the same process.

The ultimate aim of CMMI is to have standardized processes across the entire organization – i.e. there is one way of developing software within a company, used by all projects. Projects and people are expected to adhere to the defined standard or record and justify deviations.

CMMI considers the process as the key to make people more productive. In other words, it values the process more than the people.

What is the core of the agile philosophy?

It’s great care for the outcome.

Agile processes are highly iterative because they want to ensure frequent feedback (from the client) on the results (executable software) produced by the team. They are less concerned about how the outcome gets produced (the process). One could say: “We don’t really know what the right process is for this particular team and problem, so we don’t dictate anything and let them find out. We suggest some good practices (e.g. onsite customer, pair programming) and make sure they measure the outcomes frequently and reliably (backlog and sprints).”

Anything to combine?

The two philosophies couldn’t be any more different. While CMMI defines and measures how the outcome is produced, the agile methods simply measure the outcome directly. Some consider exactly this contrast as the chance to combine the two.

From a knowledge work perspective there is no point in doing that. Both have different strategies how they try to improve productivity – they don’t complement, they contradict.

A software project (domain, problem and team) is a highly complex system with many variables, unknowns and dependencies. Upfront definitions, as required by CMMI, are always at risk of being outrun by reality. Improper processes, however, hamper productivity.
Complex environments are like feedback control systems. Effects need to be checked after each operation, not only after the project. Focussing control on the outcome, the process can and should be adaptive, and the team be free to learn and develop its own way. This is why the Agile Manifesto values individuals and interaction more than processes.

CMMI may have some interesting practices (to what extend their attempt to turn everything into routine work is applicable to software development will be subject of a later post). However, focussing on the process creates functions where people’s reason and creativity is needed, and it distracts the view from what really requires all attention when solving a problem – the solution. The agile approach is therefore much more straightforward and naturally effective.

One thing the agile and knowledge working community still need to think about is sustainability in a post-CMMI world. How can an organization continuously improve and learn from successes and failures?