Scrum is the go-to agile methodology for software and engineering teams. When we first started to use Kanban, we found it equally useful as a complement for scrum projects. We found that many of the same principles that were effective in scrum also helped our kanban teams work better together.
However, as we began to practice both methodologies more closely, the underlying assumptions behind each approach became clearer and led us further down different paths. The most notable difference between them is how they treat re-estimation and backlog grooming – two core practices essential to every project’s success. If you’ve had similar experiences (or if you simply want more information on how these ideas diverge) I’ll go into more depth in the following paragraphs.
For example, in scrum it’s common practice to re-estimate (i.e., revise) scope throughout a project’s cycle; whereas later in this article I’ll explain how kanban recommends against estimation because of its potential for waste and harm to team morale. Similarly, while grooming backlogs may seem like an obvious task to both methodologies, they take different approaches when deciding what stories or tasks should fall under this umbrella. For instance, scrum uses the concept of “user stories” which are very focused on acceptance criteria and small enough that they can be completed within one sprint; whereas kanban describes work items as either “to do” or “done” with few rules surrounding how many items should be in any stage. As an added bonus, Scrum doesn’t even need to be performed by software development teams; since it can equally apply to business analysis or testing efforts.
Before I get into this article series’ explanation of the differences between these two methodologies, let me start off by saying that there are really only one key difference between scrum and kanban: The amount of planning done at each project’s outset. Although both methodologies are still more similar than they are different, this single point will have a ripple-like effect on most other points where scrum has defined practices while kanban does not. For instance, some agile experts say that the lack of upfront planning is what separates kanban from scrum the most.
I am of course referring to this image (and yes, it’s an actual slide used by a former client of mine):
So what is the big deal about getting rid of planning altogether?
It all comes down to predictability and risk. When we do not plan or estimate work upfront, we are at best flying blind and at worst taking an enormous gamble with our project’s success. Best-case scenario: We deliver exactly what is needed when it is needed…which happens more often than you think! Worst-case scenario: The lack of planning results in either scope creep or missed deadlines – which then requires us to re-plan during some crunch time as deadlines loom closer and work becomes more frantic. Either way, we suffer the consequences of unpredictable and last minute changes to our project (which means that we will not be able to accurately predict future work or set reliable expectations for customers).
I recently had a conversation with someone who questioned my stance on planning. She asked me how I can say that planning is bad when many successful projects require planning “and lots of it.”
My first question back was: “Have you ever seen a software project finish early?”
It looks like this:
The point is clear – scheduled work takes longer than scheduled time – every single time – without exception. Whether we use hours, days, weeks or months as units of time, by not estimating our progress upfront and instead letting our work emerge from a prioritized backlog, we can begin to build a healthy understanding of the innate volatility in software development.
This article is about why it’s important not to plan any work upfront and how this simple idea can make us happier as professionals. It’s aimed at product owners, project managers, developers and designers but I hope anyone involved with their own or other people’s projects will find it useful.
What makes us think we need to plan? For some reason most of us have been conditioned to believe that unless we map out our time ahead of time we won’t get anything done. This goes double for software projects – something we’ve had multiple centuries of experience building non-software versions of (farms, roads etc). Sadly, if we’re not careful we can convince ourselves that software projects are so different and complex that only painstaking upfront planning will save us from disaster.
The good news is it isn’t true . It’s actually pretty easy to build something fairly impressive without much advance planning – I’ve done it myself many times. But even better than that, getting rid of the idea of a plan will make you happier as a professional and might even make your project more successful.