Monday, July 12, 2010

Sprint Renegade

When you're constructing a sprint backlog, there are almost always more things to do than you could possibly handle. Marketing wants some things, sales could close a big deal if only they had some new feature, product management feels like this other thing would be a great differentiator, support has a few requests for additional logging, oh, and development also has a few technical tasks (build restructuring, etc.) they really ought to handle.

So much to do, and unfortunately, those technical tasks often simply don't make it into the sprint. Over time, not having that technical keep up causes increases in technical debt and slows down delivery. Eventually, you have a lot of technical tasks, and yet everyone else still wants new features. Velocity is slowing down, builds are taking longer, and there's more general muttering about things not being clean in the development and test environments.

It's time to introduce the sprint renegade.

The sprint renegade is someone who effectively leaves the team for a sprint. He goes off and simply works on tech tasks to make it easier for the rest of the team to meet the obligations of the backlog. This reduces your potential velocity for that sprint by one person, but it boosts your long-term velocity by taking care of some of the drag on the team. Repeat this for each sprint until velocity is back up where you want it to be.

The general idea of a sprint renegade is that internal tech tasks are very hard to sell onto a backlog, and they will often lose in the face of customer-facing tasks. If that's true in your company, sometimes drastic measures are in order, temporarily.

If your technical debt has crept up to a point where it's interfering with delivering, find yourself a renegade. You'll be glad you did.

2 comments:

  1. This isn't a new concept by any means.

    http://blogs.atlassian.com/developer/2009/06/the_disturbed.html

    ReplyDelete
  2. I'm not sure the article you link to is addressing the same problem; it talks more about interruptions and having a dedicated person handling for them. The underlying principle of "a temporary specialist" is common, however. We've seen this idea of "one guy dedicated to deal with problem X" for years and years and across many different definitions of "problem X" (think maintenance teams, escalation engineers, bug fixers, etc.).

    So I make no claims to have made this up. But it's worked for us, so I thought I'd point out one implementation that I've found functional.

    ReplyDelete