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.
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!