Skip to main content

Agile maturity

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 successful 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 don't 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.


Popular posts from this blog

Using xUnit.Net with .Net 4.0

I’ve been using xUnit.Net for a while now. It’s just a tiny bit cleaner and slightly less abrasive than other .Net unit testing frameworks. Leaving out unnecessary stuff like [TestFixture] and shortening Assert.AreEqual to the equally clear but shorter Assert.Equal don’t seem like big improvements but when you type them several times a day tiny improvements start to add up. I also like the use of the [Fact] attribute instead of [Test]. It shifts the focus from testing to defining behavior. So how do we get all this goodness working with the Visual Studio 2010 beta?

Square One available on the Android market

This is just a short post to let you know that a first version of the Android app I’ve been working on for the last couple of weeks is available on the Android market. The app is called Square One and it’s a simple bassline synthesizer. It’s free so try it out and let me know what you think of it, but be prepared it’s still an early version. I hope to add more features in the next few months and maybe build something that can be used to create real music.The lower part of the screen contains the sequencer controls that can be used to program your own bass lines. On the left is a four by four grid of buttons where you can select a step in the sequence. On the right you can select the note to be played on that step. When you’re done you can press Start and the sequence starts playing. The knobs on the top can be used to control a couple of parameters from the synthesizer engine that creates the sound. You can control the cutoff frequency and resonance of the low-pass filter, attack and …

Building Android projects with Jenkins, Ant and Mercurial

I have recently set up a Jenkins build server for my Android projects hosted on Bitbucket. It’s not difficult but there are a couple pitfalls and the information on how to do this isn’t available from one single place so I decided to document the process and put up the information over here. Maybe other people will benefit from having a step-by-step guide too.