Maybe it’s all the time I spend with startups, but while I strongly value Scrum’s ideas behind self-organizing teams & continual feedback – I can’t help but feel Kanban represents the next level of agility, giving us more flexibility and capitalizing on the lessons we’ve learned from Lean.
Scrum
A lot of people tend to think Agile means Scrum – you know how it goes:
And I think there’s a lot of goodness in Scrum. It provides clear structure for what the team needs to do (the Sprint Backlog), gives them focus for getting it done (backlogs are fixed for the duration of the sprint), and then enables the team to determine the best methods for getting that work done. It even provides them a coach (ScrumMaster) who’s job it is to make sure they have what they need and to get impediments out of their way.
I love it’s feedback loops for constantly checking in, making sure we’re on track and – when we find we’re not – adapting as needed: Daily quick (15 minutes max!) meetings for the team to sync up, customer demos each sprint, regular team retrospectives. As Ken Schwaber says, software is too complex to completely avoid failure and why would we want to anyway since failure is how we learn! Instead, what we need is a framework that enables us to identify failures as quickly as possible so that we can learn from them and adapt accordingly (see: Framework for Finding Failure).
The Problem with Scrum’s Time-boxed Sprint Lengths
The thing I’ve grown to dislike about Scrum are it’s time-boxed sprints.
Working with startups, Scrum sprints are almost always way too long. When your sprints are too long then releases are infrequent (deferring revenue) and the team is forced to wait too long before being able to adapt to changing customer needs. This is wasteful because it means you’re continuing to move forward with outdated information.
On the other hand, if sprints are too short, big features need to be arbitrarily chunked into smaller tasks, which aren’t useful to the customer on their own & can obfuscate what the team is trying to achieve (see: Kanban Development Oversimplified).
I recognize the advantage to Scrum’s set-lengthed sprints was to provide predictability. If we work in consistently-lengthed sprints then we can define our team’s velocity to predict how many stories we can deliver each sprint. Or, as is the norm with Scrum, we can say, “on X release date we’ll deliver this long list of features.”
But, I believe that for the same reason two weeks is suddenly too long, this predictability isn’t realistic anymore. The faster technology improves in allowing us to quickly build & demo features, the faster it enables the customer to change their thinking, the faster it enables us learn and adapt, the faster things are changing. And we can either respond to those changes by truly adapting the software into the right solution. Or we can blindly ignore this information and stubbornly continue marching down the not-quite-right-path because our sprint hasn’t ended yet.
Kanban
Kanban addresses these challenges with a different approach to scheduling. Rather than working in time-boxed sprints (Kanban has no sprints), Kanban puts limits on how many features a team can work on at a given time.
As soon as a feature is completed – two things happen:
- The feature is available for immediate release into production (should the team wish to do so)
- The team can start working on whatever the next highest priority item is. Even if that item was just learned today!
Below is an example of a Kanban board, which is used to visually track the status of each feature:
Each column represents the state of the feature, and under each column – in red – is the maximum number of features that are allowed to exist in that state at any given time. The columns can be named whatever makes sense for the team, but you’ll typically have a To Do column with the next features to work on. Next, you’ll have 1 or more columns to represent the work that’s In Progress (here, we have Development, Test & Release). And finally a Done column.
You don’t want to go too crazy on the # of columns else you’ll hit inefficiencies from that as well, but separating the work into a few different states reaps yet more advantages from Kanban:
- You can specify different workload capacities for different disciplines based on your team’s capabilities
- You get a visual, real-time status of your team’s workflow so you can be continually optimizing your process as well as eliminating bottlenecks (or other problems) as they occur (before they have a chance to compound).
The result is more feedback with the ability to adapt to that feedback faster.
Evolving Practices
I still believe Scrum contains excellent ideas – like self-organizing teams & continual feedback – that we shouldn’t just throw out with the bathwater. But, these same ideas continue to work with Kanban’s scheduling (see Kanban and Scrum).
And so, I believe the evolution of agile – as has always been the case with agile methodologies – is pulling from those practices that make the most sense. Kanban for scheduling, Scrum for self-organizing & feedback loops, and XP (with some of the new practices from Lean Startup!) for technical practices.
Photo Credits: Scrum Process by Mountain Goat Software, Kanban: Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
