Indicators of Agile Maturity

Consider this a guest posting. Recently a colleague and I were discussing the best indicators of Agile maturity. He came up with an interesting indicator. Below is the email he (Geert) sent on the subject. The approach requires close observation of the behaviors and attitudes of the team. This is valuable because such observation will uncover other strengths and weaknesses. I think you will find the perspective interesting.

Excerpt from Geert’s email to me….

I think you can measure the maturity of an agile development team by looking at how they want to use hardening iterations and where they would like to put them.

The text in red identifies actions one can take to help move to the next level … the levels go from 1 (novice) – 4 (mature). After that I tried to explain where unified backlog management fits into this and why there is really a need for it after a team reaches the fourth level.

1. A beginning agile team will prefer to schedule 6 hardening iterations after a 12 iteration development plan. This is “agile” to the hard core “waterfall guy”. A lot of people will actually think they are doing agile, just because they renamed the phases in the development process. People will say “whatever” when they are asked if they like “the new agile approach”. This is still a safe mode to operate in, the “waterfall” process is still there but especially if the discipline and goals of agile are not understood people will really find it cumbersome. Getting past this stage is essential in growing in agile (this is the “painful” stage – because benefits are not clear to anyone). The only thing people have remembered from the meetings is “cool, we don’t have to write specs anymore”. Instead they understand they are now writing cards and should be accepting them (but they don’t have the discipline to do so, especially because they don’t “get it” yet). What will typically happen here is that development management will tell the people the process needs to be followed, cards have to be accepted, etc … A next step is typically that there should be an explanation of “known bugs” in the iteration… not because it’s useful to anyone, but to tell people that this is exactly what we are trying to prevent from happening! Make them realize that a card can’t be accepted with outstanding bugs on it.
   
2. As time goes by, the team will mature a bit and you will see the seasoned agile team will shrink the number of required hardening iterations at the end, just because they understand they need to “fix” the high severity bugs as they go and QA understands they need to test closer and better early up in the release cycle. More matured agile teams have been told to accepting cards will be followed more strictly and processes need to be followed. The team will start understanding the benefit of agile and although some will still see it as a corporate tax, they “feel” there is something different about how they do things. Here you have to do whatever you can to encourage there is a trust relationship between Dev/QA and documentation. They have to learn they are all essential in the process and all understand how it works. This can be done in a variety of ways. For example why not let a development demo done by someone from Documentation (if they feel up for it), or let development explain the open bugs to everyone present during the demo, while let QA explain how a certain problem was addressed… this is somewhat controversial, but it works.
3. Further down the road the team will notice that by adding a hardening iteration in the middle of the development cycle (and flushing out even lesser priority bugs earlier on in the process), it will help them to maintain cadence later on. Usually this proposal comes from the team itself. If you get to this stage you can say you have a team which is starting to “live” the agile way. Some members of the team will say “I don’t care if it’s waterfall or agile, I can do whatever”, but they will have been transformed in their mind and really never want to go back. From this point on, the team starts growing and is self maintained… and they get better at it. Now is the time to encourage this team to train other teams and share experience with others. The team can still grow further but expose them to the experience of others. Product management better be ready at this point understanding that this is not the team they were working with before and it’s the goal of product management to come closer to the development process (closer than they are now – which is typically during demo time).
4. The final step of maturity is there when the team starts understanding “hardening is not required anymore”, because they made fixing bugs part of their daily routines. They understand bugs will need to be fixed anyway, so there is no point waiting for the hardening iteration to do that. They have completely nailed it down, in most case if catastrophy strikes code can be release almost immediately (there is always the need for some QA testing and getting to the desired image). In this context “immediate releasability” is in relative context. It means : “There was no way we could have done it faster”. For some projects it may be determined that untested story cards are removed, or sometimes when there is a really large feature being implemented in the codebase, you can leave it “inactivated” if possible. The team is now a 100% agile team, and product management has to be brought into the mix on an almost daily basis because now you can start leveraging the whole team as a software factory.

After teams have hit stage “4”, the product management team will really start appreciating the benefit of having a backlog available at all times. That way “smaller items” can be added easily if development is done early. Release planning is defining the “must have” backlog for the release and iteration planning is just a run-time orchestration of feeding the backlog to the development teams.

In very mature teams you will see that bugs end up on the backlog as well, with a high priority, and the backlog is nothing but a set of card decks, where everyone in the team takes a card from their stack when they finished the previous card. Bugs found by QA are added on top of the development deck (because QA has to be able to complete testing and signoff the card as soon as possible). Development completes cards and adds them to the bottom of the QA desk.

Product management always has access to the development cards that have not been started yet, so they may reshuffle the stack as they want. Development can really only see the top card from the stack anyway.

You will start to notice that you need an agile development team before you can leverage the power of backlog management like described here. I think this growth is natural (and can be boosted with proper management), but will require time.

Of course such teams are not created by putting bodies in a room and telling then “you are a team”. This requires trust in each other a lot of trust … and experience … a lot of it… so bottom line, it requires time. Time for people to learn to trust each other, time for people to grow in the maturity curve and time for people to understand and learn to accept this has true benefit to them.