Startups Should Consider Kanban
Many early-stage startups use scrum, but should consider kanban instead. Why?
Before that, let’s understand how scrum and kanban work:
Scrum works in discrete sprints of 2 weeks 1 each. We begin with a planning meeting where a list of tasks is identified for a sprint, engineers estimate them, and some tasks are removed if they don’t fit in the sprint. Then the sprint starts, and tasks scheduled for the sprint can’t be added, removed or modified. After 2 weeks, the sprint ends, and a retrospective meeting helps us explore how it went and what we can improve.
Kanban works continuously, without any specific sprint beginning and end dates. kanban is like an escalator that moves continuously, while scrum is like a lift that makes a bunch of discrete trips (sprints) carrying a specific set of people in each trip. In kanban, the Product Owner maintains a prioritised backlog at all times. When an engineer is done with his work and is looking for something to do, he picks tasks in order of priority 2. Kanban is a pull-based system, where each engineer pulls tasks from the backlog as needed 3. Managers should not push tasks onto engineers, asking them to take on a task in addition to their existing in-progress tasks.
With this understanding of scrum and kanban in mind, let’s look at why startups should consider kanban.
First, kanban works better for tech support, where a fast turnaround time is important. Many engineers respond to customer requests as part of their job, and delayed responses frustrate customers. Think about how frustrating it is for you when your bank or phone company screwed up and didn’t respond to your requests, leaving you high and dry.
Second, generalising from tech support, if a high priority task comes up suddenly, kanban enables a faster turnaround time by putting it at the top of the list, as opposed to scrum, which forces the high priority task to wait up to two weeks for lower priority tasks 4.
Third, as a consequence of the above two points, non-technical stakeholders are more likely to follow kanban than scrum.
Fourth, scrum can cause a code review rush at the end of the sprint. This is a bad idea for the same reason it would be a bad idea for an airport to schedule all flights to land at the end of the day. Kanban avoids this code review rush, since it’s a continuous flow process. In addition to at the end, scrum also causes a rush of meetings at the beginning, when you’re trying to cram the retrospective and the planning session in the first half of Monday, to avoid wasting a whole day as a gap between sprints. Such rushed meetings are stressful for the team, and kanban avoids them. You can do a retrospective any time, asynchronously, rather than being in the critical path. In general, you want to decouple things, for greater flexibility.
Fifth, kanban works better when you don’t have enough visibility into the future to plan two weeks work. Say the subsequent tasks are dependent on the earlier ones. Or you have a critical customer meeting which would affect what we do next. Kanban is more flexible and adapts to reality, rather than trying to force reality into rigid two-week sprints.
For all these reasons, startups should consider kanban.
You can instead go with 1 or 3 weeks.
Though they can deviate if doing things in a different order saves time, or if they’re fed up of doing too many tasks of the same kind.
Or if he’s stuck and wants to put it on the backburner for a few days.
Obviously, every task can’t be done faster — the total capacity of the team is still the same, so if one task is done today, another isn’t. But that’s a win when the one that isn’t is lower priority. Kanban lets us be more responsive to higher priority tasks. Prioritisation is all about doing more important things first.