Holy Land Kanban
Uploaded by
Tiago de Souza BarbosaHoly Land Kanban
Uploaded by
Tiago de Souza BarbosaHoly Land Kanban
Best of the Agile/Kanban Blog from Israel
©2012
Last published on 2012-02-27
is is a Leanpub book, for sale at:
http://leanpub.com/holylandkanbanbestof
Leanpub helps authors to self-publish in-progress ebooks. We
call this idea Lean Publishing. To learn more about Lean
Publishing, go to: http://leanpub.com/manifesto
To learn more about Leanpub, go to: http://leanpub.com
Contents
0.1 Anowledgments . . . . . . . . . . . . . . . . 1
1 Kanban - Beyond the Basics 2
1.1 Collaborating with specialized roles using kan-
ban classes of service . . . . . . . . . . . . . . . 3
1.2 Encouraging Feature-level progress traing in
Kanban . . . . . . . . . . . . . . . . . . . . . . 6
1.3 How I would simulate time-boxed agile in the
@getkanban kanban board game . . . . . . . . 12
1.4 Kanban early warning using a predictive variant
of SPC . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Lean/Kanban approa to Teams . . . . . . . . 22
1.6 Linking Team Modes to RightShiing . . . . . . 29
1.7 MMF driven sprints in a Kanban world . . . . . 32
1.8 My thoughts on how Kanban and TOC Critical
Chain relate . . . . . . . . . . . . . . . . . . . 36
1.9 Paerns for geing to a lower WIP level in a
system – e Freeze, No New Work, Limit Later,
and some Mashups… . . . . . . . . . . . . . . . 43
1.10 e Agile Lowest Common Denominator – Avoid-
ing a slowdown due to the weakest link . . . . 47
1.11 Touing your electronic kanban board . . . . . 51
i
CONTENTS ii
2 Agility at Large 56
2.1 Fair Process and Agile – going further than the
Scrum Team . . . . . . . . . . . . . . . . . . . 57
2.2 Driving Motivation – an exercise for under-
standing the Daniel Pink’s Drive model . . . . 60
2.3 How does the performance objectives process
ange in a Lean/Agile world? . . . . . . . . . 63
2.4 If productivity experts tell me to keep email
closed most of the day – why shouldn’t I avoid
looking at defects for most of the release? . . . 66
2.5 Punctuated Equilibriums, Containers, all things
Complexity and how Kanban fits in . . . . . . . 71
2.6 e Ant and the Grasshopper – Application for
product development . . . . . . . . . . . . . . . 79
2.7 oughts about the Toyota Kata in the world of
Knowledge/Tenology work . . . . . . . . . . 81
2.8 “We are already Lean/Agile” – Really? . . . . . 91
2.9 Why I think Sla is highly important during an
Agile/Kanban transition . . . . . . . . . . . . . 95
2.10 Using Kanban to drive Continuous Improve-
ment and Management Teams . . . . . . . . . . 99
2.11 Want to experience agile in an accelerated form
and focus on innovation at the same time? Try
an agile FedEx day! . . . . . . . . . . . . . . . 102
CONTENTS iii
3 Kanban - Not Just for Soware Development 108
3.1 Kanban in HR . . . . . . . . . . . . . . . . . . 109
3.2 Using Kanban to improve audit management . 116
4 Kanban thinking in Scrum Land 125
4.1 Want my elevator-pit answer to what is Kan-
ban for a Scrum rookie? . . . . . . . . . . . . . 126
4.2 Scrumban when will this be done . . . . . . . . 128
4.3 Scrum Sprint Commitment Rant . . . . . . . . 130
5 Focus on Testing Aspects 140
5.1 So what is the right ratio between developers
and testers? . . . . . . . . . . . . . . . . . . . . 141
5.2 Finding the right Dev to Test Ratio when work-
ing in Kanban . . . . . . . . . . . . . . . . . . 144
5.3 QA Effort Effectiveness . . . . . . . . . . . . . 149
6 Lean/Agile in the Holy Land 153
6.1 Israeli Culture and the Evolutionary Revolution 154
CONTENTS 1
0.1 Acknowledgments
I’d like to thank all my blog readers and commenters who
provided me with feedba and kept me going, my colleagues in
AgileSparks who provide me with the sandbox to try my crazy
ideas and my family - especially my wife and kids who bear up
with the time spent on writing and thinking.
1
Kanban - Beyond the
Basics
2
Kanban - Beyond the Basics 3
1.1 Collaborating with specialized roles
using kanban classes of service
I want to share a solution I came up with together with a team
of performance / non-functional testing, working in a product
group in a large enterprise. is solution deals with the allenge
of bridging the principles of “ose who build the system test
it”, “Non functional testing is a collaboration role”, and the fact
that specialized roles su as performance testers are usually
streted to cover the demand for their services.
is group wanted Performance testing for the product of course.
What usually happened though is that the performance team
only got usable features towards the end of the release (think
waterfall like behaviour). is usually meant serious waivers
and compromises around performance testing.
e first step taken by the product group was to work more on
effectively breaking the features into smaller viable features and
stories. Once this was done, it was easier for the performance
testing team to get involved throughout the version, and aieve
a more reasonable flow.
ings should have been great by now.
BUT then another problem surfaced, even while we were dis-
cussing how this would work.
It was clear that the capacity of the performance testing team
wasn’t sufficient to really address everything.
e naive policy meant that when a feature arrived at perfor-
mance testing, they would decide whether they have time to
Kanban - Beyond the Basics 4
cover it, do risk management and either test it or skip it.
e downside for this was that its a bla/white decision. is
misses the opportunity for the delivery agile teams to do at
least SOME performance testing, even if they don’t have the
capabilities, tools, expertise of the dedicated performance testing
team.
Our suggested solution was to use the concept of kanban Classes
of Service to improve on this naive policy.
Since we already know not every feature requires the same
performance test aention, lets not wait until it arrives at the
performance team to make this classification. Lets do it earlier,
before we go into development/testing.
With this classification, policies can be setup that can involve
both the performance testing team as well as the delivery agile
teams in the work of performance / non-functional testing.
We came up with a flag system:
• Red – performance team Must be involved hands on –
probably by joining the Feature team working on this
feature for the duration of the effort
• Yellow – performance team Advise/Consult, but most
work is in Teams. Representative of the performance team
will be visiting the Feature team quite oen while the
Feature is being worked on.
• Green – don’t need any involvement from performance
team
Kanban - Beyond the Basics 5
Classes of Treatment in Kanban
is system helps drive collective ownership of non-functional
testing. One of the first things that happened is that the Feature
teams told the performance testers that there are some kinds of
tests they can run on their own, although they don’t have highly
specialized performance tools.
We are also experimenting with systems like this for involving
aritecture teams, and it applies for most kinds of super-
specializations that are not easily integrated into Feature teams.
Managing the overall flow using kanban will also help see
whether a bolene develops, and what can be done further
to overcome it.
Kanban - Beyond the Basics 6
1.2 Encouraging Feature-level progress
tracking in Kanban
One of the key questions project managers and senior manage-
ment in general ask themselves and their teams on an ongoing
basis is - “Are we on tra to deliver the scope we commied
to, on time”. In some environments “on budget” is added to the
question.
If you are talking about a Release Scope, the answers are quite
similar whether you’re doing Scrum or Kanban. If you don’t care
too mu about the budget aspects, a Release Burnup can show
you the commited scope, the commied date, and the actual
progress in working soware towards that goal – Plan versus
Actual. If you ARE interested in the budget picture – commied
budget versus actual, and are we on tra to finishing the release
with the budget we commied to – use AgileEVM¹ on top of
that.
Basically for all of this – you are measuring the amount of
done features work compared to the amount of features work
originally planned for. Whether sized using effort days, story
points, function points, the idea is the same.
In a conference a couple of months ago I talked about Agile
Release Management² and covered this subject somewhat. I
would add that this expectation of management is what we
call Predictability in the Kanban world, and based on some
¹http://www.infoq.com/articles/agile-evm
²http://www.slideshare.net/yyeret/managing-projectsreleases-using-leanagile-
techniques
Kanban - Beyond the Basics 7
encounters I’ve had with senior management, we as the Agile
community have not been doing a great job at connecting to the
expectation of Predictability. In many cases its the opposite – we
create the impression that Predictability is a lost cause because
everything is Agile.
In Kanban we try to beer connect to this expectation of Pre-
dictability/Commitment to the important things. Senior man-
agement doesn’t care about commiing to a sprint goal and
meeting it. ey care about meeting commitments to deliver a
release on time and with feature highlights communicated to the
stakeholder community. ey care about meeting commitments
to deliver certain features on time to internal and external parties
that count on this feature to continue and do something else.
Predictability will continue to be important. e way its mea-
sured might ange. For now, most teams/projects are indeed
evaluated based on the answer to “Are we on tra to meeting
the release goal on time”. We should support those teams with an
approa that complements their kanban flow-based workflow.
e methodology is all there if you connect the dots.
e room for improvement is mainly in connecting the dots and
providing a structured methodology that can be applied as a
framework, as well as beer tool support.
What are the gaps?
First, e thinking around CFD needs to swit from history to
also a forward-looking predictive art. What do I mean?
Most CFDs you see today focus just on an operational view CFD
– what is the current state, as well as history, whi can help you
improve your process, operation.
I’m Missing a view of the work needed by a certain date, and
Kanban - Beyond the Basics 8
whether we are on tra to aieve our commitments/goals.
Tools that extend the CFD to a view that includes current trend,
required trend to meet the goal, and trend of requirements urn
can answer this question – you see whether the DONE trending
towards the overall commied scope is on time or not.
One more complication is that of course you sometimes want
your board to reflect many releases, not just one. You’re working
to finish one release, and then you move to another.
In this case, You probably want this view per-Release on the
board.
So we need visibility arts that can aggregate the status of
several cards e.g. Feature, Release, MMR, MMF whatever you
want to call it. In Feature Driven Development³ Parking Lot
diagrams⁴ are a popular way to convey the status of various
features/aspects in a Project/Release. An extension of a Parking
lot diagram can be to have a mini-burnup of that entity. So
beyond just the status (whi is basically the current point
of a burnup), you can have a mini-graph showing the status
of entities comprising this feature. See below for a sket of
how this can look. ( Note that the Warning Indicators box
are taken straight from the organizational dashboard page of
LeankitKanban. I recently started to explore the capabilities in
this dashboard and find them quite useful to help bring a process
under control, and the sort of stuff you might want to look at in
an operational review).
³http://www.featuredrivendevelopment.com/
⁴http://www.nebulon.com/articles/fdd/ptsparkinglot.html
Kanban - Beyond the Basics 9
Parking Lot Charts
e color of ea parking lot / feature can easily be derived from
where the actual progress is compared to the expected progress
curve. e expected curve can be defined to be Linear (yeah
right), S-curve based as David Anderson is fond of⁵, or whatever
you think the profile should look like. Once you are below the
curve, you start to gain reddish colors. Above it – you are
green. With Agile approaes relying on Working Soware as
a measure of progress, you can really trust those colors… Its no
more a watermelon (green outside, red inside – courtesy Kent
Be⁶)
For those interested in the details, here is one way a CFD can be
extended to provide burnup capabilities.
⁵http://edn.embarcadero.com/article/32411
⁶http://twitoaster.com/kentbeck/rt-pmagile-a-little-joke-i-told-at-the-agile-conf-
execs-see-watermelon-projects-green-on-outside-red-on-inside/
Kanban - Beyond the Basics 10
CFD with Burnup Trending/Forecasting
With this in mind, the mini-burnup in the parking lot can be
upgraded to a mini-CFD
Parking Lot Charts with a Mini-CFD
Now, with a CFD, some more intelligence can be applied to help
Kanban - Beyond the Basics 11
determine the color/state of the Feature. High level of WIP can
be a leading indicator of problem (but knowing about Lile’s
law and how a CFD looks like you probably know that it will be
apparent in the burnup being quite flat as well…). I’m guessing
that with time, we will learn to study and identify progress risks
using a CFD, beyond the basics we currently use.
Boom line – my feeling is that in order for Kanban to cross the
asm into the majority of projects/development groups, who
are quite concerned with delivering Releases and Features on
sedule, not just with trusting the Flow, we will need to provide
more and more tools and focus to support this use case. e core
thinking is there, the hunger on the part of the IT world is there
as well it seems, so lets go out there and make it happen. my 2c…
Kanban - Beyond the Basics 12
1.3 How I would simulate time-boxed
agile in the @getkanban kanban board
game
At Agilesparks we’ve recently been using the Kanban Board
Game ⁷ developed by Russell Heally quite extensively. We use
it as part of Kanban courses, sessions for Scrum teams that want
to learn about Kanban, Kanban teams that are already working
and want to raise their game as well as in sessions for project
management teams.
We love what the game does, and it has actually become a
allenge to coordinate whi of us has the game kits at any point
in time, especially because in large events we need 4 kits so we
need to borrow from one of our nice clients that has 2 kits as
well…
One idea we’ve been toying with for some time, is that it would
be great to use something like this game to accelerate learning of
Scrum as well. At a minimum, one of the questions I’m adding
to the debrief for Scrum teams, is how would Scrum look like in
this game, and what would be the effects. It seems clear to teams
that Scrum would reduce throughput due to the need to clean the
board every sprint, whi means less ability to take advantage of
the speciality of the Analysts/Developers/Testers. It would also
make the game run slower due to the overhead of planning…
I’ve been reading some ideas from David Anderson and Russell
about this, whi helped me along. I’ll provide my take on this,
⁷http://getkanban.com/
Kanban - Beyond the Basics 13
but first a brief overview of the game to those not familiar with
it.
e GetKanban Game
e game simulates a process workflow where there is a sta
(balog) of cards whi represent stories for development. e
cards are pulled into a READY area, then pulled into Analysis,
Development, Testing and finally deployed. ere are differ-
ent types of cards representing different work types/classes of
service – a normal business value card, a fixed date card, a
quality card, and an expedite card. Ea card specifies the
amount of work required to process it in ea station, whi
provides the variability between work items so typical of product
development and other knowledge creation areas. Another form
Kanban - Beyond the Basics 14
of variability is the fact that how mu work you are able to
do ea day is decided by throwing dice. You have dice in
different colors that represent specialists in ea area (Analysts,
Developers, Testers), and you as the team playing the board can
decide where to use ea dice ea day. Either use it in the
specialty area of that person and gain a multiplier, or use it
elsewhere without a multiplier. e game is played in cycles
of days – ea day you decide your strategy, throw the dice,
play the game, update visibility arts, and also handle an event
that might throw you some additional curve balls… at should
suffice as a qui intro to understand the rest of the post, or at
least as a teaser to find the opportunity to play the game. It really
is highly recommended to anyone interested in Agile / Kanban
/ Scrum / Games. Exceptional work by Russell.
If you noticed so far, the game indeed simulates kanban. No
time-boxes or bates, just flow and flow and flow. e only
area where you get some sort of sprint behaviour is towards the
end of the game. If you are approaing the end of the game and
the teams know its coming, they will start to prefer cleaning the
board and deploying items, rather than maintaining flow. at
makes sense. If you announce end of the game on day 24 for
example, but finish it a few days early without telling the teams,
you will get flow behavior all the way to the end. You can play
with that, depending what you want the teams to experience,
and whether you want to have the timebox behavior as a paern
to discuss in the debriefing.
In general, it shouldn’t be too hard to make the adaptation of the
whole game to timeboxes/sprints. maybe the biggest allenge
is to have teams see the name Kanban on their new shiny Scrum
process training…
Kanban - Beyond the Basics 15
But seriously, the main thing you need to take care of is the
sprints. e concept of 3 day billing cycles in the game can be
extended to portray a sprint. You would start the cycle with
planning what cards you will work on in the cycle. is requires
looking at your velocity in the last cycle, your capacity (cubes
and statistics…) thinking about anges that were made in the
environment (Carlos etc.), and the cards that are currently in the
balog. You would commit to what cards you plan to deliver.
Whi gets us to the balog… e trivial option is to make the
READY area the balog, and only pull into the READY area
(into the board actually) cards that fit into the planning. is
is not perfect though. For starters, how do we model the work
that is done by the Product Owner? In addition, the whole flow
from READY through analysis, development, testing might be a
bit too long for a 3 day cycle.
at brings me to an alternative I’ve been thinking about – make
the Analysis phase the work of a “Product Owner”. Use the
analyst dice to represent the Product Owner, and the “Analysis
Done” area the “Sprint Ready” balog the teams can use for their
planning.
is has the benefit of portraying the Product Owner work, it
reduces the cycle time within a sprint whi I think will provide
a more reasonable simulation within a 3 days cycle, and can also
bring about a discussion of the wastes of too mu sprint ready
balog, versus a team that runs dry during a sprint. (Whi is
one of the common problems with Scrum teams, and a big benefit
of doing this game with them I think)
So assuming the Analysis Done was the sprint candidate/ready
balog, the team does planning, pulls the planned stories into
another queue between Analysis Done and Development in
Kanban - Beyond the Basics 16
progress, whi we can call – the Sprint Balog
A sprint will be 3 days where the team works to finish and deploy
all the cards in the Sprint Balog – processing them through
Development and Testing. Within this sprint the team also needs
to take care to replenish the “Sprint Candidate/Ready Balog”,
because remember at the end of the cycle, there is another Sprint
Planning, where they will need to have enough candidate cards
that they can pull into the Sprint Balog, to avoid starvation in
the sprint. To properly simulate a real Scrum environment, it
shouldn’t be allowed to pull cards within a sprint, because it is
harder to plan within a sprint.
For advanced uses and for those Scrum people whi are crying
this is not fair, we can discuss a couple of options. One option
is to allow pulling stories, while paying a fine for it to represent
the cost of replanning. For example, you can put one of the dice
on planning a story instead of executing it. Another option is to
allow pulling quality cards during a sprint.
In general btw, we need to think how to portray the cost of
planning. In a typical stable Scrum team, there is a cost of about
2-3 hours of planning per a 10 day sprint. is is about 4%
whi should be negligible in the game. Another option is to just
compare the time it takes to do rounds of flow versus timeboxed
rounds in the game and see what is the actual time it takes to
run the game… I would expect flow to run mu faster than the
time-boxed version… but need to try it!
At the end of a sprint, what would happen is that you expect to
have clean Sprint Balog, Development and Testing stations,
with all the cards deployed already. Any work that is not
completed will probably be continued into the next timebox and
should be included in the plans. I’m thinking a fine should
Kanban - Beyond the Basics 17
be included here – every card that spills to another timebox
should have a few points of work added to it (e.g. if there are
12 development points, the team finishes with 6 points of work
le, in the new timebox there will be 6+3 points of work)
What would happen to Cycle Times? I’m quite sure cycle times
will be mu higher for a team doing timeboxes. e need to
keep a queue of work ready for sprints will probably add about 2-
4 days of cycle time, depending on how the team balances safety
of having spare stories, versus the waste of having a story decay
in the queue. Since the game doesn’t model a price for decaying
stories, I assume teams will prefer more in the queue. e only
thing that will stop them from doing that is limited amount of
analysts… need to try it but I’m guessing there is a ance that
the analyst will not be able to keep up, or at least we need to
create scenarios that impede him from keeping up (e.g. bloers
in analysis, reduced capacity of analysts, or taking stories that
were analysed and cancelling them so now analysts have to rush
to replenish the ready stories queue)
e event cards are another area whi might need tweaking.
For one, some events are unfair to introduce in the middle of
a timebox because the team should know about them when
planning. Need to look at them and align them with the
timeboxes as necessary. Beyond that, some new kinds of events
can be leveraged to spice up the timeboxes game (see above for
example)
Will the effect of time-boxes be realistic enough? e concern is
that if the time-box is too short, it will be hard to deliver stories
and run an effective time-box. Similar to what teams experience
when the story size is too large for the sprint. Basically, need
to play around with it and see… I think that by removing
Kanban - Beyond the Basics 18
the Analysis from the sprint itself I reduce the ance of this
happening, but maybe its not enough. Worst case can play with
multipliers on the cubes some to make the team capacity higher
compared to the work, or strengthen the effect of the quality
cards…
e WIP limits go away in this variant I think. e WIP limit
is the Sprint Balog whi is time-based, not station based. An
advanced team can decide to use WIP limits on the stations to
work more effectively, or we can re-introduce the WIP limits
as an event card during the game. While on this maer, a
question I usually ask teams in debriefing is what would happen
if there wasn’t a WIP limit. e answer I hear is that they would
probably start more work than they can finish, and throughput
and earnings will go down. QED…
is should give you some ideas how to play with the Kanban
game in a time-boxed manner. ere are probably other aspects
that need to be taken care of, but lets be agile about it folks…
And again, thanks Russell for the great game, whi probably
deserves to be a platform, with endless options of what to do
with it. If we could have this as a Lego kit that we can play
around with, it would be amazing.
Kanban - Beyond the Basics 19
1.4 Kanban early warning using a pre-
dictive variant of SPC
A Confession. While I’m a great fan of using SPC arts to
explore specific cycle times and reduce variation / continuously
improve a Kanban System⁸ (a great blog by benjamin mitell),
I’m only seeing preliminary results in the field with teams I’m
coaing. e main reasons are la of tooling, la of incentive
to manually manage this, and the fact that teams are not yet
mature enough. I’m hoping this will ange in the near future.
With that in mind, a constant concern I’m hearing is that finding
out that there was an exception based on SPC is too late. Why
is that? Because a classic SPC looks at final cycle time. And
Final by definition means the action is over…
A couple of months ago, I read about “average cycle time in
column” in the GSK R&D Case Study by Greg Frazer⁹.
A couple of days ago, I had the idea that perhaps using the
collected history of cycle times in columns/lanes, a current
prediction of final cycle time can be calculated for ea card
in the system. is prediction can be then traced on an SPC-
like art, and exceptions can be identified more clearly (see
illustration below for an example)
⁸http://benjaminmitchell.blogspot.com/2009/05/control-capability-charts-on-
kanban.html
⁹http://influencecorp.com/2010/06/lean-software-experience-report-
%25E2%2580%2593-rd-it-at-gsk-%25E2%2580%2593-2008-9/
Kanban - Beyond the Basics 20
Predictive SPC
is reminds me of arts used to tra “Due Date Performance”
on releases/milestones, whi I saw at one client of ours. I later
learned they are called Slip Charts¹⁰
e main difference is that the SPC Y-axis is by cycle time length.
In the Due Date traing art, its by actual date. I think its
probably sufficient to just rely on the SPC arts. I would urge
organizations traing due date performance on releases and
milestones to start doing an SPC at that level, even if they don’t
use Kanban/Agile at the Feature/Story level. ey might learn a
few things that can help them bring their process under control,
and improve their predictability.
¹⁰http://www.c2.com/cgi/wiki?SlipCharts
Kanban - Beyond the Basics 21
Ba to the predictive SPC – no tool that I’m aware of currently
offers this capability, but one can always hope.
I see capabilities su as identifying struggling work items based
on exceptions from “average time in lane” as well as overall
exception in predicted cycle time key to taking the “early feed-
ba and action” one step forward, and scaling Kanban to be
something project managers swear by.
If you are aware of any of the Kanban tools that provide this –
I’ll be happy to hear about it.
Kanban - Beyond the Basics 22
1.5 Lean/Kanban approach to Teams
To Team or not to Team?
If you look at the definition of Kanban or Lean, you wouldn’t
find teams anywhere there.
If you look at the Agile Manifesto¹¹, you can find “e best
aritectures, requirements, and designs _
_emerge __from self-organizing teams”
Scrum is quite clear about the topic (oting the Scrum Guide
2011¹²)
“Scrum Teams are self-organizing and cross-functional.
Self-organizing teams oose how best to accom-
plish their work, rather than being directed by oth-
ers outside the team. Cross-functional teams have
all competencies needed to accomplish the work
without depending on others not part of the team.
e team model in Scrum is designed to optimize
flexibility, creativity, and productivity.”
So, if you are a manager of an organization on the Kanban
train of evolutionary improvement, what does it mean for team
structure? Should you keep the current structure? Adopt the
Scrum Feature Teams concept? Do something else altogether?
How should you organize your people to be as effective as
possible in delivering value for the stakeholders?
¹¹http://agilemanifesto.org/principles.html
¹²http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf
Kanban - Beyond the Basics 23
Teams as an emerging property?
I personally believe that even if kanban the tool doesn’t talk
about teams (obviously since it’s just a visualization and process-
driving tool), despite the fact that the Kanban Method for evolu-
tionary ange doesn’t talk about teams (obviously since it starts
from where you are, respecting your current structure, leing
anges be pulled from actual need), more effective paerns for
team formation will emerge when Kanban is really used.
At their core, Teams affect communication bandwidth. ey
partition the organization to enable increased communication
bandwidth among people in a team, while counting on the fact
that communication bandwidth to people outside the teams is
not that important. Since we are talking about people, not
network nodes, teams also allow the communication bandwidth
to increase, the longer the team is working together, due to
the team formation model. I recently read “e Talent Code”¹³
where the behaviour of our brain around learning new skills
using myelin to wrap neurons to increase bandwidth reminded
me of how teams behave.
So it seems like teams can really increase our effectiveness, and
everyone in a reasonably sized organization cannot even bear to
think about geing rid of the partitioning, right?
Well some of the Kanban thinking says that since Kanban mas-
sively reduces coordination costs via hyper-visualization and the
pull system, the size of teams can increase significantly. Since we
advocate using classes of service to allocate capacity to demand,
thereby maintaining flexibility, we shouldn’t allocate people to
demand.
¹³http://thetalentcode.com/
Kanban - Beyond the Basics 24
e main reason not to go to teams is that teams might be
local optimization. If our workload/demand was certain, and
the uncertainty as to what effort/speciality is needed to deliver
it was low, we could build the teams that optimize our perfor-
mance. If that workload/demand didn’t vary over time, we could
maintain the same teams and still have optimal effectiveness.
But since in most environments we are facing a complex system
with uncertainty/variability in the workload/demand, as well
as the implementation effort/speciality required, it seems like
sustaining stable teams will cost us in some optimization.
Team Modes
In my recent conference talks (GOTOCPH, LKBE11, LKCE11)
I provided my view on this question of team formation and
Kanban. I described the following progression:
1. Functional/Component Teams based on specialization
2. Teams On-Demand – whenever pulling a new Feature for
work, associate the relevant people with it. ey will deliver
that feature, and aer a few weeks return to their home
teams. is approa provides lots of flexibility, but typically
has relatively high coordination costs. It also doesn’t really
benefit from the improved communication bandwidth among
the team members that you get from persistent teams. is is
very similar to the Feature Driven Development team mode
by the way.
3. Project/Initiative Teams – whenever pulling a new Projec-
t/Initiative for work, associate the relevant people with it.
ey will work together as a virtual team for the duration of
that project/initiative, and aer a few months, return to their
Kanban - Beyond the Basics 25
home teams. e benefits of this approa is lower coordina-
tion costs as the teams don’t ange that oen. In addition the
people working towards the same business goal are working
together. e communication bandwidth increases as well
over time, as well as the feeling of purpose and alignment.
On the other hand, flexibility goes down. It is harder to shi
people into projects/initiatives. It is harder to shi people out.
If there is significant variability in the specialization required
along the life-cycle of the project, selecting the right team
becomes hard. If you work on versatility of your people, or
already have a great group of generalizing specialists, this will
be less of a problem. It can also be addressed by keeping a
sla of several people working outside of project/initiative
teams, that can be easily shied in and out of activities on
demand. It makes even more sense if those people are your
experts/heroes. I’m seeing this mode in action in several
organizations.
4. Teams pull work – e next mode is where you create stable
work cells that are able to handle almost everything you
throw at them. ese work cells stay together as the main
organizational unit, and pull work based on the next business
option the organization wants to exercise, regardless whether
it is to accelerate an existing initiative or start something
new. Here the communication bandwidth grows stronger and
stronger. e flexibility and agility to shi business priorities
and help swarm to work in process remains quite high, but
the internal team flexibility remains an issue. e same sla
of people not associated to teams can help here as well. I’ve
seen this specific mode in action in several organization, and
it works great, assuming you are ready for the ange.
Kanban - Beyond the Basics 26
5. On demand teams – Wait, didn’t I mention this one? Yes, I
did. e difference here is that assuming you somehow have
a tightly knit group whi already managed to create lots of
communication bandwidths among the WHOLE group, you
can have a win-win. Total flexibility and global optimization.
is should be the holy grail of any manager of about 20-40
people I would imagine. A force to reon with…
Mixing it up
You don’t have to decide on one model. Not all work is created
equal, so not all teams should follow the same structure. Some
interesting examples:
1. 80% on-demand, 20% focused on an initiative
2. 80% on-demand, 20% cross-functional work cell (A-Team)
3. 80% project teams, 20% on-demand able to swarm to a team
in distress and help, or join a team to tea them some new
skill as appropriate.
Evolutionary Change
Some organizations will jump in, create work cell teams, and
start working. I’ve seen it in action, and when you REALLY have
enough energy in the organization to make this maneuver, by all
means go for it.
Other cases you will not have enough energy. Or you will
THINK you have enough energy, but reality will hit you in the
Kanban - Beyond the Basics 27
face when all the middle managers / team leads that led you to
believe they are on-board are not that supportive once it is time
for action and for supporting the actual new structure.
So think hard about what is your case. And if you want to go for
a more evolutionary ange mode, consider the following:
• Start with on-demand teams
• Pilot one initiative/project team – especially useful when
you have a risky initiative with a lot of uncertainty and
dependencies, that is mission critical. Assign the success
of this team structure to one of your best and most trusted
people, if not yourself. Whether he is the Coa, the actual
Lead, or something else is secondary. e important thing
is that he will be in arge of making the team structure
work, and together with the team make the learning from
that available to the rest of the organization
• Move to more and more initiative teams as necessary
• When a project/initiative finishes consider turning the
team to a work cell to pull more features in that area, or
more features in general
• Ideally, teams will have the capabilities to take almost all
work on. If not, use a talent matrix showing what teams
can do what and gaps to invest in. As well as talent matrix
inside a team that will help teams grow some internal
versatility (note not everyone on a team needs to know
everything at the same level)
Kanban - Beyond the Basics 28
Cautionary Notes:
When creating teams be careful not to spread yourself too thin. If
you have too many small teams it might be an indication you are
not managing flow effectively at the Initiatives/activities level. I
love teams of 4-5 people by the way.
If you find many people need to be on many teams, you have
a real problem. It is ok for a minority of the people, especially
specialists, to be needed by many teams. Maybe they should stay
as auxiliary on-demand, while spending some of their capacity
offloading knowledge to the teams. But if it’s not a minority,
then you really need to work on versatility, or the on-demand
might be a beer fit. e whole point of the teams is to create the
communication bandwidth. Without that, they’re just overhead.
Conclusion
I presented a couple of team modes here, as well as one way
you can use them. is is really context-specific stuff, so I
cannot tell what will work for your case. But I hope the modes
help you relate the Lean/Kanban effectiveness principles to the
options of team formation. In upcoming posts I will try to relate
this to a couple of thinking frameworks I grew fond of lately
(RightShiing¹⁴? Cynefin¹⁵?)
¹⁴http://www.measuresw.com/services/rightshifting.html
¹⁵http://en.wikipedia.org/wiki/Cynefin
Kanban - Beyond the Basics 29
1.6 Linking Team Modes to RightShift-
ing
What is Rightshifting?
In several conferences this year I saw references to RightShi-
ing¹⁶. I was curious to try and learn more about it, whi led to
several ats with Bob Marshall¹⁷ and think about it for a bit.
Yesterday, at home already, a couple of thoughts clied.
One of them was that my post about Lean/Kanban Team Modes¹⁸
might fit into the RightShiing¹⁹ model. Basically it talks about
companies going thru phases of effectiveness le to right -
from Ad-Hoc through Analytic, Synergistic and finally Chaordic
modes. Shiing to the right gives you a jump in your potential
effectiveness as a company. Most companies get stu in the
Leish phases.
Team modes and RightShifting
Well, thinking about the ad-hoc phase I have in mind a start-up
/ small group where everyone is one big happy family, without
any rules, haing it out. No teams there for now.
¹⁶http://www.lean-kanban-conference.de/sessions#rightshifting
¹⁷http://www.hanoulle.be/2011/07/who-is-bob-marshall-flowchainsensei/
¹⁸http://yuvalyeret.com/2011/10/22/leankanban-approach-to-teams/
¹⁹http://vimeo.com/30685754-goreaditifyou’reinterestedandthencomeback.
ThispostwillnotmakesensewithoutsomebasicfamiliaritywithRightShifting
Kanban - Beyond the Basics 30
At the dawn of the analytical phase, the group is too large,
seems like we must introduce some discipline. Part of it is
creating functional teams, and discussing the interfaces between
the functions, roles and responsibilities, RACI, etc. is is the
starting point for my previous post, and what I see in most
organizations I start working with.
e synergistic phase seems to align prey well with initia-
tive/project teams and maybe work cell teams at it’s border
with the Chaordic phase. ese teams are more synergistic
based on their cross-functionality and focus on business value
purpose. Work-cell teams are more flexible, whi is why I think
they are a bit right-shied from initiative/project/product teams.
One interesting point is that some organizations wishing to go
to “Agile”/”Scrum”/”Kanban” don’t always understand that this
will pull them right dragging along the cultural mindset… ey
want this agile thing as a plug-in to their analytic mindset… at
is always lots of fun to deal with…
Where do we go from work-cell synergistic teams? Well, I think
the return to on-demand teams, this time within a bigger group
that already has wide any to any communication bandwidth so
strong dynamic teams can be setup and tear down with minimal
coordination cost, might be a good fit for a aordic mindset. I
have a few organizations on the verge of this transition, maybe
exploring the framework with them will help formulating a
vision / rationale for what is going on.
Disclaimer
I’m no RightShiing expert. Far from it. Just some thoughts I’m
puing out there, with the hope they will enri the conversa-
Kanban - Beyond the Basics 31
tion, and maybe interest a couple of my readers in RightShiing.
Kanban - Beyond the Basics 32
1.7 MMF driven sprints in a Kanban
world
e more experience I get with Kanban, and the more I talk
about it with people, I see that one of the main allenges is
maintaining some form of goal-driven cadence that energizes the
team.
If every one of your Kanban Cards/Stories is an independent goal
(e.g. a support environment) its easy to connect to the business
and there’s usually an SLA to energize you.
If you are working in an environment where the business goals
are quite big, and have been broken down in order to flow
through your system, its a different allenge.
I’ve lately been thinking more and more about how to use the
MMF level to generate this cadence.
It actually started in a pure-scrum environment where a team
was frustrated about fixed length sprints, and asked why not to
do a sprint that is aligned with the delivery of the feature that
they’re currently working on. Later, I’ve started to dive deeper
and deeper into Kanban, and I’m seeing teams that I think will
benefit from a clearer higher level goal than delivering stories.
It also makes a lot of sense to align the cadence with the higher
level activities, the “mini-projects” that you are working on.
In parallel, there was some discussion over in kanbandev²⁰
around improving the status reporting/visibility around features
²⁰http://finance.groups.yahoo.com/group/kanbandev/
Kanban - Beyond the Basics 33
in a kanban world²¹. So I sat down with Elad Amit, another
Kanban freak in the Agilesparks team, to think about what we
can experiment with here. Also, doing some resear, I recalled
that Scrum Type C²² is quite similar to what we are discussing.
And I also came (again) across Kanban and the New New Product
Development Game²³ whi discusses MMFs and Scrum Type C
and talks more or less about our direction here.
So, down to business, what are we talking
about?
e main thing we came up with is the understanding that
ideally, a team should be able to do an MMF-based one piece
flow – meaning a ** WIP limit of one MMF per team**.
What does this mean? lets assume the team is currently working
on an MMF. is MMF has some stories in progress, some are
done, some have been identified but not yet started. is is
similar to observing a team whi is in the middle of a Scrum
sprint. ey are working on stories, doing a daily standup,
reviewing ea story with their customer/product owner as it
materializes. Once all the stories are done (working tested
soware, potentially shippable product), this MMF is also done,
and can be reviewed (at the MMF level), retrospected. en the
team can start planning the next MMF – understanding the story,
breaking down to smaller bits that can flow in the team and
²¹http://finance.groups.yahoo.com/group/kanbandev/message/8796
²²http://scrum.jeffsutherland.com/2005/03/scrum-evolution-type-b-and-c-
sprints.html
²³http://availagility.co.uk/2008/11/26/kanban-and-the-new-new-product-
development-game/
Kanban - Beyond the Basics 34
whi the team can swarm on. Once the planning is done, the
team can start working on this MMF-driven sprint.
So far so good.
Now a few questions come up:
• What is the length of this MMF-based sprint? Is it
pre-determined using Estimation/Commitment? Does it
emerge as the stories are completed and progress is made?
• What happens if the team cannot effectively swarm to one
MMF? Do we introduce another MMF? What happens to
the Cadence then? Do we do the Cadence as one big team,
or break into teamlets that do the cadence for their MMF
separately?
• How do we deal with the issue of first/last days of an
MMF sprint? How do we use the Sla there, and how
do we deal with overloading Testing at the end? Is it
enough to say “break work into smaller story, use mu
more automation” and the other typical recommendations
of how to avoid the ScrumFall? Since we are more of the
Kanban evolution model, shouldn’t we allow a beer way
to deal with this than requiring a fast revolution?
• What kind of visibility/metrics can we align with th
I will not answer all questions today, but try to follow up in other
posts soon. In the meanwhile we’re also trying out those things
in actual client deployments, whi in a true agile fashion will
probably affect our thinking…
Kanban - Beyond the Basics 35
To sum up for today, it seems like what we are talking about
is improving the ability of the MMF to be a boundary object
between a team and the bigger project/release, emphasizing it as
the main object for discussion, traing, reviewing, delivering to
the downstream aspects of the workflow, and ideally releasing.
is idea is sort of a mashup of different ideas raised by others,
and I suspect some of the Kanban practitioners are already doing
this at some level, but its not yet documented or supported fully
by tooling at this point (as the discussion about feature-level
burnups/CFDs/parking lots in kanbandev²⁴ highlights).
It also might warrant a caty name, whi is not one of my
strengths.
Screatureban? (Scrum-Feature-Kanban…)
FeatureBan?
So what do you think? Are you actually doing this today and
can share from your experience? Do you think its a good/bad
idea?
²⁴http://finance.groups.yahoo.com/group/kanbandev/message/8796
Kanban - Beyond the Basics 36
1.8 My thoughts on how Kanban and
TOC Critical Chain relate
Background
I recently had a short twier at with Catherine Swetel²⁵ and
Steven Holt²⁶ about the relation between TOC Critical Chain and
Kanban. is post will try to sum up my thoughts in a way that is
a lile bit more persistent, as well as add a _bit _more color and
depth that is not possible in 140 aracters. To start with, lets just
make clear – I’m no expert at TOC or Critical Chain. I’ve done
my share of reading over the years and have seen organizations
using CC and helped them explore the Agile/Kanban world. I’ve
read Critical Chain for the first time ba in 1996 or so and also
familiarized myself with the MPCC S&T tree in the last couple
of years. With that disclaimer, here are my thoughts, for what
they’re worth:
Multi-Project / Program Level
If you start at the project/portfolio level, I see the Multi-Project
Critical-Chain and especially its Strategy and Tactics tree as
very similar to the Kanban System for driving improvement.
Both approaes start with Limiting Work in Progress at the
Projects level as key to reducing unhealthy multi-tasking and
improving predictability and effectiveness. With time, excess
²⁵http://twitter.com/#!/CatSwetel
²⁶http://twitter.com/#!/SKHolt
Kanban - Beyond the Basics 37
capacity can be used to shape demand and create new exciting
business models. I think the CC world is more advanced in its
view on this aspect, but the Kanban world is certainly going
there. We would be wise to learn from Viable Vision and other
great thinking in the TOC world.
The Feature Design Factory
Once inside a project, kanban advocates a feature driven ap-
proa to development. e understanding that product devel-
opment is a knowledge discovery process where units of inven-
tory start as options and end up being working tested validated
features is at the core of the Agile approa. e assumption
is that we are operating in an uncertain environment. Both
the requirements/problem as well as the tenology/solution
has considerable elements of uncertainty. We welcome this
uncertainty as it comes together with the opportunity for great
returns. We also recognize that Integration activities hide a lot of
the risk in our projects, and so we drive for early and continuous
integration to minimize that risk.
e way to operate effectively in this environment is to have
a continuous process of focusing on a few features, seeking
Kanban - Beyond the Basics 38
feedba along the development process all the way to cus-
tomer/field feedba, orienting ourselves based on it iterating
thru the same or earlier stage of the process depending on the
feedba, and at the end having a marketable/viable feature that
doesn’t hid any more work behind it. Only then do we pull
another option/feature and drive it thru the process.
Kanban realizes that we have a certain capacity of features we
can effectively process at any point in time. Overburdening this
capacity will mean the knowledge discovery for ea feature will
take longer and the feedba will be handled later at a higher
cost. I’m guessing this will resonate with any TOC practitioner.
And indeed, the realization that features can be handled as
inventory opens the door to applying a lot of the pure TOC
thinking.
is approa can be used for handling an ongoing product
development context where there is always plenty of options that
can provide business value, and we are a factory/studio oosing
the best option to develop and deliver.
Managing Projects with Kanban
When the context is a major project comprised of many different
capabilities/features, this approa works as well. ere might
be a stronger need to manage the overall project health, but the
basic principles still apply. ere was an interesting discussion²⁷
about this lately in the kanbandev user group²⁸. I also covered
this in my recent talk about Commitments in a Kanban world²⁹.
²⁷http://finance.groups.yahoo.com/group/kanbandev/message/13783
²⁸http://finance.groups.yahoo.com/group/kanbandev/message/13783
²⁹http://prezi.com/fs-dklxllca0/commitments-and-energies-in-a-kanban-system/
Kanban - Beyond the Basics 39
In this area, I believe CC provides us with good practices and
tools – Release Burnup/CFD arts can evolve to Fever arts
for ea project, and an overall Fever art managing the overall
projects portfolio.
Typically, breaking projects to features will result in quite a
simple dependency graph/pert art. is is because the network
is comprised of self-sufficient features. Sometimes though,
Features do have dependencies on ea other, or dependencies
on external groups, as well as need to be delivered independently
before the major delivery. When this list of dependencies grows
larger and larger, maintaining a Critical-Chain view of the
project/program together with relevant feeding buffers might
make more and more sense. is view should only care about
Features with dependencies, so it is typically quite simple, ideally
managed as a Big Visible Chart on a project wall, a Look-Ahead
plan, etc.
Burnup CFD
Kanban - Beyond the Basics 40
Kanban’s view of Specialists
Kanban and Lean/Agile in general recognize specialization as a
root cause for la of flexibility and an impediment on the way to
business-driven agility. We advocate generalizing specialists and
the use of healthy engineering practices to make sure more of the
work can be done by more of our people. While this is a worthy
vision / desired state, many organizations cannot economically
aieve that goal, not in the near term, maybe not ever.
So we need to optimize how we involve our Specialists while we
are aiming to reduce our dependency on them, where it makes
economic sense.
We start by recognizing that ea person, including Specialists
has a certain capacity for spreading his aention as well as
for actual delivery. Once we overburden this capacity we are
abusing our scarcest resource. When we limit the work in
the workflow we align the workload with the capacity in the
line. But specialists that hover above the work like busy bees
flying between flowers require a separate approa. One way
is to limit the number of cards a specialist can be involved in.
Once that limit is reaed, he cannot be asked to be involved
in a new card. So either manage without him, or wait with
starting that work. Visualizing this involvement will already
drive some realizations and maybe some investment in reducing
the dependency somehow by knowledge sharing, offloading, etc.
Kanban - Beyond the Basics 41
Classes of Treatment
Another approa I tou on elsewhere (including the commit-
ment talk³⁰ mentioned above) is to classify the work based on
need for shared resource and affecting routing decisions based
on that. So if a specialist or any other type of shared resource is
currently congested, consider pulling work that doesn’t require
mu of his involvement. Or even beer, pull work that will
reduce your dependency on him in the future.
Summary
Well, ese are just some thoughts, an invitation for future
discussion. I believe there is potential for a lot of synergy
between Kanban and CC, especially in the world of complex
programs/portfolios. I especially urge the TOC/CC practitioners
out there to explore the “Feedba Oriented” view of Agile.
What we all need to remember is that the main thing about
the Kanban method is that it is aimed at catalyzing evolutionary
improvement. It is similar to the aim of the TOC S&T trees trying
to drive towards a Viable Vision. Don’t get confused by the
³⁰http://prezi.com/fs-dklxllca0/commitments-and-energies-in-a-kanban-system/
Kanban - Beyond the Basics 42
meanics. e key is to use the conversations that happen when
it is painful to follow an explicit process policy, like maintaining
a WIP limit, to learn something and improve.
And if you are currently using Critical Chain and would like to
explore what Kanban or Agile might mean or how they can help
you, I’d love to help.
Kanban - Beyond the Basics 43
1.9 Patterns for getting to a lower
WIP level in a system – The Freeze,
No New Work, Limit Later, and some
Mashups…
Some of us have the luxury of designing processes for greenfield
systems meaning there is no history/legacy to deal with.
Typically though, we are dealing with Brownfield/Legacy sys-
tems – is usually means there is some work in the system
already, there are outstanding commitments, and some existing
queues between steps in our processes.
I’m working with several clients that decided to start using a
Kanban system to manage their work, and believe Limited Work
in Process is key to improving their performance.
But a allenge most of them share is how to deal with is
something along the lines of:
• We already have a commitment to deliver V10 with 20
features by end of October.
• Our testing department is balogged – its still dealing
with the previous release V9 while development are al-
ready working on those 20 features for V10.
• V10 is critical to the business.
We then discuss various ways to get from here to there.
Kanban - Beyond the Basics 44
The Freeze
Essentially prioritize all work. Anything that is in process but
above the WIP limit, goes to the freezer – a new temporary
lane/area where work is put on freeze until there is room for
it.
e immediate effect would be acceleration of all work inside the
WIP limit, and significant risk to the commitment made about
the frozen work. Yes, you say that the original commitment
took all the work into account so why is there a risk just due
to anges in parallelism? Well, because we focus on the higher
priority work, reality is that we might spend more effort on it, to
deliver it with reasonable quality (not necessarily an aribute
of previous releases…), we might spend more time investing
in Versatility in order to sustain a lower more focused work
in process limit. So, it would be prudent to negotiate the
commitment level on a couple of lower priority features from the
release… and give the business a heads up this might happen.
is is one of the fastest ways to aieve a new inventory/WIP
level in the system. If we are looking to show qui results and
are able to negotiate a temporary ange in service levels with
the business, this can be a great approa.
is strategy is elaborated in depth in the eory of Constraints
body of knowledge.
No New Work
is is a more evolutionary version – don’t freeze current work,
but deny new work until we rea the desired work in process
levels. is means anyone finishing work on something will look
Kanban - Beyond the Basics 45
how he can help someone else, instead of starting something
new. ere will still be effects on the release commitment, but
milder ones.
e price we pay here is that it will take more time to rea
the new inventory/WIP level. It’s easier to negotiate with the
business, but the results will show more slowly…
Here is a short clip of how it looks like:
Visualize now, Limit Later
is is even a more evolutionary version. You start with Kanban
principle #1 – Visualize work. You don’t put any WIP limits for
now. You see how work looks like, you try to manage WIP, but
don’t limit it. Perhaps when negotiating commitments to the
next release V11 you take into account a period of cleaning the
system/queues and the implications of lowering the WIP, and
at that point you go into a Freeze/No New Work period, with a
bit more confidence in how this will look like, based on a few
weeks/months of visualizing your work.
is clearly is the risk-averse approa. Just be careful of
running out of improvement energies and forgeing that just
Visualizing Work is not enough…
Differentiated Service
A tweak on all of the approaes above can be to treat different
work types differently. is is what we call Classes of Service in
Kanban.
Kanban - Beyond the Basics 46
For example, Normal work above the WIP limit will be frozen.
Fixed date work will hopefully be inside the WIP limit and be
allowed to finish. New Fixed date work can be allowed to start,
with the condition that a Normal work will be frozen in exange
for introducing it. If all work currently in the system is Fixed
Date, we can decide whether to allow the new Fixed date to start
(should be a comfort zone for most organizations … ) or to have
a serious discussion with the business on the risks it introduces
and how we want to address them.
We can also say we visualize all work, but limit specific types of
work.
Feedback
What do you think about those approaes?
Whi of the above did you find useful in real life?
Do you have other strategies for starting up in the real world?
Kanban - Beyond the Basics 47
1.10 The Agile Lowest Common Denom-
inator – Avoiding a slowdown due to
the weakest link
One of the concerns oen raised when people hear about kanban
is that the weakest/slowest link will slow down the whole ain.
For example if testing is a bolene what will happen is that
the whole ain will accommodate its pace.
Similarly in scrum a team that actually does realistic planning
will commit to a goal that stretes the bolene leaving other
resources some serious sla.
In both approaes this is indeed a valid concern.
e worst thing that can happen is if the bolene causes the
rest of the links to adjust their pace, and worse than that their
“pace memory”. I’ve been thinking about this for a while and
am also asked about this quite frequently whenever I introduce
kanban to Managers with some experience…
In an old but wise article about the “Four Roles of Agile Man-
agement”³¹ David Anderson³² refers to it as “e team can
forget how to run fast – when there is a bolene/drum”. I
recently had a twier at with David on the subject. David
sees this problem as an optimization problem for high maturity
organizations. Based on the discussions I’m having, I think the
optimization might indeed by a high maturity tweak, but even
the concern about this happening is a roadblo to accepting
³¹http://www.agilemanagement.net/AMPDFArchive/FourRolesFinalRev0804.pdf
³²http://agilemanagement.net/index.php/About/
Kanban - Beyond the Basics 48
the concept of Kanban Limited WIP or Scrum Whole Team
Commitment.
I think we need to have a beer answer for this question as part
of the kanban “sales pit”. At least I need it…
So what do we say? Based on the discussion with David and
some more thoughts some of them fueled by recently reading e
Principles of Product Development Flow: Second Generation
Lean Product Development³³, I would recommend the following.
Basically, what we want to do is solve a conflict. On one hand
we don’t want to create inventory and increase the gap between
faster stations and the bolene as we know that creates slow
feedba, lower quality, and we will have to close the gap at some
point. On the other hand we don’t want to slow down the other
stations as we know its both lost capacity, as well as can lead to
lower capabilities over time if they “forget how to run fast”.
How can we solve the conflict? By looking at the assumption
that the other stations always work on flows that must involve
the bolene. Can we break this assumption? YES we can…
ere might be work types that don’t need to go thru the
bolene. Not all work is created equal. For example, if Server
guys are the bolene, oose work that is not as Server-Heavy.
If Testing is the bolene, oose work that is not Testing-
heavy, or even items that can be tested without the involvement
of the testing bolene.
Now the purists will say that the priority always needs to be
the business priority. But now we’re pulling and prioritizing
³³http://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/
1935401009
Kanban - Beyond the Basics 49
work based on our capabilities. Yes we are. Prioritizing purely
based on the business priority will lead to lower business out-
come overall. Our aim is throughput of business value. We
aieve that through the right mix of Business Priority and right
exploitation of our resources.
Having said that, if we see that we keep skipping priorities due
to our capabilities, its time to go to the next step. Create a
work item / class of service that serves to realign the business
needs and the factory/maine capabilities. For example, in the
world of testing this can be test automation done by developers
in case testing is a bolene. If Server are the bolene, we
can define a balog of items that reduce the workload on Server
(e.g. Refactoring and returning Tenical Debt), or cross-train
UI people to gain Server capabilities.
ere are more ways to do this, but the boom line is to always
have items in the balog that the non-bolenes can pull
and run as fast as they can on. Preferably some of them are
aimed at helping balance the line, driven by a process of ongoing
improvement.
Since I started talking about this with Management, I see mu
more traction for the various ways to limit WIP, whether Scrum
Sprint Commitment or the more explicit Kanban WIP Limit.
I think the idea of “Too mu sla” is currently a truth the
mainstream is simply not ready for. Beyond that, I think its not
fair to ask people/teams to solve this conflict on their own. Help
them by discussing the various ways to address the problem,
by helping them create balogs of improvement ideas they
should pull in those situations, and by seing the right classes
of service / work types that create the alternative routes around
the bolenes. I think this IS a management role in an agile
Kanban - Beyond the Basics 50
environment.
PS None of this is really new. e innovation is in seing up the
right classes of service and the right risk profiling to effectively
manage the line. Elements like oosing items with low cost of
delay so they can be used to “Fill Sla” and not pulled as part
of the normal priorities. And risk profiling so we re-route or
skip the bolene on the items where the risk of doing that is
minimal. Add to that measuring local cycle times (e.g. with tools
like LeanKitKanban ³⁴) so ea Capability can focus on its own
performance as well as the overall cycle time, and you get quite
an elaborate system. Sounds advanced? It is. I intend to cover
this in Advanced Kanban Workshops we will be starting to run,
since we know have quite a community of Kanban Practitioners
around Israel. Hopefully we can extend that community to the
region soon.
³⁴http://www.leankitkanban.com/
Kanban - Beyond the Basics 51
1.11 Touching your electronic kanban
board
Some of the teams I work with oose to have electronic kanban
boards. Why? see for example 5 Reasons Why Electronic Boards
Are Beer an Physical Boards³⁵ a good new blog post from the
guys over at Silver Stripe Blog³⁶.
My main recommendation to those teams is to insist on having
a big visible board, preferably in a public non-meeting-room
space. is is useful both to ensure the daily sync meetings are
casual rather than formal, as well as to have a constant big visible
control in your face, showing both your boards as well as other
dashboards (e.g. Continuous Integration status, Defects Metrics,
Production Analytics, etc.)
In the 2011 Lean Conference in Long Bea the LeankitKanban
guys came with big touscreen LCDs, whi seems a great
direction to go with.
³⁵http://toolsforagile.com/blog/archives/760
³⁶http://toolsforagile.com/blog/
Kanban - Beyond the Basics 52
Bandit Soware CEO, Chris Hefley, using LeanKit Kanban on an 82-in
touscreen
Bandit Soware CEO, Chris Hefley, using LeanKit Kanban on an
82-in touscreen
e question I then get asked, especially in Israel, is how do I
find su a thing…
Following the reuse guidelines we prea when talking about
good engineering practices, now that I’ve been asked 3 times,
I’m collecting the relevant links in a post I can refer people to in
the future, as well as to serve the general public looking for su
information.
Note: I still haven’t seen su screens in action beyond the
short demo mentioned above, so consider this information “AS
IS”, not a review/endorsement. Also note I have no connection
whatsoever to the vendors or sellers listed below. I just found
some links on google. Hopefully a couple of organizations I’m
working with will get su a board soon and I’ll be able to do an
actual experience report.
Kanban - Beyond the Basics 53
HP LD4200tm 42-in Widescreen LCD Interactive Digital
Kanban - Beyond the Basics 54
[
See also pdastore in israel³⁷ whi has a variety of touscreen
LCDs
If you’re in the US and are looking for a real treat, seems
like Horizon Tenology³⁸ are a good custom installer to e
out. ey provided LeankitKanban with the 82€³ custom screen
shown above. If you want to be the team with the biggest LCD
touscreen in town, that’s the way to go I guess…
Hope this helps. And if you’re in Israel and are seing up a cool
³⁷http://www.pdastore.co.il/pdastore/product.aspx?p_id=11673
³⁸http://www.horizontechnology.com/
Kanban - Beyond the Basics 55
electronic board/dashboard, let me know! I’ll be happy to drop
by and e it out!
If you have good experience with other types of touscreen
LCDs, or a good review resource for those, please comment and
let others know.
2
Agility at Large
56
Agility at Large 57
2.1 Fair Process and Agile – going fur-
ther than the Scrum Team
A client I worked with about 2 years ago mentioned that in
senior management training his organization was emphasizing
Fair Process¹ as a key tool for enhancing decision quality and
team commitment.
It sounded interesting, but I didn’t have a ance to dive too deep
into the concept.
Over time, it made more and more sense. What is Fair Process²:
“Fair Process, or procedural justice, universally re-
quires adherance to three principles: Engagement.
Involve individuals in the decisions that involve
them. Get their input, allow them to actively Peer-
Review³ the ideas on the table. Respect individuals
for their ideas. Explanation. Everyone involved
and affected must understand the reason why the
decisions were made. Demonstrating the rationale
behind decisions shows people that you have con-
sidered their opinions thoughtfully and impartially.
Not only will this make people trust the decision
maker but it will help them learn. Expectation
clarity. Once a decision is made, clearly specify the
¹http://meatballwiki.org/wiki/FairProcess
²http://meatballwiki.org/wiki/FairProcess,http://wwwling.arts.kuleuven.be/fll/
grammars/fairprocess.pdf
³http://meatballwiki.org/wiki/PeerReview
Agility at Large 58
expectations for the people involved, what respon-
sibilities they have. Even if the expectations are de-
manding, people want to know by what standards
they will be judged and what penalties there will
be for failure. Understanding what to do reduces
useless political manouevering and it allows people
to focus on the task at hand.”
When I look at the managers I had a ance to work with as well
as my management style, I find that I was mu more commied
and engaged when my manager employed Fair Process (whether
he knew he was using it or not). And also I felt my team was
more commied and engaged as well as devised beer plans
when my style was oriented towards what I now can name “Fair
Process”.
Geing to the Agile world, I think its quite clear that Scrum
advocates an extreme version of Fair Process in the Scrum Team,
and other Lean/Agile approaes take a similar stance as well.
But don’t stop there. If you want your organization to be
Lean/Agile, think about how your team can enjoy a bit of Fair
Process, even if its a management team, a steering team, etc.
Some examples of decision-making processes that can benefit
from Fair Process:
• Roadmap/Release Balog Prioritization among a Product
Management team (btw this is related to Perpetual Multi-
Voting⁴ but don’t forget to add in a conversation…)
• How is our Agile process going to look?
⁴http://leansoftwareengineering.com/2008/09/29/perpetual-multivote/
Agility at Large 59
• How do we want to allocate our capacity between the
various investment themes?
• Whi defects do we want to fix, whi do we waive?
• Do we release, or do we do more stabilization?
Exercise for the reader – ink about decisions your team made
in the last month. What was the process for making that
decision? What are your thoughts on the quality of that decision,
and how engaged the team members were to it?
Agility at Large 60
2.2 Driving Motivation – an exercise for
understanding the Daniel Pink’s Drive
model
Recently, the issue of motivation is permeating our work as agile
consultants. And not surprisingly, Drive: e Surprising Truth
About What Motivates Us⁵ by Daniel Pink is the main model
we’re currently excited about. Our resident AgileSparks CST and
team coaing expert Danny Kovat is leading that arge…
Today, while Danny (aka Danko) was describing the Autonomy
Mastery Purpose (AMP) model in our Agile Forum meeting, I
thought of an exercise that can be used to learn and internalize
the model. Here it is, provided AS IS… I didn’t have a ance to
run this yet but fully intend to.
While writing the blog item, I realized that this can be thought
of as a paern of the Force Field Analysis⁶ retrospective activity
The outline of the exercise
• Ask participants to come up with as many management
actions they can think of that happen in their organization,
they heard of, are considering, etc. Write them on stiy
post-its.
• Provide a primer on Drive and the AMP model
⁵http://www.danpink.com/drive
⁶http://j.mp/dT6SOi
Agility at Large 61
• Meanwhile Draw the diagram from the first slide on a
whiteboard / flip art / several flip arts
• Ask the participants to come place their actions in the right
place in the diagram – ea action can be driving/restrain-
ing one of the A M P aspects.
• Ask the participants to look for duplicates and conflicts –
actions that they have disagreement/confusion about
• Have a discussion about the items in disagreement
• Ask participants what are the actions they are commiing
to try in order to help drive higher motivation, and what
are the actions they are commiing to try to stop. One
from ea category should be enough per participant.
Tweaks
Some advanced tweaks or ideas that might improve the exercise:
• Use pictograms for the actions
• Use different colors for activities currently being done, and
ideas.
• Separate discussion to current activities, and later on aer
discussing the model, ask participants to come up with
ideas that can help drive higher motivation
• Reorder the steps somewhat…
Agility at Large 62
• Provide a set of activities that the participants need to
classify, instead of coming up with their own, or on top
of it as a bootstrapping activity.
If you try this and find it useful – let me know!
Agility at Large 63
2.3 How does the performance objec-
tives process change in a Lean/Agile
world?
Seems like every January I get questions from HR leaders in
organizations I’m working with that go something like this –
“We are working on the yearly performance objectives process,
and we were wondering whether it needs to ange in an agile
environment?”
e main evolution I see in the Performance management pro-
cess is leaning towards measuring up and across as well as fo-
cusing on capabilities improvement rather than a set of concrete
product deliverables specified up front.
Measuring up will motivate individuals to become beer team
players in their teams, as well as be beer connected to their
business objectives.
I personally preferred capabilities improvement over concrete
deliverables for many years even before I’ve been exposed to
agile, but of course it makes more sense. ere are many
situations where you cannot specify deliverables up front these
days. You CAN aim for a certain capability or improvement
trend.
Another trend I’m seeing and think is useful is to give teams
shared goals on top of individual goals. ese are again capability-
driven goals as well as business objective goals.
A couple of years ago I compiled a list of individual and team
Agility at Large 64
goal examples⁷ that some HR leaders found useful. Maybe
you will find them useful as well. Below are some references
I used to build this list and I think are a good place to start
for HR professionals interested in the performance/professional
development aspects of agile. ey are a bit dated I admit, and
those following my writing and twier presence will find more
stuff.
BTW HR professionals that were exposed to the Management 3.0
work by Jurgen Appelo⁸ found it very interesting and relevant…
e it out…
References
• hp://www.poppendie.com/measureup.htm about how
to measure/compensate in a group accountability environ-
ment
• hp://runningagile.com/2008/01/22/review-process-for-agile-
team-members/
• hp://theleanmanager.wordpress.com/2009/08/20/what-are-
the-traits-of-a-lean-manager/
• hp://www.infoq.com/news/2008/10/performance_review
• hp://www.infoq.com/news/2009/08/agile-managers-role
• hp://www.infoq.com/presentations/poppendie-agile-leadership
• hp://www.noop.nl/2009/12/elist-for-goals-and- res-
olutions.html
⁷http://www.slideshare.net/yyeret/individual-and-team-goals
⁸http://yuvalyeret.com/agilesparks.com/management3.0
Agility at Large 65
• hp://scrum.jeffsutherland.com/2010/11/happiness-metric-
wave-of-future.html
• hp://hr.mcleanco.com/resear/ss/hr-leverage-agile-goal-
seing-for-improved-employee-engagement-performance
From my own blog – try to think about what something like the
Toyota Improvement/Coaing Kata would mean for individ-
ual goal seing… hp://yuvalyeret.com/2012/01/10/the-toyota-
kata-book-review-and-thoughts/ (Look for this apter later in
the book)
What resources do you find useful for HR in an agile environ-
ment?
Agility at Large 66
2.4 If productivity experts tell me to
keep email closed most of the day –
why shouldn’t I avoid looking at de-
fects for most of the release?
An interesting question was raised to one of our coaes at
Agilesparks.
estion: Isn’t it more efficient to wait till the end of the release
and then all together handle all the bugs?
One of us answered that same like you probably prefer to answer
emails throughout the day rather than at the end, you want to
deal with bugs during the sprints.
I of course fully agree that you need to deal with bugs during
the sprint/release, or in other words keep the Bugs In Progress
number limited. (Anyone for Limited BIP society?)
But this answer doesn’t convince me.
many productivity experts[](hp://www.inboxoverload.com/time_-
management-partI.htm) will tell you to turn email off for most
of the day, and open it in specific slots throughout the day, to
avoid context swites, etc. is will protect your flow on the
tasks you should be focused on. is is btw different between
managers and makers, and is similar to how their calendars look
like (see a great post⁹ by Paul Graham ). I would say that the
more reactive your role is, the more responsive you probably
need to be to email, and the less actual creative flow you can
⁹http://www.paulgraham.com/makersschedule.html
Agility at Large 67
expect. When you do need to make something, TURN YOUR
EMAIL OFF.
I would add a caveat to this rule to say that in collaborative
environments like Agile teams, care and balance need to be
applied to allow both Flow to happen, as well as collaboration
and fast feedba/osmosis in the team.
Now what do we tell those makers of soware, that we instruct
to ignore their EMAILs for most of the day? that they need to
deal with defects as soon as possible? Why?
e reason its different is that emails during the day don’t really
“ROT” like the vegetables in the market, do they? or at least a
major part of them doesn’t. e cost of addressing an email a few
hours late is not mu different than addressing it a few minutes
aer its sent.
Again, the caveat is those decisions others are making in our
team, that they want fast feedba and collaboration on. We
should find a way to allow those to come in (maybe by coming
by and talking?), maybe by marking the emails from the team as
higher priority, whatever.
With defects or decisions in soware development in general its
different. the cost to deal with late feedba is exponentially
higher as time goes by. Also, having the large inventory of those
issues risks the release since you don’t exactly know how long it
will take you to fix all of them.
See this classic piece by Sco W Ambler¹⁰:
¹⁰http://www.ambysoft.com/essays/whyAgileWorksFeedback.html
Agility at Large 68
Ba to email – yes, if you keep all emails to the end of the
day, you don’t know exactly how mu time it will take to fully
address them. but you can decide whether you are scope-driven
so you get to inbox zero every day (e out 0boxer¹¹ btw for a
nice gmail extension that makes a game out of this…), or whether
you give a time-slot priority based and do what you can, and
periodically deal with the overflow.
For sure, probably reading your mailing lists (e.g. kanbandev¹²,
agile-testing) are all highly valuable, but can be described as
intangible benefits to the day, so can be scoped out if necessary.
¹¹http://www.0boxer.com/
¹²http://groups.yahoo.com/group/kanbandev/
Agility at Large 69
Again, some of us actually see participation in the lists as a
tangible ROI, but then probably the way to deal with that is put
it on our sedule, think about the appropriate SLA, etc. If its
important enough to answer in realtime – then by all means
make kanbandev a high priority email in your inbox and let it
thru. Have it SMS you, twit you, whatever. But be aware of the
decisions you are making. is is similar to managing demand
for a product development group…
e decision about the level of WIP and cycle time you are shoot-
ing for should be an economy-driven decision. both context
swites as well as late feedba have a price, in the waste they
create. you need to weigh the price and decide what is best for
your context.
e reality of product development in most of the projects out
there, seems to be that its MUCH more economic to build quality
in¹³ and don’t let defects rot outside in the sun.
PS If MY inbox was turned off, I would probably not see this
email from my colleague and write this post. Now what would
be the price if I answer him in the evening? Probably the cost
of answering and dealing with the feedba would be the same.
inking about it caused me to context swit and write this
blog post. Now I usually just defer answering to su emails,
and writing blog items (I use rememberthemilk.com and have
various dra post ideas there that I get to at some point). If I was
perfect, my algorithm for when to answer and when to defer
would really be economically sound. Since I’m not, it’s probably
more about enjoying the moment and the journey. Whi is
something this colleague of mine especially appreciates… you
¹³http://agilesoftwaredevelopment.com/blog/pbielicki/seven-principles-lean-
software-development-build-quality
Agility at Large 70
know who you are!
Agility at Large 71
2.5 Punctuated Equilibriums, Contain-
ers, all things Complexity and how Kan-
ban fits in
The Kanban for Simple problems Myth
Depending on who you listen to, you might get the idea that
a Kanban system might be great for simple problems, or even
complicated ones, but when the going gets tough and a complex
problem needs to be solved, you need something like Scrum (See
Ken Swaber’s post¹⁴ and don’t skip the great comment thread).
I don’t know if those making these statements really mean
them or are using them as FUD¹⁵ to try to protect the Scrum
brand. I am trying to figure this out for myself and thought I
would share my thoughts. I will of course try to stand on the
shoulders of giants in the Kanban and Complexity world like
David J Anderson¹⁶ and Dave Snowden, and mainly summarize
my understanding.
My approa here will be to lay out my understanding of the
requirements from an approa that embraces Complexity, and
then how I think Kanban maps to those requirements.
¹⁴http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-
2/
¹⁵http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
¹⁶http://agilemanagement.net/images/uploads/KanbanWhenIsItNotAppropriate.pdf
Agility at Large 72
So what should be the behavior of an approach
that embraces Complexity?
It seems that simple, non-prescriptive frameworks is what you
need when you are working on a complex domain. ese allow
emergence and empirical learning. In order to learn you need
feedba. In order to have effective feedba, you need to output
from the system. In order to have fast learning you need fast
feedba, and for fast feedba you need early and ongoing
output. When I explain the Agile Manifesto¹⁷ to people I lay
this as the main rationale for “Working Soware”. You want to
learn fast both about the fit of the product to the needs of the
business/users, as well as the fit of the development process to
the task at hand. You “Inspect and Adapt” both the Product and
the Process.
is emergence seems to work best when the work is constrained
in several ways. Takeui and Nonaka in a 1986 Harvard Busi-
ness Review study entitled “e New New Product Development
Game” describe timeboxing as one constraint. When coupled
with a higher purpose/energizing vision this leads to faster time
to market and product innovations/creativity.
A Scrum and Complexity ¹⁸post at AgileEvolution.com ¹⁹talks
about punctuated equilibrium – the equilibrium being the “Safety
Zone” of working in a stable system for a while (e.g. during a
Scrum Sprint when the Sprint Balog does not shi within the
sprint) punctuated by events that allow the aos/shiing world
outside to affect the system, and then return to the “Safety Zone”
¹⁷http://yuvalyeret.com/agilemanifesto.org
¹⁸http://www.agileevolution.com/scrum-and-complexity-theory
¹⁹http://www.agileevolution.com
Agility at Large 73
to have an opportunity for behaviour that fits the new reality to
emerge. is has been observed in nature as well as contributing
to effective evolution.
Ken Swaber talks about the container: -
“A container is a closed space where things can get
done, regardless of the overall complexity of the
problem. In the case of Scrum, a container is a
Sprint, an iteration. We put people with all the skills
needed to solve the problem in the container. We
put the highest value problems to be solved into
the container. en we protect the container from
any outside disturbances while the people aempt
to bring the problem to a solution. We control the
container by time-boxing the length of time that
we allow the problem to be worked on. We let the
people select problems of a size that can be brought
to fruition during the time-box. At the end of the
time-box, we open the container and inspect the
results. We then reset the container (adaptation) for
the next time-box.”
To sum up – we need Containers, Punctuated Equilibrium, and
freedom for emergent behavior within these containers.
Well, does Kanban embrace Complexity?
If we start from Punctuated Equilibrium – You might think
Kanban doesn’t provide it since it doesn’t provide the safety zone
of the sprint. But actually, if your policy is that you don’t tou
Agility at Large 74
what is currently in progress, you get the environment you need.
ere is the stability of the work in progress, and opening the
hat to the aos on the outside whenever work is completed
and we pull a new item to work on. e next items to work on
can ange as many times as we want. We just care about the
snapshot state of the items ready to be pulled in when we open
the hat. Yes, you can say expedited items can interrupt that
equilibrium. But Scrum teams deal with expedited and support
items as well. Both approaes will tell you to try to shape the
demand su that you reduce the amount of these interruptions,
and try to create teams that can focus and aieve effective flow.
Emerging Process in Kanban
Beyond that, remember that the Kanban Method starts from your
current reality and helps you see the dysfunctions, wastes and
inefficiencies and provides the vision of a beer reality. e
specific steps that you need to take from where you are towards
the effective flow vision will differ depending on your context.
at is by the way part of how Kanban embraces complexity.
It doesn’t prescribe a lot of practices or roles. It anowledges
your context is your context, and while there might be some
good practices that might fit some situations, in complex systems
you cannot even get a playbook saying this practice will get you
out of this mess. You only get a catalog of practices/ideas that
you might want to try out and see if they are a step in the right
direction. If they are, reinforce them. If they are not, throw them
away and oose something new. Evolve your system of work
towards a more productive and valuable state.
Agility at Large 75
The Kanban Container for Punctuated Equilib-
rium
If we dive into the details, one might ask what is the unit of work
that is the container in Kanban. What is the equivalent of the
Scrum Sprint Container? I see several options. One is to look at
the level of the Business Value Increment (BVI) (or Minimally
Marketable Feature, MVF, whatever you prefer to call those).
When you pull in a BVI, you set a clear boundary and create
a container for people to play in. ey now need to deliver
smaller slices of functionality until they rea a state where
they can output the BVI. Within that container the functionality
requirements might ange adding and removing stories/tasks
and the implementation will emerge.
ere is nothing in Kanban that tells you what it means to be
ready to start working on a BVI and what it means for a BVI
to be done. You start with your current process policies, and
hopefully with time you adjust your policies to get beer results
from the container. If you see that you waste too mu time
hunting for details aer starting, you might try tightening up
your definition of READY. If you see you are spending too mu
effort upstream of the work, you might want to try relaxing your
definition of READY. If you get too mu failure demand, try a
tighter definition of DONE. You get the opportunities to affect
the constraints of the container.
Another option is to look at a lower level as the container. Maybe
a User Story is a beer container? have a safety zone while
working on the story, and look at the story boundary as the time
you look outside? e BVI resonates beer with me personally,
but I’m not sure about it, and would love to hear what others
Agility at Large 76
think.
But aren’t we missing the Timeboxing?
One problem with a Feature/BVI is that it’s missing the time-
box. e timebox is another constraint/aspect of the container.
Without it we are missing a certain pressure to be creative and
innovate. On the other hand, with it we might be pressured too
mu and sacrifice quality or value for the sake of time. In a
sterile world, the Scrum Timebox provides the pressure while
allowing continued work to deliver value if the direction that
emerges at the end of the timebox is seemed useful. In reality,
the timebox itself sometimes provides too mu pressure, leading
to lower quality, unsustainable pace, or losing opportunities for
value innovation.
Don Reinertsen recommends we look at Networks and Operating
Systems for ideas. Modern operating systems need to deal with
processes/jobs that have unpredictable duration, and still provide
responsive multi-tasking. ey simply cannot “trust” a process
to return control to the operating system to allow another process
to get some CPU time. So they use pre-emption. is means that
aer a time-slice called quantum, the operating system wakes up
and has a ance to decide what to do. Do we keep running the
current process, or is it beer value for the overall system to evict
it and run another process? We can use this quantum approa
with Kanban as well. We can set a quantum time for ea work
item in progress. When that time expires we decide whether we
get more value from continuing to work on it, or from finishing
it up and evicting it. Applied to BVIs, it means that aer a
certain time, we wake up and run a semi “steering commiee”
Agility at Large 77
for that BVI and decide whether to continue developing it, throw
it away, trim the tail, or whatever else we want to do. is can
add timeboxing that is BVI specific.
ere is more to be said about how this BVI as the container
might work, but let’s leave it to a future date. is post is running
long anyhow. I also think FDD Design/Build by Feature might
provide some practical examples of how this might look like.
How can we improve Kanban for Complexity?
Well, assuming you are convinced that the right Kanban system
can embrace complexity, there is only one issue I’m thinking
about - Not all Kanban systems will embrace complexity effec-
tively enough. If your process has too many prescriptions and
hand-offs, not enough protection of the work in process, not
enough punctuation opportunities to invite aos to pay a visit,
then your Kanban system might do you a disservice.
Kanban talks about starting with what you have. Assuming
what you have is not a good system for embracing complexity,
what do we do to ensure Continuous Improvement / Evolution
of the system is towards a direction that beer embraces com-
plexity?
Is it enough to set the compass to the “Improved Flow” North
Star? Do we need to give more guidance? I’m still thinking
about this, hopefully you are now too… Leave a comment and
let me know what you think…
Agility at Large 78
Other Recommended Reading/References
• hp://www.agileevolution.com/scrum-and-complexity-theory
• New New Product Development Game - hp://www.sao.corvallis.or.us/drup
• Kanban - When Is It Not Appropriate - David Anderson at
LKBE11 - hp://agilemanagement.net/images/uploads/KanbanWhenIsItNo
Video at hp://vimeo.com/30637740
• Feature Injection - hp://www.infoq.com/news/2009/05/feature-
injection-comics
• Dave Snowden on Cynefin - hp://vimeo.com/30596502
Agility at Large 79
2.6 The Ant and the Grasshopper – Ap-
plication for product development
I’m sure everyone is familiar with some version of the e Ant
and the Grasshopper²⁰
While talking to a Product Manager today, I was asked “How
come we always end up without QA resources at the end of the
version” and was reminded of this tale. Most projects behave like
the Grasshopper. Focusing on Features like Summer is endless,
building a QA debt through the project/release.
When the Stabilization/End Game/Hardening time/Winter ar-
rives, they find out they have a problem. ink of ea feature
as a ild Grasshopper. ey bred a family they cannot feed
through the winter. ey have too many features to take thru
hardening, in a fixed time. (Yeah, Yeah, the metaphor only goes
so far…)
Alternatively, in Agile/Kanban projects, we want to be the
ants, always thinking forward, always staying in a sustainable
mode, where we have enough food to feed ourselves and family
throughout the winter, and don’t breed too mu that you won’t
be able to survive (here comes the part where you say – a lot
of ants do die, its part of the plan, etc. – I have an interesting
comment on that – related to Lean Startup and Discovery cycle,
for sometime else)
What I love when I see it, is teams that start to understand this,
where suddenly its a problem of the whole team to prepare for
²⁰http://en.wikipedia.org/wiki/The_Ant_and_the_Grasshopper
Agility at Large 80
winter. Its not just a problem of the QA team anymore. e
whole team starts to think about how to prepare beer, and how
to setup the right pace of features that we can sustain through
the project.
I say to you developers out there – “To help testing be more
efficient today is to be able to work on more features tomorrow”.
Remember – its either you think testability from the start,
or you end up testing anyhow, under pressure, without
the ability to really do something useful to help you, just
focusing on survival mode.
Agility at Large 81
2.7 Thoughts about the Toyota Kata
in the world of Knowledge/Technology
work
Toyota Kata is my 2011 book of the year. It started me on a lot of
thinking streaks and opened a lot of threads for how to effectively
do my job as a Lean/Agile consultant. I have to say that many
threads are still open. But I recently reread some sections of the
book, and it’s about time to talk about it a bit, especially since I
keep recommending it to people.
What is the Toyota Kata?
If you haven’t heard of the Toyota Kata²¹ book, you can head
over to Mike Rother’s Toyota Kata Homepage²² where you can
find good presentations about the key topics as well as a good
synopsis of the book, whi I won’t repeat here. At a very very
high level this book is about the Toyota approa to management
– whi is to have a focused approa to improvement (e
Improvement Kata) and a focused approa to teaing people
how to focus on improvement (e Coaing Kata).
As a practitioner of Agile and Kanban in soware/product
development environments, I love this focus on what REALLY
makes Toyota ti. ere’s certainly a lot of bad mouthing of
Lean and Toyota’s approa to production out there, calling it
²¹http://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/
dp/0071635238
²²http://www-personal.umich.edu/\protect$\relax\sim$mrother/Homepage.html
Agility at Large 82
tool-focused and meanistic/unfocused. e Kata is book is
very aligned with our view of Lean as Kanban practitioners –
the key being the thinking about improvement rather than the
actual tools.
Let me try to review it by trying to apply it to the context of a
Kanban team.
The Improvement Kata
e Kata starts with understanding the direction. Let’s say we
bought the Kanban / Lean Startup cool-aid and are aiming at the
direction of faster end to end feedba and effectiveness through
having dramatically shorter Cycle Times.
en we grasp the current condition. is is similar to the
“Visualize the work” step in Kanban.
Establish the Next Target Condition can mean – ok now that we
understand our mean cycle time is 8 weeks and it is unstable –
ranging 4-12 weeks and the direction is towards a stable cycle
time of days not weeks, lets aim at stable 8 weeks meaning to
reduce the variability from 4 weeks in ea direction to 1 week
in ea direction. Sounds like a reasonable next target condition
to me.
Now we try to make that happen and encounter obstacles. We
would need to overcome them.
e Improvement Kata talks about a daily cycle of looking at the
current actual condition, in light of the current target condition,
understanding the obstacles explaining the gaps between the
actual and the target, and urging us to oose one of the obstacles
and work to address it in small experimentation steps using the
Agility at Large 83
PDCA cycle (Plan Do Che Act). On top of this approa sits the
Coaing Kata with Five estions that are aimed at coaing
people on using the Improvement Kata. e aim is for managers
to coa their people in their improvement work.
is is great stuff. Really great. e key point here is the focus
on the job of people to always improve in a focused way, and the
job of management to work on improvement themselves but also
work to improve the improvement capabilities of their people.
Use this as a repeating building blo, tie it to the value system
and objectives of people throughout the organization and you
stand a real ance for improvement work to become part of your
DNA.
I’m just not clear on how to implement this in Product Devel-
opment/Knowledge Work. Our processing cycles are orders of
magnitude slower than in production. Whi means we either do
coaing/improvement cycles without the ability to see samples
of finished work – whi invalidates the scientific nature of
the experimentation cycles, or we have to suffice with mu
slower improvement cycles, whi makes improvement part of
the outer-loop cadence (e.g. retrospectives, operation reviews)
rather than the inner-loop cadence (e.g. Daily Syncs). Whi is
a real shame because it seems Mike associates a lot of the power
of the Kata with the fact it is done very oen.
At the moment I’m planning to use the Improvement Kata /
Coaing Kata for outer-loop cadence, but am still trying to find
a way to run it for the inner-loop. If you have some idea or
experience with this, help me out…
A possible direction is to do the improvement/coaing kata
for local internal processes e.g. Dev/Test in the inner-loop. If
a developer is using TDD then we can apply the Kata for his
Agility at Large 84
TDD cycles. For a tester we can do it for his exploratory testing
sessions or for his test cases.
Highlights
Having a reason to avoid relaxing processes
Toyota plant manager would likely say something
like this to the assembly manager: “You are correct
that the extra paperwork and first-piece inspection
requirements are obstacles to aieving a smaller lot
size. ank you for pointing that out. However, the
fact that we want to reduce lot sizes is not optional
nor open for discussion, because it moves us closer to
our vision of a one-by-one flow. Rather than losing
time discussing whether or not we should reduce
the lot size, please turn your aention to those two
obstacles standing in the way of our progress. Please
go observe the current paperwork and inspection
processes and report ba what you learn. Aer that
I will ask you to make a proposal for how we can
move to a one day lot size without increasing our
cost.”
ink about the scrum team talking about the overhead of
weekly sprints and asking to use longer 2-week or 3-week sprints.
Or the kanban team complaining about low WIP limits. Or
testers complaining about the overhead of Small Bates. I love
this quote highlighting the use of a vision to act as a decision
filter for su policy discussions. We are using 1-week sprints
because it is bringing us closer to cycle times measured in days.
Agility at Large 85
We are using low WIP / small bates thru testing for the same
reason. Now instead of trying to revert to longer sprints/higher
WIP/larger bates, let’s observe what are the overheads that
make sprints/WIP/small bates painful and let’s see a proposal
for how we can be more effective using them. I actually started
to use this approa in the last couple of months. An exercise
I frequently run in management workshops²³ is trying to think
what would enforcing a WIP limit entail for an organization.
What would be the obstacles. It helps with ange management
to have a ance to vent some obstacles and understand how
other companies deal with them and how this group can deal
with them, even without starting to actually enforce a WIP limit.
e important point is that without the overaring direction
/ north star, it is hard to remember the rationale for many of
the lean/agile practices/tools. If we don’t remember we believe
shorter cycles lead to faster feedba leading to higher efficiency,
it is easy to fall into the trap of regression to easier more
comfortable ways of the past.
Ability to work according to Sequence is an
indication of maturity
Sequence aainment is a tighter process metric,
whi means if the assembly process has to deviate
from the intended leveling sequence, then even if
shipments are still made on time, you do not have
sequence aainment for that day
In product development this is similar to pulling cards out of
order from your input queue / Product Balog. Skipping cards
²³http://agilesparks.com/ManagementFocusWorkshop
Agility at Large 86
in the balog is a good indication of a capability problem. A
target condition can be “we always pull from the top of our
input queue/balog so that we aieve alignment with the value
priorities of the business”. A typical obstacle for this target
condition is a sparse skills/talent matrix. And a next step can
be knowledge transfer or training.
The difference between a Target Condition and
a Target
e Improvement Kata talks about seing Target Conditions,
whi are Process Conditions, whi in turn enable reaing a
Target Boom Line result. It says that having outcome targets is
important, but the means for geing to those outcomes should
be the real focus of management work. is is quite different
from how many managers see the world, especially in the era of
Management By Objectives. We have a lot of work to do to tea
managers to think about managing by Means in order to rea
Outcomes.
For example Sprint Velocity is important, but more important is
managing the means towards improving the velocity. So discuss
the target condition you need in order to have a high velocity and
manage the obstacles towards that. It can be “READY” policies,
smaller stories, healthy Continuous Integration system, TDD or
whatever you feel enables a higher velocity.
Vague Target Conditions
It is important to understand that specifying a target condition
doesn’t mean we define the solution up front. We define the
required condition up front, and let the solution emerge through
experimentation cycles. We do have a desired behavior of the
process we are improving at the bla box level and we tweak
Agility at Large 87
the process towards the required behavior through probe-sense-
respond cycles as defined in Cynefin²⁴ for example. Boom line
in my understanding the Toyota Improvement Kata is compati-
ble with Complexity inking.
Be hard on the Process – Be soft on the operators
What a great quote to start a retrospective with…
It means that if there are problems most ances are they are
process related. e process needs to help people succeed.
(individual and interactions over processes and tools?)
It is similar to deming saying 95% of what affects performance is
the system. Rest 5% is people.
Or five whys striving to policy/system impediments/obstacles
underlying people errors.
My view is that the role of people is to adapt the system/process
so they affect more than 5% at the end of the day. at is the im-
portance of the improvement kata and continuous improvement
in general
There are currently no autonomous, self-directed
teams at Toyota
Actually, Toyota even considers expecting people to autonomously
own improvements “Disrespectful of People”. While operators
and teams do participate in voluntary improvement activities,
improvement is part of the job function of team leaders, super-
visors/managers and engineers.
Applied to our typical agile team, what this would mean is
that the main ownership for improvement lies in the hands of
leaders/managers rather than the teams/engineers. Certainly
interesting thinking. I do agree that managers/leaders need to
²⁴http://en.wikipedia.org/wiki/Cynefin
Agility at Large 88
lead the improvement efforts. I do think that using fair process
and involving team members makes more sense in knowledge
work environments su as product development.
Mike does talk about operators participating in improvement
work – but mainly as improving their understanding of Kaizen
and to help understand whether they are candidates for promo-
tion.
A good take away is to let someone tale a tough process/obsta-
cle to consider whether they are ready for promotion. Maybe a
beer alternative than let them own a certain delivery objective?
To develop your own capability, the effort will
have to be internally led, from the top. If the
top does not change behavior and lead, then
the organization will not change either
Managers should lead the improvement effort. Loud and clear…
is actually means running improvement kata at a process and
coaing their people in their improvement katas. Not a trivial
request from managers. ink about the VP R&D overseeing the
improvement kata at a testing process or coaing his Director of
QA in his improvement kata for an automation allenge. Part
of this problem is a Cat-22. In order for the organization to
know how to do this they need to try it hands on. In order to
have internal leadership managers need to try it first.
Part of the approa Mike suggests is having an Advance Team
experimenting with the improvement kata hands on, before
rolling it out throughout the organization. I actually like the
implications, at least in theory. As a Kanban example, have
senior leadership involved in using Kanban to improve a process,
so they are proficient enough in the improvement process and
Agility at Large 89
its effects when Kanban becomes an improvement approa
used more and more within the organization. How can we ask
them to coa their people otherwise… is certainly helps with
stiiness of the ange/improvement effort, although it might
slow it down or even blo it from taking off in the first place in
places whi are not ready for it (at is a “Fail Fast” scenario
whi is probably preferable. We’ve all seen the stalled ange
initiative – it’s not a prey picture, not for the organization and
neither for the consultants)
coach only one target condition at a time, which
generally means one mentee at a time
We typically use forums to coa people towards improvement.
Mike’s recommendation to coa one on one is an interesting
and allenging one. Need to think about it some more.
(1) a restatement of the overall theme (for exam-
ple, “To develop improvement kata behavior in
the organization”), and (2) a reiteration of “why
we experiment,”
Another great quote to start a retrospective with… the current
focus of improvement and the reason for experimentation, to
facilitate open healthy focused retrospection.
Summary
I hope I sparked your interest in this great book. ere is still lots
of work to be done mapping the Improvement/Coaing Katas
to Knowledge Work, but even at raw unmapped form there are
great insights in this book. Highly Recommended.
Agility at Large 90
One last note – if you are interested in this topic, you will prob-
ably find Henrik Kniberg’s Tokyo Scrum Gathering Keynote²⁵
about Change interesting as well…
²⁵http://blog.crisp.se/2011/11/07/henrikkniberg/tokyo-scrum-gathering-keynote-
everybody-wants-change-but-nobody-likes-to-be-changed
Agility at Large 91
2.8 “We are already Lean/Agile” – Re-
ally?
These days more and more organizations think
they are Agile
A couple of years ago when you talked to people about agile a
common response “why should we”, “it won’t work here”, or “so
this is the new fad? What will come next?”
Times have anged. And a sign of the fact that agile is becoming
more mainstream is that it being diluted and a common response
these days is “but we are already agile!”. I want to share a couple
of questions to see if you are indeed agile.
What does it mean to be Lean/Agile
At a very high level what does it mean to be agile ? At a
first level agile is an approa to development that embraces
the complexity and uncertainty in both demand, specification
and implementation implications by working in short cycles on
small bates of work, constantly seeking fast feedba, and
empowering people to work together focused on clear business
goals, at a sustainable pace.
A second level of lean/agile is about embracing the complexity
of the systems/processes used to take soware from idea to
realized value and using an inspect and adapt approa to let
beer approaes emerge. is is a mu more pervasive aspect
of lean/agile. Organizations fail to realize the real power and
Agility at Large 92
improvements are as a result of multiple iterations thru process
experiments, always aiming to aieve goals of beer delivery
capabilities.
Are you delivering in an Agile way?
When you hear someone talking about being agile ask them:
• Do your users/business stakeholders consider your deliv-
ery cycle fast enough?
• Are you developing the Right things? Do you use your
agility to drive small features to production to validate
the value of a certain direction and then continue to
deliver a pipeline of more small features while constantly
evaluating feedba?
• Are you doing things the right way? How mu rework
is there in your work? How mu of the demand is
generated by not doing things right the first time?
Are you improving in a Lean/Agile way?
And then ask some more questions that will dive deeper into the
improvement aspects of lean/agile:
• How oen do you stop to reflect on our performance/ca-
pabilities?
• Do you have a capabilities goal/condition you are striving
for? How many people are aware of it?
Agility at Large 93
• How do u know your current state compared to that goal?
• Do you run process experiments aimed at improvement
towards a target condition we are focusing on?
• How many of these process experiments do you try in a
month?
• What is the cycle time from deciding to work on a process
improvement to finishing an iteration of the experiment
on it?
• What are the current main obstacles to improving towards
your goal? How long have you known about them?
What it means
You might find that you have an “agile” organization that is not
so agile when considering the service provided to the business.
In many of those cases when you dive deeper you will find a
weak, unfocused or even nonexistent improvement engine/cul-
ture and a static process/system.
Doing scrum sprints, user stories, or kanban boards is just the
starting point of the agile journey.
e main event is improving. Practices su us limiting work in
process or focusing on a single sprint help with that.
ere is a whole set of approaes beyond that - A3, five whys,
retrospectives, operation reviews, statistical process control, the
Toyota improvement kata, solutions focus, theory of constraints
and many more – all used to improve.
Agility at Large 94
Are you ready for the real world of lean/agile?
You might find this recent prezi useful to look at these multiple
layers of improvement and the various approaes used.
e layers of Agility²⁶ on Prezi²⁷
²⁶http://prezi.com/5yzqecopqwez/the-layers-of-agility/
²⁷http://prezi.com
Agility at Large 95
2.9 Why I think Slack is highly impor-
tant during an Agile/Kanban transition
Actually, the title is wrong. I think Sla is highly important dur-
ing any ange initiative where you expect continuous improve-
ment of the process and practices. e importance of Sla is not
new. Not in manufacturing, and not in the Soware Engineering
world. One of my favorite books is Sla: Geing Past Burnout,
Busywork, and the Myth of Total Efficiency²⁸ by Tom Demarco.
Actually anything by Tom is a gem worth reading if you’re
serious about managing Product Development organizations…
But today I had an epiphany. One of the biggest allenges
we face as consultants trying to allenge organizations to be
more effective/agile/lean, is that the people simply don’t have
enough Sla. ey don’t have enough time to meet with us.
ey don’t have enough time to meet and retrospect. ey don’t
have enough time to experiment. Experimentation takes time
– you need to think about what to try, if you take a risk, there
is a ance you will fail and lose time. Its very frustrating as a
consultant/coa. You have so mu to give, you see so many
opportunities for improvement, you know that if the team will
just sit in a room for an hour they will come up with ideas that
can help. You know that if that Developer from the team has
some sla time on his hands, he will think of a way to make
that build run faster. at test automation suite easier to update.
My pledge to managers leading Agile/Kanban transitions
²⁸http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficiency/dp/
0767907698
Agility at Large 96
Please Please Please consider how to add Sla to your system.
Especially during a ange initiative it will help you get the most
out of it. People will be more engaged, you will get mu more
out of your efforts and budget. I pledge to try and convince my
clients to do this…
Now that you’re convinced, lets discuss how to actually do it in
practice. If you’re not convinced or think you have other ways
to beer drive this point, I’m all ears… and the post is open for
comments…
To effectively use Sla I think you need to do two main things:
1. Account for Sla in your resource planning.
2. Have effective meanisms to use the Sla for the best
possible purposes.
Accounting for Sla in the plans is is quite straight-forward
as soon as you convinced your stakeholders it is a worthwhile
investment. Pointing them towards Google (20% time²⁹…), At-
lassian (20% time and FedEx Day³⁰) and other companies using
Sla as a core part of their system, might help you. Tenically,
just reduce the resource capacity % in whatever method you
are using to manage your projects/commitments. Another great
way is to use the Sla that is inherent to the plan/development
process. What do I mean? For example – in a Kanban/TOC/Flow
system the bolene doesn’t have any inherent Sla. But
upstream and downstream from it, if you work in Pull mode, you
²⁹http://almaer.com/blog/the-genius-behind-the-google-20-time-it-isnt-the-time
³⁰http://stufftohelpyouout.blogspot.com/2010/07/atlassian-20-time-and-fedex-
day.html
Agility at Large 97
will find Sla. is is because they can process faster than the
bolene, so obviously there will be times they cannot process
because they are bound by a WIP Limit (Or TOC Rope). In
Iteration-based Agile this sla takes the form of some free time
on the last few days of the iteration if you’re not the tester. In
both these scenarios when you have Sla, you can either throw
it at the bolene’s current work, or use it in other ways.
Effectively using the Sla
Now that you have some sla time, what do you do with it?
One flow/continuous oriented approa is the Google 20%³¹.
People simply have the sla to work on other things in parallel
to the ongoing core work.
Another approa is to setup special events, like Atlassian FedEx
Day³². ese events are a time where the entire team/organiza-
tion is focused on Sla kind of work, and it is probably a good
idea to use those especially when starting, to kioff the mindset
that Sla is a good thing, and show some examples of what can
be aieved.
What do you actually do on Sla time?
One type of activity is pushing the product forward in some
innovative small ways that are off-road from the main tra of
the project/release. You need to be careful here – messing around
with the core behavior of the product is probably not a good idea
without the blessing of the Product organization…
I would imagine the google engineers don’t mess around with
the homepage too mu. ey introduce their innovations via
³¹http://almaer.com/blog/the-genius-behind-the-google-20-time-it-isnt-the-time
³²http://blogs.atlassian.com/rebelutionary/archives/000495.html
Agility at Large 98
Google Labs, plugins, etc. Some ideas make their way into the
mainstream product, some become mainstream products (e.g.
GMail)
I wanted to talk about a second kind of activity – the one that
pushes the capability of the organization forward. Here, your
aim is to identify areas where improving can have an effect on
the boom line performance of your organization, and then find
ways to improve there.
I discussed before³³ some scenarios like this, but to reiterate the
important point – you want to use Sla to help Exploit your
current system Bolene. Now, as I said earlier, one way
to simply throw the Sla capacity at the current work of the
bolene. is will help tactically, but will not improve the
capacity of the Bolene in any long-term fashion. You should
balance the tactic solution with finding ways to spend Sla
capacity on things that will really make the Bolene more
efficient.
What this means is that a lot of times, the resources working to
improve the capabilities of a function, don’t even belong to that
function. is is why cross-functional teams and a holistic end-
to-end view of the Value Stream is so important… without it you
can improve things locally but have zero (or even negative) effect
on the boom line.
³³http://yuvalyeret.com/2010/08/03/finding-the-right-dev-to-test-ratio-when-
working-in-kanban/
Agility at Large 99
2.10 Using Kanban to drive Continuous
Improvement and Management Teams
It seems like new uses for Kanban are cropping up every day.
And the interesting thing is that in some cases, several different
organizations/people come up with similar ideas spontaneously.
One of those ideas is to use Kanban in order to drive Continuous
Improvement efforts.
I’ve recently described su an approa in my presentation for
Lean Conference 2010 in Atlanta (#LSSC10), it also came up in
other talks and others seem to be having great success using this
(E.g. . In Israel I saw it come up in Kanban workshops we hold
for clients, as well as some ideas that clients have aer they start
using Kanban for other things. It w
ink of mgmt teams at the organization level, or for any
group (e.g. VP R&D and his staff members, CEO and the other
CXOs/VPs, Group leader with his team leads).
We want this team to lead Continuous Improvement initiatives
in their organization. Both at the aggregate level collating and
coordinating efforts the various teams they’re in arge of, as
well as initiatives that originate and are focused at their level.
Who hasn’t seen the lessons learned exercise whi was great,
but when you come some time later, the action items are at best
documented, lets not even talk about traed and executed.
Same goes for Agile Retrospectives, even though the frequency
of the retrospectives improves the situation a bit and nags the
team some more…
Agility at Large 100
Enter Kanban. Now, really, you don’t need anything fancy.
We mainly are talking about creating a balog of action items.
Prioritizing it. And oosing a FEW action items for execution
ea time. Until you are finished with those, don’t divert or
context swit to any other initiative. is is where the Kanban
WIP Limit comes into play…
is of course can be used for ANY kind of action item for the
management team.
Again, you don’t have to do it with Kanban. A shared action
item list you e items off as you go can work just as well.
I used Sharepoint, a whiteboard, and other ways to aieve
that. With Kanban you get the added benefit of the WIP limits.
From my experience, management teams and other sorts of
commiees, are quite horrible at focusing and managing their
WIP, so Kanban can really help.
In addition, if your organization is currently undergoing a
Lean/Agile transition, adopting a Kanban board can help you
lead by example and show that you are adopting Lean/Agile
methods. It will also help you understand what is happening
at the production floor, and adopt the language being used by
the organization.
at is why, with our customers over at Agilesparks we are
starting to use Kanban boards to drive Agile Transitions, and
recommend to the team managing the transition to adopt his
board and style for their own use.
Other elements of Lean that can help here are A3 and PDM.
A3 (see hp://www.crisp.se/lean/a3-template³⁴) is problem-solving
³⁴http://www.crisp.se/lean/a3-template
Agility at Large 101
tool originating in Toyota. Its beauty is that it drives you to be
concise and focused. Ea A3 describes a problem and what you
are trying to do about it, in essence bodying the PDCA Plan Do
Che Act cycle.
PDM – e Hoshin Kanri Policy Deployment Matrix³⁵) is an-
other way to practically use the PDCA cycle. I’ll try to describe
it in more depth some other time…
³⁵http://en.wikipedia.org/wiki/Hoshin_Kanri
Agility at Large 102
2.11 Want to experience agile in an ac-
celerated form and focus on innova-
tion at the same time? Try an agile
FedEx day!
A while ago I wrote about Sla and FedEx Day³⁶ and why I
think its important to have sla in the system, and why a FedEx
Day³⁷ is a good way to to run an innovation day.
A few days ago we had the first inaugural AgileSparks FedEx
Day.
Since we are, aer all, a company whi believes in agile
approaes, we decided to some dogfooding an run our FedEx
day in an agile form.
We started with identifying the Goal of the day and then decided
on a few key themes the innovations should focus on. is was
done offline a couple of days before the actual FedEx day. For
example, one of the themes was “Process Innovation – ings
that will enable us to do our work more effectively and bring
more value to our clients”.
With those themes defined, we opened the floor to brainstorming
of ideas to work on. is as well was started offline, by sharing
a google spreadsheet where ea member of the team could add
³⁶http://yuvalyeret.com/yuvalyeret.com/2010/09/15/why-i-think-slack-is-highly-
important-during-an-agilekanban-transition/
³⁷http://stufftohelpyouout.blogspot.com/2010/07/atlassian-20-time-and-fedex-
day.html
Agility at Large 103
his ideas. Some of us had some ideas in mind, some of us came
as a “Clean Slate”.
At the morning of the FedEx day itself, we started with a warm-
up – a great breakfast accompanied by running Presentation
Karaoke³⁸ whi was quite hilarious. I drew a presentation
covering the lifecycle of a buerfly whi I used as a metaphor
for an Agile Transition… but since our rule was that things that
happen in FedEx day stay in FedEx day, I will leave it at that …)
en we looked at the ideas, collected on a sunny window, both
ideas from the spreadsheet as well as other ideas that came up
during the warm-up and gathering time. Ea of us had to
oose an idea he is excited about, and that is how we did team
³⁸http://en.wikipedia.org/wiki/Powerpoint-Karaoke
Agility at Large 104
formation. We came up with 3 teams ea working on a different
idea.
We then started sprinting! we did 4 sprints of an hour, including
planning, demo and retrospective. e demos included the
whole team. During the sprints we worked on elaborating our
ideas, using Agile User Stories and teniques su as story
mapping, as well as started implementation and delivery of
“Working Soware”. It proved a real allenge to deliver on
su short sprints, especially for those of us who didn’t have a
somewhat formed idea at the starting point.
Agility at Large 105
In the middle of that we stopped for a qui lun and great
Vaniglia Ice Cream³⁹ (is is the best ice cream in Israel IMHO
btw… and we have an Ice Cream fetish in AgileSparks…)
At the end of the day we gathered to retrospect on the whole
experience and oose the winning idea. We decided that it
was a great experience, that pushed forward several important
ideas, as well as gave us the opportunity to experience on
our environment some of the practices and approaes we are
helping teams with.
³⁹http://hungryintelaviv.blogspot.com/2009/07/vaniglia-ice-cream.html
Agility at Large 106
One important insight was that you can use a FedEx day for
various purposes. Innovation is just one of them:
• Product Innovation
• Process Innovation
• Business Innovation
• Set-based approa for Solving a tough and important
problem
• Making a real dent in a cluster of small tenical debt
areas, or a big tenical debt.
Have you thought about running a FedEx day in your team/com-
pany? If you have been sprinting/urning for a while now, and
want to ange gears, consider something like a FedEx day.
If you also try some new lean/agile practices while at it, you get
double benefit! We believe that exercises/games bring acceler-
ated learning of any new approa to doing things. One of the
Agility at Large 107
cool things about a FedEx day is that its a mix of accelerated
delivery as well as accelerated learning.
3
Kanban - Not Just for
Software Development
108
Kanban - Not Just for Soware Development 109
3.1 Kanban in HR
Background
I recently had the opportunity to talk with a couple of HR
managers who were interested in how agile can help the HR
department become more effective. is was a context where
the product development is well into their agile journey, and we
are talking about a group of about 20-30 people providing HR
services like recruiting, training, social events to an enterprise
R&D organization in the 1000 people range.
What does agile mean for HR
Well, I tend to view HR as a service driven operation. ere is
demand of various types coming in. e HR turns this demand
into a service that the organization consumes/uses. A classic
example is recruiting. Demand is the hiring manager with the
new open position. e recruiting department helps fulfill this
demand, and the end result should be position fulfilled.
So the First thing we did in the session was explain how lean/ag-
ile aims to maximize effectiveness delivering value leveraging
the following understandings:
• Most HR Activities are knowledge work with high vari-
ability and learning. We are not sure about a candidate
so we want to maximize early feedba. We want to
understand whether a training we got a request for will
Kanban - Not Just for Soware Development 110
REALLY be interesting to the people to the level they will
sign and allocate their budget to it, to avoid spending
precious energy on things that get thrown away / anged
later.
• HR groups have a certain capacity. When overloaded
performance actually goes down, same like motorways,
computers, or development groups. So we should try to
use a system that lets the group limit multi-tasking to
healthy levels.
• Activities that are only half done are very dangerous. We
call that inventory / work in progress, and the more of
those we have, the harder it is to operate. It is harder to
focus, context swites cost more.
• ere is a lot variability in the demand as well as the
work required to deliver services. During ramp up times
recruiting for example is overburdened. Versatility within
the HR department is valuable to assist in dealing with this
variability.
Kanban
With this context in mind, I outlined Kanban as a Method to
drive for improvement in this context. What does this mean?
Kanban starts with the processes you currently have. You agree
to pursue evolutionary improvement, and to respect current state
but be open to ange it.
What you actually do is take the following steps:
Visualize the Work
Kanban - Not Just for Soware Development 111
Visualize the process/workflow of fulfilling the demand. For
example if we continue with the recruitment example – raise
need for position -> create position description -> publish >
filter candidates > best and final between a few top candidates >
prepare offer > send offer > signed offer > prep for onboarding
> onboard > 3 month – successful hire. With this workflow we
draw a kanban board. I recommend starting with a simple board
with a few steps – see below…
Empty kanban board
Now we populate the board with the current work, in ea of the
phases. A card represents a piece of work that when Done will
mean fulfilled service ( eg one open position)
populate board with work
We can use different indications to show different kinds of work,
work states su as bloed, who is currently working on what
and more. e idea is to visualize as mu of the state of
work as possible. Ideally in a big physical board visible in the
workspace of everyone or in frequently visited public space. is
Kanban - Not Just for Soware Development 112
creates transparency that will in and of itself spark interesting
discussions, raise problems to the surface and start creating a list
of problems we need to handle ( whi is good… )
We want people to use this board in their day to day activities.
e board should be the main tool used to tra work and
synronize. Lots of teams use daily sync meetings in front of
the board.
Limit the work in process
Next step is to recognize that there are limits to capability, and
work should be governed by capacity. What we actually do is
assign limits to numbers of cards/items in process. e most
common way is to say “no more than 3 cards in this board
lane” or “no more than 3 positions we are currently writing
descriptions for”. is creates a pull system, because it means
that once that limit is reaed, no new work can be pulled in,
until some work has been pulled by the downstream process.
is has the effect of “We’re all in this together, concerned about
delivering value, rather than just doing our job”. Very quily
some sla will be created by the pull system. e magic is
to divert this sla to help the work flow right now, but more
importantly find ways to improve the capacity of the bolene
that caused the flow to stop.
Limiting the work in process
Kanban - Not Just for Soware Development 113
An example is probably in order. If it seems like many positions
are in “sign” it might be interesting to use sla time to help
create beer templates or easier access to salary tables to reduce
the effort it takes to prepare offers. If it also seems like a lot
of offers are rejected since the candidate is not really serious,
it might make sense to find a eaper way to verify seriousness
before spending the effort to prepare an offer. What you actually
do will be context specific of course. e Kanban Method WIP
Limit will just waive the flow problems in front of your face and
beg you to deal with them, more intensively than before.
Manage the Flow
Start caring about the flow, the time it takes from start to finish,
from request/demand to finish. Care about the mean time, the
promises you can start making, the corner cases and what they
mean and how you can improve by learning from them. For
example if a typical position is handled start to finish in 4 weeks,
and you see a position took 1 week, look at it and try to think
what makes it a “Bright Spot”? Was the job description crisp and
sexy? Was the hiring manager devoted to making it happen?
Was the recruiter using some new sourcing tenique? Same for
the opposite case – what went wrong with that position that took
8 weeks?
Make your process policies explicit
is is a very interesting step. On the surface, this is very
meanistic. Seems like “Document your process”, what’s new
here? And what’s Agile about it?
First, just to make sure we understand, these policies are the rules
of the game. ings like the WIP Limit, the conditions for cards
being done in a certain phase and ready for the next one, the
Kanban - Not Just for Soware Development 114
policies for expediting work if necessary.
Explicit policies enable empowerment. ey improve the level of
coherency of the system among all people working on it. ey
can safely make local decisions that are aligned with the rules of
the game.
Beyond that, Explicit Policies are not static. ey should evolve
based on new understanding and learning. You should experi-
ment with them to see what works. e policies will be painful.
You will sometimes feel you are hiing a wall. at they are
creating constraints for you. at is good. Constraints drive
creativity. And if the policies are constraining you in a way
that’s driving you towards beer and beer flow, that’s great.
It means the pain is part of the gain. e discussions you will
have about what to do to make the policy work for you, will drive
the improvement action items. Sometimes you will relax policies
that went too far too early. Sometimes you will tighten things up
to drive for more improvement. is is one of the key practical
ways Kanban drives learning and Continuous Improvement –
Oh that holy grail…
Improve Collaboratively using Models
Finally, with the system in place, aer you start using it, there
will be opportunities to use models that apply for Flow systems.
I will not go into this. Suffice it to say that although the Kanban
system might seem simple, there are a lot of ways to look at a
system and improve it. If you’re interested in this area, I can
refer you to more material on the subject.
Kanban - Not Just for Soware Development 115
This is it
Yes, might seem simple at first, if you’re looking for the revo-
lution it is not here. On purpose. Kanban is an evolutionary
method. It aims to provide an alternative to classic sho
and awe ange programs that many organizations had bad
experience with. With Kanban you ange at the pace that works
for you. You can accelerate pace of ange as you become more
proficient in identifying the problems and experimenting with
solutions.
What did the friendly HR managers think? Well, they liked this
method, found it very applicable to various processes in the HR
department, and can’t wait to start. We are meeting in a couple
of days again to play some Kanban games and setup their boards.
I will report when there is more to tell…
Note that nothing here is very specific to HR of course. is
simple approa can be used to introduce ange in many
knowledge-oriented services. Many Kanban practitioners are
reporting Kanban boards popping up in other departments when
the IT group starts using it. It’s quite viral…
Kanban - Not Just for Soware Development 116
3.2 Using Kanban to improve audit
management
I was asked to write this post by Jon Terry for the LeanKitKanban
blog, as part of a series of guest posts. Jon loves unique
applications of kanban, especially outside the world of soware,
so I decided to write about kanban for audit management.
You can probably generalize this post even further to think
about how kanban can apply for a variety of knowledge driven
projects/activities.
Baground
Every time we at AgileSparks get a ance to go out of our
comfort zone of tenology delivery organizations, it excites us.
We believe that the thinking, principles and practices we use
for tenology delivery are very relevant in other knowledge-
intensive domains as well, and keep looking for opportunities to
test that belief. Our work with tenology delivery organizations
exposes us to other supporting activities in organizations. I
recently wrote on my blog about an HR group that we worked
with (and I have more updates about that group that I need to
write about…). is time I want to talk about another type of
activity – Audit.
An Information Tenology Audit group within an organization
is arged with auditing systems and processes mainly as part of
Risk Management. Let’s look at what Agile/Kanban might mean
in this context.
e context of Audit
Kanban - Not Just for Soware Development 117
e work in an Audit group can range from scripted audits
to verify adherence to standards, to investigative resear type
activity to explore what is going on and identify risks. When
talking to a couple of people from su an organization, I was
reminded of Scripted Testing and Exploratory Testing¹, and
running many, many learning loops as part of the investigation
being what makes a great auditor.
Audit groups can be very powerful in an organization. Healthy
organizations try to maintain their independence so they have
them report very high in the org art, sometimes directly to
the board. With this power comes great responsibility. You
really need to make sure you are doing things the right way.
Your findings need to be correct. But more than that, you
want to get buy-in to your findings from the audited group.
If you run a one-sided show, it will be hard to maintain trust
and open lines-of-communication. All this typically means lots
of interactions between senior managers, especially as findings
are being reviewed and prepared for publication, and a lot of
aention to detail and quality.
What are the allenges in Audit?
One of the huge and unique allenges is the funnel shape of the
work. Imagine a group of 20 auditors. Ea of them is working
on their own audit project. e first steps of scoping, resear,
preparation of report they can and do quite autonomously. But
as they approa milestones su as “First Dra sent to audited
group” and “Publication”, they need more and more involvement
by the more senior auditors and managers of the group. is is
due to the sensitive nature I mentioned earlier. is can create
¹http://en.wikipedia.org/wiki/Exploratory_testing
Kanban - Not Just for Soware Development 118
a bolene or at least lots of variability when you need a non-
instantly-available resource like a VP of the group or it’s GM.
Another allenge is that, of course, the auditor needs to work
with the audited group. She needs them to share documents,
allocate time, provide access to IT systems, and various other
aspects. Remember that, while she does serve a master that
is high above the audited group, they are still mainly focused
on their day-to-day activities and typically consider the audit
unwanted interference. Even if they INVITED the audit they
still have their daily activities to take care of, so the auditor might
have to deal with lots of non-instantly-available resources – with
having to wait.
Side note: is by the way is very similar to the allenges of
the Agile consultant when working with a group. Regardless
of who invited us in, whether we are serving a very high level
directive, or invited by the group itself, it is quite hard to get
the group to dedicate aention to us in the midst of the daily
allenges that are consuming it. Actually, if we look at what we
talk about with Kanban and Lean, we aim to build organizations
that know how to effectively balance the important (improving
capabilities) and the urgent (delivering current work). Maybe
in some years more organizations will do this effectively, but
for now, we shouldn’t be surprised to see the problems we are
coming in to help organizations with…
ese allenges in geing time and aention from the teams
who are being audited and the executives who must review the
results, thus leading to lots of stop-start work, would tend to
push many organizations to load down the auditors with many
projects to keep them utilized.
And, in the midst of all that stop-start it’s inevitable that there
Kanban - Not Just for Soware Development 119
will be anges in priorities – events triggering a need for
a special audit, shiing business concerns and priorities, etc.
is can wreak havoc on an annual audit plan. With all the
variability, it is hard for managers to know when to expect
completion, or to understand whi projects are going well and
whi are struggling.
What would a great Audit group look like?
Considering the allenges above a great Audit group would
have the following aracteristics:
• e group has a good flow of work. Auditors are generally
single-tasking, aieving good flow on their main project,
geing fast feedba and support from whoever they need
including the audited group, their managers/superiors,
and able to publish an actionable audit with minimal
wasted time due to interrupts waits and rework.
• ere is minimal amount of waste due to rework – While
some rework and anges are to be expected if new
evidence/facts emerge that drive anges in the audit, the
audit group feels that unneeded rework is minimal.
• Everyone feels that from one month to the other, one audit
to the next, the process becomes smoother, there are fewer
problems, and we are able to steadily improve on our main
objectives.
• e group is able to deal with anges without losing a
stride. Stakeholders know the group can deliver in a pin
as well as on it’s strategic plans. e group can rally it’s
forces around the highest-priority work.
Kanban - Not Just for Soware Development 120
• Time is spent on doing the work or improving. Minimal
time is wasted on replanning and other non-value-add
activities
How can Kanban help?
Well, you can say my vision of a great group is very influenced
by Lean/Kanban and you probably will be right. But if you do
see the above as positive, let’s try to see how the Kanban Method
can help aieve it.
e Kanban Method² helps you improve in an evolutionary way
using flow control as one of its key tenets. You start with the
way you currently work without making any anges. e
first thing you do is to visualize the flow of work and integrate
this visualization into the way you manage your daily work as
well as your planning. Once you start to enforce flow control
using “Work in Progress Limits” you will begin to run into the
allenges and will be forced to do something about them. You
will see rework in the form of small tiets making their way
ba to earlier stages of the work, similar to how we portray
defects/bug in soware development kanban.
Kanban itself will not tell you how to fix things. But, among
other things, it will nudge you to start considering cycle time
efficiency and not just resource efficiency. Visualizing the work
will force you to make the current policies explicit. Policies
su as expectations from audited groups, expectations from
managers. How you currently allocate the time of the managers
to the various projects – Is it by priority of the audit? By its age
in the system? A combination? Even the discussion around the
²http://en.wikipedia.org/wiki/Kanban_(development)
Kanban - Not Just for Soware Development 121
policies will drive some questions and ideas for improvement.
Choose carefully what you want to experiment with.
So the Kanban Method ³will not provide you with a pre-paaged
solution up front. Far from it. Instead, it will setup a diagnostic
system that will show you where you are currently, and give you
a system you can use to evolve. In order for it to actually serve
you, you will need to define where you want to go, what concrete
capabilities you want to improve. en you can use something
like the Mike Rother’s Improvement Kata⁴ to work in small steps
towards those goals.
At some point, maybe even early on, you will say something
like “Kanban doesn’t provide solutions”. at’s partially true.
You WILL get flow control. You WILL get something that gives
you opportunities/triggers to think about how the work goes, not
just do the work. You WILL get pointed towards areas whi are
currently the biggest obstacles to further improvement in Flow.
But you WON’T get all the solutions you need to deal with those
obstacles. is is by design.
e Kanban Method talks about improving collaboratively using
models. Improving collaboratively means the people involved
in the system being part of designing the improvement exper-
iments, whi increases buy-in. e collaboration can also be
around Choosing the model to try next. ere is no playbook
giving you a perfect solution, although if several other groups
have tried Kanban for an Audit group or a similar context before
you might have some good ideas to start with. But there is no
guarantee they will help. One of the important models we use
³http://en.wikipedia.org/wiki/Kanban_(development)
⁴http://yuvalyeret.com/www.slideshare.net/mike734/introduction-to-the-
improvement-kata
Kanban - Not Just for Soware Development 122
is viewing our contexts and systems as complex. In complex
environments you need to try things, see if they help, and then
decide whether to reinforce or throw away and try something
else.
You might try the eory of Constraints⁵’s five focusing steps⁶
around bolenes whi might give you ideas like subordinat-
ing the auditors to the external groups – What would it take
to expedite response time? Clarity of the report? Some other
thing? If you subordinate to the GM who’s the ultimate internal
bolene what would it mean? Trying to minimize rework and
passes thru his review?
When trying to subordinate you might find useful guidance in
the work done in IT around Specification by Example⁷ andTest-
Driven ⁸approaes. If we consider Reviews as steps of inspect-
ing quality into the Audit, maybe approaes that build quality
in by specifying expectations and tests up front and involving the
reviewers earlier on will be more effective? Yes it might require
time of the reviewer earlier, but against your intuition it might
be the global optimum.
You might try unking an audit to smaller pieces also called
Small Bates⁹. Maybe you can start considering an Audit like a
balog of areas to work on, and drive from resources and time
rather than scope. Perhaps even if the scope is fixed, you will
reduce the effort if you get faster feedba on initial findings.
Maybe you will improve flow if you need the audited group and
⁵http://en.wikipedia.org/wiki/Theory_of_constraints
⁶http://en.wikipedia.org/wiki/Theory_of_constraints#The_five_focusing_steps
⁷http://specificationbyexample.com/
⁸http://testobsessed.com/blog/2008/12/08/acceptance-test-driven-development-
atdd-an-overview/
⁹http://www.startuplessonslearned.com/2011/09/power-of-small-batches.html
Kanban - Not Just for Soware Development 123
the internal reviewers for smaller unks of time versus long
reviews?
Summary
is is not a case study of Kanban for Audit groups. Maybe
sometime in the future. e important point is that even if it was,
it wouldn’t necessarily be something you could copycat even if
your environment sounds exactly like what I described.
What you can copy is the approa towards improvement. Iden-
tifying allenges. Picturing the ideal situation. Using Kanban to
visualize where you are, establish flow control, and then start to
experiment together with your people using small evolutionary
steps of your explicit policies guided by models that you oose
to try and apply.
You might get luy and get good results by using the mod-
els/experiments outlined above. If so then great. We might
find that a certain set of models is a great fit for a certain
environment. For example, in soware development we do have
sets of models that typically have great success (Feature Teams,
Extreme Programming Engineering Practices, Test/Behaviour-
Driven Approaes , etc).
You will also find that the word Audit can probably be replaced in
this article with any other type of Knowledge Work. e Kanban
Method has a wide applicability. e models have a wide
applicability too. ere are models that are domain-specific, but
I think careful examination even of those will provide insights to
other domains. is is the cool factor about the Kanban Method.
e sky’s the limit to what we can do with it, and we are barely
scrating the surface…
Maybe one day we will even apply Kanban to the work of Agile
Kanban - Not Just for Soware Development 124
Consultants. We certainly are a Knowledge Work domain with
lots of variability. We certainly have flow control allenges.
Maybe in 2012
4
Kanban thinking in Scrum
Land
125
Kanban thinking in Scrum Land 126
4.1 Want my elevator-pitch answer to
what is Kanban for a Scrum rookie?
Our coaing team at agilesparks runs into this question a lot.
Many of the teams we are working with are familiar with Scrum
and using it. Other teams are just now going into Scrum. Since
kanban is becoming a hot buzzword, we oen get asked – so
what is this kanban thing? How is it related to Scrum?
We needed a good answer, that depends on the context, the
amount of time you have to answer, and the maturity of the
person/forum asking.
In this post, I will try to give the answer you give when someone
finds you in an elevator, the last 2 minutes of a workshop, or on
the way ba from lun, in short both you and him have a very
short time to give an answer.
Add to that that his knowledge is quite limited.
Here goes:
“What you might have heard about kanban is that its scrum
without sprints.
I would say that Scrum is an agile approa where the container
used to protect, focus and allenge the team is the time-boxed
sprint.
Kanban is another Agile approa! In Kanban the container used
to protect, focus and allenge is limiting the amount of things
we do in parallel – Limiting the Work in Progress. If you need
to remember one thing – remember and lookup Limit the WIP”
Kanban thinking in Scrum Land 127
If you are in a very high building, you can also add:
“Mixing the two can lead to beautiful results – called ScrumBan.
Also one of the biggest differences is in how an Agile ange
usually looks like with Scrum/Kanban. Scrum is a revolutionary
big ange up front approa. Kanban is more of an evolutionary
laser-focused approa where you find where to focus (using the
WIP limit as the allenging force), do something there, continue
to the next area to focus on. If you’ve heard of TOC, its quite
similar in how it manages ange. “
Now all of this is very simplistic, but probably concepts like
Cycle Time, the Lean origins, and other Kanban goodies are too
mu for a rookie with very short aention span at the moment.
e important thing is to grow an interest for what this WIP
limit means and look it up.
Kanban thinking in Scrum Land 128
4.2 Scrumban when will this be done
Dennis Stevens wrote a wonderful blog post called Kanban and
when will this be done¹ where he talks about how to forecast
done dates in a kanban environment and how kanban looks at
estimates, unperdictability, and how to make commitments. I
think its a great post, go read it‼!
Aer you’re done, try to think how it applies in a Scrumban
environment, or more specifically, where the delivery is not
continuous but seduled in a sprint-like fashion. As Cycle time
is supposed to reflect start to finish, and finish usually means
delivered, Cycle time in a sprint environment will include time
waiting for the release/delivery event (E.g. every 2 weeks).
So for example a story with 2 days cycle time to “ready to deliver”
might have either a 3 days cycle time end to end, or 10 days cycle
time end to end, depending on how long it waited to be delivered.
is means that the cycle time histogram used to create the T-
Shirt sizes will not be very useful..
What should you do? It probably makes sense to measure cycle
time up to the release activity, and add the frequency of the
release activity to the “when will this be released” forecast. so
for example our 2 day cycle time story, added to a 2w frequency
of delivery will end up being a 16 day cycle time from first place
in queue.
When looking at longer-term commitments this effect is dimin-
ished somewhat, especially if lead times are mu longer than
the cycle times and the delivery frequency.
¹http://www.dennisstevens.com/2010/06/07/kanban-and-when-will-this-be-done
Kanban thinking in Scrum Land 129
Tools like LeanKit Kanban² provide a way to define different
levels of cycle times, whi might come in handy for su
situations. ere might be also some way to provide dynamic
disneyland queues that take into account the fact that “next
delivery cycle” might be 1 day ahead, or 10 days ahead.
But I think this goes ba into the land of planning what is going
to fit before the next delivery cycle. And that is “Scrum Sprint
Planning/Commitment” world, whi is what we’re trying not
to do here (but works in some environments…)
²http://leankitblog.com/2010/01/sneak-peak-at-the-analytical-tool-
improvements-within-leankit-kanban/
Kanban thinking in Scrum Land 130
4.3 Scrum Sprint Commitment Rant
Going on a Rant
If there’s one thing that makes me mad whenever I see it is
teams abusing the commitment concept in scrum. I’ve been on a
rampage against dysfunctional sprint commitments for a while
now, but lately my thoughts have crystalized a bit, especially
when I had a ance to discuss this with Jim benson, Alan
Shalloway, Chris Hefley and Jon Terry last week at Lean Kanban
Benelux 2011³.
Background
So what is the problem? Well quite oen you see scrum teams
that finish sprints out of breath, out of quality, out of joy. You
also teams that start the sprint full of numbing fear, set a low
bar and that low bar becomes a self-fulfilling prophecy. Add to
that Product Owners, Scrum Masters and managers all spending
precious time worrying about whether we are able to make
accurate sprint commitment, instead of working to improve the
actual capability of the team.
It’s quite sad actually. Surely that’s not what scrum should
look like and indeed other teams have energized focused sprints
where they deliver what they can, stret their abilities just the
right amount and finish a sprint with just the right energy and
mindset to joyfully go into the next one.
³http://www.agileminds.be/event/2
Kanban thinking in Scrum Land 131
So what’s causing this?
Well, let’s start with the out of breath teams. It typically starts
with unrealistic commitments they make in the sprint planning.
ey make those commitments either because they’re pushed to
do it explicitly or implicitly. Yes, scrum says the team should
pull according to their capability. But something about the way
this all works de-emphasizes actual capability of the team and
motivates them to try to take on more than they can handle.
With this in play, they start and since there is a lot in their sprint
balog they have the green light to start many things in parallel.
A few days later, in the last mile of the sprint, it’s still many
items in progress and it’s either an unsustainable effort to rea
the finish line, cuing corners or having a very disappointing
sprint result. In our #LKBE11 discussion we referred to those as
mini-death-mares…
With teams living in fear it is a different but related story.
It starts with the message/spirit conveyed to them by their
Product Owner, managers or previous life management culture.
When they hear commitment they hear “miss that and you’re
in trouble”. And if the ecosystem is su that meeting the
sprint commitment is more important than the overaring
purpose of the project/release/feature they will be driven to
satisfy what they perceive as important – being predictable at
the sprint level. So they make a safe commitment. Usually this
is aieved by taking safety in the estimates. And so starts a self-
fulfilling prophecy, as described by Parkinson’s law and Donald
Reinertsen’s principle of the expanding work.
It doesn’t help that the team thinks that if they are able to deliver
more, there is no turning ba – from that point on they will be
Kanban thinking in Scrum Land 132
asked to deliver more on a consistent basis.
Lets pause here for a second – Isn’t it a reasonable expectation?
Shouldn’t the team commit and deliver more in the future if
they’re able to? e problem is that even during a short 1-4
weeks sprint, there’s still a lot of unavoidable uncertainty
and variability. In exactly what we need to accomplish (re-
quirement space), in how to do it (problem space) and also in
how mu time will we have for it (capacity). A lot of teams
try to eliminate this variability and spend a lot of effort on it.
Planning meetings grow longer, people’s capacity is planned at
the micro-level…
Many teams will oscillate between over-commitment and
under-commitment exactly because of this variability of course.
ey and their management will be frustrated if they’re measure
for effectiveness is meeting the commitment. e only way
to consistently meet a commitment is either unsustainable
pace, or making a really safe commitment.
Lets eliminate commitment
Well, just as an exercise for now, to see why it’s there in the first
place…
Without a sprint commitment, how will the sprint look like?
Probably we will see people taking on work from all over the
place. ey will start at the top priority, but their nature will lead
them to start many other balog items since there is no focusing
force urging them to stop starting **and **start finishing. So
we need commitment, or something else, to encourage a team
to focus on a few things and finish them first. An alternative to
Kanban thinking in Scrum Land 133
commitment at the stories level is to say we are focusing on a
single feature so let’s finish it before moving on to anything else.
Commitment as a Focusing mechanism Wait – this is
the Scrum Sprint Goal – Teams are supposed to agree on a Sprint
Goal they will focus on. e detailed story level commitment
is an elaboration on that anyhow. If our product balog is
very fragmented and not feature oriented we will have a tough
time using an effective sprint goal though. is is something to
wonder about in and of itself… but if it’s indeed the business
reality that we are doing many small things, we need another
focusing guidance. at guidance can be “we think we can finish
at least 8 stories, hopefully 4 more, so lets start with 8, get a good
feeling we can finish them, and ONLY THEN move on to the 4
others”. Here, the team is still using the sprint commitment, but
they’re using it for themselves as a focusing / work in process
limiting meanism.
Containers Another problem we might have without com-
mitment is that the work will expand uncontrollably. ere is
no finish line so there is no container. One thing that might
help is very energizing purpose of where we need to get at the
end of the Feature/Project/Release and why it needs to be at a
certain point in time. Seeing our progress towards that goal (or
la of progress…) will help energize our efforts and reduce the
expansion of work.
Commit to Capabilities Improvement Another thing
that might help is to start looking at our capability as a team
and make a commitment not to exactly what we deliver
Kanban thinking in Scrum Land 134
but in general to improve our capabilities. e capability
we care about is velocity as well as ability to turn out the top
priority items in the balog as soon as possible since they are the
highest priority. So let’s monitor our capabilities over time and
try to make them more predictable first and improve them
as a next step. Specifically, measuring Velocity can be done
without making any sprint commitment. Just tra the velocity
for ea sprint, preferably on a control art so you can start to
understand the variability in your capabilities.
How can we make promises without commitment?
is is a point I love. On one hand Agile diehards say there is
no commitment in agile – “we will just work sprint to sprint and
avoid any clear external commitment the business can count on”.
On the other hand if you start a discussion about losing the sprint
commitment they and others start talking about “how can it even
work without the team making a clear commitment and stiing
to it?”. Boom line, the sprint commitment doesn’t help you
one bit in making external commitments and meeting them.
It’s simply orthogonal to it. You make external commitments
based on size estimations and historical/estimated capabilities.
You meet external commitments by monitoring where you are
towards them and adjusting scope, resources, pace sprint by
sprint. If you use the sprint commitment as you should, it gives
you nothing towards that goal. Accuracy in sprint commitments
is micro-predictability. e business cares about mezzo/macro
predictability. Same like a long-term sto investor doesn’t
care about the fluctuations within a day or a week, they care
about the sto performance over a quarter or a year. e
team should care about reducing variability in its capabilities
eg. have a lower variability in Velocity, so more aggressive
Kanban thinking in Scrum Land 135
mezzo/macro commitments can be taken on while still allowing
safe and sustainable delivery.
How can other teams count on us if we don’t have a clear
commitment for the sprint content?
What if we are in an environment where other teams in the
group/portfolio count on deliveries from us on a sprint by sprint
basis? If we don’t have any commitment how will they know
when to expect the delivery from us? If they intend to work in
parallel to us, how will they know whether to plan for this or
not?
ere are a couple of ways to look at this. If 80% of the work
is consumed by other teams then we should probably consider
the organizational design. Maybe it would be beer to work as
a single team. Maybe it is a case of us providing a service that
is consumed by many other teams, and then it might be beer
to move towards a pull system – where there is less reliance on
dates and rather an agreement on priority, an understanding of
the capability in the form of typical lead time from requesting a
service from us to the time we deliver it, and then the consumers
using that service whenever it is ready, either at their next sprint,
or even beer as soon as its ready. If you’re thinking this will
make planning sprints more complicated and prone to anges
you are right. e solution can be to move to full pull mode at
the team level, or reduce the bat size you plan for, meaning
shorten the sprint length.
If it’s just sporadic work that others depend on, make sure that
is what you start with and make a commitment to deliver it. I
wouldn’t be surprised if the term Class of Service comes to mind
at this point…
Kanban thinking in Scrum Land 136
What will be the engine of continuous improve-
ment if we don’t have a target commitment to
strive for?
Scrum is about Continuous Improvement, right? What drives
this? Isn’t it the need to meet commitments? to be beer about
commitments?
Well, not exactly. e thing that is driving Continuous
Improvement is the fact that there is a container, composed
of a certain scope to focus on, a certain time to do it in,
and the people/capacity to do it with. ink of circling the
team with a rope telling them now move together towards the
target. is will cause a lot of pain. Some people are faster,
others are slowing the team down. Some impediments come up
and cause problems. But the rope keeping the team together is
forcing them to deal with the problems rather than defer them by
making progress on things outside the container just to maintain
the comfortable feeling of progress.
So in order to maintain this improvement-inducing container we
need the time, the team, and a certain scope to focus on. We can
do that with the Sprint Forecast mentioned before.
One important concept in Continuous Improvement is to have
a vision / target condition to strive for. What is that target
condition in a Scrum environment? As mentioned above,
this typically is to improve capabilities.
Improving throughput/velocity requires more scope in ea con-
tainer.
How do we translate improving business agility to the container?
e ability to define a shorter time frame that the team can still
Kanban thinking in Scrum Land 137
deliver in. e shorter the time frame the more opportunities to
ange direction without causing waste. Problem is that there is
a limit to this. Work takes time, and there’s a limit to how small
we can slice it to still be able to use a container of this structure.
at is why, at some level, in order to improve business agility
even further, we need to move to another form of container,
one whi limits the amount of things we are working on as
a team at ea point in time.
(Clarifying note – If you’re reading this to mean get to a certain
level with Scrum then move to Kanban, that’s not what I mean.
You indeed will benefit from Kanban at this level, but you can
start your journey with Kanban in the first place, or move to it
regardless of where you are on the way)
So can we get rid of the Sprint Commitment or
not?
Well, my personal opinion is that we can live without a Sprint
Commitment as currently practiced by the majority of Scrum
Teams out there. It seems the creators of Scrum think along
similar lines, as they replaced Sprint Commitment with Sprint
Forecast in the latest Scrum Guide⁴…
I personally think commitment is important, it’s only a ques-
tion what you commit to. I prefer to focus on the following
types of commitments:
• Commit to learn about your capabilities, care about
them and continuously improve them, by using a fo-
cusing meanism allenging the team as a whole.
⁴http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf
Kanban thinking in Scrum Land 138
• Commit to deliver the class of service that the business
and other teams expect, whi means delivering on time
when it maers, delivering the most throughput when it
maers more, etc.
Some more ideas to try at home…
Before we conclude this long post – Some related experiments
you might want to try at home…
• If you feel you are over streting, For a few sprints try
setting a very low forecast and meeting it and see how
it looks like. Talk about it. Learn from it.
• Try limiting the amount of Features/Goals in one sprint.
Talk about what it anges in the energies and focus of
the team. If you cannot set a limit, that’s an interesting
discussion in and of its own, that you should have.
• Use the Sprint Goal and Sprint Stret more aggres-
sively. Set a lower goal, and commit to deliver the goal
first, and as mu of the stret as possible. Goal should
be something you can consistently deliver 95% of the time.
(Mike Cohn recommends basing that goal on the mean of
the 3 worst sprints out of last 8, another way is to use 2
standard deviations below the mean if you want to take
a more statistics oriented approa). whether 95%, 85%
or lower is your call. But the expectation should be that
if there is a difficulty meeting even this commitment, it’s
not forbidden to pi up the pace a bit in order to meet a
commitment. Learn from it at the end of the sprint and
plan more effectively next time.
Kanban thinking in Scrum Land 139
• Read about the XP Planning Game⁵ and try it… Seems the
idea that iterations can be effective without a commitment
is not a new one…
Extra Reading
• hp://damonpoole.blogspot.com/2011/08/scrum-no-commitment-
required.html
• hp://agilepartnership.com/blogit/2011/07/26/is-commitment-
dead/
• hp://www.coderan.com/t/130421/Agile/Scrum-vs-XP-
Planning-Game
• hp://www.projectsatwork.com/blog/Dave-Prior/3740/
• hp://jamesshore.com/Agile-Book/the_planning_game.html
Conclusion
Scrum has some good things going for it. e Scrum-style
Planning Game and Sprint Commitment as currently understood
and practiced by most teams and organizations is not one of
them. I hope this post will help at least some of those improve
their results as well as their happiness.
⁵http://jamesshore.com/Agile-Book/the_planning_game.html
5
Focus on Testing Aspects
140
Focus on Testing Aspects 141
5.1 So what is the right ratio between
developers and testers?
One of the questions I’m asked quite frequently is what is the
right ratio between developers and testers.
A variant on that question is what I typically see in other
organizations as the ratio.
Well lets answer the second variant and then try to deal with the
first.
Typically what we see in agilesparks customers is 2:1 or 3:1.
ere are some exceptions of 3:2 or 5:1 but they are quite rare.
What is right? Well as u might expect it depends:
- what are the skills/strength of developers and testers. Not all
engineers are made equal…
- how are the responsibilities spread between roles? Eg test
automation etc.
- what is the development life cycle style used by the group
- what is the quality of the code when delivered to testers
- tenology and aracter of the system. Usually the lower
the product is in the sta the more testing it needs per code
developed. is is due to the amount of impacted areas, the
complexity to test, and the breadth of the configuration/platform
matrix.
- how mu test automation exists
One of the typical dynamics of a phased waterfall-like devel-
opment lifecycle is that QA phase starts late and pressured and
compromises in quality are part of life
Focus on Testing Aspects 142
is means very tough weeks/months for the poor testers whi
get a big blob of code to work on, they are outnumbered, usually
outskilled and the following happens:
- the perception is that test is the bolene. ( well I would say
that in waterfall ea phase is a bolene. ose that tend to be
the last ones just get the short end of the straw - either test phase
is prolonged or developers are asked to help do testing. Or both.
But what also happens is that organizations get used to this. It’s
a fact of life. For some reason the need to strengthen the test
organization is usually outweighed by ability to develop more
features ea version.
Another thing is that developers do end up helping testers they
usually do it in crisis mode when their only option is to help do
the work, not help testers have an easier job the next time
Lets see what happens when su an organization moves to
agile/kanban
In kanban or any kind of lifecycle that is feature driven develop-
ers and testers are expected to have more
Or less the same pace / feature velocity. So our typical outskilled
outnumbered testers usually quily appear as a bolene early
in the transition to agile.
Limiting the WIP in test and Dev causes Dev to stall, leading
to one of the classic discussions in kanban workshops and even
some kanban games I wouldn’t mention to avoid spoiling the fun
( Carlos – we know you’re out there!)
In an upcoming post I will try to cover what can be done when
this typical scenario happens, using practices from Agile Testing,
the TOC five focusing steps, and agile engineering practices I
general.
Focus on Testing Aspects 143
And we will try to think what is the right ratio for an agile
environment.
Focus on Testing Aspects 144
5.2 Finding the right Dev to Test Ratio
when working in Kanban
In the last apter I started talking about the ratio between
Dev and Test and promised to revisit how it looks like in an
Agile/Kanban environment. Whenever I talk to teams/managers
about Kanban, whether as part of a workshop, or with a team
actually practicing Kanban, the issue of testing as the bolene
surfaces quite quily. A typical situation looks like this:
Bottleneed Kanban System
What we see here is a classic bolene in a kanban system.
Testing are at their work in progress limit, meaning they cannot
take on more work. Acceptance has no work in progress, what
we call a “bubble”, and development are at their limit as well.
When we take a closer look, we see even more indications this
is a bolene. We see nothing from Testing is DONE waiting
Focus on Testing Aspects 145
to be pulled, whi explains why Acceptance has a bubble.
In development, a significant part of the work in progress is
DONE waiting to be pulled into testing. e implications of this
situation is that Development will not be able to pull in new work
and will have to look what else they can do to help the flow of
work. In theoretical discussions workshop participants are qui
to grasp that development now need to go and see how they can
help the testing. In real life what you usually see at first is the
developers seeming oblivious to this simple conclusion, and the
testers starting to get defensive about bloing the flow. All of
it quite natural… I try to get teams to use the five focusing steps
from TOC ¹ at this point.
IDENTIFY the system’s constraint
Our Kanban board found the bolene/constraint for us.
Decide how to best EXPLOIT the constraint
Here I ask teams to think about whether testing is the most
efficient it can be, and whether there are ways the team can help
them be more efficient. Some practical ways to do that are:
• Break down the work of testing into smaller tasks. is
will help the team identify tasks whi can be offloaded
from testing to other members of the team, or ideally
automated. It provides beer visibility to where the
majority of the bolenes time is spent.
¹http://www.focusedperformance.com/poogi1.html
Focus on Testing Aspects 146
• Go see how testing spend their time and how mu of
the time they’re actually testing versus doing other things.
You can get some nice ideas from the “TOC Blue Light”²
story. e idea here is that testing should be able o spend
most of their time actually testing. If they’re waiting for
code, for developers to come by, for setups to happen, for
data to populate, etc. then there are probably ways to help
them be more efficient. As a manager you might need to
ask your team questions to try and direct them towards
exploring this issue.
• Explore how mu rework testing has to deal with. Re-
work comes in the form of Defects they need to open,
wait for resolution, and verify. Repeated testing due to
repeated problems. Changes to implementation that come
in late aer a round of testing, since the implementation
and acceptance criteria / test plan are not aligned. Reduce
rework to help exploit the testing constraint.
• Practices su as ATDD³ help align requirements, ac-
ceptance criteria and implementation. Other practices
from the XP world su as TDD, Pair Programming/Code
Reviews, Coding Standards, Continuous Integration, help
increase the actual quality of code that comes into testing.
• Discussing and defining what it means for a story to be
Ready for Testing (or alternatively the Definition of Done
of Development) is a very good way to reduce rework as
well.
²http://theoryofconstraints.blogspot.com/2007/06/toc-stories-2-blue-light-
creating.html
³http://www.methodsandtools.com/archive/archive.php?id=72
Focus on Testing Aspects 147
SUBORDINATE everything else to the above de-
cision
Kanban limited WIP inherently subordinates everyone to the
constraint, Providing them with sla time that can be used
to help exploit the constraint aer identifying some potenial
areas for improvement. Other ways to help may be to take on
some testing work that they can help with. is is a short term
solution though, both since developers don’t really like to do
testing for a long time, as well as since its not their strong suit.
**ELEVATE the system’s constraint – **Sometimes Exploiting
will be enough. In other cases, the constraint is so strong that
you will want to elevate the constraint in a more strategic way.
is is where actual investment and anges in structure come
in. One alternative is to shi or share responsibilities – e.g. make
test automation the baby of the entire team, not just the testers
(see“Why test automation costs too mu”⁴ for some related
ideas ) Sometimes elevating via anged responsibilities will not
be enough. One other thing to look at before coming to the
conclusion that you have the wrong ratio, is the strength of the
developers and testers. I’ve seen many cases where the team has
real stars in the dev team, but the engineers in testing are not
up to their level. Especially in an Agile environment, its quite
important to have strong testers that are able to keep up the pace
of the team. Its also important that that they have the respect
of the developers, especially if you are going for something like
ATDD where the testers actually participate in guiding the way
of the team. If you have strong testers and they’re still the
constraint/bolene, maybe indeed your ratio is not a good
one, and you need to consider what to do. But if you went thru
⁴http://testobsessed.com/2010/07/19/why-test-automation-costs-too-much/
Focus on Testing Aspects 148
the focusing steps, tried to exploit the constraint, have a kanban
system where this process is visible and there is concrete data
that shows the delivery implications of the constraints (ideally
the economic cost of the constraint as well), it will be easier to
make and get buyin for decisions that have economic outcomes
(increasing headcount, moving headcount)
Summary
Your kanban system will surface any constraints that are related
to different throughput of Dev and Test. Kanban together with
TOC 5 Focusing Steps helps the team make the best out of
what they currently have and improve their processes and tools
focusing on the areas whi require the most improvement.
If all of this still is not enough, you have a good story and
substantiation to make farther reaing decisions about ratio
with. So what is the right ratio? e best answer would be to try
using an Agile/Kanban system and find out. For those looking
for specific numbers, I can say based on what we’ve seen so far
at Agilesparks that a ratio of 2:1 has a good ance of working
for a team that is willing to adopt Agile engineering practices
including test automation by the team and ATDD, and where
the testers strength is comparable to the developers.
Focus on Testing Aspects 149
5.3 QA Effort Effectiveness
Note
is was one of my first blog posts, before I actually jumped
on the lean/agile bandwagon. I’m including it as an interesting
point of reference - you can see lean thinking lurking beneath the
surface here. It is also still a question not fully answered. Many
organizations are still struggling with how to define an effective
QA effort/group, beyond “I know one when I see it”.
QA Effort Effectiveness
How do you know your QA effort is being effective ?
Based on the different stakeholders whi require input from the
QA a typical answer might be that Product quality is high when
released to customers.
Assuming that is indeed more or less what someone expects (I’d
say effective QA needs to answer to some other requirements
as well) how does one go about eing whether the product
quality is indeed high?
ose who reaed a fairly intermediate level of QA under-
standing would easily point out that the percentage “QA Misses”
(namely, the number of issues missed in QA and detected in the
field) should be below a certain threshold. A high number here
means simply that too many issues/bugs are not detected during
the entire QA coverage only to be embarrassingly detected by a
customer.
Focus on Testing Aspects 150
If one naively optimizes just for this variable, the obvious result is
a prolonged QA effort, aiming to cover everything and minimize
the risk. If no reasonable threshold is set, there is a danger of
procrastinating and avoiding the release.
See e Mismeasure of Man⁵ of a cool article on abusing mea-
surements in the soware world…
Of course, a slightly more “advanced” optimization is to open
many many bugs/issues so the miss ratio will become smaller
due to the larger bugs found in QA, not due to missing less bugs.
is can result in a lot of overhead for the QA/PM/DEV depart-
ments as they work on analyzing, prioritizing and processing all
those bugs.
Did I forget to factor in the work to “resolve/close” those issues?
NO! Several of those issues might indeed be resolved and veri-
fied/closed, but those are probably issues that were not part of
the optimization but part of a good QA process (assuming your
PM process manages the product contents effectively and knows
how to enforce a code-freeze…).
My point is that there are a lot of issues that are simply le there
to rot as open issues, as their business priority is not high enough
to warrant time for fixing them or risking the implications of
introducing them to the version.
A good friend has pointed this phenomena to me a couple of
years ago, naming it “e Defect Junk Factory” (translated from
hebrew). He meant that bugs whi are not fixed for the version
on whi they were opened on, indicate that the QA effort
was not focusing on the business priorities. e dangers of
this factory is a waste of time processing them, and the direct
⁵http://www.hacknot.info/hacknot/action/showEntry?eid=88
Focus on Testing Aspects 151
assumption that either the QA effort took longer because it spent
time on these bugs, or that it missed higher business priority bugs
when focusing on these easy ones.
Kind of the argument regarding speed cameras being placed
“under the streetlight” to easily cat speed offenders (with
doubtful effect on overall safety), but all the while missing the
really dangerous offenders.
So what can be done? my friend suggested measuring the rate
of defects that are NOT fixed for that version. e higher this
number, the more your QA effort is focusing on the wrong issues.
Just remember that this is a statistical measure. Examining a
specific defect might show that it was a good idea for the QA to
focus there, and the fix was avoided due to other reasons. But
when looking across a wide sample, its unreasonable that a high
number of defects are simply not relevant. If not a QA focus
issue, something else is stinking, and is worth looking at in any
case.
Another factor of an effective QA is fast coverage. What is fast?
I don’t have a ratio of QA time related to development time.
Its probably a factor of the type of anges (Infrastructure, new
features, Integration work) done in the new version as ea type
has a different ratio of QA to DEV effort. (e.g. kernel upgrade
usually requires mu more QA compared to DEV effort )
Maybe one of the readers has a number he’s comfortable with –
I’d love to hear.
What I do know is that version-to-version the coverage time
should become shorter, and that the QA group should always
aim to shorten this time further without significantly sacrificing
overall quality. I expect QA groups to do risk-based coverage,
automation for regression testing, and whatever measures whi
Focus on Testing Aspects 152
assist them in reducing the repeatable cost of QA coverage at the
end of ea version. e price/performance return on reducing
the QA cycle is usually worth it to some extent.
To sum up, a good QA effort should:
• Minimize QA misses
• Minimize the defect junk factory
• Minimize QA cycle time without compromising quality
What do you think is a good QA effort? How are you measuring
it?
6
Lean/Agile in the Holy
Land
153
Lean/Agile in the Holy Land 154
6.1 Israeli Culture and the Evolutionary
Revolution
Yesterday I was listening to David J Anderson on Joe Dagger’s
Business 901 Podcast¹. One of the interesting points was about
the differences in Cultures driving to different aitude towards
the Kanban Method between the US and Europe. Basically what
David and Joe were saying is that there seems to be more traction
for Lean and evolutionary ange in Europe. e speculation is
that Continuous Evolutionary approaes are more aligned with
corporate and national European cultures. Europeans think they
are more patient than Americans. Americans look for fast results
and are more revolutionary. Go hear the discussion – it’s around
03:30-05:00 in the podcast.
is has got me thinking about Israel. Our national and cor-
porate culture is said to in general be quite similar to America.
I found this “Doing Business in Israel”² article from Commu-
nicAid whi enumerates Individualism, Directness, Impatience
and Polyronic as Key Concepts and Values. In general, this
seems discouraging for alignment with Agile approaes – whi
encourage collaboration and collective ownership over individ-
ualism, focusing and finishing things over the multi-tasking
hinted by PolyChronic. At least PolyChronic also means we
are easy on the trigger of re-prioritizing, whi explains why
business agility is quite valuable to us…
¹http://business901.podbean.com/2011/10/17/evolutionary-change-thru-kanban/
²http://www.communicaid.com/access/pdf/library/culture/doing-business-
in/Doing%20Business%20in%20Israel.pdf
Lean/Agile in the Holy Land 155
Last but not least, we are impatient. And while there is nothing
in general agile thinking that contradicts that, once you go to
Lean, Continuous Improvement, and using something like the
Kanban Method where you need to Agree to pursue incremental,
evolutionary ange³, it becomes a bit more difficult. My
experience in the field seems to align with the la of patience for
Continuous Improvement. Most Managers and Executives I see
like the Agile concept a lot, think that delivering iteratively is a
good idea, but the Continuous Improvement bit gets less traction,
no maer how mu we try. ere are of course exceptions
and bright spots shining through, but I cannot ignore the overall
trend.
is explains why Kanban as a system is geing lots of interest
and adoption in Israel, but not necessarily the evolutionary
aspects of the Kanban Method. Disclaimer – my perspective is
quite subjective, and related to the kinds of clients that approa
AgileSparks. I’m interested in what other practitioners and
consultants in Israel think.
With this starting point, you would expect head-strong revolu-
tionary agile implementations. And we are seeing many of those.
But the Impatience and PolyChronic traits also lead to losing
interest and pace even while doing the revolution. Our aention
span is short, and aer the initial excitement, we oen see
organizations not focused on the ange long enough to recover
from a deep ange and addressing all of it’s repercussions.
It’s also quite typical to see organizations signing on for the
revolution, but even when starting, they start making amends
to the reality of the revolution being too mu for them. We
see feature teams whi are not really feature teams. Doing
³http://en.wikipedia.org/wiki/Kanban_(development)#The_Kanban_Method
Lean/Agile in the Holy Land 156
agile, but continuing to work on many many projects because
deciding to freeze some of them is a hard decision. Impediments
actually requiring some tangible investment or management
staff spending time agreeing on something and anging policies,
linger.
What I started to think about was a way to learn faster what
is the real ange pace that the organization can sustain, before
diving too deep into the j-curve. Maybe by front-loading tough
decisions and seeing if they are made. Maybe by simulating real
life scenarios in more depth and making the reality they will
face later into the ange more tangible for leaders. Maybe by
starting with the tough aspects of limiting the work in progress
and pull mode at the management level, before going to the
teams level. If all of this doesn’t phase the organization and
it’s management staff, then they have the right aitude and
timing for a revolution. If they get cold feet, a more evolutionary
approa can be adopted.
I’m thinking though that there isn’t mu value in positioning
the approa as evolutionary, at least not to those organizations.
If they want an Agile Revolution, we will give them an Agile
Revolution, maybe doing it in an evolutionary way.
ere are other organizations whi ARE dis-enanted by
revolutions, are mature enough to look for methods that are
based on evolutionary continuous improvement. ey might
start with continuous improvement, but sometimes will consider
a Revolution of sorts at some point.
I think we should develop more and more ways to recognize
what is the best fit for the organization, ideally give the orga-
nization the system that helps it understand their own ability to
Lean/Agile in the Holy Land 157
pull ange at a sustainable pace. is relates to my short Pea
Kua talk from LKCE11 about Implementation/Policy Kanbans⁴
I will continue to think about this topic. Luy for me I’m seeing
many examples of Israeli corporate culture in action, so will have
a ance to examine this theory. Help me out by sharing your
experience from Israeli or other impatient cultures!
⁴http://www.slideshare.net/yyeret/change-program-stall-avoidance-101-policies-
kanban
You might also like
- Best Practices Building Isv IntegrationsNo ratings yetBest Practices Building Isv Integrations61 pages
- JF 10 KanbanALeanApproachToAgileSoftwareDevelopmentNo ratings yetJF 10 KanbanALeanApproachToAgileSoftwareDevelopment90 pages
- Kanban - Agile Methodology - GeeksforGeeksNo ratings yetKanban - Agile Methodology - GeeksforGeeks19 pages
- Addendum To Kanban Guide Implementation Options Details 2 1No ratings yetAddendum To Kanban Guide Implementation Options Details 2 120 pages
- DR Shabbir Title Pages Thesis, Final.,..No ratings yetDR Shabbir Title Pages Thesis, Final.,..54 pages
- Is Mamba Effective For Time Series Forecasting?No ratings yetIs Mamba Effective For Time Series Forecasting?14 pages
- Briefing - Promotor Daily Operational Guideline Oct 24No ratings yetBriefing - Promotor Daily Operational Guideline Oct 246 pages
- Understanding Psychology: Bab 1 PengenalanNo ratings yetUnderstanding Psychology: Bab 1 Pengenalan40 pages
- Enterprise Kanban For Scaling Agile Teams v2No ratings yetEnterprise Kanban For Scaling Agile Teams v28 pages
- Incremental: Using Kanban Techniques To Control DevelopmentNo ratings yetIncremental: Using Kanban Techniques To Control Development32 pages
- Microsoft SQL SERVER Microsoft SQL SERVER 2008: Prepared By: Engr. Cherryl D. Cordova 1No ratings yetMicrosoft SQL SERVER Microsoft SQL SERVER 2008: Prepared By: Engr. Cherryl D. Cordova 126 pages
- Agile Methodology: Presented To: Eng. Ebtesam HussainNo ratings yetAgile Methodology: Presented To: Eng. Ebtesam Hussain42 pages
- Dan Dan - Brown1@mac Com Scrum Is From Mars Kanban Is From Venus Sglon18 FinalNo ratings yetDan Dan - Brown1@mac Com Scrum Is From Mars Kanban Is From Venus Sglon18 Final32 pages
- Analisis Spektrum Sinyal Digital - Pertemuan 1No ratings yetAnalisis Spektrum Sinyal Digital - Pertemuan 123 pages
- Percentage of Result: Class: Date: Exam: Held OnNo ratings yetPercentage of Result: Class: Date: Exam: Held On23 pages
- Do You Sometimes Feel That There Is Just Too Much Going On?100% (4)Do You Sometimes Feel That There Is Just Too Much Going On?27 pages
- 1 Sap-Step-By-Step-Navigation-Guide-For-BeginnersNo ratings yet1 Sap-Step-By-Step-Navigation-Guide-For-Beginners22 pages
- Predictability & Measurement With KanbanNo ratings yetPredictability & Measurement With Kanban32 pages
- Model: SF-104B Digital Temperature Con Troller: Features of FunctionNo ratings yetModel: SF-104B Digital Temperature Con Troller: Features of Function2 pages
- Incremental: Using Kanban Techniques To Control DevelopmentNo ratings yetIncremental: Using Kanban Techniques To Control Development32 pages
- Kanban - What Is It and How Can I Implement ItNo ratings yetKanban - What Is It and How Can I Implement It8 pages
- Concept of Unity, Order With Variety & Purpose100% (1)Concept of Unity, Order With Variety & Purpose35 pages
- Kanban in 30 Minutes An Introduction: John Carey JULY 2018No ratings yetKanban in 30 Minutes An Introduction: John Carey JULY 201825 pages
- Achieving High Maturity and Agility Using KanbanNo ratings yetAchieving High Maturity and Agility Using Kanban64 pages
- EE2003 EE2003 Circuit Theory Circuit TheoryNo ratings yetEE2003 EE2003 Circuit Theory Circuit Theory9 pages
- The Impact of Artificial Intelligence Tools On Essay Writing and Critical Thinking Skills of IMS Grade 10 Learners AutoRecoveredNo ratings yetThe Impact of Artificial Intelligence Tools On Essay Writing and Critical Thinking Skills of IMS Grade 10 Learners AutoRecovered9 pages
- Vocabulary 1 Match The Pictures To The Words.: © Oxford University Press 2013No ratings yetVocabulary 1 Match The Pictures To The Words.: © Oxford University Press 20136 pages
- 815 S. Othello St. Suite 100 #304 Seattle, Wa 98118: Is Yours To Protect! Is Yours To Protect! The The20% (5)815 S. Othello St. Suite 100 #304 Seattle, Wa 98118: Is Yours To Protect! Is Yours To Protect! The The7 pages
- Full Practice 0.1 FCE Listening FCE Listening Test 2 Part 1No ratings yetFull Practice 0.1 FCE Listening FCE Listening Test 2 Part 14 pages
- Your First Successes with Kanban: Understanding Kanban in a Knowledge-based Context and Implementing it in the CompanyFrom EverandYour First Successes with Kanban: Understanding Kanban in a Knowledge-based Context and Implementing it in the CompanyNo ratings yet
- Agile Project Management With Kanban Revealed: The Secret To Get Out Of Stress And Overwhelming Work To Finally Become ProductiveFrom EverandAgile Project Management With Kanban Revealed: The Secret To Get Out Of Stress And Overwhelming Work To Finally Become ProductiveNo ratings yet
- Agile Project Management:: Navigating Pros and Cons of Scrum, Kanban and combining themFrom EverandAgile Project Management:: Navigating Pros and Cons of Scrum, Kanban and combining themNo ratings yet
