Intro to Kanban

@scrumhive
Colleen Johnson
• CEO & Founder of ScatterSpoke
• LeanKanban Accredited Kanban Trainer
• Kanban Coaching Professional
• Former AgileDenver Board of Directors
• Co-chair 2016 & 2017
Mile High Agile Conference
• Member Agile Uprising Board of Directors
• Mama to three amazing kiddos
@scrumhive

@scrumhive
• Toyota Production Systems “TPS” 1948
• Ridding the system of WASTE
o MURI~ overburden
o MURA~ inconsistency
o MUDA~ waste
• Just-in-time “JIT” Production
• KAIZEN~ continuous improvement
• Respect for People
Origins of Lean Thinking

@scrumhive
Kanban has two meanings:
Both meanings are incorporated into the
Kanban Method:
Kanban written in Kanji (Chinese
characters)
看板 means “sign” or “large
visual board”
Kanban written in Japanese
alphabet, hiragana,
かんばん means signal cards(s)
Kanban Has Two Meanings

@scrumhive
1. Start with what you do now
2. Agree to pursue evolutionary change
3. Initially, respect existing roles, responsibilities and job titles
4. Encourage acts of leadership at all levels
Kanban Principles

@scrumhive
Start Finishing
Stop Starting

@scrumhive
1. Visualize work
2. Limit work-in-progress
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally
Kanban Practices

@scrumhive
Visualize Work
Number One:
• Start with your existing process
• Don’t copy an existing Kanban
flow
• Use VERBS
• Focus on activities at each stage
• Avoid Roles
• Avoid Hand offs
• Avoid ”Holding Tanks”
• Surface blockers quickly

@scrumhive
(Okay, this part really is just a
board)

@scrumhive
Work Item Types
• What type of requests come to your team
• Tech Debt
• User Stories
• Prod Defect
• Consider how you treat your work types
as separates “classes of service”
• Expedited
• How will you visualize these differences?
• Card color, Swim lanes, Sticky Dots

@scrumhive
Fit-for-Purpose
• Our process is never final, it is
always adapting to fits the
needs of the business
• AKA, not one size-fits-all
• Identifying opportunity, trying
something different, and
iterating on solutions

@scrumhive
Limit Work in Progress
Number Two:
• Determine rate of Departures and
Arrivals
• Consider total number of contributing
team members
• Look at each phase of the workflow
• Make blockers painful
• Focus on minimizing multi-tasking
• Measure and experiment!

@scrumhive
To Do
2
Dev
3
Code
Review
1
QA
2
Deploy
6
Signal of Capacity

@scrumhive
To Do
2
Dev
3
Code
Review
1
QA
2
Deploy
6
swarm to
remove
blockers
Stop the Line

@scrumhive
To Do
2
Dev
3
Code
Review
1
QA
2
Deploy
6
Set limits the team
agrees to follow

@scrumhive
Work Done
Doing Work is
Less valuable than

@scrumhive
Manage Flow
Number Three:
• Know your target cycle time
• Making aging work visible
• Always look to finish first
• Amplify blockers
• Revisit priority daily

@scrumhive
Kanban Metrics
• Lead Time: the duration for a work item from beginning to
end, including process time and wait states.
• Cycle Time: the duration for a work item to move from point
A to point B.
• Through Put: the count of work items processed per a
specific amount of time.
• Work in Progress: the total amount of work you have
committed to but have not completed at any given time
• Flow Efficiency: the ratio between working time and the
cycle time (expressed as a percentage)

@scrumhive
To Do
2
Dev
3
Code
Review
1
QA
2
Deploy
6
Tracking Cycle Time

@scrumhive
Sample Data
Screenshot from ActionableAgule

@scrumhive
First Out
FIFO, First In

@scrumhive
Predictability can only come from limiting WIP
Littles LAW:
Cycle time = WIP
Throughput
Why WIP Matters

@scrumhive
Sample Data
Screenshot from Kanbanize

@scrumhive
Forecasting Accurate Dates
• Real data includes all
variability
• Use Actionable Agile to
get your 85% target
• Take pressure off the
team to guess
• Save time and skip story
pointing

@scrumhive
Sample Data
Screenshot fromJira

@scrumhive
Make Policies Explicit
Number Four:
• Criteria required for work items to
move forward
•Exit Criteria
•Definition of Done
• Agreed to by the entire team
• Make these visible at standup
• Review them at retrospectives

@scrumhive
Review
AC
Tech arch
Unit tests
Code
Reviews
Regression
Automation
Demo
Docs
Exit Criteria on Display

@scrumhive
Kanban Daily Meeting
• Walk the work right to left
• Did we cover all of the policies?
• What is close to being done?
• What is the highest priority to pull?
• What is aging or stuck?
• What is blocked?

