Scrum vs Kanban

Perfectial, LLC 800-274-6926 info@perfectial.com

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 info@perfectial.com

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 info@perfectial.com

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 info@perfectial.com

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.