Agile Lean Kanban in the Real World - A Case Study

Agile Lean Kanban
in the Real World
A Case Study

Agile Lean Kanban in the Real World
Outline
1. Lean Agile Overview
2. Kanban Method Overview
3. Case Study
Lean Agile Overview
Kanban Method
Overview
Case Study
Lean Agile Overview
Kanban Method
Overview
Case Study
Copyright © 2016 Russell Pannone. All rights reserved.

Lean Thinking
Lean Agile Overview
Kanban Method
Overview
Case Study
Lean Agile Overview
Lean principles originate from the lean manufacturing approach also known as 'just-
in-time production‘ as pioneered by Toyota that transformed the car manufacturer's
approach to building vehicles
The Lean "house" shown here depicts the elements of a lean system

Lean Thinking
Explicit permission granted by Scaled Agile, Inc. © 2008 - 2016 Scaled Agile, Inc. and Leffingwell, LLC

Value Delivery in Weeks versus Months
Weeks
VS
In Traditional projects:
• Value is only delivered at the
completion of last Phase of the
Project
• Real value cannot be recognized
during the majority of the
development process
• Maximum value is achieved at
product launch
Months
In Agile Projects:
• Each iteration delivers
incremental functionality
intended to continuously reflect
the customer chosen direction for
the product
• Customer realizes value as early
as the completion of the first
iteration
• Frequent integration at the end of
each iteration ensures product
quality early in the product
lifecycle

The Triple Constraint
Dynamic System Development Method
Source: http://www.dsdm.org

Lean Thinking

Respect for People
One needs to feel one’s work has
meaning
Excited to jump out of bed in the
morning and belonging to a team
with a mission that matters
Centralized Coordination
Decentralized Control
Self-directing and self-organizing
teams
Culture fosters improvement,
continual mastery, and growth

10
Seven Principles of Lean Software Development
1. Eliminate Waste
2. Amplify Learning
3. Delay Commitment
4. Deliver Fast
5. Empower the team
6. Build Quality In
7. Optimize the Whole

11
Traditional Waterfall Process

Empirical Process
Ideas
Build
Product
Measure
Data
Learn
Build It
Deploy It
Measure It
Think It
Study It
Tweak It
Image based on lean startup mentality as popularized by Eric Ries in his book The Lean Startup.

Continual Product Improvement
“Iterating” builds an “Increment” of the product, verifies & validates it,
then slowly builds up quality delivering
“Value” incrementally
Build For Some
Requirements
Initial set of Requirements, input
to the initial iteration.
Build For Some More
Requirements
Build For Some More
Requirements
Product
Increment
Product
Increment
Product
Increment
V
A
L
U
E
V
A
L
U
E
V
A
L
U
E

Continual Process Improvement
ACT
Actions to
continually
improve process
performance
PLAN
Establishment of
the objectives and
processes
DO
Implementation of
the processes
CHECK
Monitoring
measurements of
processes and
products, and
reporting the results

8 Principles of Lean Agile Leadership
Lean
Agile
Principles
1
2
3
4
5
6
7
8Build high-performing teams
Implement software
development flow
Unlock the intrinsic motivation of
knowledge workers
Take an economic view of
the full value chain
Embrace the Agile Manifesto
Develop people, not things
Own the system of which you speak
Decentralize control

The Kanban Method Overview
Lean Agile Overview
Kanban Method
Overview
Case Study
Kanban Method
Overview
http://net1.ist.psu.edu/chu/wcm/vc/toyota1.gif
Kanban is a Japanese word that literally means
sign card or sign board

Kanban Method – Core Practices for successful
adoption
1. Visualize
2. Limit Work-in-Progress
3. Manage Flow
4. Make Policies Explicit
5. Implement Feedback Loops
6. Improve Collaboratively,
Evolve Experimentally
(using models and scientific
methods)

Visualize

WIP Limits
Each activity can only have so many
work items
Work items are pulled into next state
only when there is space

Make Policies Explicit
Policy

Sample Kanban Board

• Lead time measures the arrival rate. Lead time clock
starts when the request is made and ends at delivery.
Lead time is what the customer sees.
• Lead Time is measured by elapsed time (minutes,
hours, etc.)
* Wikipedia
Ticket
Created
Lead Time
Manage Flow – Lead Time

