Kanban tricks for solving problems fast
In October, my area within Ocado Technology undertook a radical transformation. Over the course of a single day we carried out an area-wide, self-selecting restructuring exercise. The team I now work in consists of six team members. None of us had worked together before. Although most of the other new teams decided to take on a fairly traditional Scrum approach to their process, we decided that such a radical reorganisation would be a good opportunity to introduce some experimental new process ideas and ways of working. We incorporated some of our favourite Agile/Lean development techniques and spent the next three months adapting the process to fit our team. Here’s a taste of some of the things we did.
We chose Kanban.
We decided to use a variation of the Arrow Kanban board, which is itself a variation on the traditional Kanban method. Where Kanban usually has “Work In Progress” (WIP) limits for each stage of the process, we simply have a “Story in Progress” (SIP) limit. While we were a new team (learning the systems and trying to get on top of in-office support) we set our SIP limit to two stories, which provided plenty of work for two pairs of developers. We’re now more familiar with things, so we’ve given ourselves room to take on a third story, but we only do this if there isn’t anything else which can be progressed or parallelised on the other stories.
Kanban is working great for us. We maintain two work queues; a “prioritised” queue and a “random” queue. Our Product Owner (PO) can move the user stories around between these queues, changing priorities whenever she likes. This means that we can be more flexible when it comes to avoiding taking on stories which we know will become blocked, we can respond to changing business needs or deadlines very easily and we can prioritise work which would otherwise cause us to block another team. We think that this is a huge benefit over sprint-based methods of working, where it’s hard to estimate how much work to commit to and – even with a one-week sprint – you are left with very little room to act in an agile way when priorities change.
We decided we didn’t like meetings. Well, some of them.
Most of the team were in agreement that we prefer writing code to holding endless meetings. Spending a few hours every two weeks in sprint planning sessions, estimation sessions and doing backlog grooming didn’t seem like our idea of fun… and the value we thought we would get from those meetings was questionable. Maintaining a small work queue and taking on stories whenever we are ready helps us avoid these lengthy planning meetings.
As a result of Kanban and a lack of meetings, we don’t estimate our stories, either. I’ve found that estimates are almost always wrong, even when only considered in a relative manner, so I’m skeptical that there is any value in estimating stories on a routine basis. Additionally, this removes the pressure upon the team to ensure that all of the stories estimated to be finished during a given iteration are complete by the end of the iteration – something which I’ve noticed often results in teams either speeding up or slowing down towards the end of the sprint or, worse, cutting corners such as leaving out testing in order to mark the story as “done”.
This doesn’t mean we don’t have meetings. We still talk about stories and break stories down into tasks, but we do this when we’re about to start work on the story so that we aren’t as affected by requirements changing between planning and coding. It means that we can dedicate more time to discussing complex stories, rather than bundling the conversation into a meeting with several other breakdowns also required. Very importantly, we don’t require the whole team to be involved in story breakdown – just the team members who have an interest in that story. Other team members are brought up to speed during stand-ups, or when we switch pair-programming duos; something we try to do as often as possible, but perhaps not as often as we might wish to.
Removing unnecessary meetings from our calendar also meant that we have been able to spend more time doing things with more business value, such as engaging more with our users in order to keep a tighter feedback loop.
We solve problems fast.
Our team has two stand-ups a day. Yes, two. Rather than giving individual status updates, we talk through the stories we have on the board (remember – a maximum of three!). We talk about the progress made, what the blockers are and what the next steps will be. Frequent stand-ups mean that blockers can be identified and discussed more quickly, and the process has become so well-oiled that we can finish each stand-up in around five minutes.
Despite ditching sprints, we still have retrospectives. In fact, we hold them weekly. This is probably more often than most of the scrum-based teams host retrospectives. Like our stand-ups, we’ve made these meetings as short as possible; they’re an hour. A different person hosts each week and, after discussing the things that went badly or well in the past week, we try to come out of every retro with some actionable items. If an action is specific, it goes on the board. If the action item is more culture or behaviour based, we make a meme about that aspect of our work and stick it onto our team board to remind us to take the retro discussion on-board. For example, on one occasion people disliked how our “let’s take this meeting offline” codeword, “Mango”, was being used to shut people up rather than genuinely move discussion out of a meeting (see the image).
Sometimes, issues spring to mind which need team input but are perhaps too large to fall into the scope of a retrospective. This was most true when the team first had formed, and we wanted to make decisions about our release strategies, our code review policies, etc. To try and address these problems, we set up a section of our team whiteboard called “3 Things”. People could write down things they wanted to discuss in more depth and, once three things had been written on the board, we booked in an hour-long meeting to talk about those things. Now that we’ve spoken about many topics, we’ve started to notice that decisions can be made more quickly. We’re currently trialling discussing some of the smaller topics after our standups.
We measure ourselves. A lot.
Whenever our stories change state, we log it. From this data, we can track how much time stories spend in each state and we can measure our cycle time. I think we all agree that what we really want to be doing is writing code, rather than spending our time manually testing or working through a painful deployment process. By considering how much time we spend in each development phase, we can identify which types of stories get stuck in undesirable phases and work out how we can avoid this in future – usually by adding some more automation. We tend to look at the graphs of our data in our retrospectives so that we can look for problematic stories and follow our progress in improving the metrics we’re tracking. We find that our Cumulative Flow Diagram (CFD) is particularly useful at identifying bottlenecks where stories regularly get held-up.
Another thing we measure in our retrospectives is our Productivity, Collaboration and Happiness. “Our” is loosely defined here – individuals tend to factor in their perceptions of how well the team is doing, and also their own view. We cast a vote (between one and five) anonymously on post-it notes for each aspect and then draw the results up on the board. Once the results are up, we compare them with the results from the previous week and discuss the reasons for any variations. People seem to enjoy this activity. Despite the voting being anonymous, I’ve observed that people who give one of the three aspects a low score are almost always happy to identify themselves to the group and give specific reasons as to why they voted this way. I like to think that this is a sign of excellent trust within the team.
We don’t tell people how to manage their workload.
Despite the fact that I think our process is awesome (awesome enough to write a blog post), we’re hesitant to tell other people how to work. A team located near us has decided to try the switch from Scrum to Kanban. I’m delighted. Although they are doing things very differently from us, we’ve tried to give them some advice along the way.
It’s important to note that there’s no silver bullet when it comes to Agile or Lean software development. Many people think that “Agile” means “Scrum”, and that “Scrum” is a rigid process, but this couldn’t be further from the truth. What I have realised is that if you don’t enjoy your process then you probably won’t enjoy following that process. Don’t do something because I’ve said it works for my team. Don’t do something because it’s what all of the rest of the teams in your company do. Break the mould, and choose a process which works well for you.
I hope that this post gives you some confidence to pick and choose the parts of each Agile tool that your team finds the most useful, and ditch the parts that don’t provide enough value to your team.
Lawrence Weetman, Software Engineer