People come and go from teams. Sometimes people embrace this, and some avoid it at all costs. There are risks to avoiding changes in our teams related to the development of knowledge silos, competition between teams, and lack of learning to name a few.
So where did the notion of “keep teams the same” come from? Maybe it’s related to the Tuckman model. Back in 1965, and later with an addition in 1977, Bruce Tuckman came up with his highly quoted “stages of group development”.
The stages include Forming, Storming, Norming, Performing and Adjourning. His primary dataset was from a review of the literature from training and therapy groups . . not software teams. Despite all that, his model is still one of the most widely quoted in organizational development literature. (Bonebright, 2010). Even today, there is still nonetheless something very compelling about this model even to people in the software industry. It’s a catchy model.
Maybe it has to do with the relatively intuitive nature of some of the phases. The first phase of his model, Forming, and the last one, Adjourning seem straightforward enough. When new people come together to make up a team with a common goal, you could call it “Forming”. When the team dissolves for whatever reason you could say it has “Adjourned” or as some say “Mourned” to keep the rhyming scheme going. At times though we may be glad that a team has dissolved due to toxic team behavior, and so “mourned” might not quite capture the meaning.
Tuckman’s Model is a linear model that implies that you get together as a team, you keep it the same, and you go through Storming and Norming once, and thereafter you are Performing. I guess that’s not surprising. After all, the era in which Tuckman came up with that model was the same one in which the Waterfall model for software development emerged – another linear model. Linearity was hot.
The linearity of this model is problematic though, especially when thinking about the notion of conflict. It would be ideal if a team could get together, work out all their issues, and then get on with Performing.
If Storming means having conflict, that unfortunately is not a thing that happens only once on teams and then goes away. I’ve been with plenty of product development teams for the last 17 years that have had conflicts and who have “stormed” regularly. Conflict is a natural, reoccurrence when groups of people are together. People can get good at conflict. When armed with the right syntax, at least you have a shot at being more of a skillful communicator. We can train people in how to have “crucial conversations” and to talk about things that are on their minds. If Conway’s law has any truth to it, wouldn’t you want your software built via healthy, productive conversation as opposed to the opposite?
As an ORSC-trained coach, one of the things I do with teams is proactively work out with them how they want to “be with each other” when they are in conflict. We can design and share personal preferences for dealing with conflict when our teams get together initially and when they reteam. It’s quite useful. For instance, you might find out that your team member would like you to ask them to go for a walk outside if you have an issue with them and want to talk about it. You might learn that when another team member is upset, their face turns red and they like to have some space away from other people before invited to a discussion to talk about what happened. You might learn that when Joe has code on his screen, and there is the “Garfield cat” stuffed animal next to his monitor it means that he’d prefer that you didn’t interrupt him.
Moreover, conflict, and dealing with it in a healthy way is also required in the creative process when working out solutions to problems during team discussions. Sam Kaner calls this type of conflict “the groan zone” in his book on facilitation – when people come together to devise unique solutions, they first have divergent thinking, and work out their issues or conflict in “the groan zone”, before converging on their solution. In product development we are devising unique solutions over and over again as we build. Again, Tuckman’s linear model applied to teams is insufficient here.
[Conflict reoccurs in product development- It’s normal.]
In product development we live through cross-functional discussions that have varying lengths – sometimes annoying, sometimes not. When anyone complains about “design by committee” they are likely miffed about going into the “groan zone” as shown above. We want our teams to have healthy disagreements. Having divergent views is necessary to get us to awesome solutions. If everyone’s agreeing with everything everyone is saying on your teams, you might want to look into that.
The fact is, it takes time to hear each other out, to listen to different perspectives, and to come to a resolution and agreement on how to proceed. And, someone needs to forward the action/deepen the learning on the discussion to get things to closure. That takes skill and practice as you want to be inclusive, and enable “all voices to be heard.” The caveat here is that you can’t have discussions go on forever. Otherwise things can feel unproductive and that is essentially demotivating. Experienced coaches who are skilled in facilitation are helpful here. Moreover, great coaches can train anyone to move along discussions like these in a respectful way. Then the coaches can fade out and help out elsewhere in the organization.
Back to Tuckman’s Model, how do you define Performing? Is it just getting the work done? Is it watching people like a hawk? Or is there something else? What does high performance look like? Can you see or feel it? Maybe the energy is visibly high…or maybe the team is quietly cranking out incredible software to your customers regularly. Measuring performance is of interest to many, and there are many different approaches to that.
Some people might try to measure performance with an abstract level of reports and metrics like velocity – which can be easily gamed, and can lead to energy-sucking accounting work and nagging ScrumMasters. Few people want to enter in “hours remaining on work” on a daily basis to compose burndown charts. It’s a total drag. Trust me, I did it 9 years ago – it was a rookie mistake. Others go with a Modern Agile approach of Delivering Value Continuously to customers. Software in the hands of delighted customers, and delivered frequently speaks volumes about productivity, doesn’t it? See modernagile.org.
Research at Google as part of the Project Aristotle study claims that, among other things, the highest performing teams have large amounts of psychological safety. That’s when team members feel free to express themselves without fear or scrutiny. They can essentially be comfortable contributors without concern. Working on team relationships, team gel and the like is an area we will be hearing more and more about in the coming years thanks to this study. It’s about time we took more of a Humanistic stance on software development as opposed to a Mechanistic stance that is ridden with time tracking and the like. Put your software developers under scrutiny and you’re guaranteed to “dim the light” of their inherent “Geek Joy,” according to Michael “Gee Paw” Hill. Back in May at Agile and Beyond in Detroit he told me, “The fundamental fabric of geek-centric work is we don’t have to motivate them, we have to not demotivate them.” Put your geeks under a microscope won’t get you geek joy. It will get your geeks to leave for better working conditions.
Despite all that, if we keep our teams together for too long, you can have other problems. Few people know that there is a missing phase in Tuckman’s model. It’s the phase called Stagnating. It’s when you keep your teams together for too long. Since the team composition does not change, there is less new information in the system. There is less learning because of that. I didn’t make that up. It emerged in a qualitative case study that I conducted at my former company AppFolio, Inc., which I presented at Agile, 2016. Here are a couple of the quotes from the participants which inspired my Stagnating addition to Tuckman’s model:
“You just get different perspectives working with new people…unless you actively have a source of new input to your team, like you’re reading books together or something, it’s going to stagnate over time…” -Bryce, PhD, Senior Software Engineer
“If the team stays stagnant, the abilities you have stay stagnant. We have people on the global engineering team for a reason. They’re good at different things. They’re good team members. And so mixing it up all the time is important.” Comron, Principal Software Engineer
Teams that are together forever could also have very low energy. Simply put, people might just be sick of working with each other. The work itself could also be stale or uncompelling. Maybe the people are just “going through the motions” of their work. They feel disengaged from their day to day experiences but still come into work each day “looking the part”.
Keeping those people together on a team or in the company for that matter is doing a disservice to the humans present. It’s sad. Who wants to work with those people? Who wants to work with that team? That’s when we need to take a critical look at dogmatic suggestions about team stability, which can be easily misinterpreted as “keep teams the same.” Too much of the same might not be such a good thing.
So how do you know when you should reteam? Good coaches can keep the pulse on team health in your organization. They can coach teams as units or systems to understand the collective sentiment. They can also coach individuals one on one in order to “take temperatures” and see how people are doing. Managers can do that too. The important thing here is to design how you want any coaching to be in your organization. This is a deliberate discussion so that you do not have conflicts of interest or issues with confidentiality.
“Reteaming is inevitable, you might as well get used to it” is what my friend, coach Nayan Hajratwala said to me. And it’s true. People will come and go from your organization. You will team and reteam across time whether it’s your choice or not. If you’re on a team, you can decide to speak up and seek fulfilling team situations that get you excited to come to work every day. Just like for teams, coaching helps with this.
If you’d like to read more, please check out my book Dynamic Reteaming: The Art and Wisdom of Changing Teams. https://leanpub.com/dynamicreteaming
 See crrglobal.com
 This is a concept from co-active coaching which is the coaching philosophy that I am trained in.
 This is a concept from organizational relationship systems coaching which is another coaching philosophy I am trained in.
 See modernagile.org