scrum vs kanban

37
Scrum vs. Kanban Migrating from Scrum to Kanban www.torak.com

Upload: dimitri-ponomareff

Post on 06-May-2015

18.020 views

Category:

Business


6 download

DESCRIPTION

The presentation is about understanding the differences between Scrum and Kanban and underhand which Agile methodology is best suited for your needs. Kanban is a great methodology that must be used in the right circumstances. I continue to promote Scrum first for projects focused on new features to increase customer satisfaction, but when teams enter hardening phases in their product life-cycle or fall in complete maintenance mode, instead of letting Scrum lose it's shine, I prefer to introduce Kanban or Scrumban.

TRANSCRIPT

Page 1: Scrum vs Kanban

Scrum vs. KanbanMigrating from Scrum to Kanban

www.torak.com

Page 2: Scrum vs Kanban

About Dimitri PonomareffDimitri Ponomareff (www.linkedin.com/in/dimka5) is a Coach. Whether it's a sports team, software products or entire organizations, Dimitri has that ability to relate and energize people. He is consistently recognized as a very passionate and successful change agent, with an overwhelming capacity to motivate and mobilize teams on their path to continuous improvements. He is a master facilitator, as well as a captivating speaker with consistent, positive feedback regarding his ability to engage an audience.

www.torak.com

As a certified Coach, Project Manager and Facilitator of "The 7 Habits of Highly Effective People", Dimitri brings a full spectrum of knowledge in his delivery of methodologies. Through teaching by example, he is able to build teams of people who understand where to focus their work to generate the most value.

He has coached and provided tailor-made services and training for a multitude of organizations. The short list includes, American Express, Charles Schwab, Bank of America, Morgan Stanley, Choice Hotels International, JDA Software, LifeLock, First Solar, Mayo Clinic and Phoenix Children's Hospital. Dimitri enjoys his work, and does everything to ensure he shares his knowledge with others who seek it.

Page 3: Scrum vs Kanban

Agenda● Kanban overview

○ Visualizing the work○ Making the Process explicit○ Continuously improving the Flow

● Scrum vs. Kanban○ Starting with Scrum, evolving to Kanban○ Diagnosing a Scrum team○ Scrum time-boxed challenges

● Kanban (When & How)○ Ideal environments for Kanban○ Kanban JIT Backlog○ Estimates (or not) with Kanban - calculating Cycle Time○ Release planning

● Blending Scrum & Kanban○ Scaled Agile Framework (SAFe)○ Scrum + Kanban implementations○ Kanban board examples

www.torak.com

Page 4: Scrum vs Kanban

Kanban

Visualize the workflow● Kanban literally means "signboard" or "billboard"

Just-in-time (JIT)

● identify and eliminate wasteful activities, only build what you need Limit Work In Process (WIP)

● establish and respect your ideal capacity, do what works best to get the work done

Manage and optimize the flow/process

● continually seeks ways to reduce the lead time for getting the work done● make process policies explicit ● improve collaboratively

It's not an inventory control system; it's a pull scheduling system that tells you what to produce, when to produce it, and how much to produce.

www.torak.com

Page 5: Scrum vs Kanban

Toyota’s Kanban System

Philosophy of complete elimination of waste"Just-in-Time" means making "only what is needed, when it is needed, and in the amount needed."

Source: http://www.toyota-global.com/company/vision_philosophy/

www.torak.com

Page 6: Scrum vs Kanban

Kanban Board - Start

a

b

to do in process doneStart with a simple task board with 3 columns: to do, in process and done.

Each card represent a work item in the current scope. Names can be associated with the cards.

The key is to setup an easy way to visualize the work, and create an area for social interactions.

c

www.torak.com

Page 7: Scrum vs Kanban

Kanban Board - Start

a

b

to do in process doneStart with a simple task board with 3 columns: to do, in process and done.

Each card represent a work item in the current scope. Names can be associated with the cards.

The key is to setup an easy way to visualize the work, and create an area for social interactions.

b

