A team is a network of individuals working towards a common goal. There’s a lot of literature about the teams and the networks and the goals, but I would like to discuss the main ingredient: the individuals.

People have quirks. Some people are hyper-social. Others prefer to work in silence. Some team members will build a deep friendship. Others will be strictly business.

Whether it’s the Cult of Agile or corporate management, a lot of the literature seems to focus on standardizing people. Stripping away the quirks and interpersonal relationships to build a homogenous team. A grey machine.

“Jim likes to work on a feature all by himself and actively tries to avoid pair programming. He’s not a team player, the Scrum Master should fix him.”

Software developers, writers and designers are creative people. Over the years, they’ve designed a personal method that works for them. The developer who gets in the zone by dancing to loud music behind his standing desk. The designer who builds a paper model first. The whiteboard Queen, the King of long silent walks.

We hire these people because they have mastered their speciality. And then we try to grind them down to fit some corporate mould. We take a group of unique weirdos and try to make a grey mass out of them.

I once worked as a Scrum Master with a team that refused to do Scrum. Standups? Forget it! Retros? No, I’d rather continue getting work done. They were being difficult and I tried everything to coax them into the 2-week-sprint mould. Why?

I was the problem. They were doing fine before management assigned me to “scrum them up”. They were a band of misfits that found a reliable unique way to get stuff done and I was there to standardize them.

Another example? There is a recurring pattern on LinkedIn where managers will post these high drama team problems.

“I have this developer who doesn’t want to join the retro, what should I do?”.

Nobody knows what’s going on in this team. Nobody knows this dev and how she prefers to work. Yet the thread will fill up with advise and opinions of “experts”.

Isn’t that too easy? Aren’t we overfitting some solutions in order to match the book? Aren’t we oversimplifying?

All business literature is generalization. It describes how the average company builds the average product with the average team. But nobody is average. What works for team X is a deal-breaker for team Y.

People are unique, so there is no One Way that works for all teams.

I think we should take a step back from the grey standard and let people be their unique individual selves.

I’m not advocating for asshole rockstar developers. I’m not saying some methods can never work. I do think we should encourage people to let their freak flag fly.

Teams can only get better because of it.