In a post on developer works Scott Ambler proposes a "Agile Process Maturity Model" (APMM), if you are asking "WTF is that supposed to be?" Scott tries to answer that in his first sentence:

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today.

First I was quite impressed by the BWPS ratio (Buzz Word Per Sentence). I count 6 (counting "Agile Process Maturity Model (APMM)" as one). But then I realized that this is what I would highly welcome: Context for Agile Methods. If this means we get an overview of all the process that you need if you do software development and then markers in this process landscape to indicate various Agile Methods to help with this process, that for sure would be helpful. But how would this be a 'Maturity Model'?

So once again I had no choice but to read the complete article, including the comments. I must say, I was disappointed. What follows is basically a ranking of agile process, methodologies or what ever you want to call these. Such a ranking explains the 'Maturity Model' part, but it completely voids the agile part. What value can a ranking of processes have in a context where the common understanding is that processes aren't that important anyway?

So my clear opinion is: No thanks we don't need another maturity model, the existing once are causing enough problems. I know some of my coworkers are reading this blog and are by now probably thinking: "Interesting opinion for the quality manager of our company". So let me explain why I think ISO 9001, SPICE, CMMI & Co are often doing more harm then good.

The problem is the same as with any kind of measurement: If you measure people or they work, they start to optimize for the measurement. For example if you start to measure code coverage and declare high coverage to be good, people will create automated tests for code that gets created automatically, although in most cases these kind of tests are of very limited use. With all the quality norms the auditors look for proofs that a certain aspect of a process gets executed as intended. This is really difficult to do, expect for the cases where documentation is created. But documentation created only for some audit is actually the exact kind of thing you don't want to have. It costs money, gets outdated fast after the audit and has no benefit for your project, your company or the customer.

How to avoid this pitfall is a topic for a different post.