a

to do in process doneA problem with such a simplistic board, is the lack of rules and the concept of time-boxing.

A typical problem is accumulating too much work in progress (WIP).

Kanban is more than just adding work items on a board, it's also applying a PULL process.

ab a

b acc

c

a

c

www.torak.com

Page 8: Scrum vs Kanban

Kanban Board - Start

a

b

to do in process doneStart with a simple task board with 3 columns: to do, in process and done.

Each card represent a work item in the current scope. Names can be associated with the cards.

The key is to setup an easy way to visualize the work, and create an area for social interactions.

b

a

to do in process doneA problem with such a simplistic board, is the lack of rules and the concept of time-boxing.

A typical problem is accumulating too much work in progress (WIP).

Kanban is more than just adding work items on a board, it's also applying a PULL process.

ab a

b acc

c

a

to do in process doneTo truly embrace Kanban, we must regulate the volume of cards on the board. This can easily be accomplished by identifying clear thresholds associated to better defined stages of work (columns).

Another improvement is to set a multi-tasking limit per user (2) and using late binding of tasks to owners. Note that not all team members must have 2 tasks with their names, this is a maximum of 2.

b

c

a

ready

a

c

c

52

www.torak.com

Page 9: Scrum vs Kanban

Kanban Board - Mechanics

to do in process done

b

c

a

ready

a

c to do in process done

b

c

a

ready

a

c to do in process done

b

c

a

ready

a

c

a

1. Team member A completes a card and moves it to the "done" column.

2. Team member A pulls a new card from the "ready" column and starts working on it by placing it in the "in process" column. 3. The team responds to the

pull event and selects the next priority card by moving it to the "ready" column.

2

5

5

5

2

2

2

www.torak.com

Page 10: Scrum vs Kanban

Kanban Board - Flow

Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow.

to do in process done

b

c

ready

a

c

b

to do specify done

bc

ready

a

c

b

execute

2 5 2 2 3

www.torak.com

Page 11: Scrum vs Kanban

Kanban Board - Flow

Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow.

a

backlog specify done

b

ready

a

cb

complete execute

c

to do in process done

b

c

ready

a

c

b

to do specify done

bc

ready

a

c

b

execute

2 5 2 2 3

28 3 2

www.torak.com

Page 12: Scrum vs Kanban

Roles

Scrum Overview

Product Backlog

(prioritized)

Sprint Backlog

Sprint Planning

Sprint Retrospective

Sprint Review

Daily Scrum

Product Increment

Sprint

Task Board

Sprint Burndown

ScrumMaster

Product Owner

Team

Stakeholders

Users

www.torak.com

Page 13: Scrum vs Kanban

What Kanban likes about Scrum

Roles

Product Backlog

(prioritized)

Sprint Backlog

Sprint Planning

Sprint Retrospective

Sprint Review

Daily Scrum

Product Increment

Sprint

Task Board

Sprint Burndown

ScrumMaster

Product Owner

Team

Stakeholders

Users

www.torak.com

Page 14: Scrum vs Kanban

Kanban with Scrum - or Scrumban

Roles

Backlog(JIT)

Retrospective

Daily Stand

UpContinuous Increments

Kanban Board

Team

Stakeholders

Users

ReviewPlanning

www.torak.com

Page 15: Scrum vs Kanban

Scrum vs. Kanban

Scrum Kanban

Board / Artifacts board, backlogs, burn-downs board only

Ceremonies daily scrum, sprint planning, sprint review, sprint retrospective

daily scrum, review/retrospective on set frequency and planning ongoing

Iterations yes (sprints) no (continuous flow)

Estimation yes no (similar size)

Teams must be cross-functional can be specialized

Roles Product Owner, Scrum Master, Team Team + needed roles

Teamwork collaborative as needed by task swarming to achieve goals

WIP controlled by sprint content controlled by workflow state

Changes should wait for the next sprint added as needed on the board (to do)

Product Backlog list of prioritized and estimated stories just in time cards

