How 2-Person Dev Teams Are Good for Clients, Teams, and Users

At a recent engineering meeting we started to outline our position on peer programming and 2-person Scrum teams.

I was initially hesitant about the idea of placing two developers working in parallel on a project for fear that it would reduce our capacity. But, as we got deeper into the conversation, a number of clear benefits emerged that caused us to adopt the practice. Here are a few things we’ve noticed upon the implementation of two-member dev teams:

1. Two developers teams are more efficient in overcoming impediments.

   When we assign a project to only one developer, our dev team becomes fragmented with each member working in isolation. When technical blockers surface, those developers are more likely to push against the problem by themselves for longer before stopping and asking other teammates for help. However, when two developers are both on the same project, the concern of interrupting a team member is removed. They are already working together on the project, after all. Blockers are squashed more quickly which keeps momentum (and spirits) high.

2. With a fellow developer to run ideas by, solutions are refined before they are built, which leads to longer-lasting code.

   A partner is vital in challenging and/or validating solutions to coding problems. Challenges like, “Did you think of this corner case?” or “Could that be combined with my approach to achieve a hybrid?” improve the quality of solutions and reduce the amount of refactoring in the future. Furthermore, the codebase becomes more flexible for future expansion, increasing its lifespan.

3. Developer skills evolve more rapidly within teams.

   When developers see each other’s code, they sharpen their skills against each other. For example, Steve might have deep knowledge of a particular Drupal module which hasn’t been used by the rest of the team. This gives Steve a chance to propose the module, explain its merits, and teach his fellow-devs how best to work with it. Our teams improve both through teaching and learning.

4. Teamwork motivates developers to follow best practices, allowing space to focus on more challenging problems.

   If developers work with peers, there is greater visibility into their coding practices. As a result, teams agree upon and adopt best practices which results in greater standardization. This means less time spent reinventing the wheel and more time innovating and charting new territory.

5. Developers share more in common when in teams, which energizes and speeds up their progress.

   Contrary to popular belief, developers are social creatures, too. Working together deepens their relationships and builds company culture while amping up the energy level in the office. We’ve always had an energetic office with jokes and playlists flying from one corner to the other, but with project teaming, dialogue, celebrations, and even jokes are now focused on the projects developers are working on together. Since we’ve adopted two-person teams, we’re getting more done in less time, and developers are enjoying their work more than ever.

6. Sharing knowledge of a project means better support for the client and better life-work balance for our developers.

   Developer teams allow project work to remain constant through vacations and sick leave. Furthermore, when vacation time rolls around, a developer can truly unplug with the knowledge that his projects are in capable hands while he is away.