It’s been almost a year since my current team, Paycunia, inspired me to think about this question. I’d been on poorly functioning software development teams in the past, and I felt lucky to be part of a team that operates so effectively now. More than that, I felt compelled to share my perspective, which could potentially help those who find themselves on teams that are swimming upstream. However, it was only two months ago that I began actively searching for concrete answers to the question: What makes a good software development team?
Initially, answers were difficult to come by. I went through a spiral where I'd come up with something, then reflect on it, then scoff at how flimsy it sounded. At times, I cursed myself for trying to find concrete answers to such a broad, generic question. At a certain point, I shifted my focus to a different question: What does NOT make a good software development team? This was much easier to answer, mainly because the first answer was staring me right in the face—or, rather, buzzing in my ear like a pesky mosquito just when you're trying to fall asleep. The sound: the Microsoft Teams ringtone.
That’s right—Microsoft Teams does not make a good software development team. Nor does any other tool or communication platform. Slack, JIRA, Azure DevOps, etc. To people working in software, these names are synonymous with tools that you can’t escape from but that somehow always seem to cause as many problems as they solve. No tool in the world will turn a bad team into a good one. Great—we have our first answer (perhaps to the wrong question, but let’s ignore that for now). Next up: rules.
Rules don’t make good teams. It doesn’t matter what rules you set or how strictly you enforce them—unless your team is building a simple game of tic-tac-toe (and even then), rules will do very little to get a team where it wants to be. For example:
Stories must be no more than 8 points!
You need to come into the office EVERY day!
Every single pull request needs at least 3 approvers, no matter what!
In my opinion, rules like these do little except add red tape and reduce efficiency. And speaking of pull requests...
Pull requests do not make good software teams. Don’t get me wrong—I like churning out code as much as the next developer. However, you can submit, review, and merge as many PRs as you like, but alone, they don’t mean much for how much value your team is actually delivering. The same goes for tickets and story points. Your team could be completing all their tickets every sprint yet delivering no value. Another thing you can have plenty of without it adding value: meetings.
This should come as no surprise—meetings don’t make good teams. I’m sure, if you’re reading this, you’ve sat through at least one meeting where you reached the end and thought: That was a complete waste of time. What am I doing with my life?
At this point, you may be thinking, This list could go on forever. And you’re right—there is an infinite number of things that don’t make good software development teams. Luckily, in my search for things that don’t, I eventually stumbled on a few things that do contribute to making good teams. First: agility.
Where rules attempt to govern a continually growing list of ever-changing things—requiring work to maintain, more rules to govern the rules, and so on—agility makes peace with the fact that there’s no formula for creating value. The most value comes from assessing the world around you in every moment and deciding what the most prudent action is. So what if it’s not in the sprint? If you know it will make a lot of people happy, do it! And the first thing that’s likely to make a lot of people happy is: production.
Good software development teams deploy to production frequently. Pull requests mean nothing if they don’t lead to someone using the code. Completed tickets are like a pile of trash that builds up a stink if your team isn’t deploying to production frequently. More than that, once you get past the sleepless nights and fear of messing up, deploying to production is fun! Which brings me to my next point…
Good teams have fun! They play as hard as they work. They celebrate wins—big and small. They empathize with one another. They share themselves with each other. Having fun reveals the human side in all of us, and understanding that we’re all human is fundamental to working well together. But even more importantly, the fact that we’re all human reveals something greater about what makes a good software development team...
It all depends.
Everything I’ve shared up to this point is entirely subjective. The reality is that, depending on the context, agility may not be what’s needed. There are many scenarios where a team needs a solid plan or structure, where rules add a lot of value. Sometimes, a lack of pull requests is a problem that must be resolved; perhaps not enough code is being written. And sometimes teams could be deploying to production every week, but no one is using the software—where’s the value in that? As much as many of us hate to admit it, sometimes we just need to have a meeting about it. And, unfortunately, there is a limit to how much fun a team can have without compromising productivity.
So what, then?
Have I just taken you along on one of my personal spirals, listing what makes good software teams, only to debunk each point, leaving us with no real answers and no better off than when we started? Not exactly. Because there was something hidden between the lines of the answers I discovered. Something that persisted throughout. And so, when I took a closer look...
I no longer saw the importance of rules or the need for teams to remain agile. I saw how Oscar can be meticulous about updating the operations manual every time something changes, and how that’s immensely helpful for someone learning the ropes or dealing with a production incident. I saw how Giancarlo is willing to drop everything he’s working on because he sees there’s something else more important that will help more people.
I no longer saw that pull request standards or getting things to production is the key. I saw how James and Gayathri are up at 6:00 a.m. to ensure the latest deployment is working as it should. I saw Dominique putting in extra effort to automate tests and deployments when pull requests are submitted, ensuring the utmost quality and efficiency.
I no longer saw that teams need more or fewer meetings. I saw Ellen’s agenda completely packed to make sure the rest of the team can work in peace. And I saw Shaobo working overtime, not for any reason other than to ensure the team gets pizza for completing their sprint goal or has trophies to hand out at their next team building.
The point is this:
People make good software development teams.
And you know which person has been on every team you’ve ever worked with?
You.
You can be the one that makes a bad team bad. But you can also be the one that makes a good team good. So if you’re looking for a place to start in turning an underperforming team into a good one, look only at yourself. And if you’re doing everything you think you need to deliver good software, and you’re patient and persistent enough to deal with some adversity along the way, you will be the key to what makes a good software development team.
Hwaiting!
"If you want to go fast, go alone. If you want to go far, go together."
- African Proverb