Team Dynamics: Function and Dysfunction
A team starts their sprint. They begin their work like any other day, hopping right into it. Stories planned out. As the sprint goes on, distractions come in. Sprint work is lost in context switching. Points leak out unnoticed. Standups don’t see overall progress and then small slips build, a bit here, a bit there. Only a few days left in the sprint. Panic begins to take hold. Developers explain a problem in such detail that no one even remembers the PM’s question: how’s the sprint going?
When was 70% time done? Yesterday? No, mustn’t be. Where is our 30% time? No time to worry about tech debt now, a migration is mid flight and a service is blocked. 4 alerts are in the red. No one pairs, no one mobs. PRs have grown into unrecognizable eldritch forms, whispering “close me” to their authors. Friday afternoon, deployments are flying out of CI/CD like newspapers off a newsstand in New York in the 70s. Everyone sighs in relief as the commitments are “met.” A bug lingers in the unknown and a test plan lays half filled out and untouched from Monday, if it was created at all. Much like standup, retro does not see the slips of sanity that etch away with each crunch. The Song of Time plays across the weekend as you warp to the dawn of the first day, once again.
Hopefully what I just described isn’t your average sprint, but chances are you recognize parts of this and have experienced those parts first hand. Dysfunction. It’s a powerful force and it can be unrecognizable from the perspective of someone experiencing it.
Teams come in all sorts of different ways. Different cultures, different expectations, different specialities, and so on. Tuckman’s model illustrates the formation of a team from forming, storming, norming, to performing (and to adjourning! I didn’t realize there was a fifth step).
Basically, there’s a lot of ways that teams can operate, and chances are, they’re also changing how they operate, too. Either to make improvements, or to adjust for new requirements, or whatever else. As a team lead, part of my role is having a vision for these operations, and enabling the use of the resources available to the team to execute on that vision.
My team has largely gone through Tuckman’s model since I joined and with a number of team members along the way. With this, I’ve come to gain an appreciation and understanding of dysfunction and function and the role it plays and how it relates to a vision for a team.
A vision for a team is often a goal set that will help you walk Tuckman’s model and move towards that high performing team. On average, you’ll be a more high functioning team as you advance that. But there’s more nuance than that. And it has to do with function and dysfunction.
Whatever vision you come up with, your path will include taking dysfunction and turning it into function. But what is dysfunction? It’s usually a breakdown in communication or mismatch of outcomes. It’s also usually minute but multiple. It’s small pebbles that build up over time and then someone comes back who’s been away for a while and says “where the heck did all these pebbles come from?!” I don’t want to give an exact definition of dysfunction; instead, I’m trying to invoke enough about dysfunction that we’re thinking of the same thing and you can say “yeah I know what you’re talking about.”
I’d caution against thinking of dysfunction as bad, and here’s why: thinking of dysfunction as bad implies more junior teams aren’t good, and that notion is bad. Being junior is a good thing because it means you’re on your way to wherever it is you’re going. And that’s the same with dysfunction, dysfunction isn’t bad because it means you’re on your way to function. Or at least, you should be. Dysfunction which stays as dysfunction with no experiments or reflection to change can be dangerous. This is where we can spin and spin and feel things like burnout.
As the owner for the vision of my team’s operations, I consider myself accountable for this transition from dysfunction to function. Keeping in mind there’s no inherent good or bad here, just what’s happening and moving from one phase to another. Just like liquids aren’t better than gases, they’re simply phases we can move from.
At this point, it might be worth a detour to check out the five dysfunctions of a team, but I’ll leave that up to you to take a look at. Those dysfunctions will help define what I’m talking about as I didn’t earlier.
How can we deal with these dysfunctions? Each kind of dysfunction will have its own solutions, but in general I think there’s a few good habits:
Get your team to be strict with each other. This doesn’t mean be strict so that it’s fear inducing, we don’t want that, but if your team can’t be strict enough with each other to speak to their own needs or to a greater requirement, this can reduce quality (and then we introduce dysfunction).
A typical example of this is testing your work. If you’re reviewing code, you’ve got to be comfortable being strict enough to ask for tests if they aren’t there. And part of being a team lead is building team members who will do that, because you can’t do that on your own. This is also important for working agreements: if only one person on the team is enforcing the working agreement, you’re better off throwing out the working agreement and focussing on getting the team to a point where they’ll enforce something they believe in.
Get your team to be impatient, not complacent. Impatience is important in a world where software is never complete. We pick our commitments for our sprint and if we under pick or work gets taken out, our existing work will expand to fill that time. It always does. That’s why impatience between each other matters. Building a team that questions why items are still blocked and engages to pair with others to speed up existing workflows will help achieve this.
Trust your gut. When you’re in a moment that has an aura of dysfunction that you can’t quite focus on, you will likely have a gut feeling. You might not know what is wrong but don’t set it aside. Ask questions and follow the processes your team uses to validate work: RFCs, talking to other teams, PR reviews, all of them! Most times, you will find something, and the other times you’ll at least have the work to show your team validated their work.
As you read this, it’s important to keep in mind these suggestions require all members to participate. It’s why a good team lead cannot make a functioning team on their own, everyone else must execute these habits too. A big part of being a team lead for me isn’t doing the work myself, but holding others accountable to this kind of behaviour. Furthermore and ideally, a team lead will petition the others for feedback so the vision they have is one which reflects everyone’s perspectives and is easier for the team to buy into.
As a plug, Camille Fournier is an excellent source of information and advice on these topics and someone I refer to when I’m looking to develop my team functioning skills. I recommend this interview with her if you’re looking for further reading (listening) on this topic.