@scrumhive
Not the People
Manage the Work,

@scrumhive
Implement Feedback Loops
Number Five:
• Daily Standup
• Replenishment Meeting
• Operations Review
• Cross Team
• Delivery Planning Meeting
• Service Delivery Meeting
• Customer View
• Retrospective

@scrumhive
To Do
2
Dev
3
Code
Review
1
QA
2
Deploy
6
Data Driven Decision Making

@scrumhive
Improve Collaboratively,
Evolve Experimentally
Number Six:
• There’s always ALWAYS room for
improvement
• Adopt a Kaizen mindset
• Leverage data to make targeted
improvements
• Experiment! Try something different
and measure
• Never skip the retrospective

@scrumhive
What’s Different?
• We make targeted
improvements to our system
based on data and metrics
from our current performance
• AKA, not guessing
• Blending internal process and
external delivery

@scrumhive
Plan-Do-Check-Act
• PLAN: Plan your improvements,
including setting goals.
• DO: Put in place the actions
required for improvement.
• CHECK: Measure your success
relative to your baseline.
• ACT: Adjust or tweak your changes
PLAN:
Identify
the Issue
DO: Fix
the
Problem
CHECK:
Measure
the Fix
ACT:
Adjust
the Fix

@scrumhive
Where do I start?
1. Focus Efforts on Priority
2. Manage Work to Done
3. Amplify Obstacles to Resolution
4. Predict Delivery with Confidence
5. Improve Process with Data

@scrumhive
Pain point:
Team lacks focus
• Constantly shifting priorities
• Multi tasking and context switching
• Meeting and planning overhead
• Premature feature commitments
• High stress for the team

@scrumhive
Create Visibility
• Transparency of work and priorities
• Representation of varied work items
• Clear ownership and status
• Distribution of work load
• Informed decision making

@scrumhive
Pain point:
Work is slow to complete
• Long delivery times
• Poor code quality
• High volume of changes in flight
• Introducing Technical debt
• Overburdening with in the team

@scrumhive
Self Managing Teams
• Agree on workflow policies
• Push towards cycle time targets
• Swarm on work to finish faster
• Create slack to respond to unplanned work
• Find a sustainable pace of work

@scrumhive
Pain point:
Working around the blockers
• Hidden Dependencies
• Waiting for external teams
• Abandoned code changes
• High level of people management
• Defect fixes are lowest priority

@scrumhive
Resolve Blockers Faster
• Focus standups on the work
• Bring attention to stuck items
• Make resolving blockers a top priority
• Elevate cross team impediments

@scrumhive
Pain point:
Estimates are inaccurate
• Missed delivery dates
• Estimates based on limited knowledge
• Pointing far ahead of working
• Narrow focus of activities
• Team members change

@scrumhive
Forecast with Accuracy
• Use existing data to forecast delivery dates
• Forecast without story pointing or estimating
• Forecast without full story definition
• Track real time delivery probability
• Give the team ownership of project tracking

@scrumhive
Pain point:
Abandoned Agile Practices
• One-size fits all agile practices
• Stories constantly carry over
• Time spent backlog grooming
• No time to fold in user feedback
• Lack of continuous delivery

@scrumhive
Process that Fits
• Refined to fit the needs of the team
• Changes made based on data
• Measurable results and metrics
• Ownership of the agile process

@scrumhive
Benefits of Kanban
• Less Resistance to Change
• Reduces the amount of code changes in flight
• Less Regression Testing
• Better Quality
• Minimizes multi-tasking/context switching
• Reduces Overburdening
• Creates Visibility of Blockers
• Less Work in Progress results in Shorter Cycle Times

@scrumhive
KanbanScrum
Artifacts board, backlog, burndowns board , policies
Ceremonies daily scrum, sprint -planning, sprint review,
sprint retrospective
daily stand up, review on set frequency, planning
ongoing
Iterations time boxed sprints (2-4 weeks) continuous flow
Estimation yes, story points no, cycle time and throughput
Teams must be cross-functional can be specialized
Roles product owner, scrum master, team team and new roles as needed
Teamwork collaborative as needed by task swarming to remove blockers
Constraints work limited by sprint content work limited by workflow state
Changes should wait for next sprint pulled in as needed
Backlog list of prioritized and estimated stories just in time
Comparison of Practices

@scrumhive
Kanban at all Levels
Enterprise
Portfolio
Team

@scrumhive
#NoEstimates
#NoPlanning
#NoCommitments
#NoBacklog
#NoRoadmap
#NoHeroics
#NoHighBloodPressure*
*diet and lifestyle outside of work cannot be guaranteed

Intro to Kanban

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Intro to Kanban

Similaire à Intro to Kanban (20)

Dernier

Dernier (20)

Intro to Kanban