Agile maturity

23. March 2009

In the ten years I’ve been programming I’ve learned two pretty important things.

  1. Project success is about people and teams. No matter your process, good teams will succeed (usually in spite of your process) and bad teams will fail.
  2. Every time you make a rule about something, people will stop thinking about that thing and blindly apply the rule.

This sounds pretty bland, even chinese fortune cookies usually have more interesting things to say, until you think about one of the consequences. You need good people for project success but if you give them too much rules they will stop thinking and become as smart, or as stupid as the rules. Most Methodologies seem to think that more rules is better. If a rule doesn’t benefit you it surely won’t hurt too much, just implement as much as you can and things will surely get better.

This is one of the reasons I’ve never been fond of things like CMMI, the heavier your process, the more rules you implement, the more mature you are. All in the name of repeatability. You don’t want succesful projects to be a fluke you want them to be repeatable. This sounds really good but I think you throw out the baby with the bathwater. You can’t repeat success by copying and pasting because the most important factor is people and you can’t copy and paste people.

This is why I have some trouble with Scott Ambler’s ideas of an Agile Project Maturity Model. Don’t get me wrong. I like the idea of having some scale to rate agile implementations but I dont think the scale Scott proposes has much value. It takes all the faulty assumptions from CMMI and applies them to agile. It just doesn’t fit! Agile is not about repeatability, it’s about adaptability. This is why I’d like to propose a different scale, one based on the Dreyfus model.

I think maturity is about learning. And, coincidentally so is the Dreyfus model. It has five levels

  1. Novice - rigid adherence to rules
  2. Advanced beginner – limited situational perception
  3. Competent - deliberate planning
  4. Proficient - holistic view of situation, rather than in terms of aspects
  5. Expert - no longer reliance on rules, guidelines, maxims

I think organizations learn just like individuals. These levels can be applied to teams and organizations. You see this in Ken Schwaber’s books on Scrum for example. Organizations starting with Scrum should first start applying all the rules very rigidly, but after some time this is counterproductive. The rules can be adapted in project retrospectives, the organization is learning.

A mature organization should apply the right rules to the right projects leaving their professionals with enough room to react to changing requirements in every situation. A mature organizations should also recognize that less mature teams within that organization will need a different set of rules than more mature teams.

Comments

3/23/2009 10:02:21 PM

Machiel

I think you make some very mature observations Smile. I'm not sure Scrum is the best starting point for all organisations. Scrum, with all available resources and marketing, could be a good starting point, but a custom mix of Agile practices could also be used as the initial set of rigid rules. That's why I think Scott Ambler's post is troubling, I want to start my project with a mix of DSDM, RUP and Scrum elements to fit my current problems and context and move up the Dreyfus model from there.

Machiel Netherlands

3/24/2009 8:51:33 AM

Mendelt

Hi Machiel, thank you for your kind comment.

I agree that Scrum might not be the best starting point for all organizations. Organizations that are in the Novice phase need a methodology with a set of well defined rules. Scrum is such a methodology but so is XP, Agile RUP or DSDM.

I don't think mixing and matching methodologies like you suggest is a good place to start for an immature organization. You need some understanding of the consequences of the rules to be able to pick the right one. But a more mature organization or team can probably be much more productive if they are allowed to mix and match.

Mendelt

3/24/2009 9:56:13 AM

Christian

Hi,

The definition of a project is that it has some uniqueness. That means, it can't just be worked on by following specific rules. In addition, people and project teams as a whole are unique. Therefore, the outcome of a project is kind of uncertain (random?).

Companies try to reduce the randomness and uncertainty by applying rules and processes. Although this helps to a certain extend it reduces the positive aspects of uniqueness. As you point out, people reduce their thinking, but just follow the rules. This again contradicts with the definition of a project, which requires unique solutions.

Maturity as intended by CMMI works best for non-unique projects. Projects become kind of a product, which can be produced in a manufacturing process similar to building a car. People become just a ressource. On its highest level it looks like Tailorism. Do people want this? Some do, because it gives security. Others will leave since they want to keep their uniqueness.

What do companies want, followers or innovators? I guess they need both.

A company can achiev this by either limiting itself to a certain type of project or define processes and rules on such a high level that it fits to every situation. In the later, the details get lost and the repeatability is just a fake. In the former, the company limits its market.

In my opinion companies need a balanced solution. There needs to be some structure, but companies need creativity and innovations too. Currently I see the lean software development as such a balanced way.

Christian Germany

3/24/2009 10:08:46 AM

Vasco Duarte

The learning aspect that you mention is one of the issues that Scott misses. But we should not get too hung-up on what he says/writes because he is just a sales man for IBM.

That means that whatever he says needs to be understood in the context of how it sells IBM's products. This means that he is not a person interested only on the evolution of our industry like we, Agilists, should be.

Some of the things he says do make sense though Smile

Vasco Duarte Finland

3/26/2009 10:07:19 AM

bob

Scrum is crap.

An so is this article

bob United States

3/27/2009 9:24:46 AM

Mendelt

Hi Christian, thanks for you comments. I agree, you need structure. For some projects you need more structure than for other projects. I think the important part is recognizing that too much structure or the wrong structure can be more damaging than too little structure.

Many approaches to maturity in organizations seem to be about externalizing structure in rules and regulations. For individuals maturity seems to work the other way around. You start with external structure and you grow by internalizing that structure. Understanding it deeper and deeper. By really "grokking" your process you can adapt it to your needs. I hope we can measure organizational maturity using the same scale. Organizations that can do without the "training wheels" of externalized rules should be recognized as more mature.

Mendelt

3/27/2009 9:31:37 AM

Mendelt

Hi SEM Philipines, you're welcome!

Vasco, you're probably right. This blog post is actually about something I have been thinking about for some time. The post by Scott triggered the thoughts in a way I could formulate them in this post. So at least we can give him credit for making me think. In this case I'm not really interested in his motives but more in the opinion he expressed. I like the idea of being able to assess agile maturity but not as a certification method as in CMMI and not on the scale he proposes. I think a maturity model has much more value when applied internally in an organization to steer improvement. CMMI is usually applied externally for marketing purposes and because of that it is being gamed a lot, there is a lot of money to be made by having a higher CMMI level.

Mendelt

Comments are closed

Powered by BlogEngine.NET 1.5.0.7
Theme adapted from BlogEngine.NET standard theme by Mads Kristensen

Mendelt Siebenga

Mendelt Siebenga with coffeeMendelt Siebenga works as a C# programmer. In his spare time he's been known to pick up Python, Lisp and even a soldering iron from time to time.

You can also find me here