Minimizing Bad Effects of Special Projects

Agile frame works like Scrum define an iteration or sprint of two to four weeks.  This time is dedicated for the team to work tasks to complete a planned set of stories.  The team is not to be distracted from their sprint or iteration backlog.  This allows them the highest concentration possible during the iteration time.

And real business life sets in to create disturbances in the sprint.  Let’s look at a hypothetical but realistic situation where sprint disaster can strike.

Suppose there are two teams working on two projects.  Sprint after sprint the teams productively work down their backlogs, end with demos or reviews of what is now done and plan for the next iteration.  One afternoon in the middle of a sprint the department director calls a meeting of the teams following their daily stand-up meetings.

“As you know, ‘Old Yellow’ is our bread and butter product right now.  It’s earnings fuel the new product development you are doing.  BigCorp is our largest customer using Old Yellow.  They need A Great Feature added to Old Yellow right away.  We need to keep working on the new products but if we don’t satisfy BigCorp we’ll be in deep financial trouble.  We need to pull Joe and Tom from project New Blue and Lisa, Nancy and Ashok from project Shiny Red.  They will work on A Great Feature starting tomorrow.”

There is danger here!  The director has asked to pull people off their sprint teams in the middle of the sprint.

  • Team self-management takes a hit.
  • The sprint plans are in shambles.
  • Velocity measures for the teams, for that sprint, are devalued.
  • In short, aborting two sprints to start on something else right now is a bad thing to do!

In an ideal world the company would have enough people to handle sustaining efforts so the teams doing new development can stay focused on their iteration and release plans.  But special projects that cut into new development sometimes cannot be avoided and ideal staffing is rarely available.

Let’s return to our difficult stituation.

The ScrumMasters and Product Owners react negatively to splitting their teams, as they should.  One ScrumMaster wisely speaks up, “The teams are in the middle of sprints.  Can we leave the teams to complete their current sprints?  Then we can properly plan the development of A Great Feature for BigCorp with people dedicated to the solution.  Let me draw it out for you.”

Handling a special project

Handling a special project

The ScrumMaster continues, “Doing it this way protects the results of the current sprint.  It also provides for clear planning of both subsequent sprints and for development of A Great Feature.  The two current teams will be slower in their next sprint because they are smaller teams but they will now have a plan for that case.  And, A Great Feature will be completed sooner with a dedicated team working on it.”

Nodding, the director says, “Our relationship with BigCorp is excellent.  I’m sure we can explain to them the benefit of a short start delay so they can have a dedicated team working on the new feature.  In fact, I bet they will like that idea.  Great job, everyone!  We’ll lay some ground work so information is ready when your current sprint completes.”

Ah!  Happy endings are so nice!


No comments yet.

Leave a Reply