Scrum vs Kanban
Perfectial, LLC 800-274-6926 [email protected]
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.
VSVSSCRUM KANBAN
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.
Scrum vs Kanban
Perfectial, LLC 800-274-6926 [email protected]
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 KanbanScrum 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.
Scrum vs Kanban
Perfectial, LLC 800-274-6926 [email protected]
SCRUM KANBAN
Timeboxes Iterations PrescribedNot prescribedYou are free to choose when to do planning, process improvement, and release
Planning & process improvement Uses Velocity as default metricUses Lead time as default metric for planning and process improvement
Teams
Items
Chart
Cross-functional teams prescribedCross-functional teams optionalSpecialist 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 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
BoardA Scrum board is reset betweeneach 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.
Staff commitment
Better overview of the project
Less bugs
Updating of priorities
Focus on quality of the product
SCRUM
Flexibility
Focus on continuous delivery
Reduction of wasted work / wasted time
Increased productivity & efficiency
Team members' ability to focus
KANBAN
VSVS
Scrum vs Kanban
Perfectial, LLC 800-274-6926 [email protected]
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 prod-uct 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, devel-opers 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.