Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not mature enough to be part of an agile process that requires self managing teams.
I’ve learned to recognize three states a team can be in in terms of maturity -
The trick most team leaders need to do is to recognize which stage a team is in, and to advance their team to the next stage.
I would easily say that most teams are chaotic – either in technical lack of knowledge (‘what’s source control?’), lack of motives (‘I just code X lines of code and try to avoid QA’), or lack of ambition (‘things are fine the way they are’)
You can’t take a team that doesn’t even do source control, and say “you’re self managing from now on, GO.” - no one will know what to do, or have any inclination to do it.
The process of bringing a team to maturity, where a team leader as a dictator is never needed, still lacks a name. I’ve been asking around for possible names for this process. some of them were quite interesting:
Different team lead tactics apply to each stage. For the same reasons Scrum Masters (who are nothing but active coaches) fail to really help immature teams, as do team dictators, who hurt more than they help truly mature, self managing-able teams.
-- if only to bring some much needed peace and quiet to a team that might be mostly struggling to keep its head above water all day long.
A dictator team lead is there in the first stage, to bring the team up to a specific state, where they also have the time and patience to learn new things. The team lead will help put out fires and put the team in a bubble so that decision making becomes easier until the team can make its own decisions. they will start doing code reviews and many of the things this blog advocates for.
Many of these same things will be seen with very big question marks on the faces of many agile coaches out there. They fail to realize that a chaotic team still isn’t ready for a coach. it needs a direction, a back wind, and an open road to get going.
As the team lead feels that the team has reached some “safe shore” – they will move on to the next stage in the team’s life – the learning stage – the stage where a team will learn the skills needed to become self managing, all within a very concrete series of constraints that will slowly open up as the team progresses.
For example, the team lead will insist that code reviews be done on each check in, but will teach the team to do its own code review so that the team lead is no longer the bottleneck, and so that the team learns essential skills for code quality and decision making on what’s an acceptable piece of code.
Slowly but surely a team can progress to become fully self managing. At each stage of the team’s life, it learns skills that help it make its own decisions, until, at some point in time, the team lead does not need to make any day to day decisions. The team has all the skills needed to move on to the next stage.
This and the next, are the stages many scrum masters need in order to achieve anything. Sadly, most teams are not at this stage, and nothing but some good old fashioned dictatorship can help change things for those teams.
A team that can self manage just needs a coach for the personal team members, to grow them, to teach them new skills. They need someone to keep an open eye for interesting things that they may not have noticed, and they can use (not need!) a second look every once in a while if they are facing interesting dilemmas.