Crushing it with Kanban
Simple, fluid, flexible and dynamic. A better embodiment of agility.
Like most internet economy companies agile principles are at the heart of Skyscanner product development. The regular cadence of sprint meetings form the heartbeat of continuous delivery for many squads. Within the Car Hire Tribe, however, there was a niggling feeling that we weren’t being as effective as we could be. After two days squirreled away in a room applying the Theory of Constraints to our development process we came to the conclusion that Scrum wasn’t working for us.
The main criticism was the overhead involved. Too much time was consumed in (long) meetings. Not everyone was needed for every card discussion. The sprint format was too rigid. Sizing was not providing any benefits, took too long to discuss and often resulted in overfilling the sprint. Etcetera.
We decided to give Kanban a shot. The reduction of meetings provided an immediate relief. It freed up the engineers to do what they do best and what they enjoy most. Kanban put the focus back on delivering quality software. Not planning and project management. The biggest benefit to me though was the flexibility and the ability to adapt to changing requirements and priorities.
Of course you don’t want engineers continuously changing tack but Kanban gives you the flexibility to change priorities before engineers pick up the cards. The Product Manager is responsible for New column and the engineers are responsible for the other columns. Effectively sheltering the engineering team from distractions around prioritisation and churn. It avoids the false stress of altering the sprint that you “committed” to and the inevitable discussions around adding and removing items from the sprint. It makes it easier to adapt to dependencies on other teams, requests from other parts of the business, bugs, learnings from AB tests or usability studies, etc. Naturally the value of each job must be weighted and prioritised but it becomes a more dynamic, responsive process.
We still do daily standups and we still run retrospectives to help refine our process. One of the most effective refinements is that our Squad Lead engineers shape the cards in the analysis column before they are picked up for actual development. Thus the engineer with the most experience spends the time analysing the technical implementation details and provides guidance upfront (exploiting and subordinating to the constraint). UX Design also pick up cards ahead of developers without worrying about whether or not the design will fit into the same sprint as the development.
It’s not perfect by any means. The new column regularly overfills and needs pruning. Assigning cards for code-review means engineers can have multiple cards in the In Progress column, which risks the temptation to multi-task. It sometimes feels like the focus or urgency that you get in sprints is missing (we tried setting goals for the week but this didn’t sit well). Conversely, the constant flow of cards can sometimes feel unrelenting and doesn’t allow time to read or try new things. To address this the engineers wait until Test has finished before picking up new card. This has the added advantage that it prevents context-switching between the previous and new jobs.
Arguably there is more overhead on the Product Manager who has to be constantly on top of the backlog and evaluating priorities. However, in my opinion the benefits of flexibility and fewer meetings vastly outweighs this.
Kanban increased our productivity, enabling small tasks to flow quickly into production while affording the breathing space required for meatier jobs.
