Being Lean vs. Saying you are Lean · Howard Meyers - Cerner Agile Philly Conference October 23,...

Howard Meyers - Cerner

Agile Philly Conference October 23, 2017

Being Lean vs. Saying you are Lean

1310231341_Standard - Cerner PPT template_v2.2 updated: 0115 © Cerner Corporation. All rights reserved.

This document contains Cerner confidential and/or proprietary information belonging to Cerner Corporation and/or its related affiliates which may not be reproduced or transmitted in any form or by any means without the express written consent of Cerner

About Cerner

• Headquarters: North Kansas City, MO, USA

• NASDAQ Symbol: CERN

• 2016 revenue: $4.8 billion

• Cumulative R&D investment of over $5.6 billion

• More than 26,000 Cerner associates based in 26 countries worldwide

• Cerner solutions are contracted at more than 27,000 provider facilities in over 35 countries

• “Cerner” comes from the Latin word meaning “to discern”



Key Question

• I have coached teams and lead teams that say they are agile and doing lean practices.

Are they really doing it?

• By focusing on Kanban flow behaviors and practices, team performance is improved.

• This experience report compares and contrasts team behaviors and practices with lean core principles and practices.



Lean Kanban Core Principles

• Visualize the workflow

• Limit WIP (work in progress)

• Manage Flow(measure and optimize)

• Make Process Policies Explicit

• Implement Feedback Loops

• Improve Collaboratively (using models)

FLOW



Key Flow Behaviors

• We focused on three behaviors of Flow?• Establish WIP limits and manage to them.

• Work on stories/features in Priority Order as established by Strategy.

• Swarm blocking issues if they impede getting work done.

• How did we get here?



Team Behavior Modeling

• Used Influencer Model to find Diagnose and influence factors

InfluenceDiagnose

MOTIVATION ABILITY

PE

RS

ON

AL

Do they

enjoy it?

Are they

personally able?

SO

CIA

L

Do others

motivate?

Do others

make it easier?

ST

RU

CT

UR

AL

Do “things”

motivate?

Do “things”

make it easier?

MOTIVATION ABILITY

PE

RS

ON

AL

Help Them Love

What They Hate

Help Them Do What

They Can’t

SO

CIA

L

Provide

Encouragement

Provide

Assistance

ST

RU

CT

UR

AL

Change Their

Economy

Change Their

Environment

www.vitalsmarts.com Influencer model

http://www.vitalsmarts.com/



Vital Behaviors Definition

• Vital Behaviors are actions• Not results (“We want to have zero downtime”)

• Not qualities (“We want people to have courage, integrity, honesty and concern”)

• Vital Behaviors are actions that are• specific,

• observable, and

• repeatable



Behavior Model Definition & Status Example

Goal: Software quality can be improved by focusing on feature “flow.” This

results in the completion of features earlier in the release allowing for

increased and earlier testing.

Action Plan:Using the skills from the Influencer education,

identify opportunities to change the organizations

behavior that lead to prioritization of features and

feature completion before starting new ones.

This focus will lead to earlier completion and allow for

integration testing much earlier for the highest

priority/most technically risky features.

This earlier completion will allow for more testing and

higher quality.

Metrics and Goals:Flow Efficiency Improvement by 10% over version 2.0 base (to

60%) by the end of 2017.

Baseline: 50%

Target: 60%

Status:General Status:

• All education has been completed.

• Coaching to teams in progress.

WIP Limits:

• Deep coaching dives with teams and look for

opportunities

Address Work In Priority Order:

• Posters with program priorities have been

placed throughout.

• Some teams have begun to implement the

ordering by priority on Kanban boards –

feedback has been good.

Swarming Blocks:

• Reviewed Kanban metrics for swarming

behavior.



Why Do We Develop Like This?T

ho

rou

gh

Testin

g B

eg

ins

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5



Development Process with Flow

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5



Theory of Constraints – Smooth Flow

TeamGoal

Problem

Strategy

Adapted from Henrik Kniberg



Kanban Execution – Flow Problem

• Team in progress

• In Progress WIP Limit = 3

• Test WIP Limit = 2




• Card 1 Dev completed, moved to Dev Done

