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 [email protected]@steveVRporter

Please open your browser to…

http://etc.ch/8pWg

mailto:[email protected]


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


Survey

3

http://etc.ch/8pWg


Scrum

4

• Strength: Optimized for value delivery; well defined

• Weakness: mini-waterfall


Kanban

5

• Strength: Optimized for flow

• Weakness: No rules; deferred value delivery


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


Assumptions for today’s talk

1.You’re doing Scrum

2.You have a clearly defined workflow

7


Kanban Core Practices

1. Visualize

2. Limit Work-in-Progress

3. Actively Manage Items in Progress

4. Make Policies Explicit

5. Improve Collaboratively

8


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


1. Visualize - Simple

10


1. Visualize – Not so simple

11


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


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


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


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


4. Make Policies Explicit

• Explicit policies ensure transparency.

• Eg:

• The Scrum Guide

• Definition of "Done”

• SLE’s

• WIP Limits

• Workflow

• Many, many more

16


5. Improve Collaboratively

• Sprint Retrospectives

• JiT Retrospectives

17


Changes you can try in your Scrum teams

18


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



• 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



21


Flow-based Daily Scrums

• What work is blocked?

• What work is about to violate our SLE?

• What work are we not visualizing?

22


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


Flow-based Retrospectives

Stop

Start

MoreLess

Keep

• Is our cycle time decreasing?

• Did we meet our SLAs?

• Ad Hoc (SLA violation)

24


Closing

•Scrum and Kanban are complimentary

•Learn more about what Kanban has to offer

•Beware of suboptimal results

25


Thank You

26


Connect with the Scrum.org community

Twitter@scrumdotorg

LinkedInLinkedIn.com

/company/Scrum.org

FacebookFacebook.com

/Scrum.org

ForumsScrum.org

/Community

RSSScrum.org/RSS

27

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

Documents