For years we’ve been using Bruce Tuckman's team development model to guide Agile team development. You know the one: the Forming-Storming-Norming-Performing pattern that we're all trained to say when we get the question, "How do you handle team performance?" It's become the standard model, in spite of its own evolution over time and in spite of alternative models that can be more effective.
Tuckman created his model in the 1960s and added a fifth stage — Adjourning — in the 1970s. Ed Kur elaborated the model in the early 1980s with an Informing stage that described the external interface of a team and articulated the synergy among Tuckman’s stages.
In all cases, this team model and its variations were intended for project teams, which have a beginning and an end. But Agile teams are intended to be both high-performing and sustainable. So I have some reservations about the Tuckman model as a way to talk to Agile teams, their managers, and client organizations as a whole.
On the other hand, there is another model that seems more useful. In the 1980s, Allan Drexler and David Sibbet created a high-performing team model that I've found to be extremely helpful for introducing teams, developing them, and diagnosing their progress as they learn to work more and more effectively. Since team development is iterative (in depth) and incremental (in progress) we can also relate team development to Agile practice and help teams start to review their own development, in retrospectives for example.
Like all models, it needs some interpretation for individual teams, clients, and situations. Nonetheless, let’s take a look and walk through some ways to think about using it with Scrum teams.
Think about starting to coach a team. The stages represent a natural flow of engagement and commitment. The first stage (“Why”) is where we talk about Agile and give an orientation to the approach (Scrum, Kanban, etc.). It's also where a product owner presents the product vision and describes why the product &mash; or enhancement, or whatever — is important and how it will benefit customers and the company.
As the team becomes oriented, relationship building and trust building start to occur naturally. This is important for Agile, as the teams must start to learn to diminish the importance of their disciplinary roles and think across disciplines as a team. That warming up period is Stage 2 (“Who Are You?”).
Stages 3, 4, and 5 (“What Do We Do?”, “How Do We Do It?”, “Who Does What?”) create a circular pattern for reinforcing team development. Starting with planning (release and iteration), the questions of each of these stages come into play and offer the coach or ScrumMaster a chance to reinforce cross-functional teaming, shared commitment, and the like along with the business at hand.
The team can be reminded of this pattern in a very simple way: Post the team model in the team room and periodically ask, “How are we doing?” These thoughts, over time, reinforce interdependence and fosters expanded skills. Note also that this stage is also the transition between creating the team and sustaining the team — an important watershed for developing teams that will "live together" for a long time. In all cases, gentle guidance and thoughtful questions are the rule here.
The last two stages are about performance enhancement and continuous improvement. I tend to use them — particularly the “Wow” stage — as reinforcement during retrospectives as the team does something really well, or shows the courage to admit a failure and accept it as an opportunity for learning. Or when it exceeds its commitments and learns what it's capable of.
The last stage (“Renewal”) ends or resets the model (in the case of new personnel, for example), but Agile is more circular than that. If you use the model as a metaphor for team development as teams practice and continually improve their craft, then good team retrospectives lead back to the Stage 3-4-5 activities: release and iteration planning for the technical work, and deeper team improvement for the team's growth. This can become particularly important when a team thinks it has continuous improvement nailed and doesn’t need to learn any more. It might help to conceptualize this as an upward spiral, rather than a V.
Essentially, having a model like this, and explaining it in a way that links Scrum behavior and team performance, can help a team develop into a self-sustaining powerhouse. Try this out with your teams. And don’t forget the quote from George Box, "All models are wrong; some are useful." This one works for me, but as the old TV ads say, "Your results may vary.”