What is a good development team?

Beyond what makes a good team in general, what makes a good team for software development, specifically?

Two questions

By asking these two questions once per day, I believe that any well-functioning team can reach elite levels in software development. These two questions can trace their origin back to the DORA metrics which have a solid foundation in scientific data.

Did you deploy to production yesterday?

This simple question, asked every morning, cuts to the heart of the matter like no other. It is scientifically proven that teams that release code to production at least once per day are statistically better in most ways that actually matter: better business, happier customers, happier developers.

Do we have any bugs that we know about?

Known bugs in the system are like gravel in your engine. They slow you down and wear you out. A known bug has the following effects:

  • An end user / salesperson is irritated with you.
  • When developing, you need to take the bug into consideration whenever you touch any code that is even close to where the bug is.
  • When testing, you cannot assume a working product and try to break it but have to tip-toe around the bug.

So when a bug is reported, finish your current task and then fix the bug as your next task. Whatever you do, do not put it on some list which you drag behind you like an anchor. See the blog post below for my inspiration on this topic.


Some background on how I came to this conclusion.

Dora Metrics

The DORA metrics are studied by an organization owned/funded by Google and their conclusions are based on the most comprehensive set of data that I am aware of.

The metrics they have found to best correlate to team performance are:

  • Deployment frequency.
  • Mean lead time for changes.
  • Mean time to recover.
  • Change failure rate.

I have simplified the two first into the question “Did you release to production yesterday?”. Because if you do at least one deployment per day, that puts a ceiling on both your frequency and your time to get a change into production.

The second two form the basis of the second question. All systems have bugs and both code changes and bit rot lead to new bugs being introduced. By having fixed all those bugs, we also have put a ceiling on the time it takes to fix a bug and the number of bugs we put into production. 

Other things that matter

In addition to the above, a healthy team is also statistically proven to improve both productivity and health metrics. 

Susan Whelan’s model for team group development is in my view the best tool to support in that journey: https://www.hyperisland.com/blog/creating-effective-teams-the-detailed-curation

An in a commercial setting, the role of the manager cannot be underestimated. See my thoughts on what a good manager should (And equally importantly should not) do here: https://daniel.armyr.se/2022/10/08/fundamentals-of-management/