• Cycle Time measures the completion rate
• Cycle time clock starts when work begins on the request and ends when
the item is ready for delivery.
• WIP = 100 work items in progress
• Throughput = 2 work items per week
• Cycle Time = 100 / 2 = 50 weeks
This means that the Cycle Time to clear out all of this WIP is going to be 50
weeks, or roughly one year.
Ticket
Live
Ticket
Created
Start
Work
Cycle Time
Manage Flow – Cycle Time

Lead time clock starts when the request is made and ends at delivery.
Cycle time clock starts when work begins on the request and ends when
the item is ready for delivery.
Ticket
Live
Ticket
Created
Start
Work
Lead Time
Cycle Time
Summary - Lead Time and Cycle Time

Infrastructure Team Kanban Experiment
Lean Agile Overview
Kanban Method
Overview
Case StudyCase Study
• This real life example covers how a newly formed
Infrastructure group applied a hybrid of Lean Agile and
Kanban within an American multinational corporation that is
engaged in the design, development, manufacturing and
worldwide marketing and selling of footwear, apparel,
equipment, accessories and services.
• This team was part of a $700K three year strategic program
enabling Company ABC’s mission to create, transform and
lead the marketplace with new organizational skills,
processes and tools.
From To
Sales functional focus Enterprise solutions
Independent fixes Integrated environment of people,
process & technology
Unstable Sales 1.0 tools Robust Sales 2.0 ecosystem

Setting Up, Supporting and Maintaining a
Continuous Integration Environment
Local
Workstation
DEV QA STAGE PROD
Purpose
Design & Code
Purpose
Support
Development
This is the
Team Integration
Environment
Purpose
System Testing
1st testing outside
of Dev. Team
Demos
Purpose
Final Qualification
in PROD-like
environment
Purpose
Live & accessible
to End Users
Generate Sales
Gate to DEV
• Commit to
Source Control
• Compile
• Unit Test
• Analysis (Sonar)
• Component Test
• Package
• Deployment and
Configuration
Automation
Gate to QA
• Automated
Functional Test
(eg. Sauce)
Gate to STAGE
• Manual
Acceptance Test
• Manual PCI
scans
Gate to PROD
• Automated
Performance
Test
• Auto. Security
Test (PCI
Compliance)
• UAT
• PMO/Release
Man. Approval
• Business
Approval
Go live criteria
• Technical
Validation
• Business
Validation

Their Reality - Most of their work is event driven
Russell: How are things going now that you are being agile and using Scrum?
Carol: On this Program we’ve finally gone all-out being Agile and Scrum!
Russell: So how’s it going?
Carol: Well, it’s a lot better overall than what we had before...
Russell: ...but?
Carol: ... but we are a support & maintenance team.
Russell: yes, and?
Carol: Well, we love the whole thing about setting priorities in a product backlog, self-
organizing teams, daily scrums, retrospectives, etc....
Russell: So what’s the problem?
Carol: We keep failing our sprints
Russell: Why?
Carol: Because we find it hard to commit to a 2 week plan. Sprints don’t make too much
sense to us, we just work on whatever is most urgent for today. Should we do 1 week
iterations perhaps?
Russell: Could you commit to 1 week of work? Will you be allowed to focus and work in
peace for 1 week?

Their Reality
Carol: Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints...
Russell: Do your issues take less than a day to fix?
Carol: No, they sometimes take several days
Russell: So 1-day sprints wouldn’t work either. Have you considered ditching sprints
entirely?
Carol: Well, frankly, we would like that. But isn’t that against Scrum?
Russell: One size does not fit all. You choose when and how to be agile or use Scrum.
Carol: So what should we do then?
Russell: Have you heard of Lean Software Development and the Kanban Method?
Carol: What’s that? What’s the difference between that and Scrum? And I really like the
rest of Scrum though, do I have to switch now?
Russell: No, you can combine the techniques! Lets collaborate on how.
Carol: Great where do we start?

•Experiment with a process that better fits our mix of
planned and unplanned (event driven) work
•Better visibility into what the team is doing and
needs to do next
•See if Kanban Work-In-Process limits will help
improve team effectiveness.
•See if measuring and optimizing Cycle Time will
help improve our effectiveness
Goal

