Right from the outset, agile teams are expected to self-organize. Let’s take a team that just started practicing Scrum. To do Scrum well, they must self-organize how they plan the next two weeks’ worth of work during the iteration planning. They must self-organize how to coordinate today’s work during their standups. They must also self-organize how to solicit feedback on what they built (iteration demo) and how they built it (iteration retrospective). On top of that is the matter of actually self-organizing the work of building the actual solution they are working towards.
That is a lot to ask any team, especially one that is newly formed, or one that has recently changed from their old way of working (WoW) to an agile WoW. I, for one, would venture that it is impossible. A newly formed team, or a team that recently changed WoW, have to normalize first before they can carry out those tasks in a self-organizing manner.
The fact that Scrum and other agile ways of working expect this from the outset is what I call the fallacy of instant self-organization.
What is team development?
Team development and team building often get mixed up. Let’s be clear, team development is not team building. Rather, team building can be a part of team development. Team building is a catch-all phrase for activities where colleagues get to know each other better as fellow humans, not just people at work. Team building can be anything from quick social games (like Pecha Kucha or two truths and a lie) or getting away from the office for a celebratory meal, drink or game of bowling.
Team development on the other hand is a deliberate process in which a team takes time to explore its potential; how it can become even greater than it’s been before. Team development is a journey.
What is a team development model?
There are plenty of team development models to pick from. How teams form and develop has been the fascination and research of many people.
Before we move on, let’s recall the wise aphorism by George Box: that “all models are wrong, but some are useful.” Models are like a pair of spectacles. They help us see the world with more clarity to make better sense of it. But they are all inherently “wrong” because they are not the world itself.
That said, models can be very useful and provide insight and guidance for our world of agile teams. As an agile practitioner, I find three models useful: Bruce Tuckman’s stages of team development model, the Drexler/Sibbet team performance model, and Patrick Lencioni’s five beaviors model.
What can we learn from team development models when it comes to self-organization?
Looking across all three models, we can extract some key points about team development.
First, there are no shortcuts to high performance. In all the models, the team has to travel a journey of set steps or stages before reaching high performance. The steps start out very basic, like building trust and getting to know each other, and progresses to something more advanced where we learn to solve work tasks together. This all seems like a given, but it is often overlooked or forgotten.
Secondly, even though the models all lay out the road to high performance as a neat step-by-step journey, the journey is not linear. We are dealing with people, not printers. People and their interactions are messy, complex and to a large degree unpredictable.
Thirdly, regression can happen anytime. As I discussed above, the scenario of a team that has recently changed their WoW is a prime example of team development regression. The abrupt change of their way of working (say, from a traditional approach to an agile WoW) can likely cause the team members to be unsure of their role on the team, how they are supposed to work together now, and can even erode some of the trust inside the team. Regression can also occur when team members come and go, and in the case of significant external changes, regression is always something to be on the lookout for, and it is always a question that leaders should ask themselves when they make changes. Can this change adversely impact the team’s journey to high performance?
The last and most important point seen from an agile practitioner’s perspective is that the models all offer guidance for the team’s journey. Take the Drexler/Sibbet model for example:
Not only does it tell you what’s going on in each stage (by naming the stage intuitively), it also describes how to move to the next step. If you look closely at the first step (Orientation: why am I here?), you see that if left unresolved, you will get patterns (or rather anti-patterns) of: disorientation, uncertainty, and fear. The tools that we as team leaders have to resolve this step and help the team onwards are: providing purpose, team identity and membership.
Continue your learning journey
The Disciplined Agile People Management process blade contains an overview of how to manage people in an agile enterprise.
The Disciplined Agile Grow Team Members process goal contains a collection of tools and practices of how to continuously grow our team members.