Our Ways Of Working Aren’t Working

Just heard this from a fellow consultant about a technology initiative going on at a large company, and, in his words, it's all going sideways. He asked me to guess how many people they had on their daily standup. Obviously, I guessed "42" as a joke, but that wasn't even far off:

They had 35 people in their single "Scrum" team.

No wonder things are going sideways. Good luck effectively coordinating with this many team members. Even if everyone's update takes just a minute, that's over half an hour just for that, and by then, no discussion has taken place (which is the whole point of holding the standup in the first place; if everyone just gives their own update and then tunes out, just move the damn thing to an asynchronous update in Slack or Teams.)

I'll claim that if he hadn't told me that the project was going sideways, and just told me that they have 35 people in the daily standup, I'd have assumed that the project was going sideways.

What's the solution?

Smaller teams, duh.

But that's only half the story. Everyone has heard about Amazon's concept of the "two-pizza team": A team should be no larger than you can comfortably feed with two large pizzas.

The questions to answer are: How did we get here, and how do we get there?

First, how not to get there: Haphazardly splitting the one big team into 3 smaller teams, doing a random assignment of people to them and calling it a day.

Next, how did we get to such a large monolithic team? Probably a mix of inertia and management's reflex to throw more people at a problem when progress slows—which of course has the opposite effect. And since we've all got an inherent bias for addition over subtraction, this is the natural course of events.

Finally, how do we get to small teams that work, rather than small teams that are just the same big team in all but name? Teams must be designed around areas they can own, so that communication can stay mostly within that team and only occasionally requires interfacing with the other teams. That same principle prevents software from growing into a big ball of spaghetti: Modules should be strongly coupled on the inside and loosely coupled to the outside world.

That ownership part is hardest to accept for those steeped in traditional management approaches, but no amount of superficial ceremonies or org-chart reshuffling is going to fix a project that's going sideways. Only a hard look at what we're trying to achieve, and how that can be broken down into separate domains and iterated on, will get us there.