SlideShare a Scribd company logo
1 of 44
Kanban 101
David Hanson
Version 1.6
May 2019
1
看
板
https://www.linkedin.com/in/david-hanson/ dphanson63@yahoo.com
Agile 101
2 May 2019
看板
101
dphanson63@yahoo.com
Topic: Kanban 101
We all likely use elements of
Kanban, but Scrum gets all the
attention.
This session will review the basic
principles and practices of
Kanban, which can be applied to
any process to visualize work,
limit work in progress and create
continuous flow, resulting in
increased throughput and
greater agility.
This session will largely be based
on Anderson’s Kanban,
supplemented by Reinertsen’s
Flow and the presenter’s long
experience using Kanban.
Presenter: David Hanson
David has a long career
implementing Lean to transform
projects and organizations, with
his first exposure to Agile in
1999. David is an advocate of
Scrumban, incorporating the
best of Kanban, Scrum and XP.
In 2005, David developed a
unique hybrid Lean process,
which he later realized was
already documented in 2004 as
Kanban. Since then, David has
repeatedly used Kanban as an
initial step in the Agile journey,
transforming projects with an
initial focus on continuous flow
and continuous improvement.
2
Kanban 101
Agenda
 Objective
 Foundation
 Principles
 Practices
 Success
 Metrics
 Library
 Summary
 Appendix: Comparison, Application, Alternatives & Extensions
3
Objective
Kanban 101
 Introduce basic principles and practices of Kanban
 Review the most common implementation of Kanban
 Understand continuous flow is both Lean andAgile
 Suggest a path to success for Kanban andAgile
Kanban 202
 Highlight how Kanban can be integrated into any process
 Highlight alternative approaches consistent with Kanban
4
Lean
Foundation
Eliminate Waste
Build Quality In
Create Knowledge
Defer Commitment
Deliver Fast
Respect People
Optimize theWhole
5
Core Principles
StartWhereYouAre
PursueIncrementalChange
RespectProcess&Roles
DistributeLeadership
Start with what you do,
while agreeing to pursue
incremental change
Respect current process &
roles, while promoting
leadership at all levels
6
Core Practices
VisualizeWork
LimitWIP
Manage Flow
Explicit Process
ImproveEmpirically
EstablishCadence*
Regular Feedback*
Base
 Visualize work to improve
communication and create
transparency
 Limit work in progress to
increase focus and reduce
cycle time
 Manage flow instead of
schedule to establish
continuous flow
Extensions
 Explicit process with
consistent workflow and
common expectations
 Improve empirically with
collaborative and
incremental experiments
 Establish cadence for inputs
& outputs to create discipline
and predictability
 Regular feedback on product
& process to continuously
improve
*Anderson covered Establish Cadence under Manage Flow and added Regular Feedback in his
online blog
7
VisualizeWork
Process
Priority
Work
Block
Estimate
8
Backlog Analysis Development Acceptance
#2
User needs
something
Deploy
Workflow Process 
LowerPriorityHigher
#1
User needs
Something
#3
User wants
something
Rank: #1
Story:
As a <user>,
I need | want <function>,
so that <purpose>.
Lead: TBD
#4
User wants
something
Block
Defect
3
PO BA DB MT UI QA SM
Product
owner
Business
analyst
Database
developer
Mid-tier
developer
UI
developer
Quality
assurance
Scrum
master
VisualizeWork
Team Members
Respect Process & Roles:
Better w/ cross-functional
team
but can start w/ independent
analyst, developer, & QA teams
Better w/ product owner &
scrum master
but can start w/ project manager
9
Backlog Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT
#6
User wants
something
BA
#7
User wants
something
BA
#1
User needs
something
QA
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
UI , DB
LimitWIP
SetWIP limits
Track Doing vs. Done
10
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT
#6
User wants
something
BA
#7
User wants
something
BA
#1
User needs
something
QA
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
UI , DB
doing done doing done doing done
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
12
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT, DB
#6
User wants
something
UI
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
QA
doing done doing done doing done
2nd
1st
3rd
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
13
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT, DB
#6
User wants
something
UI
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
QA
doing done doing done doing done
2nd
1st
3rd
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
14
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
Add QA
resource?
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
15
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
Team
Composition
Traditional:
PM : 2 BA : 3 Dev : QA
Agile:
SM : PO : 3 coder : 2 tester
16
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
PO DB MT UI TE QA SM
Product
owner
Database
developer
Mid-tier
developer
UI
developer
Test
engineer
Quality
assurance
Scrum
master
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
17
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
block
?
ManageFlow
Queueing
Developers need QA to pull
work from done queue to
stay belowWIP limit
Starving
Developers need BA to get
analysis to done before work
available to pull
18
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
Explicit Process
Define Ready
Define Done
Define Accepted
19
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
something
BA
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Establish
Cadence
Daily,Weekly, Monthly
Plan, Demo,Retro
ReleaseCadence
Establish Cadence
Set recurring cadence for key
meetings; consider:
 Daily Standup
 Weekly Planning
 Monthly Retro
 Quarterly Roadmap
ReleaseCadence
Release on set cadence
 Deploy what’s ready and
waiting
 Dates don’t slip, but stories
may
 Creates discipline; becomes
routine; establishes rhythm
20
Anderson recommends daily standup w/ after meeting, weekly prioritization, monthly release
planning, plus triage and issues meetings
Grooming and
ReviewCadence
Ideal
Wheneverstorydone,team
reviewsstorywithPO&
users
Wheneverpullnewstory,
POgroomsstorywithteam
Suggestion
After Meeting
• Groom or review story after
the Daily Scrum with
required participants
• Always scheduled, honor
timebox, sometimes
cancelled, some participants
optional
Alternative
Weekly Meeting
• Schedule meetings similar to
weekly sprint
• Review whatever stories are
done
• Groom enough stories toWIP
limit
21
Establish
Cadence
Daily Scrum
Weekly Planning*
Monthly Release
* Consider adopting Reverse Scrum, a lightweight planning meeting, replacing sprint review and
planning, discussed in Appendix, using Walk the Board approach with weekly timeframe
22
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
QA
#3
User needs
Something
QA
#4
User needs
something
QA
#7
User needs
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#5
User wants
something
UI
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Release:
Monthly
w/ Retro
 production
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO
Improve
Empirically
Metrics:
• LeadTime
• CycleTime
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
QA
#5
User wants
Something
QA
#4
User needs
something
PO
#7
User needs
something
UI
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User needs
something
UI, DB
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Cadence:
Monthly
w/ Retro
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO
CycleTime
LeadTime
Improve
Empirically
Collaboratively
Experimentally
Collaborate
Regular Feedback
On product from users (and
team)
On process from team (and
users)
Leverage process feedback for
continuous improvement
opportunities
Experiment
Experiment and measure
impact on lead & cycle time:
• Lower or raiseWIP limits
• Adjust resource skill mix
• Split stories smaller
• Modify workflow steps
• Adjust done definitions
• Reset cadence
Test ideas generated from
regular feedback
24Experiments implemented from product feedback might be tested against Growth and Value metrics
CFD
0
4
8
12
16
20
24
Start Jan Feb Mar Apr Jun Jul Aug Sep Oct Nov Dec Finish
WorkCount
Cumulative Flow Diagram
Deployed Acceptance (2) Development (4>3) Analysis (2) Backlog
Tracks LeadTime and Cycle
Time
Tracks Backlog Size,Work In
Progress, and Completed
Work
Goals:
• Even Flow
• Increasing Slope
25
Backlog > Analysis > Development > Acceptance > Deploy
WIP limit changed from 4 to 3 for Development
CycleTime
LeadTime
WIP
BacklogSize
InProduction
CycleTime
Recipe for
Success
1. Focus on Quality: technical focus for solid foundation
2. LimitWork in Progress: reduces cycle time for delivery
3. Deliver Frequently: builds trust with clients
4. Balance Demand vs.Throughput: leave some buffer for
contingency and improvement
5. Prioritize*: influence to deliver highest business value
6. AttackVariability: standardizing leads to predictability
Follow these steps in order to
maximize chances for success
*Prioritize Ruthlessly is my viewpoint on prioritizing; not everything can or will be accomplished
My additions: Restructure Organization; Leverage Failure
26
KanbanLibrary
Lean: Mary&TomPoppendieck
www.poppendieck.com
Kanban: DavidAnderson
www.djaa.com
Flow: DonaldReinertsen
Kanban &Scrum:HenrikKniberg
blog.crisp.se/author/henrikkniberg
27
Kanban 101
Summary
• VisualizeWork
• LimitWork in Progress
• Manage Flow
Goal: continuous flow with
improving throughput
28
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
UI
#5
User wants
Something
PO
#4
User needs
something
PO
#7
User needs
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User needs
something
QA
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Release:
Monthly
w/ Retro
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO
pull
pull
block
 production
