Dahlia Bock

Making teamwork work

I've had the privilege of being a part of many software development teams in the past 2.5 years. Part of the perks of being a consultant is that one gets the experience of being in different companies, environments, cultures, initiatives and goals. Not that I'm claiming to be an expert on how things should work, but it does help to be able to gain different perspectives in a short period of time. Here's what I think is important for teams to pay attention to, but by all means, I don't mean for these to be silver bullets, just observations.

Collective Ownership

Of everything. Of defects, of the broken build, of code refactoring, of talking to the stakeholders. Some think it's a good idea to have specialized teams that drive innovation or improvements, but I think it's the team that feels the pain of a certain problem, be it a terribly long build, or incredibly flaky tests, should be the ones that drive those improvements. They know what the problems are and will have a better idea of how to make things better. Getting an external opinion is a good thing but the responsibility of the "fixing" should belong to the team.

When something goes wrong (i.e. build breaks), we should adopt the "we should fix it" not the "it's somebody else' test, they'll fix it" attitude. Even if it wasn't my checkin that broke the build, if I can be of help, or if I know how to fix it, there's no point in waiting around and leaving the light red.

One backlog, one team. Split backlogs, split teams.

I've learned that it's really hard for a backlog to be shared across split teams that don't have visibility of the big picture and don't communicate across those imaginary-team-walls. Consider this scenario, Company Z has 3 software development teams working on their online website. The teams are seated separately, don't have much communication between them except through email, and a lot of email.

Iteration 1: Team A is given work for Feature Foo. Team B is given work for Feature Bar. And Team C is given work for Feature Baz.

Iteration 2: Team A is given some work for Feature Bar, and some for Feature Baz. Team B is given some work for Feature Foo and some for Feature Baz. Team C is working on another completely different feature. But in the previous iteration, they have identified a few issues for Feature Foo that they would like to fix but since they can't work on Feature Foo anymore, the work goes to Team B who has little to no context of what the problems were.

I think if we want to have a shared backlog and have everyone on the team familiar with the different facets of the work, we need to be ONE team and not multiple teams.

Colocation

Following the previous observation, a team has to feel like they are a team and one way to encourage that feeling is to sit the team together. It might seem like a trivial act, but it does help if it's easy for me to walk up and approach another developer instead of having to walk across the entire floor and feel like intruding another team's space. It's all about false perceptions, and it'll do us good to get rid of as many of them as possible.