Wednesday, August 18, 2010

Freight Trains and Software Teams

So what do freight trains and software teams have in common?  If they don’t get a little slack every now and then, they wont ever go anywhere!

Something I’ve been doing with my teams for a while is adding “slack action” between iterations.  I’ve found that adding this time helps with code quality, planning, reflection, morale, responding to adhoc requests, and a slew of other things.

One metaphor I’ve used when describing this idea to others is that of a freight train pulling its cars.  Rail cars are loosely coupled to one another, leaving a little slack in between each one.  When a locomotive starts moving forward, the slack causes the first car to be jerked forward, which in turn jerks the next car, and the next, on down the line; each car using its own momentum to help get the other cars moving.  Finally, the train actually starts moving down the line as a whole.  This jerking between cars is know as “slack action” and without it, freight trains would never be able to move.  In fact, without it, the engine’s wheels would just spin and literally burn through the track.

I find the same to be true with software teams.  Too often I’ve seen or heard stories about teams that get burned out from doing too many back-to-back iterations.  This is especially true of environments where software development is ongoing, such as “maintenance” teams or organizations with continuous program delivery.  The problem here is not the ongoing nature of software development, in fact I quite agree that ongoing/continuous is a great fit for software.  The problem is a human problem, in that sometimes a team just needs some time to breathe and mentally shift gears for a while.

I propose that one solution to this problem is to give a team its own version of “slack action”, or a gap of time between iterations. This is more that just a retrospective and iteration planning time.  I’m talking on order of multiple days.  During this time the team can focus on other aspects of their product, their craft or themselves instead of delivery delivery delivery.

Here are some rules of thumb that I use for providing slack:
  • Keep iterations between 5 and 20 days. 
  • Try not to start an iteration on a Monday or Friday.
  • Use a ratio of about 1 day of slack for every 5 days of iteration. 
  • Keep scheduled planning and reflection times and activities.
  • Use a minimum of 2 days slack.  (This is because most of my best ideas have not always occurred to me during the scheduled planning or reflection times, but instead in random places like my bed, or the shower, where generally the rest of my software team is not :)
  • As with anything else, adjust and adapt as necessary to the needs of the team and the context.

One issue I’ve run into with pitching this idea to “management” is the misconception that slack action is just unstructured playtime or “days off”.  I argue that, in fact, it is highly structured, but in a more guided creative way rather than a controlled deterministic fashion.  I then politely explain that we are not off, and proceed to list the activities that can and are going on during this time.

Some slack action items include:
- Allowing the team to work on pieces of the project that were in need of refactor, but that were not able to be cleaned up during the iteration.
- Professional development activities (book club, katas, applicable R&D)
- Respond to adhoc requests (that were pushed out of the iteration because we *knew* we had slack time coming up)
- Planned Retrospective, Iteration & Release planning
- If there is truly nothing else to do, the team can always start the work for the next iteration (while I can’t think of a time this has ever happened, it makes “management” happy to hear it :)

I know there are other ways to achieve this, but this is one way I’ve tried that works in my environment.  As always feedback and ideas are welcome and appreciated!


No comments:

Post a Comment