CycleTime
LeadTime
David Hanson: dphanson63@yahoo.com, https://www.linkedin.com/in/david-hanson/
Kanban 202
Comparison & Application
Extensions & Alternatives
29
Kanban vs.
Scrum
Differences
 Can be applied to waterfall to
create continuous flow
 Development and QA can be
independent
 Product owner and Scrum
master not mandatory
 Works even with traditional
specifications
 No estimates, no pointing
 Work can flow week to week,
no timeboxes
 Can change priority anytime
for anything not started
Compatibilities
 Can be applied to Scrum to get
stories to ready and get stories
through acceptance & release
 Works even better with cross-
functional team and Scrum
roles
 Desirable to break work into
stories for predictable flow
 Swarming blocks and floating
resources drives collaboration
 Pulling work based on priority
empowers self-management
 Both based on Lean and Agile
principles
30
Kanban
Workflows
Startbyapplyingtowaterfall
FinishbyadoptingScrumban
Applied to Waterfall
Activity States Wait States
Planning > Planned >
Analyzing > Analyzed >
Designing > Designed >
Coding > Coded >
Testing > Tested >
Accepting > Accepted >
Deploying > Deployed
Combining with Scrum
Ready States Active States Done States
Not Ready > Readying > Ready >
To Do > Doing > Done >
UAT Ready > UAT > UAT Done >
Staged > Deploy > Verified
31Start where you are and continuously improve…
Agile
Journey
Start with Kanban
Migrate to Scrum
Refine with XP
32
XP
Feedback: Pair Programming, Planning
Games*,Test First,WholeTeam
Process: Continuous Integration,
Refactor Complexity, Small Releases
Understanding: Coding Standards,
Collective Ownership, Simple Design,
System Metaphor
Welfare: Sustainable Pace
Kanban
Principles:
Start w/WhatYou Do, Pursue
Incremental Change, Respect Process
& Roles, Distribute Leadership
Practices:
VisualizeWork, LimitWIP, Manage
Flow, Explicit Policies, Establish
Cadence, Regular Feedback, Improve
Empirically
Scrum
Roles: PO, SM,Team
Events: Sprint, Planning, Scrum,
Review, Retrospective
Artifacts: Backlog Items*, Product
Backlog, Sprint Backlog, Increment
Agreements: Ready, Done, Norms
Tracking: Burnup/down,Velocity
*User Stories most popular Backlog Item, generally credited as derived from XP Planning Games
Team
Composition
Respect Process & Roles
Distributed Leadership
TraditionalTeam
PM : 2 BA : 3 developers : QA
AgileTeam
PO : 3 coders : 2 testers : SM
33
PO UI MT DB TE QA SM
Product
owner
UI
developer
Mid-tier
developer
DB
developer
Test
engineer
Quality
assurance
Scrum
master
PO SA UI MT DB QA SM
Product
owner
Systems
analyst
UI
developer
Mid-tier
developer
Database
developer
Quality
assurance
Scrum
master
PM BA SA UI MT DB QA
Project
manager
Business
analyst
Systems
analyst
UI
developer
Mid-tier
developer
Database
developer
Quality
assurance
Distributed
Leadership
Leadership atAll
Levels
Goals
 Distribute leadership across
multiple dimensions for every
team member
 Ensure every dimension has
recognized lead and grooms
backup within team
 Every team member aims to
be generalizing specialist
with goal to add skills
Dimensions
 Technical: BA, UI, middle tier,
DB, QA or .NET, Java, SQL
 Domain: data, content, usage
 Process: source control,
continuous integration,
release & deploy, scheduler
 Management: tasks, process,
priorities
34
VisualizeWork
Story BA DB MT UI QA UAT Date Issue
User needs… x x x x x x Apr
User needs… x x * * _ Apr defect
User wants… x x x x x o Apr
User needs… x x x x o May
User needs… o x _ o o May block
User wants… x o o May
User needs… x Jun
User needs… o Jun
User wants… Jun
Alternative approach
Allows tracking work in multiple states
Color code to highlight WIP or rework
Example:
• QA preparing test cases
• UI, MT, DB coding in progress
• BA addressing issue
35
Doing Done Rework Wait
o x * _
WIP Limit
Alternative
Pros & Cons
Pro: easy to implement and
controls multi-tasking
Con: promotes less teamwork
and less swarming
36
Each person has primary task
and backup task
Focus on primary task until
done or block requiring wait
Backup task will be next task
Primary & Backup
ReverseScrum
Whyreverse?
InDailyScrummember identifies
story
InReverseScrumstoryidentifies
member
Weekly Planning
Weekly meeting in place of the
day’s daily Scrum
Effectively replaces sprint review
and planning
Reviews the last week and plans
the next week
Review each story from highest
to lowest priority, or backwards
through workflow
Target 45 minutes, if demo and
groom stories outside of
meeting
Target 1.5 hours, if also covers
demo and grooming
Walk the Board
Start by reviewing production
issues and release readiness
Then for each story:
• Who is leading this story?
• What was accomplished for
this story in the last week?
• What will be accomplished for
this story in the next week?
• What obstacles delayed or risk
delaying this story?
End by asking if anything else in
progress not being tracked
37
ManageFlow
Managing Defects
If found in production then
may be added to backlog as
new requirement
If found during acceptance
then may or may not
require analysis
May exceed WIP limit
38
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
BA
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, DB,
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
PO
doing done doing done doing done
defect
defect
defect
ManageFlow
Expedited Swimlane
• Production support
• Managing defects
For unplanned, urgent &
critical work
Subject to ownWIP limit of 1
39
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
QA
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, MT
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User wants
something
UI, DB
#2
User wants
something
PO
doing done doing done doing done
defect defect
Support
Issue
QA
pull
Manage Flow
Blocks
Defects
Suspended
Manage Flow
Track blocks as hard, soft or
risk of block
Track rework as BA issue,
developer defect, QA retest
Visually track suspended tasks;
start and stop very inefficient
Types of Blocks
Hard: full block preventing all
work
Soft: partial block allowing
some work
Risk: risk of block in near term
worth managing
40
Extensions
Establish Cadence
Regular Feedback
Establish Cadence and Regular
Feedback related
Neither explicitly called out as
core practice by Anderson
Anderson has two chapters on
Cadence for inputs and outputs
Anderson suggests Feedback
as extension in online blogs
StandardizeWork
Small Batch Size
Standardize work to reduce
variation
Work in small batches to speed
feedback
Example:
• Standardize on 2-3-5 point
stories
• Standardize on ½-1 day tasks
41
Standardize
Work
Tasking:
Replace tasks with
story checklists
Status:
notrequired
notstarted
inprogress
completed
Development Checklist
 Analysis
 Coding
 UnitTesting
 Refactoring
 UI
 Middle-tier
 Database
 Batch
