A few months ago I joined a new team as lead developer. This team was notionally using Scrum, although it was far from a textbook example of it. Right now, my preferred method of working is kanban; I’ve found that within my organisation, and the type of products we work on, the estimation, prediction and control side-effects of Scrum aren’t particularly beneficial given the overhead (it’s very easy to have 1 day a fortnight just turn into planning/demo/retro day).
With a kanban approach, we gained the flexibility to adapt to our unstable backlog as well as losing the process overhead which gave us little benefit. For the purposes of this blog post, I consider any process which implements the following principles as kanban:
- Visualise work in progress
- Limit work in progress
- Continual self-improvement
Introducing continual self-improvement
Typically, I’ve found moving a team from Scrum to kanban fairly straight-forward. Once you agree to “do kanban” and implement continual self-improvement, the other two principles just fall out as solutions to the pain that happens when you don’t do it.
I’ve been through the process a couple of times, although this example is the only case where I’ve led it. It’s particularly easy when the prediction side-effects of Scrum aren’t used, or are barely used. The first step is to agree that you’re going to do it, and in a self-directing team this is normally straight-forward. If Scrum is a management-imposed edict then I imagine it’ll be harder, but for self-directed teams, you can move to kanban, but continue estimating story points and measuring points completed per 2 weeks and provide those predictions to your external stakeholders.
As this team wasn’t providing predictions we didn’t even have to worry about it: the first step was just to decide to drop the sprint rituals and replace them with new pull-based meetings: a “requirements” session where developers got detailed visibility into what’s coming up before “ready for dev” (we’re now trying out Amigos sessions to replace this) to replace planning, but we hung on to the retrospective and demo (however the demo is to our stakeholders, rather than the product owner, who has already seen and signed off the feature).
One potentially controversial approach I decided to take was to maintain fortnightly retrospectives/demos. One argument in kanban is that self-improvement should be continual, rather than restricted to fortnightly meetings as in Scrum, but in my experience, it’s still important to make time for reflection, rather than expecting it to emerge organically. Running a good retrospective is important regardless of which technique you’re using, and I’ve written a separate blog post detailing my experiences of it.
Once you agree to “do kanban”, then visualising everything instantly becomes very important. How do you know what to pull if the backlog isn’t visualised alongside the development work? In this team we had 3 different task boards: the product ideas board, the UX team board, and the dev team sprint board, across tools like Trello, Google Sheets and a physical board. We decided to consolidate everything into one Jira board and sat down to properly define our delivery pipeline, making our Jira board reflect that process. Simply doing this highlighted so many issues: UX weren’t working on what the highest product priorities were, some of the upcoming product ideas had large external technical dependencies which hadn’t been identified, product thought developers were building things which weren’t on their roadmap… The upside of using one tool for everything negated any downside some people felt associated with moving to Jira.
Kanban also felt like a more natural fit with our continuous delivery approach.
Kanban and Continuous Delivery
In this model, we’ve essentially dropped planning, yet one of Scrum’s strengths was in tasking out each feature which gave a good level of insight into the level of work involved. As our team has adopted continuous delivery techniques, we’ve challenged ourselves to “vertically slice the backlog”, meaning each user story that comes through is as small as can reasonably be, yet still implement some business/user value, as an alternative to tasking.
In the context of our continuous delivery pipeline, this gives us an interesting funnel, as things on the left of our pipeline are quite large, and then get increasingly small as it approaches ready for dev, so we can release a feature in quite small chunks. This ties in quite well to the limit work-in-progress and visualisation principles of kanban. One large user story can actually hide a lot of work, however WIP limits are typically set on number of items (easier to manage) than total amount of work (as tickets can vary in size). If you take in a single large item, then you may appear to be under your WIP limit, but actually have exceeded it notionally by having one thing that hides multiple things in there — this parallels Scrum’s sprint planning which ensures you don’t take too many big things into a sprint by tasking them out in advance.
Generally, I find kanban better reflects a CD pipeline as stories move through the pipeline they come better defined and smaller, which we reflect by having smaller WIP limits the further right a ticket travels on the board, as smaller tickets can move faster. And after all, software development is all about taking a user need, iterating on that, increasing its definition until it’s specified in the ultimate level of precision — implemented code.