We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?
Here the team is typically innundated with three sources of new information: the Agile process and practices, the nature of the project and the other people in the team. This can be overwhelming and people will react in diverse ways: calm wait-and-see, rebelliousness, passive-aggressive, excitement, etc. If the team has an effective coach or mentor shepherding them through this, then feelings will tend towards excitement. The reality of learning so much at the same time will make the first few weeks of the team’s time together quite exhausting. People will be actively fighting old habits, and people around the team will be asking lots of questions. Retrospectives will usually show that the team is impressed with their own teamwork and communication and will also show some disappointment with specific agile work practices.
After only one or two iterations, the team will transition into the Storming stage of development. Because Agile methods “front-load” the learning and the crisis, this forming stage comes fast, but it is also relatively mild. (Front-loading the learning means that all the problems that an organization has that hold it back from delivering quality work quickly are made visible in the first couple of iterations.) People are not used to a project being in crisis right at the start. It is critical for a coach or mentor or manager to be aware of this effect and expecting it. Again, for emphasis: an Agile project is in crisis immediately!… and this is perfectly normal and healthy. If the organization and the team are able to find means of dealing with this early crisis, then the project will continue and build larger and larger successes. On the other hand, if the organization or the team try to ignore or hide the problems, then very quickly work will revert to the old way: bureaucracy or chaos.
After about four to eight iterations, the team will reach a fairly comfortable place: the basic agile processes and practices are understood, the organization and the team have removed some basic obstacles to getting work done (and consciously left some obstacles in place in all likelihood), and everyone on the team has a basic level of comfort with their role. The challenge at this stage is to avoid falling into the trap of complacency. Although comfortable, this level of performance is probably not all that much better than the old way. There will be real advantages: regular delivery of work, good communication between stakeholders and the team. But there will be many obstacles still to be removed, and the team has a long way to go in its development. If the team becomes complacent, then it is critical that a catalyst be introduced to incite the team to further development. Often, this can be as simple as a systematic and intensive program of capability building. As team members learn and practice new skills: process skills, technical skills, people skills, strategic skills, business skills… and as they become more and more aware of each other’s capabilities, they will also become more and more aware of areas for improvement. Incentives need to be provided to help team members focus dilligently on self-improvement and team improvement. The iteration retrospectives become critical to help with this process… the tricky bit is that this is the stage when people start to think the retrospectives are no longer necessary!
The transition into the Performing stage for an agile team is gradual and happens over a fairly extended period of time. The definition of “getting to done” will gradually expand to allow the team to go from zero to full delivery of the end results every single iteration. There will be a temptation to split up the team and use these experienced team members to seed new agile teams – resist this temptation! Breaking up the team at this point destroys the value of time and effort invested in the team. It is much more effective to start a new team from scratch. The essence of a performing agile team is not the transferrable knowledge about agile processes and practices. Rather, the most important result of the team-building process combined with the agile process is the team itself.