Acceptance Checklist
 Planning
 Manual
 Automation
 Maintenance
 Integration
 Acceptance
 Regression
 Performance
42
Metrics
LeadTime and CycleTime
LeadTime:
Time from idea to delivery
Time from entering product
backlog to exiting deployment
queue
CycleTime:
Time actively being worked
Time from entering to exiting
development queue
ActivityTime andWaitTime
Extension leveragingValue
Stream Mapping
Track ActivityTime andWait
Time
ActivityTime: time in doing
WaitTime: time in done
MinimizeWaitTime
Optimize ActivityTime
43
Jeff Sutherland emphasizes Process Efficiency, calculated as Activity Time / Lead Time, with goal of
25%, assuming Activity Time is also Value Added Time.
The
Principles of
Product
Development
Flow
Major
Themes
 Economics: prioritize based
primarily on cost of delay
 Queues: process inventory,
often unmeasured, is waste
 Variability: leverage risk for
better economic outcomes
 Batch Size: reducing batch
size positively impacts above
 WIP Constraints: simple
control to learn and delay
 Flow: control flow with
cadence & synchronization
 Fast Feedback: learn and
react fast for better outcome
 Decentralized Control:
empower with alignment
44
Economics:
Cost of Delay
Cost of Delay example:
 DeliverableA takes 3 months and will return one time benefit of
$250K if early to market else $200K if late to market; cost of delay
$50K
 Deliverable B takes 3 months and will return recurring benefit of
$25K/month; cost of delay recurring $25K/month
Options for delivery:
 Option 1 (equally important): work concurrently, delivering both in
6 months; at end of 1 year return is $350K
 Option 2 (early return): deliverable A in 3 months, followed by
deliverable B in 6 months; at end of 1 year return is $400K
 Option 3 (cost of delay): deliverable B in 3 months, followed by
deliverable A in 6 months; at end of 1 year return is $425K
Cost of Delay impacted by all factors: queues, variability, batch size,
WIP, cadence & flow, feedback, and control
45

More Related Content

What's hot

Agile101 - What Agile Is and What Agile Is Not
Agile101 - What Agile Is and What Agile Is NotAgile101 - What Agile Is and What Agile Is Not
Agile101 - What Agile Is and What Agile Is NotDerek Huether
 
Scrum in Distributed Teams
Scrum in Distributed TeamsScrum in Distributed Teams
Scrum in Distributed TeamsCprime
 
DevOps Approach (Point of View by Ravi Tadwalkar)
DevOps Approach (Point of View by Ravi Tadwalkar)DevOps Approach (Point of View by Ravi Tadwalkar)
DevOps Approach (Point of View by Ravi Tadwalkar)Ravi Tadwalkar
 
DevOps Kaizen: Practical Steps to Start & Sustain a Transformation
DevOps Kaizen: Practical Steps to Start & Sustain a TransformationDevOps Kaizen: Practical Steps to Start & Sustain a Transformation
DevOps Kaizen: Practical Steps to Start & Sustain a Transformationdev2ops
 
The Roles and Responsibilities in an Agile Project and Organization
The Roles and Responsibilities in an Agile Project and OrganizationThe Roles and Responsibilities in an Agile Project and Organization
The Roles and Responsibilities in an Agile Project and OrganizationToivo Vaje
 
Agile Delivery Powerpoint Presentation Slides
Agile Delivery Powerpoint Presentation SlidesAgile Delivery Powerpoint Presentation Slides
Agile Delivery Powerpoint Presentation SlidesSlideTeam
 
Agile2013 sustainable change
Agile2013 sustainable changeAgile2013 sustainable change
Agile2013 sustainable changeDennis Stevens
 
Deloitte lean agile state of the nation
Deloitte lean   agile state of the nationDeloitte lean   agile state of the nation
Deloitte lean agile state of the nationAlexis Hui
 
Adm Initial Proposal
Adm Initial ProposalAdm Initial Proposal
Adm Initial Proposalcfry
 
Understanding Agile Hardware
Understanding Agile HardwareUnderstanding Agile Hardware
Understanding Agile HardwareCprime
 
Understanding the Relationship Between Agile, Lean and DevOps
Understanding the Relationship Between Agile, Lean and DevOps Understanding the Relationship Between Agile, Lean and DevOps
Understanding the Relationship Between Agile, Lean and DevOps LeanKit
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development OverviewDUONG Trong Tan
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development processjhericks
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanDimitri Ponomareff
 
High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
 

What's hot (20)

Agile101 - What Agile Is and What Agile Is Not
Agile101 - What Agile Is and What Agile Is NotAgile101 - What Agile Is and What Agile Is Not
Agile101 - What Agile Is and What Agile Is Not
 
Scrum in Distributed Teams
Scrum in Distributed TeamsScrum in Distributed Teams
Scrum in Distributed Teams
 
DevOps Approach (Point of View by Ravi Tadwalkar)
DevOps Approach (Point of View by Ravi Tadwalkar)DevOps Approach (Point of View by Ravi Tadwalkar)
DevOps Approach (Point of View by Ravi Tadwalkar)
 
DevOps Kaizen: Practical Steps to Start & Sustain a Transformation
DevOps Kaizen: Practical Steps to Start & Sustain a TransformationDevOps Kaizen: Practical Steps to Start & Sustain a Transformation
DevOps Kaizen: Practical Steps to Start & Sustain a Transformation
 
The Roles and Responsibilities in an Agile Project and Organization
The Roles and Responsibilities in an Agile Project and OrganizationThe Roles and Responsibilities in an Agile Project and Organization
The Roles and Responsibilities in an Agile Project and Organization
 
Agile Delivery Powerpoint Presentation Slides
Agile Delivery Powerpoint Presentation SlidesAgile Delivery Powerpoint Presentation Slides
Agile Delivery Powerpoint Presentation Slides
 
Agile Product Owner
Agile Product OwnerAgile Product Owner
Agile Product Owner
 
Agile2013 sustainable change
Agile2013 sustainable changeAgile2013 sustainable change
Agile2013 sustainable change
 
Deloitte lean agile state of the nation
Deloitte lean   agile state of the nationDeloitte lean   agile state of the nation
Deloitte lean agile state of the nation
 
