Experimenting with One Week Sprints

Problem

A few years ago our product team quickly grew from 5 to 12 teammates within a short three months. This growth came with the challenge of trying to keep things simple and efficient without being weighed down under a bunch of new processes and meetings. We wanted to be able to nurture our accumulated good practices but also to adopt our way of working into this new context.

Actions taken

At that time we had been practicing three week Sprints within our product team. We learned from each iteration by conducting retrospectives and we improved our workflow by taking actions. However, I wanted reduce the cadence of the Sprint while maintaining all of it's practices and so I decided to move from three weeks Sprints down to one week Sprints. My ambition in doing so was that we would multiply by three the opportunities to improve our organization. Here are the results:

• By accelerating the pace of our work we were able to speed up both the learning process and our workflow experience by conducting more attempts.
• A shorter time-box helped us to better figure out issues. Each difficulty that could be endured in a longer iteration became a severe pain in the neck. For instance: a very long continuous integration build, an inefficient code review, etc.
• It strongly pushed us to find smaller actions to remove the rocks on the road, actions that should have been simple enough to be applied the following week.
• It was more demanding and required higher predictability. We had no buffer to handle surprises. We improved a lot our story slicing.
• We worked harder to compensate for emerging problems. We took care in order to not be in a permanent state of rushing and instead promoted a sustainable rhythm.
• Even with hard time boxing and the reduced length of Sprints, we never reduced the time spent in our ceremonial meetings.
• Because we lowered the number of stories per Sprint, we needed to be vigilant about maintaining team commitment. Thus, we avoided switching to individual engagement per story.
• We reduced the slack time thereby limiting the amount of re-work we embedded in a Sprint but contrarily allowing for the accumulation of more technical debt.

Lessons learned

• We kept up this pace for four months before we changed to two week Sprints. Since then, we have adopted different iteration lengths depending on the context.
• As managers, part of our job is to shape a relevant playground for a given context. Setting constraints can help the team and the organization improve.
• The learning rhythm is a powerful lever, especially when you welcome a lot of changes. It's a good way to speed up transformation.