A central component of Kanban is to make invisible knowledge work visible. However, you will notice quite often that you very often cannot work, but are blocked. Waiting for the test environment, requirements unclear, or missing customer information are only a small part of blockages that prevent us from continuing to work. These blockages are in most cases not a singular event, but have a systemic cause. In other words, it is very unlikely that a blockage occurs only once in the history of a company. Normally the same blockage occurs again and again.
What can one do about it? Jumping out of the window in despair would be a possible approach. Another idea would be to see the blockages for what they are: Treasures of improvements. In this session, we show you how to harvest these treasures and to improve sustainably your working system. In addition, we will present a model that shows with the help of a few simple number games, which blockages need to be removed to achieve the greatest possible leverage.
Try MyIntelliAccount Cloud Accounting Software As A Service Solution Risk Fre...
Blocker Clustering reloaded (V2)
1. Dr. Klaus Leopold
web: www.LEANability.com
blog: www.klausleopold.com
mail: klaus.leopold@LEANability.com
twitter: @klausleopold
Blockers - Treasures of Improvement
Lean Kanban North Amerika - LKNA15, June 9, 2015, Miami Beach, FL
6. @klausleopold www.LEANability.com
others
test env.
not ready
reviewer X
not available
47 days
11 days
32 days
waiting for
backend
87
days
content
missing
waiting for
UX
109 days
22 days
no pictures
customer A
waiting for texts
customer B
missing pictures
customer D
UX for app x
not ready
waiting for backend
backend not ready
no test environment
cluster blockers
7. @klausleopold www.LEANability.com
content
missing
109 days
?- WHY is content missing?
!- The customers don’t send it.
?- WHY don’t they send it?
!- Often they don’t know what we need.
?- WHY don’t they know what we need?!- We don’t tell them always.
—> Maybe it’d be smart to tell them ALWAYS…
Add an item to the Definition of Done checklist in
the ANALYSIS activity:
—> INFORM CUSTOMER ABOUT CONTENT DELIVERIES
understand problem
find solution
9. (3)
ANALYZE
IN PROG. DONE IN PROG. DONE
(3)
DEVELOP
(3)
TEST
(6)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(∞)
Features —>
Rework —>
payment
module
payment
module payment
user
profile
search
A large percentage ofSUPPORT REQUESTSis actually rework!
REWORK and SUPPORT
are blocking you from
doing valuable stuff!
11. (3)
ANALYZE
IN PROG. DONE IN PROG. DONE
(3)
DEVELOP
(3)
TEST
(6)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(∞)
Features —>
Rework —>
defect!
12. (3)
ANALYZE
IN PROG. DONE IN PROG. DONE
(3)
DEVELOP
(3)
TEST
(6)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(∞)
Features —>
defect!
don’t allow
return traffic
BUG FIXING IS
NO NEW WORK
Rework —>
13. (3)
ANALYZE
IN PROG. DONE IN PROG. DONE
(3)
DEVELOP
(3)
TEST
(6)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(∞)
Features —>
DEFECTS ARE BLOCKERS!
Rework —>
16. @klausleopold www.LEANability.com
?- WHY are we blocked by UAT?
!- Customers are not satisfied with
what we deliver.
?- WHY aren’t they satisfied?
!- There’s a mismatch on what they
want and what we deliver.
?- WHY is this mismatch?
!- …
UNDERSTAND THE PROBLEM
FIND A SOLUTION
-introduce review activity after analysis
-participants: customer, BAs, DEVs & Testers
UAT not
passed
92 days
17. @klausleopold www.LEANability.com
what’s worth
collecting & analyzing?
BLOCKERS
- anything that prevents flow of work items
BUGS & DEFECTS
- anything you have to spend additional effort on
because of bad quality (bugs, defects, etc.)
CONSCIOUS POLICY VIOLATIONS
- write the reason of the violation on a sticky
and attach it to the work item
- collect & cluster policy violations
- understand & improve
REWORK & SUPPORT REQUESTS
- defects in the live environment
- queries from customers
18. @klausleopold www.LEANability.com
We’re often fooled by biases…
-The ones with the highest delay
-The ones “we” own – because we’re in control
-The simple ones – because we want to see quick results
-The most recent ones – they’re fresh in memory
-…
What cluster should you solve first?
test env.
not ready
reviewer X
not available
47 days
11 days
waiting for
backend
87
days
content
missing
waiting for
UX
109 days
22 days
UAT not
passed
92 days
19. @klausleopold www.LEANability.com
1. Fix clusters that constrain the system
content
missing
109 days
test env.
not ready
47 days
waiting for
UX 22 days
Text and photos
for reservation
page missing
(Customer X)
[DEV]
ACTIVITY
(4)
ANALYZE
IN PROG. DONE IN PROG. DONE
(4)
DEVELOP
(4)
TEST
(4)
DEV READY
VERIF. UAT
READY TO
DEPLOY
(∞)
20. @klausleopold www.LEANability.com
1. Fix clusters that constrain the system
(4)
ANALYZE
IN PROG. DONE IN PROG. DONE
(4)
DEVELOP
(4)
TEST
(4)
DEV READY
VERIF. UAT
READY TO
DEPLOY
(∞)
content
missingwaiting for
UX
test env.
not ready
109 days 47 days
22 days
21. @klausleopold www.LEANability.com
(4)
ANALYZE
IN PROG. DONE IN PROG. DONE
(4)
DEVELOP
(4)
TEST
(4)
DEV READY
VERIF. UAT
READY TO
DEPLOY
(∞)
content
missingwaiting for
UX
test env.
not ready
109 days 47 days
22 days
1. Fix clusters that constrain the system
22. @klausleopold www.LEANability.com
hard to solve
moderate
easy to solve
lowmediumhigh
time blocked
solvability
3
1 2
4
5 6
7
8
9
2. Weight resolution effort
against blocker impact
content
missing
109 days
solution: DoD-Item to
inform customer about
content
waiting for
backend
87
days
solution: merge/restructure
back-end and front-end teams
reviewer X
not available
11 days
solution: talk to reviewer X
and find a solution with him
24. @klausleopold www.LEANability.com
(3)
ANALYZE
(2)
DEVELOP
(2)
TEST
(4)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(3)
REVIEW
Is it economically
meaningful to
implement solution?
LET’S THINK ABOUT IT…
- additional review increases lead time for all work items
* higher lead time —> worse TTM & pot. higher CoD
- lower lead times for items with potential defects
* lower lead times —> improved TTM & less CoD
- less effort for defect fixing
- …
28. @klausleopold www.LEANability.com
BLOCKER HANDLING
- collect & cluster blockers
- understand problem
- find solution
- evaluate clusters
* think about constraints
* weight effort against impact
* economics is your friend
29. @klausleopold www.LEANability.com
performance
time
CADENCE
- trade-off: quantity of blockers vs.
narrow time frame
- 4-weekly cadence is a good start
- adapt cadence to your needs
MEETING FORMAT
- Use established improvement meetings for it
- participants:
* on team level - the team
* on higher flight levels, multi-tier systems -
work with delegates
WHAT ELSE TO CONSIDER?
fucked-up
performance
time
j-curve
30. (2)
ANALYZE
IN PROG. DONE IN PROG. DONE
(2)
DEVELOP
(2)
TEST
(3)
DEV READY
VERIF. ACC.
READY 2
DEPLOY
(∞)
DEV-WORK —>
IMPROVEMENTS —>
(2)
PREPARE
(1)
REALIZE
(2)
VALIDATE
IN PROG. DONE IN PROG. DONE
SUCCESS
FAILED
(1)
READY
31. order at http://bit.ly/kcl-wiley
25% off promo code VBJ24
Thanks to Troy Magennis for working with me on this topic!
“Using Blocker Clustering, Defect Clustering, and Prioritization for Process Improvement”,
Klaus Leopold and Troy Magennis, InfoQ, http://bit.ly/InfoQblocker