An Agile Team's Progression Through the Stages of Team Development
I read an old colleague’s article about ‘Adaptive Leadership’. I really enjoyed it. He posted it on LinkedIn. Go check it out, it’s a good read. It’s his fifth article on there and I hope to see more. In it, Brian discussed and explained the different leadership styles used during different team development stages (you know, forming-storming-norming-performing). We all know the goal is for the team to get to the performing stage as quickly as possible but how much influence do we as managers (or better yet, leaders) have over the team’s development stage. Can our leadership style speed up or slow down the team’s developmental progression?
In the Scaled Agile Framework, the key leadership roles are Scrum Master, Release Train Engineer (RTE) and Value Stream Engineer (VSE) for the Agile Team, Program and Value Stream, respectively.
Team Development and Leadership Styles Matrix as adapted from Bruce Tuckman’s Stages of Group Development:
Team Development Stage | Suggested Leadership Style |
---|---|
Forming | Directive |
Storming | Coaching |
Norming | Supportive |
Performing | Participative |
Bruce Tuckman proposed that the recommended leadership style during the ‘Forming’ stage should be ‘Directive’. Meaning, to provide specific instruction on who, what, when and how to do things and to rally the team to a common objective. I would agree with this to a certain extent, however, if our goal is to form a self-organizing team, taking a directive leadership style too early and for too long during the team forming stage can hinder this development and result in the team relying on a central authority to spark motive action within the team.
Below is a drawing that I made of a typical agile release train’s progression through the stages of team development. This is no hard fast rule. Don’t think you’re doing it wrong if your team’s development hasn’t followed a similar path. Some team’s take longer, some take shorter but they tend to follow a similar curve assuming their aren’t any major organizational changes or other significant disruptive forces.
Let me explain this picture a little bit. Along the x-axis we have time (not to scale) showing three Program Increments and a period of mobilization prior to the first PI Planning Meeting. Each subsequent diamond represents an Inspect & Adapt Workshop and a PI Planning Meeting (the closeout of the previous and kick off of the next Program Increment, respectively). Along the y-axis I’m showing the expected development stage for the team and when I say team I mean an Agile Release Train or 50-125 people organized into 8-12 scrum teams of 6-8 team members. You can read more about the structure of an Agile Release Train here.
The mobilization phase that precedes the first PI Planning meeting is a busy time. It’s filled with discussions about roles & responsibilities, team structure as well as loads of upward and downward communication. It’s a time where the virtual organization of the Agile Release Train is first forming. For organizations new to agile (and even some that aren’t), there is often confusion (or at lease inconsistent competency) with the basics of agile, how to operate agile at scale and where people’s old roles or titles fit within the new virtual organization.
During this period the RTE definitely must take on a more directive leadership style, especially in organizations where the agile competency is low. This directive leadership style will be vital in the lead up to the train’s first PI Planning meeting. The organization that the RTE is responsible for is a combination of event planning and roles & responsibilities communication to the broader organization. However, directive should not be confused with autocratic. Again, we’re trying to facilitate the creation of a self-organizing team. If the RTE is wielding absolute power and moving team members around like chess pieces then we’ve lost. The RTE’s directive leadership style needs to manifest itself in the who’s, what’s and how’s of the scaled agile process but he should still be a facilitator.
A) Storming Spikes while forming
As the team is forming tough conversations will be had regarding the organizational structure. Feelings and egos might be hurt due to fear of the unknown and perceived loss of status or title within the old organization. The RTE should utilizing coaching and supportive leadership styles to help build bridges to individuals feeling anxiety or perceived loss.
B) Peak of Inflated Expectations
The first PI Planning Meeting is the ultimate storming accelerator. What do you think is going to happen when you thrust 150 people into one big room for two straight days of intensive planning workshop. Tensions can run high but if the right mood is cultivated, by the end, everyone will be all smiles. This first workshop, powered by the buzz and energy that comes with it, propels the team to a norming state before the culmination of the event: the commitment to the plan.
C) Trough of Disillusionment
After the first PI Planning Meeting, the team usually finds that mistakes were made, assumptions agreed to were faulty and a storming period begins. As a result, Program Increment #1 is usually home to a trough of disillusionment. However, if the team embraces failure and applies continuous improvement processes within the iterations they will gradually claw their way back up.
D) Working your way out
The PI Planning Meeting for Program Increment #2 usually hits while the team is still storming. Major unresolved issues and dependencies are yet to be resolved and a new cynicism has evolved out of the initial failure of Program Increment #1. This cynicism tempers the euphoric highs achieved at the conclusion of the first PI Planning Meeting but instills a resolve to look at dependencies with a more critical lens.
E) Catching your rhythm
Thanks to this more somber and realistic approach to dependencies between teams, Program Increment #2 usually is where the train strikes the norming stage. Issues and dependencies remain to be resolved but the teams have hit a stride.
F) Owning it
It might take one Program Increment, it might take two but once the team has gelled and the newness and uncomfortableness of planning together, tackling dependencies and maintaining transparency through cadence the team finally hits that Performing stage. Now is the time that we as leaders need to get out of the way and let this self-organizing team do it’s thing and, as Bruce Tuckman pointed out, we can shift more into participants rather than Directors, Coaches, and Supporters.