Introduction
Maybe you’ve heard of the Kanban agile management methodology and are wondering what it’s all about and why one might want an alternative to Scrum. If so, this blog post is for you. We’re going to look at why you might be having issues with Scrum, why Kanban might be a viable alternative, and how you can learn more and try it out.
Coming From Scrum
…there are projects and teams for which Scrum’s processes and ceremonies are
less than ideal and for which an alternative approach may be better suited
You’re probably familiar with Scrum, the development management process that has arguably become the dominant face of agile. Developed in 1993 and presented publicly in 1995, Scrum has a claim to be one of the first agile processes documented for software development. Scrum has been used at organizations of all sizes and for all kinds of work, from product development and agency work to maintenance. Scrum is a highly prescriptive practice, and there are many teams and projects for which these prescriptions are a great fit. However, I will present the case that there are projects and teams for which Scrum’s processes and ceremonies are less than ideal and for which an alternative approach may be better suited.
In case you aren’t already intimately familiar with Scrum, let’s look at Scrum in a nutshell. In Scrum, work is time-boxed in development cycles called sprints, typically two weeks long, and a core principle is that work assignments are never changed in mid-sprint. Coordinating and planning the work for each sprint falls to a dedicated individual, the Scrum Master, who works closely with the dedicated customer representative, the Product Owner. On each cycle, work is selected from a backlog owned by the Product Owner, work items are estimated as a team into story points, and work is chosen for the cycle according to the team’s velocity, which corresponds to how many story points they typically achieve in a sprint.
Before each sprint, the team conducts the sprint planning meeting. There's a daily short standup Scrum meeting to coordinate around any blockers. To close out a cycle, they conduct a sprint review meeting, including a sprint demo, in which the work from the cycle is reviewed and demonstrated to all stakeholders. Finally, after each cycle is complete, they conduct a sprint retrospective meeting to analyze how the cycle went, looking for ways to improve. Ideally, this cadence lets the team get better and better at planning and they are able to improve their velocity over time. This works very well on good teams with the right kind of work.
However…..
Problems With Scrum
In my experience - and that of many experienced developers I’ve spoken with while conducting technical due diligence at RingStone - the reality is not always so rosy. Now a disclaimer: I have certainly been on effective and productive Scrum teams before. But I have also been on dysfunctional Scrum teams, and my opinion after these experiences is that, when the team is not a good fit, Scrum lends itself all too easily to abuse and can result in significant wasted time and effort. I am certainly not going to argue that Scrum is never a good fit, but I will argue that Scrum, by virtue of its de facto dominance, is often used when it shouldn’t be. Let’s take a look at some of the problem areas.
Work Decomposition
The first attribute of Scrum that can cause problems is the rigid sprint cycle. In Scrum, everyone’s work must be decomposed into chunks that will fit neatly into the set duration of the sprint. Essentially, the team plays a game of Tetris in which they break all work down into items such that everyone is busy for two weeks and no one’s work item overlaps from one sprint to the next. The reality is that this process requires a significant amount of planning work, and yet it still doesn’t always work well. When you think about it, what are the odds that the most logical decomposition of problems -the decomposition that makes the most sense purely from a development efficiency perspective - will happen to work out to fit neatly, cycle after cycle? From what I’ve heard talking with teams during diligence, some kinds of projects or development work lend themselves quite easily to rigid sprints, while on others, this is a constant uphill battle.
A common complaint from developers who are struggling with Scrum is that they are pressured to make things fit, leading to fudging estimates or breaking up stories in inefficient ways - letting the tail wag the dog, so to speak. They get implicit pressure to estimate items to fit and explicit pressure to finish things by the end of the sprint, regardless of whether the estimate was correct. This can lead to deadline pressure on some team members while simultaneously leaving others looking for things to do. At its worst, this can be an ongoing source of stress and burnout and lead to interpersonal friction and declining morale, with some developers feeling like they are treated inequitably based on the type of development they happen to be doing. I’ve personally seen this happen on teams where it reduced developer engagement and company spirit. Overall, it’s worth critically evaluating how well breaking work down into set cycles is working for your team and projects.
Process Overhead
Scrum’s formality imposes a substantial amount of planning overhead. Breaking work items down into specified stories that will neatly fit the cycle length takes time - sometimes a lot of time. To achieve this, Scrum teams have meetings and roles dedicated entirely to the estimation and planning process. In the wrong setting or on the wrong team, Scrum Master and Product Owner roles can become make-work projects, with the work for the role expanding to fill all the available space. Sprint planning meetings and retrospectives have a way of using all their allotted time, even when they could have been minimized or dispensed with entirely. In the process of diligence at RingStone, I’ve encountered numerous teams in smaller companies where an entire FTE salary was being used up on a Scrum Master and a Product Owner, despite the development work and the size of the company not being sufficient to justify this. Create the role and give them Jira, and they will find a way to use the time!
Again, we should look carefully at our team and project, critically evaluating whether the resources allocated to fulfilling Scrum’s prescriptive ceremonies - instead of on development or QA - are actually justifying the costs. Certainly, there are projects where the formality and granularity of tracking that we get from Scrum are necessary, but there are others where this is simply a poor use of limited resources.
Team Maturity
In my personal experience, Scrum works best on highly experienced and highly mature teams. Oh, if only we all got to work on those teams all the time!
In the real world, we sometimes have team members who are too junior to estimate well or fail to understand how to best break up a complicated task. And sadly, we also get teammates whose priorities are themselves over the team. A common comment from developers dealing with this situation is that Scrum is too easily gamed. Developers who want to prioritize looking good over producing actual value will overbid story point estimates for their tasks, giving themselves an easy cruise and the appearance of high productivity.
Now, the Scrum advocate will (correctly!) point out that estimation is supposed to be a team affair to stop this from happening. But this ignores the reality of team personalities and office politics. On one team I ran as a newly arrived leader, the most senior developer was the bad apple - he’d been able to get away with these sorts of shenanigans for years before I got there. He had always strongarmed his way through estimation and planning meetings and had engineered a nice situation in which he always looked like the hero, but in reality worked the least of anyone on the dev team.
Continuous Delivery
As companies mature, they often evolve to the point of decoupling development releases from marketing releases. Today, releasing code to production continuously is the standard that most teams follow. A common scenario is that new development work is kept under wraps with feature toggles so that it can be released daily but revealed at times that make sense for marketing.
Another advantage of continuous releases is that we are able to deal with the occasional need to get something out in a real hurry. While no sane developer wants drive-by managers asking for urgent feature releases in an ad hoc manner, the reality is that business is not always neat and tidy, and sometimes getting a fast fix, patch, or minor improvement out the door tomorrow can make a very big difference to the business. In a Scrum situation, this either has to wait a cycle, or we throw the Scrum planning in disarray for a cycle.
If your team has been wrestling with these problems and feels that Scrum is akin to hammering a round peg into a square hole, it might be time to consider Kanban.
Kanban
Rather than decomposing work into set cycles with precise estimates and detailed tracking, Kanban prioritizes continuous flow and minimum process overhead
Kanban approaches agile process management with rather different priorities from Scrum. Rather than decomposing work into set cycles with precise estimates and detailed tracking, Kanban prioritizes continuous flow and minimum process overhead. In Kanban, work is constantly moving through the pipeline, and all planning decisions revolve around keeping that movement steady, ensuring no stage gets clogged up.
Kanban In A Nutshell
The fundamental core of Kanban is the Kanban board, and in fact, the term itself comes from the Japanese word for “signboard.” The process originates from Toyota’s lean manufacturing practices and is part of their “just-in-time” manufacturing philosophy. Traditionally, the board is implemented as a physical board with vertical columns for stages and movable cards representing work items. In Agile Kanban methodologies, stages are named for actions, such as “specify”, “implement”, and “validate”. Of course, there are now many software-based Kanban board options, but many colocated teams still use a physical board instead (or use one in addition to software), preferring how well a physical board visually conveys the board density and flow at a glance. All that said, a board with columns and cards is not enough - having a Trello board doesn’t mean you’re doing Kanban!
The critical components of Agile Kanban are that stages have both defined entrance and exit criteria and that each stage is allowed a maximum of work items at once, known as its WIP limit (Work In Process). Stages are commonly owned by an individual or sub-team, such as the QA team owning the “validate” stage. When a team member is ready for more work, they will themselves take a card from the previous stage, so long as it has passed the definition of done for the stage it is leaving. Some implementations use two sub-columns under stages to provide visual differentiation between “in-progress” and “ready-for-next-stage”.
If a stage exceeds its WIP (i.e., has too many cards in the column), the team members will adjust their work to correct this, potentially pausing other items, changing priorities, or working on items from stages that aren’t normally their area to get the board unblocked. This “swarming” to get the board unclogged is a fundamental tenet of Kanban.
That’s pretty much Kanban in a nutshell - everything else is up to the team. While Kanban is not strictly defined the same way Scrum is and doesn’t mandate any particular meetings, most Kanban teams do adopt the daily standup meeting. This is typically kept to under 15 minutes and is used to discuss blockers and WIP clogs and how to resolve them.
...compared with Scrum, Kanban is deliberately minimal and very unopinionated
As you can see, compared with Scrum, Kanban is deliberately minimal and very unopinionated. There are no defined sprint cycles, weekly planning meetings, retrospectives, or special roles. There are no epics or milestones, unless you want them. There isn’t even a set number of work items that each person should have going at once, though a common approach is to have one larger and one smaller active item per person. Kanban doesn’t prescribe any particular estimation system nor any specific schedule or methodology for grooming the backlog or conducting retrospective analysis. Some Kanban teams moving from Scrum continue to do group estimation with story points, but from those I’ve spoken with, most prefer to simplify this to t-shirt sizes. Because there’s no need to fit work into a set container of time, precise estimates are not as important.
Advantages of Kanban
The main improvement teams report when moving to Kanban is efficiency. Scrum takes a lot of people hours. The time is completely warranted for some kinds of work, but for others, it would create a lot more business value if the hours were used for development. For some teams, it’s a revelation how much more they accomplish by simply dispensing with all the work necessitated by the rigid Scrum sprint cadence. Most developers I know who have moved from Scrum to Kanban subjectively prefer it - developers would rather be coding than doing planning meetings!
....In Kanban, the entire team is watching the board daily to help monitor flow, and the WIP limits ensure the board stays understandable at a glance
In my experience, Kanban is also less prone to abuse when dealing with suboptimal teams. Without story point estimations, velocity metrics, and sprint burn-downs, there’s really no reward for gaming the estimation process. In Kanban, the entire team watches the board daily to help monitor flow, and the WIP limits ensure the board stays understandable at a glance. As a result, people taking too long on work items tend to get noticed right away, whether the cause was too big a work item, other blockers, or something else entirely.
All team members are responsible for ensuring they take on appropriate tasks and keep them moving. This also tends to lead to a better sense of group ownership. While your mileage may vary, I have personally noticed a palpable change for the better in team spirit from moving to Kanban.
Kanban is ideal when combined with Continuous Delivery and is a natural fit for trunk-based development. Finished items can be released into production as soon as they are done. Of course, this requires a team with a mature QA process and strong automated testing. But again, continuous delivery isn’t a requirement of Kanban - teams who are not there yet can use a Kanban process with feature branches and can still collect finished items into buckets for releases at whatever cadence they wish.
While Kanban - much like Scrum - can be used on all kinds of teams and projects, it’s especially popular on projects where demonstrating incremental improvements to stakeholders every two weeks doesn’t make sense from a higher-level project planning perspective. For example, DevOps and maintenance teams often adopt Kanban for their ongoing work. And on the other end of the scale, large game studios building very complex software like it for the way it keeps everyone focused on work, with little planning overhead going towards intermediate milestones of questionable usefulness.
About The Author
Iain C.T. Duncan has spent the last 20 years working in the software industry as a CTO, developer, software architect, and consultant, building B2B and internal web applications at startups, agencies, and early-stage companies in Canada and the U.S.
As a practitioner at RingStone, he works with private equity firms globally in an advisory capacity, conducting technical diligence on early and mid-stage companies and preparing companies for the diligence process. He has worked in the diligence sector for six years and has been involved in hundreds of diligence efforts as a practitioner, reviewer, and trainer. Before the diligence sector, he worked on software in e-commerce, association management, non-profit fundraising, genomics, and online education, among others.
An active open-source developer and researcher, Iain is currently completing an interdisciplinary PhD in Computer Science and Music at the University of Victoria, working on applications of Scheme Lisp to algorithmic music and music pedagogy. He is the author of the Scheme for Max open-source programming extension to the Max/MSP audio programming platform and is the founder and developer of the online music education platform SeriousMusicTraining.com.