Done right – either Scrum or Kanban will work for an agile team. As a Product Owner I always leave the choice to the team, even though I do have a preference.
One of my teams, who initially chose Scrum, decided to give Kanban a try. The plan was to try it for a month and then retrospect on what suits us better. Every day we were collecting data in order to make a proper data driven decision at the end of the experiment.
Work in progress (WIP) limits
We already had a WIP limit for number of tasks (7) and decided to keep it as it was. Deciding on SIP (stories in progress) limit was not that easy however. The very first day, the team (of 8 people) automatically picked 6 stories from the backlog and were ready to start each of them(!) straight away. From my perspective they were completely missing the point. Less work in progress means more focus and less context switching, which is a silent killer of good quality. Here is a good video about why limiting WIP works.
We negotiated and ended up with a limit of 4 stories. Observing the team I realised, that there was an attitude change required as well. I witnessed a situation when two team members finished a story and instantly started picking a new story from the backlog, instead of checking with the rest of the team if there is anything they could do to help progress other stories.
NB: WIP limit is a limit, not a target!
We were not excelling in Scrum straight away. It took 6 sprints to deliver exactly the number of stories we committed to in the sprint planning meeting. To be fair, these were very first sprints of the newly created team, so we knew it was not going to be perfect.
What actually triggered the thoughts of a change, was the fact that the team was adding quite a lot of technical stories to the backlog. Some of those should really be part of the original user stories the team was working on. Questioning further, we found out that the reason for separating the ‘user work’ and ‘technical work’ was… the sprint end. The team wanted to mark stories as done, even though unit test coverage (or some other technical aspect) was not good enough. That’s not really a ‘done’ story, is it?
Initially the team kept working on many stories at the same time (orange bars on the chart below). This was making the cycle time of each story longer – very little was being completed (green bars on the chart). As soon as the number of stories in progress went down, stories were completed more frequently and the cycle time (and lead time) got shorter.
Another thing that improved when we switched to Kanban was the number of stories completed (throughput). The data clearly shows that the team started delivering faster than before.
Before deciding one way or another, we dedicated one retrospective meeting (we kept having retrospectives during the Kanban trial) to talk about what went well (or not) and how does the team feel about going ahead.
The new ‘data’ (post-it notes) clearly showed an interest in Kanban.
Some conclusions about Scrum:
- End of sprint was causing stress to some team members and resulted in additional technical stories. However, a deadline was a good motivation for others.
- Sprints mean predictability, but because we almost never completed all stories that we committed to, it was no use to me as a PO.
- Some team members didn’t have anything to do at the end of the sprint, while others were rushing to complete their work (or create a ‘leftover’ story instead).
- There are a lot of rules to follow and artificial deadlines.
- Every sprint naturally ended with ‘lab days’ – a day and half when the team could work on anything they wanted or simply learn new things.
Some conclusions about Kanban:
- We were going faster (which could be also a result of the team maturing).
- Kanban is more responsive to changing business priorities, which is great from a PO perspective, but not everyone in the team can embrace uncertainty the same way.
- Meetings only happen when we need them, and not because the calendar said so. Stories are groomed as we go along, demos happen when there is something to demo.
- Stories are broken down to tasks only by part of the team, which is more cost effective, however perspective of other team members is missed.
- Developers can focus on finishing a story, including unit test and any required refactoring, without stressing about the sprint end (let me quote one team member: ‘hack less to complete story on time’).
- There is less work in progress.
- The team missed their lab days because there was no sprint end.
Some of these points, like WIP limit or lab days, could be enforced in both – Scrum and Kanban, so they are not really related to the framework.
The voting was undisclosed. Everyone simply stood by the side of the wall, which described their chosen framework. This resulted in 5 people standing by Kanban side and 3 people closer to the Scrum side (in between actually).
Something to remember
Before you switch to any new framework – invest some time in communicating again what the change is about. I don’t think it was very clear in our team – we just assumed that everyone knew what Kanban was about. Surprisingly – we weren’t aligned and some people struggled initially.
Experimenting with different frameworks can help the team to uncover some issues, that even though not related to a specific framework, might have been not visible before.
In my opinion, Kanban is more flexible to work with, but requires more self discipline. I’d advise less experienced teams to try Scrum first.
1. Short videos comparing Scrum and Kanban:
2. A blog post from my other team, who uses Kanban from day 1.
3. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win – a great novel about Kanban in practice.