Agile basics
Agile basicsAgile basics
Agile basics
 
Adm Initial Proposal
Adm Initial ProposalAdm Initial Proposal
Adm Initial Proposal
 
Understanding Agile Hardware
Understanding Agile HardwareUnderstanding Agile Hardware
Understanding Agile Hardware
 
Understanding the Relationship Between Agile, Lean and DevOps
Understanding the Relationship Between Agile, Lean and DevOps Understanding the Relationship Between Agile, Lean and DevOps
Understanding the Relationship Between Agile, Lean and DevOps
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
Introduction to Lean, Agile, Scrum, & XP
Introduction to Lean, Agile, Scrum, & XPIntroduction to Lean, Agile, Scrum, & XP
Introduction to Lean, Agile, Scrum, & XP
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development process
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and Kanban
 
Agile 101
Agile 101Agile 101
Agile 101
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and Scrum
 

Similar to Kanban 101

Making quality visible in Product Engineering
Making quality visible in Product EngineeringMaking quality visible in Product Engineering
Making quality visible in Product EngineeringJan Petter Hagberg
 
Working Agile with Scrum and TFS 2013
Working Agile with Scrum and TFS 2013Working Agile with Scrum and TFS 2013
Working Agile with Scrum and TFS 2013Moataz Nabil
 
Introduction to Scrum.ppt
Introduction to Scrum.pptIntroduction to Scrum.ppt
Introduction to Scrum.pptMohan Late
 
Agile SharePoint Development With Scrum
Agile SharePoint Development With ScrumAgile SharePoint Development With Scrum
Agile SharePoint Development With ScrumAndrew Woodward
 
Introduction to Agile and Lean Software Development
Introduction to Agile and Lean Software DevelopmentIntroduction to Agile and Lean Software Development
Introduction to Agile and Lean Software DevelopmentThanh Nguyen
 
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystems
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystemsTechnical Webinar: By the (Play) Book: The Agile Practice at OutSystems
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystemsOutSystems
 
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...Agile Project Management in a Waterfall World: Managing Sprints with Predicti...
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...John Carter
 
DevOpsDays Jakarta Igites
DevOpsDays Jakarta IgitesDevOpsDays Jakarta Igites
DevOpsDays Jakarta IgitesDevOpsDaysJKT
 
Keeping the JIRA team on track: Five techniques we use to boost both speed an...
Keeping the JIRA team on track: Five techniques we use to boost both speed an...Keeping the JIRA team on track: Five techniques we use to boost both speed an...
Keeping the JIRA team on track: Five techniques we use to boost both speed an...Atlassian
 
7 Steps for Successful Project Management
7 Steps for Successful Project Management7 Steps for Successful Project Management
7 Steps for Successful Project ManagementFahrenheit Marketing
 
5 Key Metrics to Release Better Software Faster
5 Key Metrics to Release Better Software Faster5 Key Metrics to Release Better Software Faster
5 Key Metrics to Release Better Software FasterDynatrace
 
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code Deploys
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code DeploysDevOps Days Toronto: From 6 Months Waterfall to 1 hour Code Deploys
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code DeploysAndreas Grabner
 
From four to forty in four years - lessons from growing a team
From four to forty in four years - lessons from growing a teamFrom four to forty in four years - lessons from growing a team
From four to forty in four years - lessons from growing a teamRich Allen
 
The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010scrummasternz
 
Accelerating Agile by Adding Business Analysis
Accelerating Agile by Adding Business AnalysisAccelerating Agile by Adding Business Analysis
Accelerating Agile by Adding Business AnalysisIIBA UK Chapter
 

Similar to Kanban 101 (20)

Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
Making quality visible in Product Engineering
Making quality visible in Product EngineeringMaking quality visible in Product Engineering
Making quality visible in Product Engineering
 
Working Agile with Scrum and TFS 2013
Working Agile with Scrum and TFS 2013Working Agile with Scrum and TFS 2013
Working Agile with Scrum and TFS 2013
 
Introduction to Scrum.ppt
Introduction to Scrum.pptIntroduction to Scrum.ppt
Introduction to Scrum.ppt
 
Agile SharePoint Development With Scrum
Agile SharePoint Development With ScrumAgile SharePoint Development With Scrum
Agile SharePoint Development With Scrum
 
Project Management
Project ManagementProject Management
Project Management
 
Introduction to Agile and Lean Software Development
Introduction to Agile and Lean Software DevelopmentIntroduction to Agile and Lean Software Development
Introduction to Agile and Lean Software Development
 
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystems
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystemsTechnical Webinar: By the (Play) Book: The Agile Practice at OutSystems
Technical Webinar: By the (Play) Book: The Agile Practice at OutSystems
 
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...Agile Project Management in a Waterfall World: Managing Sprints with Predicti...
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...
 
DevOpsDays Jakarta Igites
DevOpsDays Jakarta IgitesDevOpsDays Jakarta Igites
DevOpsDays Jakarta Igites
 
Keeping the JIRA team on track: Five techniques we use to boost both speed an...
Keeping the JIRA team on track: Five techniques we use to boost both speed an...Keeping the JIRA team on track: Five techniques we use to boost both speed an...
Keeping the JIRA team on track: Five techniques we use to boost both speed an...
 
7 Steps for Successful Project Management
7 Steps for Successful Project Management7 Steps for Successful Project Management
7 Steps for Successful Project Management
 
5 Key Metrics to Release Better Software Faster
5 Key Metrics to Release Better Software Faster5 Key Metrics to Release Better Software Faster
5 Key Metrics to Release Better Software Faster
 
Agile webinar pack (2)
Agile webinar pack (2)Agile webinar pack (2)
Agile webinar pack (2)
 
Evolve 19 | Gina Petruccelli | Let’s Dig Into Requirements
Evolve 19 | Gina Petruccelli | Let’s Dig Into RequirementsEvolve 19 | Gina Petruccelli | Let’s Dig Into Requirements
Evolve 19 | Gina Petruccelli | Let’s Dig Into Requirements
 
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code Deploys
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code DeploysDevOps Days Toronto: From 6 Months Waterfall to 1 hour Code Deploys
DevOps Days Toronto: From 6 Months Waterfall to 1 hour Code Deploys
 
From four to forty in four years - lessons from growing a team
From four to forty in four years - lessons from growing a teamFrom four to forty in four years - lessons from growing a team
From four to forty in four years - lessons from growing a team
 
The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010
 
Kavithe_Res.doc
Kavithe_Res.docKavithe_Res.doc
Kavithe_Res.doc
 
Accelerating Agile by Adding Business Analysis
Accelerating Agile by Adding Business AnalysisAccelerating Agile by Adding Business Analysis
Accelerating Agile by Adding Business Analysis
 

More from David Hanson

Agile Maturity Assessments
Agile Maturity AssessmentsAgile Maturity Assessments
Agile Maturity AssessmentsDavid Hanson
 
Relative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & IllustrationsRelative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & IllustrationsDavid Hanson
 
Root Cause Analysis
Root Cause AnalysisRoot Cause Analysis
Root Cause AnalysisDavid Hanson
 
Backlog Refinement 101 & 202
Backlog Refinement 101 & 202Backlog Refinement 101 & 202
Backlog Refinement 101 & 202David Hanson
 
WIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple MathWIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple MathDavid Hanson
 
Exercises in Self-management
Exercises in Self-managementExercises in Self-management
Exercises in Self-managementDavid Hanson
 
Unplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableUnplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableDavid Hanson
 
Scrum of Scrums Patterns Library
Scrum of Scrums Patterns LibraryScrum of Scrums Patterns Library
Scrum of Scrums Patterns LibraryDavid Hanson
 
What is wrong with Jira? My top 20 for 2020.
What is wrong with Jira?  My top 20 for 2020.What is wrong with Jira?  My top 20 for 2020.
What is wrong with Jira? My top 20 for 2020.David Hanson
 
Extreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesExtreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesDavid Hanson
 
Managing Multiple Priorities
Managing Multiple PrioritiesManaging Multiple Priorities
Managing Multiple PrioritiesDavid Hanson
 
Epic Estimation 2019
Epic Estimation 2019Epic Estimation 2019
Epic Estimation 2019David Hanson
 

More from David Hanson (12)

Agile Maturity Assessments
Agile Maturity AssessmentsAgile Maturity Assessments
Agile Maturity Assessments
 
Relative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & IllustrationsRelative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & Illustrations
 
Root Cause Analysis
Root Cause AnalysisRoot Cause Analysis
Root Cause Analysis
 
Backlog Refinement 101 & 202
Backlog Refinement 101 & 202Backlog Refinement 101 & 202
Backlog Refinement 101 & 202
 
WIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple MathWIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple Math
 
Exercises in Self-management
Exercises in Self-managementExercises in Self-management
Exercises in Self-management
 
Unplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableUnplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitable
 
Scrum of Scrums Patterns Library
Scrum of Scrums Patterns LibraryScrum of Scrums Patterns Library
Scrum of Scrums Patterns Library
 
What is wrong with Jira? My top 20 for 2020.
What is wrong with Jira?  My top 20 for 2020.What is wrong with Jira?  My top 20 for 2020.
What is wrong with Jira? My top 20 for 2020.
 
Extreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesExtreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP Practices
 
Managing Multiple Priorities
Managing Multiple PrioritiesManaging Multiple Priorities
Managing Multiple Priorities
 
Epic Estimation 2019
Epic Estimation 2019Epic Estimation 2019
Epic Estimation 2019
 

Recently uploaded

A Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfA Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfICS
 
The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)Roberto Bettazzoni
 
Effective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConEffective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConNatan Silnitsky
 
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio, Inc.
 
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Andreas Granig
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jNeo4j
 
Rapidoform for Modern Form Building and Insights
Rapidoform for Modern Form Building and InsightsRapidoform for Modern Form Building and Insights
Rapidoform for Modern Form Building and Insightsrapidoform
 
Lessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfLessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfSrushith Repakula
 
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024SimonedeGijt
 
Community is Just as Important as Code by Andrea Goulet
Community is Just as Important as Code by Andrea GouletCommunity is Just as Important as Code by Andrea Goulet
Community is Just as Important as Code by Andrea GouletAndrea Goulet
 
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...Navigation in flutter – how to add stack, tab, and drawer navigators to your ...
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...Flutter Agency
 
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024MulesoftMunichMeetup
 
Your Ultimate Web Studio for Streaming Anywhere | Evmux
Your Ultimate Web Studio for Streaming Anywhere | EvmuxYour Ultimate Web Studio for Streaming Anywhere | Evmux
Your Ultimate Web Studio for Streaming Anywhere | Evmuxevmux96
 
Test Automation Design Patterns_ A Comprehensive Guide.pdf
Test Automation Design Patterns_ A Comprehensive Guide.pdfTest Automation Design Patterns_ A Comprehensive Guide.pdf
Test Automation Design Patterns_ A Comprehensive Guide.pdfkalichargn70th171
 
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypseTomasz Kowalczewski
 
Food Delivery Business App Development Guide 2024
Food Delivery Business App Development Guide 2024Food Delivery Business App Development Guide 2024
Food Delivery Business App Development Guide 2024Chirag Panchal
 
Encryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key ConceptsEncryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key Conceptsthomashtkim
 

Recently uploaded (20)

Abortion Pill Prices Turfloop ](+27832195400*)[ 🏥 Women's Abortion Clinic in ...
Abortion Pill Prices Turfloop ](+27832195400*)[ 🏥 Women's Abortion Clinic in ...Abortion Pill Prices Turfloop ](+27832195400*)[ 🏥 Women's Abortion Clinic in ...
Abortion Pill Prices Turfloop ](+27832195400*)[ 🏥 Women's Abortion Clinic in ...
 
A Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfA Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdf
 
The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)
 
Effective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConEffective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeCon
 
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
 
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
 
Rapidoform for Modern Form Building and Insights
Rapidoform for Modern Form Building and InsightsRapidoform for Modern Form Building and Insights
Rapidoform for Modern Form Building and Insights
 
Lessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfLessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdf
 
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
 
Community is Just as Important as Code by Andrea Goulet
Community is Just as Important as Code by Andrea GouletCommunity is Just as Important as Code by Andrea Goulet
Community is Just as Important as Code by Andrea Goulet
 
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...Navigation in flutter – how to add stack, tab, and drawer navigators to your ...
Navigation in flutter – how to add stack, tab, and drawer navigators to your ...
 
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
 
Your Ultimate Web Studio for Streaming Anywhere | Evmux
Your Ultimate Web Studio for Streaming Anywhere | EvmuxYour Ultimate Web Studio for Streaming Anywhere | Evmux
Your Ultimate Web Studio for Streaming Anywhere | Evmux
 
