One week sprints tend to be less popular than their more fashionable cousin – the two week sprint. However, I’ve found it can dramatically improve team maturity and efficiency, providing a gateway to successfully practicing Kanban.
Scrum vs Kanban
Virtually every agile coach has heard the complaints that Scrum doesn’t work and we should be doing Kanban instead. In my experience this is because both Scrum and Kanban are misunderstood. Scrum forces you to be disciplined, Kanban expects you to be disciplined. Those who assume Kanban is a silver bullet tend to have little understanding of how Kanban really works. Moreover they are less likely to have the skills and discipline to practice it successfully. There’s a fine line between Kanban and chaos. If practiced well, Scrum, and one week sprints in particular, can be used to effectively avoid chaos and exploit Kanban’s full potential.
A Tale of Two Teams
I’d like to say this was all part of a master plan, but as with all great lessons, I learned through experience. At the time I was coaching two teams working on the Moonpig website – I’ll call them Team A and Team B.
Team A decided to work in one week sprints to shorten the feedback loop and improve rapidly as a team. Team B started working in two week sprints, and then switched to one week sprints in the hope they’d be easier to plan and complete.
Team A successfully practiced one week sprints from the very beginning. Team B struggled as much with one week sprints as they had with two week sprints. So what was the difference between the teams? Team A certainly had some core advantages – they had more greenfield projects, while Team B were involved in complex rewrites and re-architecting. Team A worked to a clearer product vision, whereas Team B had to define the work themselves because it was re-architecting rather than introducing new functionality. But in fact, these had no influence – the difference was in the way the two teams worked. Once Team B adopted the practices of Team A, they changed almost overnight. So how did Team A make it work?
Getting it Right
Put simply, Team A were “kanbanising” their sprints. Without any reference or knowledge of the Kanban framework, they were applying Kanban principles to complete their sprints. The specific practices they used were:
- Limiting work in progress – whilst they never used this term or set an official limit, they were fixated on completing work in progress before starting anything new. Put simply, they focused on finishing, not starting.
- Ticket-focused stand-ups – whilst Scrum tends to advocate a stand-up in which people update on their progress, Team A focused instead on the tickets on the board. This shifted the focus of the stand-up to discussing what could be completed today, and how that would be achieved. In keeping with Kanban, this shifts focus to the workflow of tickets ensuring everything moves as swiftly as possible.
- Collaboration – every piece of work was either paired or swarmed on. Where code changes were confined to a single component, the engineers would pair. Where multiple components required change they swarmed – one pair might focus on the database element, whilst another might pair on an API element and a further pair might work on the frontend. On occasion the whole team could be occupied working on a single ticket, and consequently it got done extremely quickly.
- Pair rotation and knowledge sharing – the team would often be working across two features simultaneously. As there tends to be a limit to how many people can work on a single feature without treading on one another’s toes, you often need two features in development simultaneously. When this was the case, instead of falling into the trap of splitting the team, with half working on each feature, individuals rotated between features each sprint. This ensured domain knowledge of each feature was fully shared and understood. Crucially this meant any ticket could be picked up by any engineer – everyone would have the necessary context. Sprint planning sessions were used to manage this rotation and ensure context and domain knowledge was widely spread.
- Small stories – we know breaking work down small helps us get it done quicker, but story splitting is notoriously difficult. Working in a one week sprint forces you to break everything down small enough to be done in a week; it means you have to get better at story splitting. Coaching can do a lot to support this, and with practice teams do get the hang of it. Once they have learned to break work down small, it becomes a healthy habit, and vital to practicing Kanban successfully. When teams struggle to break features down, my advice is not to worry unduly about the value of each individual story. Focus first on getting the smallest, independently testable and releasable unit of work. Once that is mastered, you can start effectively splitting to deliver maximum value to the end user.
Getting it wrong
So if team A were getting it right, what were Team B doing wrong? Two key practices marked the significant difference in performance between the two teams:
- Working in isolation – pairing virtually never happened. Engineers worked in isolation, relying on code reviews which were lengthy and typically required multiple changes. This both increased the amount of work in progress, and increased the cycle time of each individual piece of work.
- Feature silos – as with Team A, Team B usually had two work streams in progress. Unlike Team A they did split the team across those two work streams. This meant we effectively had two mini teams. In sprint planning sessions we would plan first half the team’s work, and then the other half of the team’s work. This limited the number of people that could work on any one ticket – a ticket for feature X might need a code review, but the only person free would only have knowledge of feature Y. So instead of completing the work already in progress, they’d pick up a new ticket from the feature Y backlog. This lead to the ridiculous situation whereby at the end of the sprint we’d have planned work that was incomplete, but half the team would have finished what they were working on early and would need to bring more work in!
Righting the wrongs
The good news is that, once they recognised the problems, Team B were able to transform their performance virtually overnight. To help illustrate the problems that prevented them successfully completing sprints, I gathered together some metrics and showed them the following:
This showed the volume of stories still in progress at the end of each sprint. As I explained to the team, one story done is worth more than 5 stories in progress.
The second graph illustrates the volume of unplanned stories that were completed as compared to the volume of planned stories in progress. When shown the data the team instantly identified the changes they needed to make. They agreed that they would pair on everything, and that there would no longer be feature silos. Via pair rotation they would all work across all features in development.
Performance changed immediately. Thereafter, every sprint was completed within +/- 20% of what they’d planned – which we considered a good measure of performance, given that you would never expect a team to complete every sprint. They continued to deliver consistent performance for another 18 weeks, before successfully transitioning to kanban.
Moving to Kanban
Thanks to the disciplines developed in one week sprints, migrating to Kanban was virtually seamless. Each team experienced an early bump in the road as you might expect. Team A lost the focus encouraged by a sprint deadline, allowing work to extend to fit the time available. Team B started to ignore the work in progress limit. Both teams immediately saw the impact of these practices on their velocity and made the necessary corrections immediately. Crucially, disciplines developed within one week sprints had become habit, enabling them to leverage Kanban’s potential without falling foul of chaos.
Another Key Technique
Within the Moonpig web teams we have made a concerted effort to develop cross-functional engineers over the past few years. We no longer hire QAs, and the few people hired as QAs are being supported to upskill in development. Consequently our teams are made up of cross-functional engineers who design, write, test and deploy their own code. This mix of skills means no ticket is ever blocked because a certain skillset is required to work on it. It also means everyone takes ownership of quality.
Arguably Scrum relies more on cross-functional engineers, but your Kanban workflow will undoubtedly improve with cross functional engineers.
Want to give it a try?
If you’re keen to try one week sprints, here’s a couple of common resistance points you might encounter.
- One week sprints mean we have too many meetings!
You will need an extra planning meeting, but it will be half as long because you’re planning half as much. So the net meeting time doesn’t change! Likewise you can have one longer retro every two weeks (as we chose to do) or have two shorter retros once a week. In the early stages the weekly retro might help you improve faster; later you can move to retros every two weeks.
2. What about the release cycle?
You don’t have to release at the end of each sprint, but if you can release, why not? Delivering once a week instead once every two weeks is no bad thing, but it’s certainly not mandatory.
3. Sprint demos
If it takes two weeks to have enough to share with stakeholders, continue to hold your demos every two weeks. The chances are you’ll have more to show from two successful one week sprints than one unsuccessful two week sprint!
And one final note of caution… Expect the first couple of sprints to be tough. It’s unlikely to work perfectly at the start. Prepare the team for this and focus on improving with each sprint. The long term performance improvement will make up for a temporary dip in velocity.