Impediments dealt with immediately avoided

www.torak.com

Page 16: Scrum vs Kanban

Scrum vs. Kanban

Sprint Day 1 Mid-Sprint Sprint Last Day

Any DayKanban

Scrum

www.torak.com

Page 17: Scrum vs Kanban

Diagnosing a Scrum team3 Roles ● Team - Is the team 5-9 people? Is it cross-functional or specialized?● ScrumMaster - Is there a real ScrumMaster or someone acting in the role?● Product Owner - Who actually writes the stories? Is the Product Owner truly

available?

4 Ceremonies ● Daily Scrum - Is it under 15 minutes? Does the entire team attend?● Planning - Is it collaborative? Is it often the same tasks/estimates?● Review - Do stories often carry over from sprint to sprint?● Retrospective - Is it taking place every sprint? Is the team raising concerns

with Scrum?

A few artifacts ● Product Backlog - Is it mostly maintenance/operational work?● Sprint Burndown - Are we burning story points or tasks?● Task board - Has the board evolved passed the 4 typical Scrum columns?

www.torak.com

Page 18: Scrum vs Kanban

Scrum time-boxed challenges● Time-boxes force stories to be smaller for the sole purpose of

"fitting" into the sprint length ● Breaking down stories require unnatural breakpoints create

difficulties for deployment and testing of the work● Too small of stories are no longer valuable and are not

potentially shippable product increment at the end of the sprint● Increased dependencies between stories, which requires more

coordination to plan the work● Increased testing due to the need to test (and retest) many

small incomplete stories that are difficult to test and require more scaffolding efforts

www.torak.com

Page 19: Scrum vs Kanban

Ideal environments for Kanban● If Scrum is challenged by workflow issues, resources and

processes● Event driven work

○ help-desk/support○ hardening/packaging phases

● Projects with frequent and unexpected user stories or programming errors

● Maintenance projects or sunsetting products● Around Scrum teams focused on new product development

○ work preceding sprint development (R&D, procurement)○ work following sprint development (system testing, release and

deployment)● Facilitating improvement communities across the organization

www.torak.com

Page 20: Scrum vs Kanban

Backlog

Kanban JIT Backlog

● extend board to include story creation/elaboration ● avoid creating/analyzing too many stories and having duplicates, reduce waste● assure the necessary level of analysis before starting development● the backlog should be event-driven with an order point● prioritization-on-demand - the ideal work planning process should always

provide the team with best thing to work on next, no more and no less

2 5 2

Elaboration Development Testing Deploy

1

Done

8

Page 21: Scrum vs Kanban

Queue

Estimating (or not) in Kanban

● No need to estimate at the card level, each card is "similar size"● Cards don't need to get broken down to tasks with estimates, the work is

known by the team and they will swarm to figure it out● Simply calculate the average Cycle Time for cards to get through the board

○ Done Date - Start Date = Cycle Time

2 4 2

Elaboration Development Testing Deploy

1

Done

12 days

24 days

Page 22: Scrum vs Kanban

Agile Release Planning week 1 week 2 week 8week 7week 6week 5week 4week 3

Kanban team releasing every 2 weeks like Scrum

sprint 1 sprint 3sprint 2 sprint 4Scrum team releasing every sprint

Kanban team releasing every week

Kanban team release when ready/needed

planning review & decision to release retrospective

Page 23: Scrum vs Kanban

Blending Scrum and Kanban

Page 24: Scrum vs Kanban

Scrum + Kanban

Scrum KanbanScrumScrum

Q1 Q2 Q3 Q4

Yearly Release (or very long ones)

Some organization choose to release only once a year. Although not ideal in Agile because it removes the advantages of going to market as soon as something is ready, this scenario requires that you get it right the first time / the only time you release that year!

When new features are planned at the beginning of the year, the team(s) will benefit from working in a structured environment with time boxes and discipline with regular ceremonies (Scrum).