• Next card moves to In progress




• Card 10 Dev completed, moved to Dev Done

• Next card moves to In progress

• Is this correct team behavior? How long will Dev Done queue build up? • “Busy hands model”




• Coached Result• Team swarms to testing

• Dev Done wait queue diminishes



Kanban Execution – Priority Order

• Use Visual Board to show Ranked features / projects

• Focus team on higher ranked work first

To Do Analysis Dev Test DoneRank

100

200

300

• Conversation starter when lower ranked items are started before higher ranked items

600



Coaching for Key Behaviors

• WIP and Staffing levels• Talk about how the team works with WIP to limit work.

• WIP Limit is where team should operate. It is Not a ‘Speed Limit’ value.

• Set WIP limit as a ratio to staffing levels. Look for Maximum ratios – ex. 1.5:1 to 2:1.

• Should not have an overlap of group and individual WIP limit assignments.

Team Size

2

11

2




• Cumulative Flow Diagram• Arrival/Departure Rate stability

• When does the team or a person decide to move a new card on board?

• Do they consider what is on the board already?

• Did they look at the WIP limit of the team before moving a card?

• Significant variances in individual columns

• Did the team ask if anyone else needs help before pulling next card.

• Cards Move in Batches:

• Are cards independent of each other for Doneness policies?

• “Staircase” behavior

• How are cards moved to next queue

• Pull i.e., next owner takes ready

• Push i.e., previous owner moves card in next queue



Good Flow– CFD, WIP Age

https://www.actionableagile.com/analytics



Non-Flow – Dev, Support, Story Age

Support

Dev

Dev WIP Ave Age



Staircase Behavior

• Questions to ask?• Are these cards dependent

• External blocks

• Clear path to done





• Scatter Chart• Story variance. Are stories broken down

• Batch behavior pattern

• Vertical line: Waiting for dependent stories or external factors before moving all cards at once (Scrumban?)

• Triangle: Stories not ‘architected’ properly so many stories need to start at same time

• Thresholds

• Why are some stories way above threshold values.



Coaching for Key Behaviors – CFD

“Triangle” Behavior”

“Batch” Behavior”





• Flow Efficiency• The GOAL is to increase

efficiency

• Lower wait queue time

• Reduce or eliminate blocks

• Wait time increases costs:

• Start/stop of more items in process

• If wait is prolonged, risk of changes to existing deliverable

• Behaviors to look for

• Is there a Clear Path to Done?

• Support Infrastructure setup

• Team members working on other projects

Cycle time




• Flow Efficiency example shows time spent in Active queues vs. Wait queues




Anti-Flow Patterns (i.e., Challenges)

• Lack of Role Flexing• When team members don’t have the skill set to move between

specialties e.g., Analysis, Development, testing

• Allowances: Allow WIP limit violation, request help outside teams, request overtime allowances, allow mini-waterfall approach for related board columns




• Work for team represented on multiple visual boards• When people are working on multiple boards, WIP capacity is

not correctly represented.

• Allowances: negotiate so that blocks of time is dedicated to each board, like 1 day alternate between boards.




• Extended Wait Queue time as part of normal process• Examples are waiting on environment availability, long running

automated testing.

• Allowances: Work with team on alternatives to testing work cards. If work is batched e.g., environment only available on Friday’s, make sure team is dedicated.




• Constant team re-forming• When team’s reform, historical data is more unreliable. If

possible, work with a subset of data to view team’s data results until there is enough data points (about 9).

• The risk is that if there is enough team instability/reforming, teams may be constantly in Storming stage.

• Allowances: Rely on expert opinion until data is available.

http://archive.siia.net/index.php?option=com_content&view=article&id

=1760:ray-solnik-president-appnomic-systems&catid=161:software-

articles&Itemid=1823



Summary

• Focus on team key behaviors.

• Use independent observable data to start conversation.

• Continuously Improve (Kaizen)



Questions

Being Lean vs. Saying you are Lean · Howard Meyers - Cerner Agile Philly Conference October 23,...

Documents

Transcript of Being Lean vs. Saying you are Lean · Howard Meyers - Cerner Agile Philly Conference October 23,...