Scrum vs Kanban
SCRUM
VS
KANBAN
Scrum & Kanban - Are They That Different After All? Scrum and Kanban are both part of Agile software development methodology, and basically are just a matter of choice between simple, and more simpler, because in this case less is more. The better developers will work on your product, the faster you’ll hit the market, and probably will have better chances to succeed. With Agile you get a very lean approach to the development of your application, but Agile itself comes in all sorts of shapes and sizes, so, let’s talk about two most trendy ones.
What Agile is All About? People. The simplest answer to the most complex question about software development methodology. The majority of clients that outsource their software development jobs to Eastern Europe tend to choose Ukrainian developers over others just because here in Ukraine we understand the Agile manifesto like no one else does. Ukrainian developers are happy to speak out about the problem, and very proud when they find the best possible solution. Agile relies on people who thrive on collaboration and creativity, and that’s a good practice we have developed over the years at Perfectial.
Scrum in a Nutshell Split into small, cross-functional, self-organizing teams; Split your work into a list of small, concrete deliverables; Sort the list by priority and estimate the relative effort of each item; Split time into short fixed-length iterations (1 to 4 weeks), with potentially shippable code demonstrated after each iteration; Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration; Optimize the process by having a retrospective after each iteration.
Perfectial, LLC 800-274-6926
[email protected]
Scrum vs Kanban
So, instead of having a large group of developers spending a lot of time building a large thing, you get a small team that spends less time building small thing, but iterating regularly to see the whole.
Kanban in a Nutshell Visualize the workflow Split the work into pieces, write each item on a card and put on the wall; Use named columns to illustrate where each item is in the workflow; Limit Work In Progress (WIP) – assign explicit limits to how many items may be in progress at each workflow state; Measure the lead time (average time to complete one item, sometimes called "cycle time"), optimize the process to make lead time as small and predictable as possible.
The Difference Between Scrum and Kanban Scrum and Kanban are just tools, and like any other tool, neither is perfect nor complete. Scrum constrains you to have timeboxed iterations and cross-functional teams. Kanban constrains you to use visible boards and limit the size of your queues. Scrum is more prescriptive than Kanban, and this means more rules to follow. It gives you more constraints, and thereby leaves fewer options open. For example Scrum prescribes the use of timeboxed iterations, Kanban doesn’t. Scrum prescribes 3 roles: Product Owner (sets product vision & priorities), Team (implements the product) and Scrum Master (removes impediments and provides process leadership). Kanban doesn’t require you to have roles at all, thought that doesn’t mean you can’t. It means you don’t have to. So, a Scrum iteration is one single timeboxed cadence combining three different activities: planning, process improvement, and (ideally) release. With Kanban you get to choose when to do planning, process improvement, and release, thus making it a more lean tool to use. Or does it? Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process and customize it to your environment. Sometimes, you’ll have to agree to implement elements of Scrum into Kanban, like have a product owner, for instance, or introduce a Kanban board to the Scrum process. It’s all the matter of building the software right. Use whatever works best for your exact case.
Perfectial, LLC 800-274-6926
[email protected]
Scrum vs Kanban
KANBAN
SCRUM Timeboxes Iterations
Prescribed
Not prescribed You are free to choose when to do planning, process improvement, and release
Planning & process improvement
Uses Velocity as default metric
Uses Lead time as default metric for planning and process improvement
Teams
Cross-functional teams prescribed
Cross-functional teams optional Specialist teams allowed
Items
Items must be broken down so they can be completed within 1 sprint.
No particular item size is prescribed.
Chart
Burndown chart prescribed
No particular type of diagram is prescribed
WIP limit
Per sprint
Per workflow state
Estimation
Prescribed
Optional
New items
Can’t be added to ongoing iteration
Can add whenever capacity is available
Backlog
Is owned by one specific team
May be shared by multiple teams or individ-
Roles
Prescribes 3 roles (PO/SM/Team)
Doesn’t prescribe any roles
Board
A Scrum board is reset between each sprint
Doesn’t prescribe any roles
Prioritization
Prescribes a prioritized product backlog
Optional
What Scrum & Kanban are Good For? Both Scrum and Kanban will work well for most cases, from medium to large size projects (from 4 months to multiple years). Each of them has their own advantages, and can be applied according to the need.
SCRUM Staff commitment Better overview of the project
KANBAN
VS
Flexibility Focus on continuous delivery
Less bugs
Reduction of wasted work / wasted time
Updating of priorities
Increased productivity & efficiency
Focus on quality of the product
Team members' ability to focus
Perfectial, LLC 800-274-6926
[email protected]
Scrum vs Kanban
Scrum’s roles prescriptions make it a unique methodology with a role of Scrum Master that can be thought of as a coach for the team, helping team members use the Scrum process to perform at the highest level, and the Product Owner role that represents the business and the customer, and guides the team towards building the right product. Kanban is good for projects with floating amount of requirements. In fact, Kanban is often described as a way to organize the chaos. The board helps uncover workflow and process problems so you can fix those in order to deliver the right product on time, as well as concentrate on the delivery of a certain feature at a time. What will work best for you? Scrum, Kanban, both, neither? Experiment, adapt, change, it all depends. In most cases, developers will work with what’s best for them. I’d recommend to go with what they have, and suggest changes if possible. If you insist on using a specific methodology, be ready to face troubles, and fix them, or even wear a role of a product owner.
Perfectial, LLC 800-274-6926
[email protected]
