This two-part interactive workshop begins with a detailed look at how to interpret Kanban boards and ask thoughtful questions so that you can improve the work of your teams. We will provide an overview of the Kanban Method and then proceed through a series of several short exercises that will give you an opportunity to review and interpret various Kanban board configurations with other attendees at your table.
After a short break, part two of the session now puts the attendees in the driver’s seat to create their own board configurations. We provide several business scenario exercises and ask the attendees how they would go about configuring their Kanban board given the unique system constraints for each scenario.
2. Kanban System Design in Context: Mark Grove & Craeg Strong
• CTO @ Ariel Partners
• 20+ years IT profession
• Accredited Kanban Trainer (AKT)
• ITIL, DevOps, CEH, and spicy food
Craeg StrongMark Grove
• Management Consultant @ Excella Consulting
• 20+ years IT profession
• Accredited Kanban Trainer (AKT)
• Amateur photographer and astronomer
3. Kanban System Design in Context: Mark Grove & Craeg Strong
Get to Know Each Other (5 minutes)
At your table introduce:
• Your name and your current role
• The industry in which you work
• Your level of Kanban proficiency
• Where you are currently using Kanban or
where you imagine you could use it
Identify a spokesperson for the table
When called upon, tell us how your
table is represented
4. Kanban System Design in Context: Mark Grove & Craeg Strong
Kanban System Design
in Context
Observing Flow
5. Kanban System Design in Context: Mark Grove & Craeg Strong
Imagine you were hired to provide consulting assistance for a
new team just starting with Kanban. The team has been
struggling and is looking forward to your expert guidance,
support, and advice.
It’s your first day and you just walked into the team room to look
at their physical board. You want to make smart observations and
thoughtful interpretations so you can have meaningful
conversations. The team starts assembling for the daily standup
and you plan on making some comments afterwards.
What comments would you make?
As you review each board, consider the following questions to
help you think through your comments to the team (Note: each
new board can be treated independently of the others).
• What are you observing?
• Why might that be happening?
• What questions would you ask of the team to learn more?
Kanban System Design in Context:
Scenario Background
6. Kanban System Design in Context: Mark Grove & Craeg Strong
To Do Analysis Development Test Done
7. Kanban System Design in Context: Mark Grove & Craeg Strong
Backlog Discovery Implementation Verify Done
Doing Done Doing Done
JP
JP
JP
JP
KMKM
KM
MK
PC
JP
AB
JP DP
CS
CSMK
CW
CW
JP
JP
CW
JP
PC
8. Kanban System Design in Context: Mark Grove & Craeg Strong
To Do Discovery (3) Implementation (2) Verify (2) Done
Doing Done DoneDoing
9. Kanban System Design in Context: Mark Grove & Craeg Strong
Insurance
Application
Received
Risk
Review
[External Rate
Team]
Prices Risk
Issue
Quote
Issue
Binder
Issue
Policy
Igor
Mary
Priyanka
Progress
Towards
Monthly Goal
10. Kanban System Design in Context: Mark Grove & Craeg Strong
Ready Discovery (3) Implementation (2) Verify (2) Done
Doing Done DoneDoing
Blocked
(6)
11. Kanban System Design in Context: Mark Grove & Craeg Strong
To Do Discovery
(2)
Implementation
(3)
Verify
(3)
DoneReady
(3)
Notify
(2)
X
X
XDiscovery
Implementation
Verify
Notify
Req. Done
X
XDiscovery
Implementation
Verify
Notify
Req. Done
X
Discovery
Implementation
Verify
Notify
Req. Done
X X
X
X X
Implementation
Discovery
Verify
Notify
Req. Done
X
X
X X
Implementation
Discovery
Verify
Notify
Req. Done
X X
X
Implementation
Discovery
Verify
Notify
Req. Done
X
X X
Implementation
Discovery
Verify
Notify
Req. Done
X X
X
X X
Implementation
Discovery
Verify
Notify
Req. Done
X X
X X
Implementation
Discovery
Verify
Notify
Req. Done
12. Kanban System Design in Context: Mark Grove & Craeg Strong
To Do
Discovery
(2)
Implementation
(3)
Verify
(3) Done
Ready
(5)
Doing Done Doing Done
13. Kanban System Design in Context: Mark Grove & Craeg Strong
Creating Flow
Kanban System Design
in Context
14. Kanban System Design in Context: Mark Grove & Craeg Strong
Innovation Team
You are working with an innovation team
They want to ensure they are always working on a pool of ideas
because many are discarded over the course of the workflow:
• Ready
• Hypothesize
• Refine
• Explore
• Validate
• Done
How would you visualize this?
How would you help them ensure they are always working on
enough things?
15. Kanban System Design in Context: Mark Grove & Craeg Strong
Ready Hypothesize Refine Explore
Doing Done DoneDoing DoneDoing
Validate Done
Discarded
(7 - 10) (4 - 7) (1 - 4) (4)(8 - ∞)
16. Kanban System Design in Context: Mark Grove & Craeg Strong
Business Development Team
A government business development team is tracking
the flow of new business opportunities through the
pipeline:
1. Unqualified Opportunity
2. Qualified Opportunity
3. Pursue the Opportunity
4. In Development
5. Submitted
6. Won / Lost
They want to keep the pipeline full enough to ensure
they have enough sales to meet their targets.
How will we ensure we keep the pipeline full enough?
How could you visualize reasons for losses on the board?
They also want to highlight their recent losses so
they can learn what went wrong. There is usually
more than one reason for each loss. We want to
visualize the reasons so we know where to focus
our improvement efforts.
In order to ensure we have at least 3 wins during
each quarter, we will need at least 20
Opportunities, however, we can’t effectively
execute pursuit on more than 10 opportunities at
once. The team indicates they can’t develop more
than 3 opportunity proposals at a time.
17. Kanban System Design in Context: Mark Grove & Craeg Strong
Unqualified
Opportunity
In
Development
Submitted
Wins this Quarter
Pursuit
(20- 40) (3)
Qualified
Opportunity
Recent Losses
(5 - 10)
Top Reasons For
Losses
$
$
$
$
(10- 20)
18. Kanban System Design in Context: Mark Grove & Craeg Strong
Setting Initial WIP Limits
A team wants to start using WIP limits and is looking for guidance. They have told you, on average,
they feel they complete about five items per week. They also mentioned they meet with business
stakeholders weekly to discuss new items to work on.
What board suggestions might you introduce? Why?
What WIP limit suggestions would you suggest experimenting with? Why?
What other guidance would you give about WIP limits new to a team?
This is their current board.
The seven person team thinks things will improve if:
• The five Developers can experiment with pair
programming
• The two Testers can work on Test items even when
one item is blocked and cannot be worked on
You also learn some items in Develop are Done.
Options Develop Test Done
19. Kanban System Design in Context: Mark Grove & Craeg Strong
Options
Ready Develop
TestDoneDoing Done
Remember: we need to manage and measure flow!
Since they complete five items per week
and they meet weekly with the business,
we may want to experiment with a WIP
limit of five here, thus not committing to
more work that they can finish each week.
To encourage pairing,
experimenting with a WIP
limit smaller than the number
of developers may be helpful.
To allow testers to continue to
work even if one item is
blocked, you may experiment
with setting a WIP limit greater
than the number of testers.
(5)
(3)
(3)
20. Kanban System Design in Context: Mark Grove & Craeg Strong
Working With Dependencies & Handoffs*With Thanks to Ian Carroll!
An HR team has the following types of work:
1. Recruitment
2. Onboarding/offboarding employees
3. Training & Career development
4. Administering Benefits
When a given item is in progress, it could have any
of these dependencies:
1. IT
2. Facilities
3. Legal
4. Finance
Each of those teams has their own Kanban board,
but we still want to represent dependencies on our
board, and know whether a dependency is in
progress or done.
A given item may have multiple dependencies, all
proceeding at the same time. Once our work
plus all of the dependencies are done, we can move
a work item to done.
How can we visualize our work in progress alongside the four other teams we work with?
How could we identify and visualize the next set of work items to work on, while ensuring we address all 4 work
types?
How can we track the pieces being done by different dependencies so that we know what is remaining?
21. Kanban System Design in Context: Mark Grove & Craeg Strong
To Do
(4)
Recruitment
Onboarding /
Offboarding
Next
Training & Career
Development
Administering
Benefits
DONE
a
DoneDoing
(4)
A
d
a
IT Facilities Legal Finance
b b
db
CB D
d
a
22. Kanban System Design in Context: Mark Grove & Craeg Strong
Research Team
You’re working for a research team that
gradually refines and improves the items
that they work on; they have just four
basic steps in their workflow:
• Options
• Ready
• In Progress
• Done (Ready for Production)
The “In Progress” step involves a lot of work;
ideas move along two dimensions:
• They become progressively more refined
(fewer open questions)
• They also become more production-ready (the
associated processes become better known)
They believe that those two dimensions are
important to model and that neither one has a
well-defined sequence of steps.
How would you go about helping them visualize their work?
How would you help them introduce WIP limits?
23. Kanban System Design in Context: Mark Grove & Craeg Strong
Options Ready In Progress Done
MoreRefined
More Production Ready
(3)(3)
24. Kanban System Design in Context: Mark Grove & Craeg Strong
Options Ready In Progress Done
MoreRefined
More Production Ready
(3)(3)
25. Kanban System Design in Context: Mark Grove & Craeg Strong
One Team, Three Work Types
A sales team has identified three work types as part of its sales pipeline: Cold Calls, Referrals,
and Existing Clients.
Cold calls and Referrals are first vetted for suitability before the sales team commits to pursuing
them. Existing Clients do not need this vetting.
The downstream workflow is (Initial Contact, Proposal, Client Negotiation, Completed)
The sales team is interested in visualizing its pipeline wins or losses once the work is completed.
How would you visualize the upstream vetting process?
How would you visualize the downstream flow for the three work types?
What about their desire to visually see wins vs. losses?
Though not explicitly discussed above, how might you envision using WIP limits?
26. Kanban System Design in Context: Mark Grove & Craeg Strong
Sales
Lead
Options
Vetting Proposal
(2)
Completed
Doing Ready DoingDoing Done Done
Work
Type
Cold
Calls
Referrals
Existing
(≥1)
(3)
(4)
Discard
Win Loss
Initial
Contact
(2)
Client
Negotiation
(2)
27. Kanban System Design in Context: Mark Grove & Craeg Strong
IT Portfolio Management*With Thanks to Pawel Brodzinski!
You are working with a CIO of an organization who needs
to manage a portfolio of 8 projects across 4 teams.
• The Teams are “Team A” through “Team D.”
• The Projects are “Alpha” through “Theta”
Projects are either Strategic or Tactical.
During a given calendar quarter, a Team can work on:
• three small projects,
• one large project, or
• one medium + one small project at a time.
How might you go about helping the CIO visualize his portfolio over the next 4 quarters?
Project
Alpha
Project
Beta
Project
Gamma
Project
Delta
Project
Epsilon
Project
Zeta
Project
Eta
Project
Theta
Tactical or
Strategic
Strategic Tactical Tactical Tactical Strategic Strategic Tactical Tactical
S / M / L Small Medium Small Medium Large Medium Small Small
Team Team A Team A Team B Team B Team C Team D Team D Team D
Start Q1 Q1 Q2 Q1 Q1 ½ way thru Q1 Q1 Q1
Projected
Finish
Q4+ ½ way thru Q2 Q4+ Q3 Q4 Q4 Q1 Q2
28. Kanban System Design in Context: Mark Grove & Craeg Strong
Q1
Team
A Beta
Eta
Strategic
Tactical
Q2 Q3 Q4
Team
B
Team
C
Team
D
GammaGammaGamma
Epsilon
ZetaZetaZeta
Zeta
Theta Theta
DeltaDeltaDelta
Alpha
EpsilonEpsilonEpsilon
Alpha Alpha Alpha
Beta
29. Kanban System Design in Context: Mark Grove & Craeg Strong
Creating Flow
Questions?
30. Kanban System Design in Context: Mark Grove & Craeg Strong
Thank You!
Kanban System Design in Context