what every scrum teams need to know about kanban · by scrum.org –improving the profession of...

© 1993-2017 Scrum.org, All Rights Reserved

by Scrum.org – Improving the Profession of Software Delivery

What every Scrum Teams need to know about Kanban

Steve PorterTeam Member Scrum.orgSteve.Portert@scrum.org@steveVRporter

Please open your browser to…

http://etc.ch/8pWg

© 1993-2017 Scrum.org, All Rights Reserved

About Me

• Scrum.org Team Member

• Professional Scrum Trainer

• Professional Series Manager

• Nexus Framework Contributor

2

• Accredited Kanban Trainer

• Kanban Coaching Professional

• Founding Board Member of LKU

© 1993-2017 Scrum.org, All Rights Reserved

Survey

3

http://etc.ch/8pWg

© 1993-2017 Scrum.org, All Rights Reserved

Scrum

4

• Strength: Optimized for value delivery; well defined

• Weakness: mini-waterfall

© 1993-2017 Scrum.org, All Rights Reserved

Kanban

5

• Strength: Optimized for flow

• Weakness: No rules; deferred value delivery

© 1993-2017 Scrum.org, All Rights Reserved

Daniel Vacanti

• Helped to create the Kanban Method

• Kanban trainer and coach

• Author of two books on flow metrics, predictability, and forecasting.

6

www.actionableagile.com

© 1993-2017 Scrum.org, All Rights Reserved

Assumptions for today’s talk

1.You’re doing Scrum

2.You have a clearly defined workflow

7

© 1993-2017 Scrum.org, All Rights Reserved

Kanban Core Practices

1. Visualize

2. Limit Work-in-Progress

3. Actively Manage Items in Progress

4. Make Policies Explicit

5. Improve Collaboratively

8

© 1993-2017 Scrum.org, All Rights Reserved

1. Visualize

• Visualization of work items

• Visualization of workflow

• Visualization of how Work In Progress is limited

• Visualization of a Service Level Expectation (SLE)

• Visualization of process policies

9

© 1993-2017 Scrum.org, All Rights Reserved

1. Visualize - Simple

10

© 1993-2017 Scrum.org, All Rights Reserved

1. Visualize – Not so simple

11

© 1993-2017 Scrum.org, All Rights Reserved

2. Work in Progress

• The Sprint itself limits WIP

• WIP limit can apply to a column, a set of columns or the entire workflow

• Implements a pull system

• A WIP limit that doesn’t actually limit WIP is not a WIP limit

12

© 1993-2017 Scrum.org, All Rights Reserved

3. Actively Manage Items in Progress

• Responding quickly to blocked items

• Making sure that items are only pulled into a process at about the same rate that items are leaving a process

• Ensuring items don’t age unnecessarily and are completed according an established Service Level Expectation (SLE)

• Unclogging work that piles up in a column or columns

• Etc

13

Some Examples

© 1993-2017 Scrum.org, All Rights Reserved

3. Actively Manage Items in Progress - Required Metrics

• To actively manage work in progress you must track when work begins and when work begins and when work is done.

• Cycle Time: The elapsed time between when works starts and when work finishes.

• Work item age: The time between when works starts and the current time.

• Throughput: The total number of items of items finished per unit of time.

14

© 1993-2017 Scrum.org, All Rights Reserved

Service Level Expectations

• A forecast for how long an item should flow through the workflow.

• Two portions:» A probability

» A range

• Eg: 96% of all items complete in 14 days or less

• At a minimum, your Sprint length should define your range.

15

© 1993-2017 Scrum.org, All Rights Reserved

4. Make Policies Explicit

• Explicit policies ensure transparency.

• Eg:

• The Scrum Guide

• Definition of "Done”

• SLE’s

• WIP Limits

• Workflow

• Many, many more

16

© 1993-2017 Scrum.org, All Rights Reserved

5. Improve Collaboratively

• Sprint Retrospectives

• JiT Retrospectives

17

© 1993-2017 Scrum.org, All Rights Reserved

Changes you can try in your Scrum teams

18

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Sprint Planning

• Leverage the Sprint Goal

• You don’t need to plan out the entire Sprint

• You can begin unplanned work part way through the Sprint

• Work can flow across Sprint boundaries

19

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Sprint Planning

• Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

• The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

• As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

20

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Sprint Planning

21

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Daily Scrums

• What work is blocked?

• What work is about to violate our SLE?

• What work are we not visualizing?

22

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Sprint Reviews

• What is our current throughput?

• How does this impact items in our Product Backlog?

• Has our SLE changed?

• What is our lead time?

23

© 1993-2017 Scrum.org, All Rights Reserved

Flow-based Retrospectives

Stop

Start

MoreLess

Keep

• Is our cycle time decreasing?

• Did we meet our SLAs?

• Ad Hoc (SLA violation)

24

© 1993-2017 Scrum.org, All Rights Reserved

Closing

•Scrum and Kanban are complimentary

•Learn more about what Kanban has to offer

•Beware of suboptimal results

25

© 1993-2017 Scrum.org, All Rights Reserved

Thank You

26

© 1993-2017 Scrum.org, All Rights Reserved

Connect with the Scrum.org community

Twitter@scrumdotorg

LinkedInLinkedIn.com

/company/Scrum.org

FacebookFacebook.com

/Scrum.org

ForumsScrum.org

/Community

RSSScrum.org/RSS

27