• Backlog: Product Owner’s next 8 things for team to address. Max=8 Min=3. This state
should *never* run out
• Ready: Tasked-out stories ready to be worked. Max=8 Min=3
• Pending External Dependency: Blocked due to dependency on a ticket, meeting, info, etc.
• Done: No limit
• Accepted: A celebration of recently completed work. Clear out every two weeks
• Expedite: Emergencies (Yellow Cards)- may exceed the WIP limits
Initial cut: Infrastructure Kanban Board
Backlog
(3-8)
Ready
(Tasked)
(3-8)
Pending
External
Dependency
(8)
In
Progress
(6)
Done Accepted
Expedite

• When you are available but WIP limit is reached, instead of starting
something, can you collaborate to get something Done?
• If not confer with the rest of the team and then go ahead and exceed the WIP limit if that’s the
only way to do valuable work. We hope that will be rare.
• If you identify the need to issue a ticket, setup a meeting, request
information, etc. Initiate that request during Task-out and put the card in
Pending External Dependency. That gives us a head-start on things that
require waiting. Put a sticky on the card to identify the dependency.
• Use the process to the team’s benefit – but the process should not prevent
you from doing the right thing.
• Help someone requests turn into quick-planned stories, grouped into a
Consulting epic.
• Emergency is something broke and are Yellow-Card expedites. Hopefully
rare.
Explicit policies

• Continuous Planning: No Sprint Planning / Sprint Closing Meetings
• Product Owner prioritizes the Backlog and keeps the 8 slots in Product
Backlog column full.
• The Team tasks out stories when a slot is available in the Ready
column.
• WIP Limits: When a Work-In-Progress limit is reached, help someone
finish something instead of starting something new (as much as possible).
• Less Splitting: No need to artificially split a story to make it fit-in-a-sprint.
However still a good idea to deliver value in small, manageable chunks.
• VersionOne: New status Pending for (Pending External Dependency).
• Cycle Time: Measuring and optimizing cycle time how fast can we get
tasks done.
• Consulting Stories: Help someone consulting (> 1 hour) – create a story
and work with Product owner to plan it in right away Kanban-style.
What changes

• Daily Stand Up
• Product Owner prioritizes backlog
• Retrospectives every two weeks
• Product Owner backlog refinement daily
• Time box Research stories
• Track event driven work as Tasks
• Keep the Kanban board and VersionOne in-sync
What stays the same

•What is the right Work-in-Process limit (if any)
for Pending External Dependency column?
•If you are interrupted from In Progress work,
should that card come out of the column? Where
should it go? How does it re-start?
Need to figure out

Scrum Kanban Scrumban
Board/Artifacts
Product backlog
Sprint backlog
iteration
board mapped on the process board mapped on the process
Events
daily Scrum
sprint planning
sprint review
sprint retrospective
none required
daily Scrum
other Scrum related events if needed
Prioritization Part of backlog grooming. Done by PO
Out of the process. There should be a
prioritized backlog.
Out of the process. There should be a
prioritized backlog.
Who feeds the work in progress (brings
new work)
PO
Depends on defined roles and
necessities
Depends on defined roles and
necessities
Iterations yes (sprints) no (continuous flow)
not mandatory (continuous flow); could
have sprints
Estimations yes (in ideal days or story points) no (similar work size items) (a) no (similar work size items) (a)
Teams recommended cross functional cross functional or specialized cross functional or specialized
Roles
Product Owner
Scrum Master
Team
as needed Team + as needed
Teamwork collaborative based on pull approach based on pull approach
WIP planned for the duration of the sprint controlled by workflow state controlled by workflow state
changes to work scope should wait for next sprint added as needed (JIT) added as needed (JIT)
Product backlog
prioritized list of user stories
(estimated)
no (JIT) no (JIT)
Impediments addressed immediately addressed immediately (b) addressed immediately (b)
When does it fit?
Product development
Small value adding increments
development possible
Requirements are in good shape
Support/maintenance work
(operational level)
Product development
(a) team needs to comment on non-fitting work items in order to ensure readiness
(b) stop the line approach; teams should swarm to solve the impediment
http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html

Agile Lean Kanban in the Real World - A Case Study

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile Lean Kanban in the Real World - A Case Study

Similar to Agile Lean Kanban in the Real World - A Case Study (20)

More from Russell Pannone

More from Russell Pannone (20)

Recently uploaded

Recently uploaded (20)

Agile Lean Kanban in the Real World - A Case Study