Great Tiny Teams

I am in the middle of my forth week of being apart of my tiny team. There was a development-facing team restructuring at Altmetric where we decided to have fixed teams of just two or three people. That’s a fairly small number, but there’s a few reasons we’re feeling more productive.

Our teams have gone from one team with everyone working on the same queue of work (the sprint); to two teams – one person handling support work and interruptions, whilst the rest focus on the sprint; to three tiny teams.

The tiny teams are working very well.

Self organising teams are lovely but your developers probably don’t have the communication skills for it. I don’t think I’m offending too many people by lumping us all together and saying that. Toes get stepped on, work is duplicated without realising, and interfaces accidentally end up clashing. We’ve JIRA boards to keep all that clear, but only really get updated when someone is prodded to.

None of this can happen in a tiny team of two people. Sharing progress becomes more concise, since updates are more frequent, and so quicker and clearer. There’s hardly any need for tools for developers to keep up-to-date when you’re sitting next to the person you’re sharing the work with.

Another problem, which may stem from developers’ social skills again, is in our bigger groups of four or five people finding a pairing partner is much harder. Should you interrupt Johnny to pair with, or wait for Shaun to be free? That choice is taken away when there’s only two of you. If you’re in need of a pair then you’ve only one place to turn.

The same indecision disappears when it comes to code review. You have to review your partner’s work, no one else will. Whereas before you might shy away from reviewing an overly large pull request, you’ve now got to sit up and understand it.

Those are just a few of the reasons I’m excited about tiny teams at the moment.