Why I now love one week sprints
Last year I joined a project for a few months to help with their mobile architecture. The delivery lead had a very strong idea of team culture and practices — one of which was one week sprints.
At first I was very sceptical. What can anyone achieve in a week? What percentage of the week would be consumed with sprint ceremonies? How do you get a feature in Jira to be built, tested and deployed in such a short timeframe? Would one week allow meaningful changes — what about larger pieces of functionality?
I am now back on the project and I found myself defending the weekly sprint cycle during a discussion with some of the dev team. I was surprised that I had been converted.
So what is it about a weekly sprint that now makes sense?
1. It puts pressure on brittle parts of your process.
When iterating in short cycles, the weakest part of your process becomes immediately apparent. The longer the sprint, the longer you wait to encounter failure and the less immediate or intense the pain.
Let’s take an example. One part of the definition of done for this project was to be deployed to the QA and Pre-Production environments. In this particular organisation, that is actually quite hard to achieve.
Early on we continually failed to get to ‘done’. I think it took about 8 sprints until we got there. However, knowing that we failed every week made it clear to everyone on the project where the point of failure was and it kept our goal ever present.
Similarly, there was recently an issue with a CI environment. The breakage became quickly urgent as multiple teams failed to complete a sprint just a few days later.
The one week sprint cycle helps us break (i.e. fail) fast.
2. Scrum teams integrate sooner and more often.
We have multiple scrum teams working on the same app. Completing sprints every week means we are constantly merging our work together into the develop branch.
The benefit is that we don’t get large “oh sh*t” integration moments. Any merge problems are relatively small and much easier to resolve.
We also get confidence that the app is working despite new code from multiple developers on multiple features. Again, if something breaks, we know after only a week rather than multiple weeks.
Ongoing integration is also something that happens between the app and the backend services. This provides even more opportunities to spot problems and misalignments.
3. Features must be decomposed into smaller steps.
The rigour of weekly sprints is felt outside the technical team as well. Product Owners and Business Analysts have to think about how a feature is delivered incrementally.
We find it makes us think about what is the most minimal experience for a feature. It helps us achieve value for users as early as possible and then bring improvements out in quick succession.
4. We are forced to invest in efficiency.
Weekly sprints means we have to get the most out of the development time available. This drives us to think about our code and architecture carefully and ensure it makes feature development efficient. It lends purpose to our technical decisions.
Identifying opportunities for reuse becomes second nature. This drove us to encapsulate the product’s design language into UI components which dramatically speeds-up development of new screens.
Separating concerns also helps focus on where code changes. We strive to separate out where we integrate with APIs vs common UI elements vs app flows etc. Our team can organise themselves around these concerns during a sprint and work together sensibly on one change.
Effiency also means fewer and more focused meetings. The team naturally gets very uncomfortable when they are pulled away from their work for too long.
5. Impediments and trajectory are readily apparent.
The shorter sprints means that bad news travels fast. This helps our programme management see problems faster.
The sorts of things that become quick to identify include blockers, unmet technical dependencies, unplanned work, code quality problems, unstable environments, unexpected team absences.
Whilst bad news is never welcome, the element of surprise for the project is vastly reduced.
Although I am now a convert, there are some challenges with short iterations.
- It is very easy to derail a sprint. Critical bugs from previous builds, team members out sick, a few too many beers down the pub the night before…
- Teams must be careful not to create a pressure-cooker environment with a never-ending cycle of hard-to-achieve sprints.
- Individuals in the team need to be good at managing their time and not letting it get consumed by meetings, tangential discussions etc. When each sprint has four effective days for technical work, it is critical to protect one’s time.
- The team needs to be kept aware of the big picture. It can be hard to see the full extent of a feature through the keyhole of weekly iterations.
- It can be difficult to decompose a feature into small enough pieces to be consumed on a weekly basis.
Going forward I will be encouraging weekly sprints in other projects. Maybe I will get a chance to write-up our experiences here.
