Published on: July, 2014
Topics:
- Development •
- Methodologies
Published on: July, 2014
Whitepaper: Kanban vs Scrum
Kanban vs Scrum By Belatrix Software | Topics: Software Development
Introduction
Have you ever wondered what the best agile methodology is? Even though you may not need to make a decision right now, you probably want to understand how each methodology can help you.
I want to share with you a brief comparison between 2 trending agile methodologies. Each one has its own evangelists dedicated to preach about the advantages and functionalities that makes one better than the other. But… which is the one that fits your needs? What’s the most adopted methodology world-wide?
I’m briefly describing both and then reviewing some of the differences and similarities of each one, so we can understand which one is better for your project.
Scrum in a nutshell
- Splits your organization into small, cross-functional, self-organizing teams.
- Splits your work into a list of small, concrete deliverables. You can sort the list by priority and estimate the relative effort for each item.
- Splits time into short, fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code, that will be demonstrated to the client after each iteration.
- You can optimize the release plan and update priorities in collaboration with the customer, basing your decisions on the insights generated by inspecting the release after each iteration.
- Optimizes the process by having a retrospective meeting after each iteration.
So instead of a large group of people spending a long period of time building a unique, big product, we have small teams, working in short periods of time, building small parts of the product, integrating them regularly to the bigger project.
Kanban in a nutshell
- Makes the workflow very visual
- You have to split the work into pieces, write each item on a card and put them on a wall.
- Then, name columns to illustrate where each item is in the workflow.
- Limits WIP (work in progress) – assigns explicit limits to how many items can be in progress at each workflow state.
- Measures the lead time (average time to complete one item, often called “cycle time”), and optimizes the process to make lead time as small and predictable as possible.
Kanban has almost no restrictions. The only 2 rules are “Make the workflow very visual” and “limit your WIP” (Work In Progress).
How do Scrum and Kanban relate to each other?
- Both methodologies are Lean and Agile:
- Scrum and Kanban are both pull scheduling systems, corresponding to the JIT (Just in Time) inventory management principle of Lean. This means that the team chooses when and how much work commits. They “pull” work when they are ready, rather than having it “pushed” in from the outside, just like a printer pulls in a new page only when it is ready to print on it.
- Scrum and Kanban are based on continuous and empirical process optimization, corresponding to the Kaizen principle of Lean.
- Scrum and Kanban emphasize on the ability to response to change over following a plan (although Kanban typically allows faster response time than Scrum), one of the four values of the agile manifesto.
- Both use pull scheduling.
- Both limit WIP: Kanban limits the WIP by workflow state and Scrum by iteration (or capacity).
- Both use transparency to drive process improvement.
- Both focus on delivering releasable software products early and often.
- Both are based on self-organizing teams.
- Both require breaking the work into small pieces.
- In both methodologies, the release plan is continuously optimized based on empirical data (velocity / lead time).
| Scrum | Kanban |
| Timeboxed iterations prescribed. | Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed. |
| Uses Velocity as default metric for planning and process improvement. | Uses Lead time as default metric for planning and process improvement. |
| Cross-functional teams prescribed. | Cross-functional teams optional. Specialist teams allowed. |
| Items must be broken down so they can be completed within 1 sprint. | No particular item size is prescribed. |
| Burndown chart prescribed | No particular type of diagram is prescribed. |
| WIP limited indirectly (per sprint) | WIP limited directly (per workflow state) |
| Estimation prescribed | Estimation optional |
| Cannot add items to ongoing iteration. | Can add new items whenever capacity is available |
| A sprint backlog is owned by one specific team | A kanban board may be shared by multiple teams or individuals |
| Prescribes 3 roles (PO/SM/Team) | Doesn’t prescribe any roles |
| A Scrum board is reset between each sprint | A kanban board is persistent |
| Prescribes a prioritized product backlog | Prioritization is optional. |
Which one is better?
It all depends on the context and needs. For example, Scrum is better to work in the following conditions:
- Having a person exclusively dedicated to the role of Product Owner. This person should have enough time to take note of the client requirements and write the user stories; be available for the Delivery team; maintain the Product Backlog prioritized and with enough detailed user stories to fill a sprint of work; etc..
- Fully dedicated Scrum Master. S/He will be in charge of facilitating everyone’s work removing impediments on time.
- Enough and stable amount of work provided by the client to avoid free time between sprints.
- Self-organized and semi-senior technical level team members.
- The client agrees on avoiding changing requirements in the middle of a Sprint.
- The team is developing a brand new product that generates a minimum of 3-month workload and planning effort.
Kanban is ideal in the following scenario:
- Unstable amount of requirements from the client during an iteration. Sometimes is too much and sometimes is not enough to fill an entire iteration. Or sometimes the Product Owner is not 100% dedicated to the project and can’t provide the team with the requirements on time.
- Team member’s skills are different and their seniority levels differ. That makes it very difficult for the team to agree on time & effort estimations.
- Requirements change frequently and fast or the team is in maintenance phase of the product, where a change needs to be put in production as soon as possible.
- The team is developing several applications at the same time. Kanban does not differentiate between products or applications; it focuses on tasks in a workflow.
Scrum has more restrictions than Kanban because it requires iterations and self-organized teams among others. Kanban is closer to “do whatever you want”, although this seems to be very agile, it’s also true that the lack of limits and clear rules makes team management more difficult.
Shorter iterations lead to Kanban. Once you start talking about doing iterations shorter than a week, you should consider moving off from closed time iterations.
Regarding daily meetings and retrospective meetings, I strongly recommend to have them in both methodologies.
World trend
Until 2013, Scrum and all Scrum variations (73%) are still the most popular methodology. Despite Kanban represents only 5% of all methodologies, its use continues growing within organizations.
Conclusion
This discussion is just starting. Although Scrum is more world-wide adopted and has proven efficiency in software product development, Kanban adoption is growing at a fast rate.
The final decision depends on your project’s current situation. Being Agile can also mean being able to change the methodology if the project rules change (the amount of work becomes inconsistent, team members or team members availability change, etc.).
Being Agile means being flexible to adapt to changing scenarios to deliver high-quality software products, providing innovation and leveraging the potential of top talent. Your final decision should be based on choosing the methodology that will make your project hit the goals faster and better.
References
- https://www.infoq.com/minibooks/kanban-scrum-minibook
- https://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
Belatrix Software is a leading Software Services Outsourcing company with its main offices and delivery centers based in Mendoza, Argentina and Lima, Peru. We provide Software Development, Quality Assurance, Localization and Graphics Design Services using the “Agile Near-Shore Model”.