Scrum vs Kanban - Perfectial

Scrum and Kanban are both part of Agile software development methodology, and basically are just a matter of choice between simple, and more simpler, ...

18 downloads 365 Views 2MB Size
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


SCRUM Timeboxes Iterations


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


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 limit

Per sprint

Per workflow state




New items

Can’t be added to ongoing iteration

Can add whenever capacity is available


Is owned by one specific team

May be shared by multiple teams or individ-


Prescribes 3 roles (PO/SM/Team)

Doesn’t prescribe any roles


A Scrum board is reset between each sprint

Doesn’t prescribe any roles


Prescribes a prioritized product backlog


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



 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]