What Makes (Dev) Teams Great?
What Makes (Dev) Teams Great?
A team's values and the culture they work to create go a long way to helping them make quality software and great products.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
"Great things in business are never done by one person. They're done by a team of people." ~ Steve Jobs
This article was inspired by a talk that I recently presented at the Johannesburg Developer User Group (DevUG).
Throughout my career, I've found myself developing a growing interest in people, teams, and culture. I've become passionate about exploring the things that make teams work well. Over the years, I've been privileged to work on some really great teams - and on teams that weren't so great (and as I write this, I'm lucky enough to be on a great team).
In this article, I'll summarize five core values that I personally believe contribute towards making teams great. After all, to quote a great leader, a team is more than just "a bunch of individuals working off of the same backlog."
Great teams have values that they stick to; everyone knows what those values are and individuals hold one another to them. Furthermore, those values are not forced onto teams - instead, they are an inherent part of the team and they come from within.
I remember when I first walked into the area where my current team sits. On the wall, right next to the Kanban board, there was a team agreement. It was compiled by the team members themselves, and it occupies a prime spot in our space; it's highly visible and it serves as a constant reminder of what we stand for. Lastly, the team agreement is a living document - it changes as the team changes. The version that is currently up on the wall is not the same version that was there when I joined - simply because the team has changed, as people left and new people joined.
Great teams have a clearly defined purpose - they know why they exist and what value they add. They don't fall victim to the curse of 'busyness' - it's not about looking busy; it's about doing the right thing in order to add value to the organisation that you work for. Some of the worst teams are those teams where it is frowned upon if people aren't sitting at their desks hammering away at keyboards eight hours a day - even if they have no idea what they are doing or why they are doing it - in other words, teams that lack purpose.
Great teams don't measure themselves by hours worked or by the number of tasks that they've completed; they measure themselves by the value that they've added. On my team, our Kanban board has a heading that emphasises 'The Value We Add' instead of 'The Work We Do.' Our Definition-of-Done isn't the usual - 'tested, deployment, and in production'; instead, it is 'adding value.' It doesn't matter if we've tested and deployed and we have software in production - if our users aren't deriving value from what we've done, we haven't accomplished what we set out to do.
Great teams recognize that we are all individuals - we have lives and responsibilities and problems outside of work. In my first stand-up with a former colleague, he said something profound - "first we are people, then we are workers." Great teams keep this in mind; they support each other when they need to. Great teams also take collective ownership of what they do - no single individual is forced to take the blame for failure, nor can anyone take all the credit for success.
On my team, we're not big on titles - the fact that someone is perceived as a 'junior' developer doesn't mean that their opinion is irrelevant. Similarly, the fact that someone is an 'architect' doesn't mean that they're always right. Great teams can, respectfully, challenge each other on their ideas without fear of being ridiculed or punished.
Great teams don't make a habit out of working 12 hours a day; managers who respect their teams won't just sit back and allow them to burn out. Great teams respect the fact that everyone has lives outside of work, and that time spent with their families and loved ones is important.
Software development is a craft, and great teams realize that there is always more to learn. In fact, they actively encourage learning. Some teams are even afforded the luxury of spending an hour or two during the week on learning activities (Friday afternoons are great for this - who's super-productive on Friday's anyway?). Here are just a couple of ways in which you can spend this time; either by watching a talk, by playing around with a piece of technology, or by getting a team member to present something to the rest of the team.
On my team, our stand-ups also emphasize our focus on learning - a key question (every day) is "what have we learned and want to share?" We also encourage learning by working together on problems - it is core to our team culture. By using mob programming, we allow everyone to learn from everyone else in every task that they work on.
Great teams also realize that retrospectives are a great place to learn. Sadly, in some teams, it often feels like retros only exist in order to tick off an item on the 'Agile checklist.' Instead of being valuable learning sessions, they become a formality.
Great teams allow their retrospectives to be a safe space where concerns can be raised without fear of retribution (the scariest retro that I've ever been in was one where someone had an issue that they refused to talk about for fear that it would be held against them). Once the team has raised their concerns, they work towards addressing the underlying issues and applying their learnings in order to better the team as a whole. I believe that retro feedback is probably the single most valuable thing that a team can use to drive positive change. Don't defend; don't argue; just listen.
Great teams have fun at work - contrary to what some folks believe, it's okay to have fun at work! Fun helps teams to bond, and when teams bond, they can work together well.
Some of the greatest teams that I've worked on made a habit of doing coffee runs together. Never underestimate the value of stepping out of the office and experiencing a change of scenery for a few minutes. After all, as a developer, your job is thinking, not typing - and that you can do just as well over a cup of coffee.
My team has a foosball table right next to our Kanban board - and that serves as a reminder that fun is as much a part of who we are as the work that we do. I can think of at least one problem that I spent ages trying to figure out at my desk that was solved about three goals into a foosball game.
How Do I Develop a Great Team?
It might seem daunting, or even impossible, to try and create a great team when you are not in a formal position of power. Nonetheless, it's possible. Here are a couple of tips that you can use as a starting point:
Respect your colleagues; they are people.
Socialize at work - start with coffee runs.
Do your part to allow retrospectives to be a safe place where concerns can be voiced and dealt with without fear of repercussions.
A Note on Bad Teams
I want to leave you with a few closing thoughts on bad teams.
- People are minions.
- People don't get to have opinions - the boss is always right.
- People live in fear.
- The team functions at 100% capacity all the time (burnout, anyone?).
- People are treated as "resources," not individuals.
- Teams are forced to fight political battles.
If you do find yourself on a bad team, my advice would be to try to fix it - have open, honest discussions with your manager and your team members. Point out the problems and propose solutions - be proactive about it. However, if you've tried and failed and you find yourself becoming miserable at work, get your CV out there! Life is too short to work in a place that makes you miserable.
Feel free to leave a comment if there's anything that you would like to add or discuss.
Disclaimer: As always, the views expressed in this post are my own.
Published at DZone with permission of Riaan Nel . See the original article here.
Opinions expressed by DZone contributors are their own.