Everyone knows that practicing pair programming and agile development are the best ways to produce high quality software as fast as possible. But setting these pairs up is a lot harder than it looks. Here’s how we do it. How can we improve? Read more...
The Challenge
Resourcing pairs in an agile shop is difficult for a lot of reasons. One of the big challenges is that they have to constantly change. While one of the big objectives of pairing is to reduce developer blind spots, the same thing can also happen if you pair the same developers together for too long.
To further complicate matters, not everyone starts the day with a clean slate. They might have started a story yesterday and not finished it, or they might be leaving for an hour to go to the doctor’s office. The big point is that not everyone has the same amount of hours to devote to writing code.
Every developer has areas of expertise - and every developer has areas where they’re a novice. One of the biggest opportunities pairing brings to our team is to have these areas of specialization transfer to other developers. And unfamiliarity increases the quality of the pair because the expert is forced to articulate the challenge in a simple way to the novice.
In our experience, the key to resourcing pairs is to match people based on expertise and availability. We don’t have the perfect approach to resourcing, but we wanted to share what we’ve been doing lately in hopes of learning from you.
Our Approach
Every morning we meet for our day-planning meeting. It runs from 9:15am to 10:00am. The first order of business is to review the work each person completed yesterday, and review the work they started but didn’t finish. This step is repeated for each team member. Based on the commitments they have, we count the hours they have available for writing code, and we write it on the whiteboard.
The next thing we do is open Pivotal Tracker. As a team, we review each user story that was completed yesterday, as well as each story that was started but not finished. Then, we begin selecting new stories from the current iteration - which have already been prioritized by our product manager and customer support agents.
After we select each story (starting with the ones that weren’t completed yesterday), we create a pair based on their available hours, and their level of familiarity with the particular story. We’re looking for people who have about the same amount of productive time available. We also keep an eye out for an expert and a novice. We keep assigning stories until all the pairs have a full plate.
Next, we sequence the stories - discussing any dependencies or scheduling conflicts, and discuss any risks associated with other commitments. Once that’s done, we open up the floor to questions, and when those are done it’s time for announcements, which can be professional or personal. And we generally save a few minutes to look at one of Dave’s awesome youtube favourites.
If you like lists, I’ve included one below so you can review it and put it use. If you have an idea on how we can improve the way we resource pairs, please find me on twitter or write something more detailed on hacker news.
The Big Bang Morning Meeting:
- Each person states yesterday’s accomplishments
- Each person states work that was started but not completed
- The number of available hours are recorded on the whiteboard
- Repeat for all developers
- Open Pivotal Tracker
- Review work finished yesterday
- Review work started but not completed
- Select a story from the top of the current iteration (including stories started but not finished)
- Assign the pair based on available hours and Expert/Novice
- Sequence the activities to account for prior commitments
- Assess any risks
- Questions and Announcements
- Get to work!