The post Kanban vs Scrum – Why Kanban is More Agile first appeared on Qvault.
Agile is great and has made software development more fun and productive while simultaneously less punitive and slow. In this article, I plan to go over my favorite parts of Agile development and point out why I generally prefer Kaban to Scrum. If you’ve read my first article, you’ll know I’m not Scrum’s biggest fan.
What is Agile Development?
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
The same authors of the manifesto also have provided the following 12 principles that back it up:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Assuming you agree with the majority of these principles, the question is, how do we put them into practice?
Kanban vs Scrum
Kanban and scrum are two of the most popular strategies for putting Agile principles into practice. In my geographic area and perhaps generally, it seems scrum is, unfortunately, more popular. I believe this is to be the case not because Scrum is better, but because it makes managers feel better. I’ve already pointed out most of my problems with Scrum here, so instead, in this article, I’ll try to focus on why I believe Kanban methods are more Agile. That said, I think every organization will have different needs depending on culture, preferences, size, etc.
Here are some quick definitions of Scrum and Kanban, but if you’re not familiar with the systems you may want to read up on them in more detail as well.
Scrum
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
Kanban
Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to finish—usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.
Atlassian has a great comparison chart:
| Scrum | Kanban | |
|---|---|---|
| Cadence | Regular fixed length sprints (ie, 2 weeks) | Continuous flow |
| Release methodology | At the end of each sprint | Continuous delivery |
| Roles | Product owner, scrum master, development team | No required roles |
| Key metrics | Velocity | Lead time, cycle time, WIP |
| Change philosophy | Teams should not make changes during the sprint. | Change can happen at any time |
At first glance, Kanban at the very least appears more Agile, but let’s go over some critical points in more detail.
Continuous Flow
As I explain in my criticism of Scrum, Scrum inserts artificial stopping points in the middle of the development lifecycle. The purpose of the sprints is to remind the team to go back and get feedback from customers at the end of each cycle and use that feedback as input to the next cycle.
While feedback is of utmost importance, I’ve found that few teams actually go talk to customers in-between sprints. The underlying assumption that’s incorrect is that getting customer feedback can be scheduled. Instead, Kanban takes a more realistic approach and does it without adding stopping points to slow everything down.
In Kanban, we create a task, and we’re always getting customer feedback. The instant the feedback indicates that it’s time to pivot, we just pivot. Sometimes that means throwing away a task or changing its direction completely. That’s okay. Most importantly, we can just get our tasks done, we don’t have to break them down artificially, have meetings to talk about burndowns, or pretend we can estimate their duration using t-shirt sizes.
Continuous Delivery
Kanban places emphasis on continuous integration and delivery. If you’re a fan of DevOps as much as I am, this point is critical. There are many arguments for delivering software as quickly as possible, but here are the key points:
- Increased ability to compete in the market. If a competitor can only release features and bug fixes every two weeks, their products will not only improve at a slower pace but will appear less stable. With good CI/CD practices, many bugs can be fixed the same-day.
- Code is deployed sooner and starts making money faster. We write code to improve products and make money. The longer code is complete but waits sitting in a queue the more money we’re wasting.
- Engineers are happier and more productive. Engineers like to see the code they’ve worked on be deployed and get used by people. With long release cycles, it takes longer to get that dopamine hit. Easy and frequent deployments to production make happy engineers, and happy engineers stick around.
- Higher code quality. If we think of each deployment as the code going through the car wash then it makes sense that more frequent and easy deploys will keep the codebase cleaner. I have a couple of small refactors I want to get in, is it worth it if I have to wait two weeks to get them merged in? By then I will likely have a merge conflict or two.
No Required Roles
Scrum has a product owner, a project manager (dubbed the scrum master), and a development team. Kanban has team members. There actually isn’t much to say here other than hands-off project managers are a mistake.
My main criticism of the way many Scrum teams are organized is that the person who’s responsible for timelines doesn’t have the product knowledge to know why we are working on y next, or the technical knowledge to understand why x is taking so long.
Estimates
In Kanban, we don’t take estimates as seriously as most Scrum teams do. I’m not sure if this is actually a Kanban vs Scrum idea – but I’ll say what I personally think on the subject.
Estimates are a necessary component of running a business. We need to have an idea of how long a feature will take to release. If we’ve concluded a feature can add $150,000 of revenue each year, that may be great if it takes 2 weeks to get it out the door, but is a horrible time investment if it will take 2 years to complete.
My opinions with estimates are the following:
- They aren’t deadlines. No one should be getting punished for not meeting an estimate.
- Ideally, managers and team leads are capable of estimating tasks they assign with minimal meetings and disruptions to the rest of the team. Again, this requires hands-on managers.
- Estimates should be made in real-time units. A task is estimated to take 1, 2, or 4 weeks, not L, XL, or XXL t-shirt sizes.
Thanks For Reading!
Take computer science courses on our new platform
Follow and hit us up on Twitter @q_vault if you have any questions or comments
Subscribe to our Newsletter for more programming articles
Latest comments (3)
depending on the project
scrum:
youtube.com/watch?v=cV8A_a_ev9E
kanban:
youtube.com/watch?v=U4kfbcUzD9Q
I am a Kanban user myself. It is wonderful because it's perfectly suited to both personal and group use.
This is great. I've been trying for a few years to convince teams to just be honest and switch to Kanban rather than calling what they do Scrum, even though in practice it tends to be like Kanban but with time wasted doing Fibonacci "points" estimation etc. Sprints would never complete all tasks so they'd end with a feeling of failure. I still wonder how and when estimates should be calculated. If it's a "hands-on manager", then it's very hard to avoid a feeling of pressure within the team to treat the estimates as deadlines or targets, which leads to stress and demotivation when things inevitably go to plan. Maybe managers should privately create estimates and not share them with the team, treating them instead as a prediction exercise only.