Mind the gap: smoothing out team project transitions
Two four-week projects never take eight weeks. Two ten-point Epics are rarely completed in the space of a twenty-point Epic. And two Small projects, ostensibly the size of a Medium, never seem to work out as such.
The culprit isn’t your flavor of agile methodology. It is not your team’s ability to estimate work units accurately. And it’s most certainly not that you need to switch project management tools. It’s the dreaded gap.
The gap is the time it takes to finish a project and tie up all the loose ends. It’s the time spent waiting to turn a feature on in production, the effort required to monitor its success metrics and the overhead of turning the feature right back off because of an issue. If you have manual QA cycles*, those are part of the gap too. The gap includes the follow-up feedback you want to be able to respond to and the small usability issue you notice only after actually giving your work a spin.
Similarly, it takes some time to get going on the next project. Open questions need answers. An architectural approach needs to be selected and vetted. Designs need to respond to uncovered constraints. These too are part of the gap.
During the gap, time seems to disappear. Each project really only took the effort it should, but the process of moving from one to the other results in wasted cycles. In strict agile teams, the gap often shows up as a period of lowered velocity, in not-so-strict teams, that roughly translates to observers as “what were they working on again?”
A simple solution.
When I first encountered the gap, I started asking teams to include transition time between projects in their plan. While this did make the gap more predictable, it didn’t completely solve the problem. During that time, we would still have a designer blocked on engineer input and several engineers blocked while they decide on an approach. We still faced the thrash of changing focus between the recently deployed and the just getting started. This is wasted time and effort that no organization can afford.
The key to a successful project transition is to smooth over the gap rather than simply accounting for it.
Here’s how: part of the team ramps down the existing project while the other part of the team ramps up the new one. Slowly move people from focusing on one project to focusing on the other as the relative effort requires changes. This looks something like this:
It’s extremely simple (aren’t the best things in life), but it works especially well for the following reasons:
Better ownership. Great designers and engineers want ownership. In this model, a portion of the team (usually 1–3 individuals) are tasked with a project from the early planning stages through to post-project follow up. They get help in the middle from the rest of the team, but it’s those individuals who get to own the project end to end.
Coherent planning. I once started a major rewrite with seven people. In the first four weeks of that effort, we would have made significantly more progress with just two contributors. Why? Because it takes time to form a coherent strategy, and even the best of the best need to test their approach before diving in. Sending off a few individuals from the team to do this planning saves cleanup work later on.
Flexibility. Blocked on the new project? Go back to the old one. Finishing touches turning into a project in their own right? Send the team right on back to help. After all, predictability is important, but so is doing right by your customers and future teammates.
Knowledge share. While one half of the team or the other is always more knowledgable about a project, by combining forces for the guts of execution, everybody has at least a passing familiarity with the entire project.
The gap can get in the way, but focusing the team on smoothing over the gap has concrete benefits — not just on the gap, but on the team’s ability to adjust to changing circumstances and ultimately to deliver more value.
*Full automation on legacy code bases takes time. Just keep moving forward.