Abortion Clinic In Pretoria ](+27832195400*)[ 🏥 Safe Abortion Pills in Pretor...
Abortion Clinic In Pretoria ](+27832195400*)[ 🏥 Safe Abortion Pills in Pretor...Abortion Clinic In Pretoria ](+27832195400*)[ 🏥 Safe Abortion Pills in Pretor...
Abortion Clinic In Pretoria ](+27832195400*)[ 🏥 Safe Abortion Pills in Pretor...
 
Test Automation Design Patterns_ A Comprehensive Guide.pdf
Test Automation Design Patterns_ A Comprehensive Guide.pdfTest Automation Design Patterns_ A Comprehensive Guide.pdf
Test Automation Design Patterns_ A Comprehensive Guide.pdf
 
Abortion Pill Prices Mthatha (@](+27832195400*)[ 🏥 Women's Abortion Clinic In...
Abortion Pill Prices Mthatha (@](+27832195400*)[ 🏥 Women's Abortion Clinic In...Abortion Pill Prices Mthatha (@](+27832195400*)[ 🏥 Women's Abortion Clinic In...
Abortion Pill Prices Mthatha (@](+27832195400*)[ 🏥 Women's Abortion Clinic In...
 
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
 
Food Delivery Business App Development Guide 2024
Food Delivery Business App Development Guide 2024Food Delivery Business App Development Guide 2024
Food Delivery Business App Development Guide 2024
 
Encryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key ConceptsEncryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key Concepts
 

Kanban 101

  • 1. Kanban 101 David Hanson Version 1.6 May 2019 1 看 板 https://www.linkedin.com/in/david-hanson/ dphanson63@yahoo.com
  • 2. Agile 101 2 May 2019 看板 101 dphanson63@yahoo.com Topic: Kanban 101 We all likely use elements of Kanban, but Scrum gets all the attention. This session will review the basic principles and practices of Kanban, which can be applied to any process to visualize work, limit work in progress and create continuous flow, resulting in increased throughput and greater agility. This session will largely be based on Anderson’s Kanban, supplemented by Reinertsen’s Flow and the presenter’s long experience using Kanban. Presenter: David Hanson David has a long career implementing Lean to transform projects and organizations, with his first exposure to Agile in 1999. David is an advocate of Scrumban, incorporating the best of Kanban, Scrum and XP. In 2005, David developed a unique hybrid Lean process, which he later realized was already documented in 2004 as Kanban. Since then, David has repeatedly used Kanban as an initial step in the Agile journey, transforming projects with an initial focus on continuous flow and continuous improvement. 2
  • 3. Kanban 101 Agenda  Objective  Foundation  Principles  Practices  Success  Metrics  Library  Summary  Appendix: Comparison, Application, Alternatives & Extensions 3
  • 4. Objective Kanban 101  Introduce basic principles and practices of Kanban  Review the most common implementation of Kanban  Understand continuous flow is both Lean andAgile  Suggest a path to success for Kanban andAgile Kanban 202  Highlight how Kanban can be integrated into any process  Highlight alternative approaches consistent with Kanban 4
  • 5. Lean Foundation Eliminate Waste Build Quality In Create Knowledge Defer Commitment Deliver Fast Respect People Optimize theWhole 5
  • 6. Core Principles StartWhereYouAre PursueIncrementalChange RespectProcess&Roles DistributeLeadership Start with what you do, while agreeing to pursue incremental change Respect current process & roles, while promoting leadership at all levels 6
  • 7. Core Practices VisualizeWork LimitWIP Manage Flow Explicit Process ImproveEmpirically EstablishCadence* Regular Feedback* Base  Visualize work to improve communication and create transparency  Limit work in progress to increase focus and reduce cycle time  Manage flow instead of schedule to establish continuous flow Extensions  Explicit process with consistent workflow and common expectations  Improve empirically with collaborative and incremental experiments  Establish cadence for inputs & outputs to create discipline and predictability  Regular feedback on product & process to continuously improve *Anderson covered Establish Cadence under Manage Flow and added Regular Feedback in his online blog 7
  • 8. VisualizeWork Process Priority Work Block Estimate 8 Backlog Analysis Development Acceptance #2 User needs something Deploy Workflow Process  LowerPriorityHigher #1 User needs Something #3 User wants something Rank: #1 Story: As a <user>, I need | want <function>, so that <purpose>. Lead: TBD #4 User wants something Block Defect 3
  • 9. PO BA DB MT UI QA SM Product owner Business analyst Database developer Mid-tier developer UI developer Quality assurance Scrum master VisualizeWork Team Members Respect Process & Roles: Better w/ cross-functional team but can start w/ independent analyst, developer, & QA teams Better w/ product owner & scrum master but can start w/ project manager 9 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO #5 User needs something MT, DB #4 User needs Something UI, MT #6 User wants something BA #7 User wants something BA #1 User needs something QA #8 User needs Something PO #2 User wants something QA #3 User wants something UI , DB
  • 10. LimitWIP SetWIP limits Track Doing vs. Done 10 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #5 User needs something MT, DB #4 User needs Something UI, MT #6 User wants something BA #7 User wants something BA #1 User needs something QA #8 User needs Something PO #2 User wants something QA #3 User wants something UI , DB doing done doing done doing done
  • 11. ManageFlow PullWork Float Resources Balance Resources Swarm Blocks 12 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #5 User needs something MT, DB #4 User needs Something UI, MT, DB #6 User wants something UI #7 User wants something BA #1 User needs something PO #8 User needs Something PO #2 User wants something QA #3 User wants something QA doing done doing done doing done 2nd 1st 3rd
  • 12. ManageFlow PullWork Float Resources Balance Resources Swarm Blocks 13 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #5 User needs something MT, DB #4 User needs Something UI, MT, DB #6 User wants something UI #7 User wants something BA #1 User needs something PO #8 User needs Something PO #2 User wants something QA #3 User wants something QA doing done doing done doing done 2nd 1st 3rd
  • 13. ManageFlow PullWork Float Resources Balance Resources Swarm Blocks 14 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something UI, MT, DB #7 User wants something BA #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something QA doing done doing done doing done
  • 14. Add QA resource? ManageFlow PullWork Float Resources Balance Resources Swarm Blocks 15 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something UI, MT, DB #7 User wants something BA #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something QA doing done doing done doing done
  • 15. Team Composition Traditional: PM : 2 BA : 3 Dev : QA Agile: SM : PO : 3 coder : 2 tester 16 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something UI, MT, DB #7 User wants something BA #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something QA doing done doing done doing done PO DB MT UI TE QA SM Product owner Database developer Mid-tier developer UI developer Test engineer Quality assurance Scrum master
  • 16. ManageFlow PullWork Float Resources Balance Resources Swarm Blocks 17 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something UI, MT, DB #7 User wants something BA #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something QA doing done doing done doing done block ?
  • 17. ManageFlow Queueing Developers need QA to pull work from done queue to stay belowWIP limit Starving Developers need BA to get analysis to done before work available to pull 18 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something UI, MT, DB #7 User wants something BA #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something QA doing done doing done doing done
  • 18. Explicit Process Define Ready Define Done Define Accepted 19 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs something BA #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something QA #7 User wants something UI, DB #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something PO doing done doing done doing done Ready: Who, what, why Acceptance criteria Reviewed w/ team Done: Unit tests pass Code reviewed Refactor if req’d Accepted: Passes acceptance Passes regression Reviewed w/ users
  • 19. Establish Cadence Daily,Weekly, Monthly Plan, Demo,Retro ReleaseCadence Establish Cadence Set recurring cadence for key meetings; consider:  Daily Standup  Weekly Planning  Monthly Retro  Quarterly Roadmap ReleaseCadence Release on set cadence  Deploy what’s ready and waiting  Dates don’t slip, but stories may  Creates discipline; becomes routine; establishes rhythm 20 Anderson recommends daily standup w/ after meeting, weekly prioritization, monthly release planning, plus triage and issues meetings
  • 20. Grooming and ReviewCadence Ideal Wheneverstorydone,team reviewsstorywithPO& users Wheneverpullnewstory, POgroomsstorywithteam Suggestion After Meeting • Groom or review story after the Daily Scrum with required participants • Always scheduled, honor timebox, sometimes cancelled, some participants optional Alternative Weekly Meeting • Schedule meetings similar to weekly sprint • Review whatever stories are done • Groom enough stories toWIP limit 21
  • 21. Establish Cadence Daily Scrum Weekly Planning* Monthly Release * Consider adopting Reverse Scrum, a lightweight planning meeting, replacing sprint review and planning, discussed in Appendix, using Walk the Board approach with weekly timeframe 22 Backlog Analysis Development Acceptance #10 User wants something BA Deploy #9 User wants something BA #13 User wants something PO #14 User wants something PO 2 3 2 #6 User wants something QA #3 User needs Something QA #4 User needs something QA #7 User needs something UI, DB #1 User needs something PO #8 User needs Something UI, MT, DB #5 User wants something UI #2 User needs something PO doing done doing done doing done Ready: Who, what, why Acceptance criteria Reviewed w/ team Done: Unit tests pass Code reviewed Refactor if req’d Accepted: Passes acceptance Passes regression Reviewed w/ users Release: Monthly w/ Retro  production Ranked: Daily Review: Weekly #11 User needs something PO #12 User needs something PO
  • 22. Improve Empirically Metrics: • LeadTime • CycleTime Backlog Analysis Development Acceptance #10 User wants something BA Deploy #9 User wants something BA #13 User wants something PO #14 User wants something PO 2 3 2 #6 User wants something QA #5 User wants Something QA #4 User needs something PO #7 User needs something UI #1 User needs something PO #8 User needs Something UI, MT, DB #3 User needs something UI, DB #2 User needs something PO doing done doing done doing done Ready: Who, what, why Acceptance criteria Reviewed w/ team Done: Unit tests pass Code reviewed Refactor if req’d Accepted: Passes acceptance Passes regression Reviewed w/ users Cadence: Monthly w/ Retro Ranked: Daily Review: Weekly #11 User needs something PO #12 User needs something PO CycleTime LeadTime
  • 23. Improve Empirically Collaboratively Experimentally Collaborate Regular Feedback On product from users (and team) On process from team (and users) Leverage process feedback for continuous improvement opportunities Experiment Experiment and measure impact on lead & cycle time: • Lower or raiseWIP limits • Adjust resource skill mix • Split stories smaller • Modify workflow steps • Adjust done definitions • Reset cadence Test ideas generated from regular feedback 24Experiments implemented from product feedback might be tested against Growth and Value metrics
  • 24. CFD 0 4 8 12 16 20 24 Start Jan Feb Mar Apr Jun Jul Aug Sep Oct Nov Dec Finish WorkCount Cumulative Flow Diagram Deployed Acceptance (2) Development (4>3) Analysis (2) Backlog Tracks LeadTime and Cycle Time Tracks Backlog Size,Work In Progress, and Completed Work Goals: • Even Flow • Increasing Slope 25 Backlog > Analysis > Development > Acceptance > Deploy WIP limit changed from 4 to 3 for Development CycleTime LeadTime WIP BacklogSize InProduction CycleTime
  • 25. Recipe for Success 1. Focus on Quality: technical focus for solid foundation 2. LimitWork in Progress: reduces cycle time for delivery 3. Deliver Frequently: builds trust with clients 4. Balance Demand vs.Throughput: leave some buffer for contingency and improvement 5. Prioritize*: influence to deliver highest business value 6. AttackVariability: standardizing leads to predictability Follow these steps in order to maximize chances for success *Prioritize Ruthlessly is my viewpoint on prioritizing; not everything can or will be accomplished My additions: Restructure Organization; Leverage Failure 26
  • 26. KanbanLibrary Lean: Mary&TomPoppendieck www.poppendieck.com Kanban: DavidAnderson www.djaa.com Flow: DonaldReinertsen Kanban &Scrum:HenrikKniberg blog.crisp.se/author/henrikkniberg 27
  • 27. Kanban 101 Summary • VisualizeWork • LimitWork in Progress • Manage Flow Goal: continuous flow with improving throughput 28 Backlog Analysis Development Acceptance #10 User wants something BA Deploy #9 User wants something BA #13 User wants something PO #14 User wants something PO 2 3 2 #6 User wants something UI #5 User wants Something PO #4 User needs something PO #7 User needs something UI, DB #1 User needs something PO #8 User needs Something UI, MT, DB #3 User needs something QA #2 User needs something PO doing done doing done doing done Ready: Who, what, why Acceptance criteria Reviewed w/ team Done: Unit tests pass Code reviewed Refactor if req’d Accepted: Passes acceptance Passes regression Reviewed w/ users Release: Monthly w/ Retro Ranked: Daily Review: Weekly #11 User needs something PO #12 User needs something PO pull pull block  production CycleTime LeadTime David Hanson: dphanson63@yahoo.com, https://www.linkedin.com/in/david-hanson/
  • 28. Kanban 202 Comparison & Application Extensions & Alternatives 29
  • 29. Kanban vs. Scrum Differences  Can be applied to waterfall to create continuous flow  Development and QA can be independent  Product owner and Scrum master not mandatory  Works even with traditional specifications  No estimates, no pointing  Work can flow week to week, no timeboxes  Can change priority anytime for anything not started Compatibilities  Can be applied to Scrum to get stories to ready and get stories through acceptance & release  Works even better with cross- functional team and Scrum roles  Desirable to break work into stories for predictable flow  Swarming blocks and floating resources drives collaboration  Pulling work based on priority empowers self-management  Both based on Lean and Agile principles 30
  • 30. Kanban Workflows Startbyapplyingtowaterfall FinishbyadoptingScrumban Applied to Waterfall Activity States Wait States Planning > Planned > Analyzing > Analyzed > Designing > Designed > Coding > Coded > Testing > Tested > Accepting > Accepted > Deploying > Deployed Combining with Scrum Ready States Active States Done States Not Ready > Readying > Ready > To Do > Doing > Done > UAT Ready > UAT > UAT Done > Staged > Deploy > Verified 31Start where you are and continuously improve…
  • 31. Agile Journey Start with Kanban Migrate to Scrum Refine with XP 32 XP Feedback: Pair Programming, Planning Games*,Test First,WholeTeam Process: Continuous Integration, Refactor Complexity, Small Releases Understanding: Coding Standards, Collective Ownership, Simple Design, System Metaphor Welfare: Sustainable Pace Kanban Principles: Start w/WhatYou Do, Pursue Incremental Change, Respect Process & Roles, Distribute Leadership Practices: VisualizeWork, LimitWIP, Manage Flow, Explicit Policies, Establish Cadence, Regular Feedback, Improve Empirically Scrum Roles: PO, SM,Team Events: Sprint, Planning, Scrum, Review, Retrospective Artifacts: Backlog Items*, Product Backlog, Sprint Backlog, Increment Agreements: Ready, Done, Norms Tracking: Burnup/down,Velocity *User Stories most popular Backlog Item, generally credited as derived from XP Planning Games
  • 32. Team Composition Respect Process & Roles Distributed Leadership TraditionalTeam PM : 2 BA : 3 developers : QA AgileTeam PO : 3 coders : 2 testers : SM 33 PO UI MT DB TE QA SM Product owner UI developer Mid-tier developer DB developer Test engineer Quality assurance Scrum master PO SA UI MT DB QA SM Product owner Systems analyst UI developer Mid-tier developer Database developer Quality assurance Scrum master PM BA SA UI MT DB QA Project manager Business analyst Systems analyst UI developer Mid-tier developer Database developer Quality assurance
  • 33. Distributed Leadership Leadership atAll Levels Goals  Distribute leadership across multiple dimensions for every team member  Ensure every dimension has recognized lead and grooms backup within team  Every team member aims to be generalizing specialist with goal to add skills Dimensions  Technical: BA, UI, middle tier, DB, QA or .NET, Java, SQL  Domain: data, content, usage  Process: source control, continuous integration, release & deploy, scheduler  Management: tasks, process, priorities 34
  • 34. VisualizeWork Story BA DB MT UI QA UAT Date Issue User needs… x x x x x x Apr User needs… x x * * _ Apr defect User wants… x x x x x o Apr User needs… x x x x o May User needs… o x _ o o May block User wants… x o o May User needs… x Jun User needs… o Jun User wants… Jun Alternative approach Allows tracking work in multiple states Color code to highlight WIP or rework Example: • QA preparing test cases • UI, MT, DB coding in progress • BA addressing issue 35 Doing Done Rework Wait o x * _
  • 35. WIP Limit Alternative Pros & Cons Pro: easy to implement and controls multi-tasking Con: promotes less teamwork and less swarming 36 Each person has primary task and backup task Focus on primary task until done or block requiring wait Backup task will be next task Primary & Backup
  • 36. ReverseScrum Whyreverse? InDailyScrummember identifies story InReverseScrumstoryidentifies member Weekly Planning Weekly meeting in place of the day’s daily Scrum Effectively replaces sprint review and planning Reviews the last week and plans the next week Review each story from highest to lowest priority, or backwards through workflow Target 45 minutes, if demo and groom stories outside of meeting Target 1.5 hours, if also covers demo and grooming Walk the Board Start by reviewing production issues and release readiness Then for each story: • Who is leading this story? • What was accomplished for this story in the last week? • What will be accomplished for this story in the next week? • What obstacles delayed or risk delaying this story? End by asking if anything else in progress not being tracked 37
  • 37. ManageFlow Managing Defects If found in production then may be added to backlog as new requirement If found during acceptance then may or may not require analysis May exceed WIP limit 38 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something BA #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something UI #5 User needs Something MT, DB #4 User wants something QA #7 User wants something UI, DB, #1 User needs something PO #8 User needs Something BA #3 User wants something QA #2 User wants something PO doing done doing done doing done defect defect defect
  • 38. ManageFlow Expedited Swimlane • Production support • Managing defects For unplanned, urgent & critical work Subject to ownWIP limit of 1 39 Backlog Analysis Development Acceptance #10 User needs something PO Deploy #9 User needs Something PO #11 User wants something PO #12 User wants something PO 2 3 2 #6 User needs something QA #5 User needs Something MT, DB #4 User wants something QA #7 User wants something UI, MT #1 User needs something PO #8 User needs Something UI, MT, DB #3 User wants something UI, DB #2 User wants something PO doing done doing done doing done defect defect Support Issue QA pull
  • 39. Manage Flow Blocks Defects Suspended Manage Flow Track blocks as hard, soft or risk of block Track rework as BA issue, developer defect, QA retest Visually track suspended tasks; start and stop very inefficient Types of Blocks Hard: full block preventing all work Soft: partial block allowing some work Risk: risk of block in near term worth managing 40
  • 40. Extensions Establish Cadence Regular Feedback Establish Cadence and Regular Feedback related Neither explicitly called out as core practice by Anderson Anderson has two chapters on Cadence for inputs and outputs Anderson suggests Feedback as extension in online blogs StandardizeWork Small Batch Size Standardize work to reduce variation Work in small batches to speed feedback Example: • Standardize on 2-3-5 point stories • Standardize on ½-1 day tasks 41
  • 41. Standardize Work Tasking: Replace tasks with story checklists Status: notrequired notstarted inprogress completed Development Checklist  Analysis  Coding  UnitTesting  Refactoring  UI  Middle-tier  Database  Batch Acceptance Checklist  Planning  Manual  Automation  Maintenance  Integration  Acceptance  Regression  Performance 42
  • 42. Metrics LeadTime and CycleTime LeadTime: Time from idea to delivery Time from entering product backlog to exiting deployment queue CycleTime: Time actively being worked Time from entering to exiting development queue ActivityTime andWaitTime Extension leveragingValue Stream Mapping Track ActivityTime andWait Time ActivityTime: time in doing WaitTime: time in done MinimizeWaitTime Optimize ActivityTime 43 Jeff Sutherland emphasizes Process Efficiency, calculated as Activity Time / Lead Time, with goal of 25%, assuming Activity Time is also Value Added Time.
  • 43. The Principles of Product Development Flow Major Themes  Economics: prioritize based primarily on cost of delay  Queues: process inventory, often unmeasured, is waste  Variability: leverage risk for better economic outcomes  Batch Size: reducing batch size positively impacts above  WIP Constraints: simple control to learn and delay  Flow: control flow with cadence & synchronization  Fast Feedback: learn and react fast for better outcome  Decentralized Control: empower with alignment 44
  • 44. Economics: Cost of Delay Cost of Delay example:  DeliverableA takes 3 months and will return one time benefit of $250K if early to market else $200K if late to market; cost of delay $50K  Deliverable B takes 3 months and will return recurring benefit of $25K/month; cost of delay recurring $25K/month Options for delivery:  Option 1 (equally important): work concurrently, delivering both in 6 months; at end of 1 year return is $350K  Option 2 (early return): deliverable A in 3 months, followed by deliverable B in 6 months; at end of 1 year return is $400K  Option 3 (cost of delay): deliverable B in 3 months, followed by deliverable A in 6 months; at end of 1 year return is $425K Cost of Delay impacted by all factors: queues, variability, batch size, WIP, cadence & flow, feedback, and control 45

Editor's Notes

  1. 101: target 30 slides 202: target 15 slides
  2. Also mention aligns with Agile principles
  3. Establish cadence for inputs & outputs with regular feedback on product & process
  4. Extend for different work types; support, technical Could modernize terminology, replacing Analysis with Discovery
  5. Could illustrate starting with traditional team and transitioning to Agile team
  6. Better slide for printing than presenting
  7. Better slide for presenting than printing
  8. Maybe PO could write stories and swap BA for TE Current industry recommend 1 SM : 1 PO : 3 coders : 2 testers My long time recommendation 1 manager : 1 analyst : 4 coders : 2 testers
  9. Maybe PO could write stories and swap BA for TE Current industry recommend 1 SM : 1 PO : 3 coders : 2 testers My long time recommendation 1 manager : 1 analyst : 4 coders : 2 testers
  10. Goal: steady, even, continuous flow of work; maybe 2 rows across, ideal 1 row across
  11. Correct column width spacing (throughout)
  12. Anderson: Daily Standup, After Meeting, Prioritization Meeting, Release Meeting, Adhoc Triage, Issues Meeting
  13. Change side to reflect content; drop reference to Reverse Scrum?
  14. Add time waiting for deploy Similar to product backlog burnup
  15. My additions: Restructure Organization: culture follows structure Leverage Failure: as opportunity to change and improve
  16. Rework conclusion to be interactive; maybe use whiteboard to ask participants to recreate?
  17. How visualize or make glanceable?
  18. Specifying > Specified? Ready > In Progress > Done? Flowchart?
  19. Consider start here arrow with circle loop
  20. Could illustrate starting with traditional team and transitioning to Agile team
  21. Combine WIP Limit Alternative with Types of Blocks?
  22. Can “Why reverse?” be animated to display last?
  23. Swim lanes can be extended to reserve bandwidth for strategic vs. tactical or story vs. defect or business vs. IT
  24. Footnote on Anderson Focus Team
  25. Learn and delay; delay starting to learn first