The challenge will be at the end when other groups join the effort to prepare the release of this work. The coordination and possible issues that arise will benefit from switching all efforts to hardening the release (no new development) and following a clear process (Kanban).

Scrum Kanban

Page 25: Scrum vs Kanban

Scrum + KanbanSOA Environments

In Service Oriented Architecture (SOA) environments, building/maintaining services is a specialty and requires a certain type of developer. Since there are rarely enough SOA developers to be on every development team/project and there is a need to centralize work on services, the SOA development is a specialized process that received demands from multiple teams/areas. The key is to funnel all requests.

The visual nature of Kanban is ideal for SOA because it forces to respect their WIP limits and all the work across the various areas is clearly visible to organize and prioritize. Also SOA requires experts and that is the huge difference between Scrum (cross-functional) and Kanban (specialized).

Scrum Kanban

Team 2Team 1 Team 3

SOA Team

service A

service B service C

service D service E service F

Page 26: Scrum vs Kanban

Scrum + KanbanApplications vs. Infrastructure

Scrum and Kanban are both Agile methodologies. The key is that they share the same values and principles, and therefore the basis to improve behaviors to reach common organizational goals.

Scrum tends to take the organization by storm in the spirit of increasing efficiencies, but if the IT groups are not also Agile, Scrum hits a wall. Scrum teams have roles/ceremonies that align the business and development sides, but once this is achieved there is another technical component (IT), which cannot be left at the end. The goal is to find common grounds to streamline the work across the organization. IT doesn't have the need/luxury of the Scrum roles, they need clear Agile processes (Kanban).

Team 2

Team 3

Team 5

Network Team

Scrum Kanban

DBA Team

Release Team

Support Team

SecurityTeam

Team 1

Team 4

Page 27: Scrum vs Kanban

Kanban Board Example

Page 28: Scrum vs Kanban

Kanban for Portfolio Management

Queue In Process Release Done

Concept Scope Development Testing

Project Team #1

Project Team #2

Project Team #3

6 5 2

Page 29: Scrum vs Kanban

Kanban for Architecture

Queue In Process Release Done

ModelingAnalysis Development Testing

Service #1

Service #2

Service #3

6 5 2

Page 30: Scrum vs Kanban

Backlog In Process Done

Production

Release

Dev Support

Project A

Project B

Analysis

Specify Execute

Kanban for IT

8 3 6

Page 31: Scrum vs Kanban

Kanban for Support with multiple clients

BacklogIn Process

DoneSpecify Publish

Estimate

C1

C4C3

C2

Design Code Test Package

New Analysis Development DoneProduction

Issues

3 2 3 42

Page 32: Scrum vs Kanban

Kanban for Marketing

Priorities In Design Done3rd PartyIdeas Release

Web Event

COM PR

ValidateReviewSpecify Execute 2438

Page 33: Scrum vs Kanban

Kanban for Sales

Queue Create RFP Review Done

RFP Ready In Progress Complete

Sales Team #1

Sales Team #2

Sales Team #3

26 5

Page 34: Scrum vs Kanban

Agile Coaching, Staffing and Training.

Learn more at www.torak.com

Learn more at www.AgileTestingFramework.com

Page 35: Scrum vs Kanban

Thank You

Page 36: Scrum vs Kanban

Resources and References● Scrumban - Essays on Kanban Systems for Lean Software Development

by Corey Ladas

● Kanban and Scrum - making the most of both by Henrik Kniberg, Mattias Skarin

● Wikipedia - Scrum

http://en.wikipedia.org/wiki/Scrum_%28development%29#Scrum-ban

● Toyota○ Just-in-Time — Philosophy of complete elimination of waste○ TPS (Toyota Production System) or "kanban system"○ http://www.toyota-global.com/company/vision_philosophy/

Page 37: Scrum vs Kanban

This presentation was inspired by the work of many people and we have done our very best to attribute all authors of texts and images, and recognize any copyrights. If you think that anything in this presentation should be changed, added or removed, please contact us.

http://creativecommons.org/licenses/by-nc-nd/3.0/