Small software companies often find themselves trying to do too much with too little. This was certainly the case at Agentek. At one point earlier this year, we had a problem… We were not finished with the current release (call it release A), but we could not wait until it was finished to get a start on our next release (call it release B). There was too much unknown involved in release B. We had to get started on it. At the same time, we had just committed to ourselves that we would not leave our customers with anymore half-finished releases. What to do?
Our team had four fully dedicated developers, a tester, and me. We needed to dedicate 25% of our time to release B. The first option was to simply intersperse the backlog with stories from release A and release B…
Interspersed Backlog
There were two problems with the interspersed backlog. First, release A has a good bit of reactive work; so, the backlog is unpredictable and tends to consume the entire team’s attention. Second, since stories vary in actual effort to complete, we cannot really gauge or control what percentage of our capacity is applied to each effort.
The next idea, was to split the team and apply 25% of the people to release B….
Split the Team
This is the mathematically cleanest solution and the option that traditional software managers would probably pick every time. However, this option has major disadvantages…
- Only one developer will know anything about how release B was implemented.
- The many advantages of pairing are lost on both efforts because we have only one developer on release B and an odd number on release A.
This option really just throws the team-based approach to building software out the window; so, not an option for us.
Next thought was to create two separate backlogs….
Split the Backlog
This makes the problem we are trying to solve clearer, but we still have the problem of how do we stay united as a team, yet timebox each backlog.
The next step was to designate days of the week for servicing each backlog. To give the forward-looking release one fourth of our capacity, we dedicated one pair to that backlog for half of the week. To simplify things, and give it a little more than 25%, went ahead and gave it three full days instead of two and a half. So this is what things looked like…
Split the Backlog and the Week
We rotated the release B pair so that there would always be one person that worked on that last week for continuity and one new person.
In our first retrospective after we finished release A (and moved onto release B fulltime), the team was convinced of a few things:
- One team working on two releases at once is hard.
- Keeping the team together was really important.
- Splitting the backlogs and the week turned out to be a great way to do both at the same time.