If the Kids are United

If the kids are united
They will never be divided

-Sham 69 (If the Kids are United)

"Is your group a team or are they strangers on a bus? Going the same direction, but nothing else connecting them?" I had a manager ask me that of my team, and I had to admit they were more the bus-type people. They were siloed in their work and rarely asked for help; they weren't territorial, but they didn't care enough to be that way. The work got done, but nothing really improved; nothing got better in the circumstances or the work. I tried changing the ceremonies, adjusting retrospectives, adding more collaboration time. Nothing stuck. The bus kept rolling, everyone staring out their own window.

Spend enough time in any sort of group work, and you'll come across Bruce Tuckman's "Tuckman's stages of group development." It's got some dubious science behind it, but it's an easy-to-remember process for how teams congregate towards one another. Forming, Storming, Norming, Performing, and, later on, Adjourning. This is all on the precondition that the team doesn't change during this process, and that, as far as I've seen, almost never happens. The order in which they happen also changes a lot, so a team can fall back into norming, so it's not so much a model of how things work as a process for how things come to be. Company reorganizations, someone quits, someone is fired, someone gets transferred, there is always a new person in the team, which resets the cycle, and people almost never take that into account. So the model should be taken with a large ass grain of salt, but it's a good way to give a high-level overview of what teams go through when trying to get better at working together.

I've seen super successful teams that go through this process, get to the performing stage amazingly quickly, get their jobs done as quickly as possible, and weather the ever-changing disruptions to the process. Kitchens, not just cause of the brigade system they have, but because during service every night they're pushed to their limits on what they can produce and put onto plates as fast as possible without making mistakes.

"I feel like a pirate. I've been kicked out of every legitimate profession, and all I've got is the other rejects standing beside me making these meals." One of the line cooks I worked with years ago was at a burger bar. He wasn't wrong, each night the number of tickets they would pull through was astounding, but the norm, then they would get drunk together, go home, sleep, and do it again with the same hangover they had from yesterday. Fire forges strong metals, and these people were forged in fire nightly.

I've thought about ways to bring this to the tech field. Going so far as to plan out a kitchen day where we take programmers and make them be line cooks in a workshop. It didn't pan out due to a lack of interest, but the idea is still there. I did hear about another idea, though—the FedEx day.

Like FedEx, you place an order and receive it within 24 hours. The team creates a product wholesale in a day. This takes some blessings from the company to have you all not working on backlog items, but boy, does it test the team and show where their weaknesses lie. It builds some resiliency by showing how a team now needs to work together to complete a project. Certain patterns always show up when you go through the Tuckman model, which I count more as a process that continually happens. You also start seeing the parts of a team start to form. There is always a team lead—not a team leader per se but the person who interacts with the business to the detriment of the code. Then the person who handles the interpersonal conflict which invariably flares up—the mom of the group if you will—they help arbitrate discussions and put things back on track when tempers flare. You have the person who brings up the wariness of the plan to make sure that all the bases are covered, and other positions always seem to show themselves when a team is formed, not just strangers on a bus but a team.

I did one with a DevOps team I was working with, and we got permission to revamp the office lunch ordering menu. It had absolutely nothing to do with what we were working on, and the team did an amazing job of working together and realizing that they couldn't use the standard processes of dividing up the work and taking their time on each part. The QAs were roped in early to show which tests would be needed, and the developers, instead of code reviewing, started pair programming. Best practices became the norm for a day because they needed the extra time to meet the deadline. We got a product out and working. It wasn't used because the company wasn't impressed by it, even though it was incrementally better than what we had. The team did take the practices they learned and kept them up, so all in all, it was a win.

If the team is co-located or available to be around one another, I've found escape rooms do a similar thing, but they're very fleeting and don't stick as often. They're an amazing diagnostic tool for things you've seen happening on your team.

You can see which team members never trust one another, and you can tell which managers are thinking they should be the leader just because of the title. You see who hangs back and contributes little to the puzzle-solving. I find that all the problems that you see over many given sprints will show up in the hour that you're in an escape room.

Chris,

Your team has had the bus driver sent packing how many times now? No one is even sure anymore. They're apprehensive and aren't going to form into a team unless they're put under fire. They've been burned by products, but that's not the same as having to work together. Even if you get let go tomorrow in a reorganization, the best thing you could do for that team is to help them learn how to navigate the Tuckman process as quickly as possible and rely on one another.

You're their manager, make sure you're also not their leader. It's a false trap that a lot of managers fall into. You're a part of the team, not the head of it. That means when you run a FedEx Day—and you should—you're building the thing with them, not watching from the sidelines. Your code gets reviewed too. Your ideas get challenged too. You're in the escape room solving puzzles, not standing outside timing them.

Start small. Pick something low-stakes that forces collaboration. Give them a reason to talk to each other that isn't about the backlog or the next sprint. Let them see each other as people who can help, not just names on a Jira ticket.

I hope that helps.