View
43
Download
1
Category
Tags:
Preview:
DESCRIPTION
Delivering Better Predictability, Business Agility & Governance with Kanban. Executives demand improved agility without sacrificing predictability & governance Bangalore, December 2012. Background. Microsoft 2004 - the XIT Story. Change requests. PTCs. 6. 8. 1. 2. 4. 12. 11. 10. 7. - PowerPoint PPT Presentation
Citation preview
dja@djaa.com, @agilemanager
Delivering Better Predictability, Business Agility & Governancewith Kanban
dja@djaa.com, @agilemanager
Background
dja@djaa.com, @agilemanager
PM
Change requests
Microsoft 2004 - the XIT Story
Developers TestersProduct
Managers
User Acceptance
Deployment
1211
10
9
8
7
6
5
4
3
2
1
PrioritizedBacklog
76
5
9
4
3
2
1
Waiting forTest
11
1
PTCs
PTCs? What did that acronym mean? Items that did not require coding!
Why were they treated as emergencies?
Requests for estimates or analysis of future work are often “invisible”, have
an unpredictable arrival rate & are given priority.Emergency work is unplanned &
receives highest priority. Arrival rate & volume are unpredictable.
Effect is hugely disruptive!
dja@djaa.com, @agilemanager
Predictability, Agility & Governance
Developers TestersProduct
Managers
User Acceptance
Deployment
1211
10
9
8
7
6
5
4
3
2
1
PrioritizedBacklog
76
5
9
4
3
2
1
Waiting forTest
11
1
PTCsSo how were they doing on our
measures of predictability, agility & governance?
On-time delivery was 0%. There was a 100% chance of interruption to estimate future
work.
Planning & prioritization were conducted monthly. Fastest response from receipt to
deployment was around 6 weeks.
But everything had a business case and was prioritized by ROI!
So the drive for good governance was destroying predictability and agility!
dja@djaa.com, @agilemanager
What Were the Issues?
Developers TestersProduct
Managers
User Acceptance
Deployment
1211
10
9
8
7
6
5
4
3
2
1
PrioritizedBacklog
76
5
9
4
3
2
1
Waiting forTest
11
1
PTCsSo what issues affected the outcome?
Why were governance policies so disruptive?
Product managers demanded fast response on estimates to facilitate future planning and provide fast feedback to business owners.
Entire backlog was planned & commitments made early. 90% of the backlog was re-planned
each month.
Expedite policy for PTCs was folklore – no one could explain why
Process Improvement Conclusion Controlling unplanned, disruptive
demand would improve predictability!
dja@djaa.com, @agilemanager
A virtual kanban system was chosen
Backlog
D
E
A
I
Engin-eeringReady
G
5Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
F
B
CPull
Pull
PTCs are permitted to break the kanban limit
*Blocked to service PTC
*
UAT
Deploy-mentReady
∞ ∞
H
FF
FFF
F F
G
Pull
ChangeRequests It’s important to realize the process for
software development did not change. The kanban system is an overlay on the existing process. It changes scheduling
and prioritization only
dja@djaa.com, @agilemanager
The Results
Time (in quarters)
CR
s
10
30
50
Backlog depleted. Serving at rate of
demand
240% improvement
in delivery rate
Time (in quarters)
Avera
ge
Tim
e t
o R
esolv
e
25
75
125
90% drop in end-to-end cycle time*
* Includes queuing time prior to selection
dja@djaa.com, @agilemanager
Robert Bosch* (2006-2008)IS Website Maintenance Results
Time (6 mth intervals)
Avera
ge
Tim
e t
o C
reate
to R
esolv
e
10
20
40
78% drop in end-to-end cycle time
* South Bend, Indiana
dja@djaa.com, @agilemanager
State of Virginia, Department of Corrections (2011-2012)
Time (3 mth intervals)
Avera
ge
Tim
e t
o C
reate
to R
esolv
e
10
20
40
58% drop in end-to-end cycle time
dja@djaa.com, @agilemanager
Understanding Kanban Systems
dja@djaa.com, @agilemanager
H
FF
FFF
F J
I
Pull
ChangeRequests
Kanban are virtual!
Backlog
D
E
A
I
Engin-eeringReady
G
5Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
F
B
CPull
PullThese are the virtual kanban
*
These are the virtual kanbanThese are the virtual kanbanThese are the virtual kanban
The board is a visualization of the workflow process, the work-in-progress
and the (virtual) kanban
Boards are not required to do Kanban!
The first system used database triggers to signal pull. There was no board!
UAT
Deploy-mentReady
∞ ∞
dja@djaa.com, @agilemanager
Wish to avoid discard after commitment
Commitment is deferred
Backlog
H
E
C A
I
Engin-eeringReady
D
5Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
Commitment point
We are committing to getting started. We are certain we want
to take delivery.
UAT
Deploy-mentReady
∞ ∞
FF
FFF
F F
G
Pull
ChangeRequests
Items in the backlog remain optional and unprioritized
dja@djaa.com, @agilemanager
Discard rates are often high
Backlog
H
E
C A
I
Engin-eeringReady
D
5Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
UAT
Deploy-mentReady
∞ ∞
FF
F F
G
ChangeRequests
H
Discarded
The discard rate with XIT was 48%. ~50% is commonly observed.
Options have value because the future is uncertain
0% discard rate implies there is no uncertainty about the future
I
Reject
Deferring commitment and avoiding interrupting
workers for estimates makes sense when
discard rates are high!
dja@djaa.com, @agilemanager
FF
FFF
F F
Specific delivery commitment may be deferred even later
UATBacklog
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
Pull
Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
2nd
Commitmentpoint*
Kanban uses
2 Phase Commit
∞
Discarded
I
We are now committing to a specific deployment and delivery
date
*This may happen earlier if circumstances demand it
dja@djaa.com, @agilemanager
FF
FFF
F F
Replenishment Cadence
UATBacklog
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
Replenishment
Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
∞
Discarded
I
The frequency of system replenishment should reflect
arrival rate of new information and the transaction &
coordination costs of holding a meeting
Pull
Frequent replenishment is more agile.
On-demand replenishment is most
agile!
dja@djaa.com, @agilemanager
FF
FFF
F F
Delivery Cadence
UATBacklog
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
DeliveryOngoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
∞
Discarded
I
The frequency of delivery should reflect the transaction &
coordination costs of deployment plus costs &
tolerance of customer to take delivery
Pull Deployment buffer size can reduce as frequency of delivery
increases
Frequent deployment is more agile.
On-demand deployment is most agile!
dja@djaa.com, @agilemanager
FF
FFF
F F
Defining Lead Time
UATBacklog
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
Pull
Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
∞
Lead Time
The clock starts ticking when we accept the customers order, not
when it is placed!
Until then customer orders are merely available optionsLead time (through
the kanban system) ends when the item
reaches the first ∞ queue.
This provides the correct result for Little’s Law and
visualization on a Cumulative Flow
DiagramDiscarded
I
dja@djaa.com, @agilemanager
Delivery Rate
Lead Time
WIP=
Mean Lead Time
Mean Delivery Rate
WIP
Backlog ReadyTo
Deploy
Little’s Law
dja@djaa.com, @agilemanager
Improving Agility
dja@djaa.com, @agilemanager
Factors Affecting Agility
The business agility of the system is determined by the replenishment cadence, the delivery cadence
and the lead time (or end-to-end cycle time) through the system.
Kanban decouples replenishment from lead time & delivery
enabling tailoring of the process to the dynamics of the business
domain
dja@djaa.com, @agilemanager
FF
FFF
F F
Benefits of Limiting WIP
UATBacklog
H E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
Pull
Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
∞
Lead Time
Discarded
I
#*
Blocked!
*Specialist test environment unavailable
Bug
Blocked!
Defect found requiring coding fix
Limiting WIP reduces multi-tasking. Shortens lead time. Focuses
organization on impediment removal and limits due date performance
degradation from poor quality & rework
dja@djaa.com, @agilemanager
Observe Lead Time Distribution as an enabler of a Probabilistic Approach to Management
Lead Time Distribution
0
0.5
1
1.5
2
2.5
3
3.5
Days
CR
s &
Bu
gs
SLA expectation of44 days with 85% on-time
Mean of 31 days
SLA expectation of105 days with 98 % on-time
This is multi-modal data!
The work is of two types: Change Requests (new
features); and Production Defects
This is multi-modal data!
The work is of two types: Change Requests (new
features); and Production Defects
dja@djaa.com, @agilemanager
Filter Lead Time data by Type of Work (and Class of Service) to get Single Modal Distributions
85% at10 days
Mean5 days
98% at25 days
Change R
equest
s
Pro
duct
ion D
efe
cts
85% at60 days
Mean 50 days
98% at150 days
dja@djaa.com, @agilemanager
Lead Time
Lead Time
Allocate Capacity to Types of Work
DoneBacklog
F
H
E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
GY
PBDE
MN
2 ∞
P1
AB
Separate understanding of Lead Time for each type of work
Ongoing
Development Testing
Done VerificationAcceptance3 3
ChangeRequest
s
Production
Defects
Separate understanding ofLead Time for each type of work
5
3
Consistent capacity allocation should bring some consistency to delivery rate of work of each type
Consistent capacity allocation should bring more consistency to delivery rate of work of each type
dja@djaa.com, @agilemanager
Flow Efficiency
Done
Poolof
Ideas
F
H E
C A
I
Engin-eeringReady
Deploy-mentReady
GD
GYPB
DEMN
2 ∞
P1
AB
Lead Time
Ongoing
Development Testing
Done VerificationAcceptance3 3
Flow efficiency measures the percentage of total lead time that is spent actually adding value (or knowledge) versus
waiting
Until then customer orders are merely available options
Waiting Waiting WaitingWorkingWorking
Flow efficiency = Work Time x 100%
Lead TimeFlow efficiencies of 2% have been reported*. 5% -> 15% is
normal, > 40% is good!
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
dja@djaa.com, @agilemanager
Short lead time reduces chance of discard
FF
FFF
F F
Benefits of Reducing Lead Time
UATBacklog
H E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
5∞
Pull
Ongoing
Development Testing
Done3 3
TestReady
5
PTCs
ChangeRequests
∞
Discarded
I
Bug
Bug
Bug
Defect insertion rate increases non-linearly with long lead times
and low flow efficiency.
Defect fix times increase non-linearly with delay time from
discovery to fix
Short lead times enable later commitment, reduce likelihood of post-commitment discard or rework due to perishable nature of information and improve quality as defect insertion
rates fall non-linearly with reduced lead time
dja@djaa.com, @agilemanager
More Results (from 2005)
Time (in quarters)
Flow
Effi
cien
cy (
%)
15
45
75
Flow efficiency improved from
8% to 92%
Time (in quarters)
Due D
ate
Perf
orm
ance
15
45
75 DPP improved almost instantly from 0% to
98% against lead time SLA*
* Measured from point of commitment
These improvements were minimally intrusive, met with little to no resistance
(though some managerial derision) and cost almost nothing!
If it works this well, perhaps we should try this
again?!!
dja@djaa.com, @agilemanager
Ability to handle variety and heterogeneity of risks improves business performance
The kanban system explicitly exposes the business risks in terms of types of demand, quantity & rate of demand. It helps us to understand the costs & benefits of frequent interaction with upstream &
downstream functions. And it gives us a temporary and quantitative understanding of our capability to
deliver against demand
Kanban enables us to build a trusted delivery capability. Agility
and predictability are tuned to the inherent risks in the business
domain!
dja@djaa.com, @agilemanager
Risk Management
dja@djaa.com, @agilemanager
The psychology of a probabilistic approach can be challenging…
Change R
equest
s
85% at60 days
Mean 50 days
98% at150 days
I don’t want to take the risk of being longer than 60 days. I need a precise estimate of when it will
be delivered!
dja@djaa.com, @agilemanager
Cost of Delay is a critical business risk
time
impa
ct
time
time
time
impa
ctim
pact
impa
ct
time
impa
ct
time
impa
ctim
pact
Expedite – critical and immediate cost of delay; can exceed other kanban limit (bumps other work)
Fixed date – cost of delay goes up significantly after deadline; Start early enough & dynamically prioritize to insure on-time delivery
Standard - cost of delay is shallow but accelerates before leveling out; provide a reasonable lead-time expectation
Intangible – cost of delay may be significant but is not incurred until much later; important but not urgent
time
Qualitative approaches to risk management using taxonomies of 2 to 6 categories for
each dimension of risk have been shown to fast, cheap & effective in comparison to quantitative methods that often involve
speculation and false precision
dja@djaa.com, @agilemanager
Implementing Classes of Service
Done
FH
E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
2 ∞
P1
Ongoing
Development Testing
Done VerificationAcceptance3 3
Expedite 1
3
Fixed Date
Standard
Intangible
2
1
Different distributions for different classes of service increases the level of trust that an item will be
delivered in a timely manner, demonstrating that cost of delay is
a risk under management
dja@djaa.com, @agilemanager
The Optimal Exercise Point
impa
ct
When we need it
85th percentile
Ideal StartHere
Commitment point
If we start too early, we forgo the option and opportunity to do something else that may
provide value.
If we start too late we risk incurring the cost of delay
With a 6 in 7 chance of on-time delivery, we can always
expedite to insure on-time delivery
dja@djaa.com, @agilemanager
Hedge Delivery Risk by spreading capacity across items of differing urgency
Done
FH
E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
2 ∞Ongoing
Development Testing
Done VerificationAcceptance3 3
Expedite 1
3
Fixed Date
Standard
Intangible
2
3
Uncertainty in demand or arrival rate of urgent & critical items is offset with capacity for items that are easily delayed
dja@djaa.com, @agilemanager
Kanban improves risk management
Kanban systems should be designed to visualize the true business risks under
management.
Demand can be classified for multiple risks & analyzed for
arrival rate
Risk is a multidimensional problem.
Kanban enables many strategies for managing it, including hedging & aspects of real option theory eg deferred commitment, optimal
exercise point decision making; & system liquidity management.
dja@djaa.com, @agilemanager
Cost of Delay has a 2nd Dimension
time
impa
ct
time
impa
ct
time
impa
ctim
pact
Extinction Level Event – a short delay will completely deplete the working capital of the business
Major Capital – the cost of delay is such that a major initiative or project will be lost from next year’s portfolio or additional capital will need to be raised to fund it
Discretionary Spending – departmental budgets may be cut as a result or our business misses its profit forecasts
Intangible – delay causes embarrassment, loss of political capital, affects brand equity, mindshare, customer confidence, etc
time
?
Working capital
Working capital
dja@djaa.com, @agilemanager
Market Risk of Change
Mark
et
Ris
k
Sch
ed
ulin
g
Highly likely to change
Highly unlikely to
change
StartEarly
StartLate
Differentiators
Spoilers
Table Stakes
Cost Reducers
Potential Value
ProfitsMarket Share
etc
RegulatoryChanges
dja@djaa.com, @agilemanager
Aligning with Strategic Position or Go-to-Market Strategy
Done
F
H
E
C
A
I
Engin-eeringReady
Deploy-mentReady
G
D
2 ∞Ongoing
Development Testing
Done VerificationAcceptance3 3
Table Stakes 3
1
Cost Reducer
s
Spoilers
Differentiators
2
1
Market segmentation can be used to narrow the necessary table stakes for any given market niche!
Enabling early delivery for narrower markets but potentially including value generating
differentiating features
dja@djaa.com, @agilemanager
Product Lifecycle Risk
Pro
du
ct
Ris
k
Investm
en
t
Not well understoodHigh demand for innovation &
experimentation
Well understoodLow demand for
innovation
Low
Low
Innovative/New
Major Growth Market
Cash Cow
ProfitMargin
High
Low
High
dja@djaa.com, @agilemanager
ACash Cows10% budget
Growth Markets60% budget
Innovative/New30% budget
Allocation of personnelTotal = 100%
B
D
E
F
K
H
G
Projects-in-progress
Horizational position shows percentage complete
Complete0%
Complete100%
C
Color may indicate cost of delay (or other risk)
Hedging Risk in a Portfolio Kanban
dja@djaa.com, @agilemanager
Visualize Risks to provide Scheduling Information
TS
Market Risk
CR
Spoil
Diff
Lifecycle
Cost of Delay
Tech Risk
Delay Impact
CowMid
New
Expedite
FDStd
Intangible
ELE
Maj. Cap.
Disc
Unknown SolnKnown but not us
Done it beforeCommodity
Risk profile for a work item or deliverable
Outside:Start Early
Inside:Start Late
Items with the same shape carry the same risks and should be scheduled into the kanban system
at approximately the same time.
Do not prioritize items. From a group of items with the same risk profile pick whichever ones you like
or prefer most
It is also wise to hedge risk by allocating capacity in the system for items of different risk profiles.
dja@djaa.com, @agilemanager
Table Stakes 3
1
Cost Reducer
s
Spoilers
Differentiators
2
1
Improving Liquidity through Labor Pool Flexibility
Teams
F
HE
CA
Engin-eeringReady
G
D
GY
PBDE
MN
2
P1
AB
Ongoing
Analysis Testing
Done VerificationAcceptance3 3Ongoing
Development
Done3
Joe
Peter
Steven
Joann
David
Rhonda
Brian
Ashok
TeamLead
Junior who will be rotated through all 4 teams
Generalist or T-shaped people who can move flexibly across rows on the board to keep work
flowing
It’s typical to see splits of fixed team workers versus flexible system
workers of between 40-60%
Roughly half the labor pool are flexible workers
Promotions from junior team member to flexible
worker with an avatar clearly visualize why a
pay rise is justified. Flexible workers help manage liquidity risk
better!
dja@djaa.com, @agilemanager
Risk is a multi-dimensional contextual problem
These are just useful examples!
We must develop a set of risk taxonomies that work in context
for a specific business.
We can easily envisage other risk dimensions such as technical risk, vendor dependency risk, organizational maturity risk and so forth.
It may be necessary to run a workshop with stakeholders to explore and expose the real
business risks requiring management
dja@djaa.com, @agilemanager
Coping with Larger Deliverables
dja@djaa.com, @agilemanager
Cost of Delay attaches to a deliverable
So understanding cost of delay enables us to know what to pull
next?
Yes, however, it isn’t always relevant! Cost of delay attaches to a deliverable item. What if that
item is large? Whole projects, minimum marketable features (MMFs) or minimum viable products (MVPs) consist of many smaller items.
We need to understand the risks in those smaller items too, if we are to know how to schedule work,
replenish our system and make pull decisions wisely
dja@djaa.com, @agilemanager
Make a long term plan to build platform replacement
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Fe
atu
res
Inventory Started Designed Coded Complete
Slope in middle3.5x - 5x slope
at ends 5x
Required throughput (velocity)
2006 2008
During the middle 60% of the project schedule we need Throughput (velocity) to average 220 features
per month
dja@djaa.com, @agilemanager
Delivery Rate
Lead Time
WIP=
Little’s Law
From observed capability
Treat as a fixed variable
Targetto
achieve plan
Calculated based on known lead time
capability & required delivery
rate
Determines staffing level
Changing the WIP limit without maintaining the staffing level ratio represents a change to the way of
working. It is a change to the process and will produce a change in the observed ‘common cause’
capability of the system
Plan based on currently observed capability and current working
practices. Do not assume process improvements.
If changing WIP to reduce undesirable effects (e.g.
multitasking), get new sample data (perform a spike) to observe
the new capability
dja@djaa.com, @agilemanager
55/week
0.4 weeks
WIP = 22=
Using Little’s Law
From observed capability
Treat as a fixed variable
Targetto
achieve plan
Calculated based on known lead time
capability & required delivery
rate
Determines staffing level
At this point perhaps just a little black magic and experience may
be required.
Rounding 22 up to 25 would conveniently provide for 5 teams with a WIP limit of 5 items each
If our current working practices/process exhibited an
average WIP of 1 item per person then we require 25 people
organized in 5 teams of 5 people to complete the project on-time
dja@djaa.com, @agilemanager
1 lane per team
dja@djaa.com, @agilemanager
Lead time
WIP in this area should be 25
items*
*photo taken early in the project
before it was fully staffed/loaded
Median lead time target is 2 days
Alert managers if beyond 5 days
dja@djaa.com, @agilemanager
Definition of TheKanban Management Method
dja@djaa.com, @agilemanager
Kanban creates an evolutionary capability within your organization
Kanban systems have been shown to catalyze process evolution.
It is thought that the WIP limit provokes conversations &
encourages collaboration around changes
Kanban is a cultural & management approach to organizational
improvement founded on 4 principles
1. Start with what you do now2. Agree to pursue evolutionary change
3. Initially respect current roles, responsibilities & job titles
4. Encourage acts of leadership at all levels in your organization
dja@djaa.com, @agilemanager
Evolutionary capability protects a business from an uncertain future
An evolutionary capability is vital to coping with complexity and manage
the risk of “unknown unknowns.”
Kanban creates evolutionary capability through the use of 6
practices
Core Practices of the Kanban Method
1. Visualize2. Limit WIP
3. Manage Flow4. Make Policies Explicit
5. Create feedback loops (at workflow, management & organizational
levels)
6. Improve collaboratively, evolve experimentally (using models & the
scientific method)
dja@djaa.com, @agilemanager
Better Governance
dja@djaa.com, @agilemanager
Key Risk to Manage is “What to Pull Next?”
Done
Poolof
Ideas
F
H
E
CA
I
Engin-eeringReady
Deploy-mentReady
G
D
4 ∞Ongoing
Development Testing
Done VerificationAcceptance3 3
J
L
KI have 4 options, which one
should I choose?
Pull
∞
Pull
SystemReplenishment
PullSelection
Replenishing the system is an act of commitment – selecting items for delivery. Committing to the
cost to convert from options into real value.
Pull Selection is choosing from immediate options – an act of dynamic prioritization of the item with
the most immediate risk attached to it
dja@djaa.com, @agilemanager
Continuous Improvement
dja@djaa.com, @agilemanager
Team-level Kaizen events happen naturally
dja@djaa.com, @agilemanager
Operations reviews drive inter-team kaizen events
dja@djaa.com, @agilemanager
The 5 Benefits of Kanban
Kanban is a “many-headed-hydra.” It helps us deal with simple, complicated
& complex problems
The wide utility of Kanban makes it broadly applicable in many
domains
Benefits of Using Kanban
1. Improved Predictability2. Better Business Agility
3. Better Governance4. Improved Risk
Management5. Evolutionary Capability
for resilience in the face of uncertainty
dja@djaa.com, @agilemanager
Conclusions
dja@djaa.com, @agilemanager
Kanban systems control variability that affect predictability
Kanban systems defer commitments improving quality of decision making and reducing unnecessary work and
rework.
Predictability is improved!
Committing early is comforting but can lead to disappointment later.
Kanban builds trust enabling deferred
commitment
dja@djaa.com, @agilemanager
Kanban enables improved agility
Replenishment & delivery cadences are de-coupled and can be tuned to
information arrival and overhead of the transaction.
Lead time can be independent of replenishment & delivery cadence!
Industries such as media require the decoupled dynamics of kanban to
react to unfolding events
dja@djaa.com, @agilemanager
Kanban Improves Governance
Visualization of the kanban system and explicit declaration of policies improves
transparency on risk management
There is no crystal ball gazing! Risk analysis is not speculative!
Kanban systems can be designed to align directly with strategic plans & go-
to-market strategies
dja@djaa.com, @agilemanager
Thank you!
dja@djaa.com, @agilemanager
About
David Anderson is a thought leader in managing effective software teams. He leads a consulting, training and publishing and event planning business dedicated to developing, promoting and implementing sustainable evolutionary approaches for management of knowledge workers.He has 30 years experience in the high technology industry starting with computer games in the early 1980’s. He has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint and Motorola.
David is the pioneer of the Kanban Method an agile and evolutionary approach to change. His latest book published in June 2012 is, Lessons in Agile Management – On the Road to Kanban.
David is a founder of the Lean-Kanban University Inc., a business dedicated to assuring quality of training in Lean and Kanban for knowledge workers throughout the world.
dja@djaa.com, @agilemanager
Acknowledgements
A virtual kanban system was first used with an offshore team within Microsoft’s IT department in 2004/2005. The Kanban Method as it is known today emerged at Corbis 2006/2007.
Adoption of cumulative flow diagrams, Little’s Law, virtual kanban systems & cost of delay were heavily influenced by Donald Reinertsen.
Major contributors to the material in this presentation include Daniel Vacanti, Jim Benson, Corey Ladas, Janice Linden-Reed, Troy Magennis, Chris Matts, Olav Maassen and Julian Everett
dja@djaa.com, @agilemanager
David J Anderson& Associates, Inc.
dja@djaa.com, @agilemanager
Appendix
dja@djaa.com, @agilemanager
Example Distributions
Sta
ndardE
xpedit
e
Inta
ngib
le
Fixe
d D
ate
dja@djaa.com, @agilemanager
Recommended