Energizing kanban systems

Energizing
What do we mean when we talk about Energies of a
Kanban System?
A Kanban system that is energized is a healthy system. Items flow
effectively, and there is a feeling of engagement, focus and
accomplishment. How does a Kanban system that is low on energy look
like? There’s a feeling of being stuck in mud, of procrastination, of things
basically taking longer than they should have. Something feels very
wrong.
It is of course an analog scale with few systems in the perfectly healthy or
absolutely sick end of the range. My aim here is to start you thinking
along these lines and give you some tips how to shift a system towards a
more energized, healthier mode.
Aspects effecting energies/health of the work system
It seems that systems exhibiting certain properties seem to attract better
energies/health. In my experience and research I found those to be key
attractors you might want to start with:
 Meaningful/Purposeful work with clear visibility to current progress towards
the goal
 granular work items each with clear boundaries/constraints
 real-time clear visibility to the current health of each work item
 real-time and historical visibility to the health of the overall system
 Pull complemented by some time-driven self-accepted realistic/achievable
challenge
 Dynamic context-specific policies to deal with shifting context and demand
 Effective WIP Limits that provide enough space to maneuver but keep flow
running
 Attractor for effective local cycle time compared to “Hurry up and Wait”
This list is influenced both by these positive attractors as well as by some
negative attractors that seem to inhibit healthy systems. As we go over
the list of attractors, try to identify which of those exists in your
environment.

www.agilesparks.com - @yuvalyeret
Meaningful/Purposeful Work
Teams that have a clear, achievable, business goal with a meaningful cost
of delay function they understand and believe in are typically quite
energized and typically don’t rely on the Push system for their energies. At
one point in my time as VP Engineering my organization was working on a
release aimed at enabling one of our OEMs to really go to market with our
product. Time was of the essence as we wanted to take the next step with
this OEM and we knew a lot of the business case for the company
depended on this project. We used a Kanban pull system for most of this
release and didn’t have any energies issue. We actually delivered a very
meaningful release a few days ahead of time.
Working towards one big goal
Some teams are working on big things where the meaningful result is at
the end of delivering many small pieces. An example can be New Product
Development (NPD), a platform refresh project, or delivering a new
system. Despite our preference towards smaller batches, minimally
marketable features and minimally viable product, these contexts do exist
and will continue to exist at least in upcoming years. How do you energize
a system when the finish line is far away?
I believe you need to chunk this big thing to small pieces to generate a
sense of progress and finishing things, to provide you with some “progress
bar” to see that something is happening as well as where are you in your
progress towards the finish line and whether you are at a good pace or
not. In the world of Agile/Kanban we use Release Tracking techniques to
help with that. We break a big release to small chunks, and use “Release
Burnups” or “Release Cumulative Flow Diagrams” to see where we are
compared to where we should have been. This is important not just for
project risk management. It is important as a progress bar for people as
well. If that is the finish line we are all trying to get to together, we need
to be aware of where we are. But if the finish line is too far, we need to
chunk into smaller pieces similar to stages in races and look at our “Split
time”.
Working on a flow of items
What if there isn’t any overarching goal? What if we are a support team
just churning the support calls on a daily basis? What if we are a team
working on a flow of features that each adds incremental value to the
business? This approach is the classic flow scenario and makes lots of
sense from a business perspective. We keep choosing the best thing to do
at each point in time and do our best to deliver it.
But there is a grave danger here. Where is the meaning? People and
teams can get into a rut where they do things mechanically without a
purpose.

Try… KPI Teams
In Lean Kanban Central Europe 2011 the Prezi team presented a concept
(S. Farkas, 2011) which I think is great help here. The Goal-oriented
Teams. The concept is for each team to have one vision, one goal, with
clear supporting KPIs the Team can use to verify it is on the right track. So
we have purpose and we have clear visibility to progress towards our goal
along the way. Since those teams deliver small pieces of work using flow,
after each delivery they can validate that they are making progress.
Sample Team can be “Increase Registrations Team” with the KPIs being
increase number of registrations and visitors.
What about support teams which are working on cases/tickets not new
features? Here there is a real challenge. Beyond using SLAs as an attractor
for energized work I would experiment with engaging the team in
improving the overall results by setting Improvement goals/KPIs that are
associated with a certain class of service that runs in parallel to the
external demand. I’ve seen several successful Customer Oriented RND
Teams (CORD) that mix SLA-driven work and Improvement/Innovation
projects as a way to engage and retain great people on those teams.
Having Improvement/Innovation work that you can get to if you keep up
with the SLA-driven work tends to energize the system.
The Right thing, the Whole Right thing and Nothing but
the Right thing
Story
While not under oath, in knowledge work we are expected to do the Right
things. What are the right things? Those that bring the best return on the
investment in our efforts. We are expected to deliver the whole right thing
asked of us and nothing but it. This is a Lean concept – delivering what’s
valued by our customers. In Implementing Lean Software Development
(Poppendieck, 2006) Mary and Tom Poppendieck map Lean’s
overproduction waste to “Extra Features” waste – adding features that are
not needed to get the customers’ current job done. If there isn’t a clear
and present economic need for the feature it should not be developed.
They also talk about the waste of Partially Done Work. While they mainly
talk about Work In Progress, I want to extend it to work that was
delivered but creates failure demand since we haven’t delivered the Whole
right thing. This one is tricky though. In Lean we try to learn what is
needed, and talking about the Whole Right thing can be interpreted as big
batches. The concept of Minimally Viable/Marketable Feature helps us
here. We focus on the minimum thing that can get the job done or get us
the answers we need to learn about our next steps. Less than that and the
job won’t get done or we won’t have effective learning. More than that and
we have “Extra Features” waste.
One of the situations I see very often is teams that have a hard time
tuning to the right level of Minimally Viable Feature. This affects the

business value they deliver but more pertinent to our context also the
energies. When the problem grows extreme people on the team start to
lose the faith that they are delivering value towards a meaningful purpose.
Think about starting to work on a feature, and while working on that
feature being asked to add lots of functionality and capabilities that seem
over the top. At some point teams get into auto-pilot/whatever mode.
Think about a project to setup a new shipping center. The goal is very
clear – enable a new shipping partner by a certain date. If along the way it
seems that a lot of the work we are asked to do seems like the personal
fantasy of the business analyst or the product manager, the effectiveness
of the purpose or timeline will diminish since it sends us a message that
not everyone is aligned on the same goals.
One of the successful projects I took part in provides an example of the
opposite direction. At the time we were developing an OEM version of our
product. We were laser-focused on what we needed to enable this OEM –
help him do his job of selling his product with our product inside. When in
doubt we had direct channels to the partnership owner on the OEM side
and could collaborate on nailing down the details. The Product group was
running interference to avoid any unneeded scope getting into this
release. People felt like they were doing something with a purpose, and
that everyone is rallying to help them achieve their goal.
Effective Work Items
So how do we help teams focus on the right things? We start with looking
at the work items/containers, also called Backlog items. These might
require different effort at various stages. We want our items to be sized
effectively. Healthy team-level Kanban systems have items that rarely
stay in one lane of the board more than a few days, ideally not more than
even a day. In order to minimize the cases of unbounded work due to Pull
mode we want the items to have clear scope boundaries. Exactly what is it
that we will have when the item will be done? How will we see and verify
that?
Try… Defining work items using Stories and Examples
Approaches such as User Stories, Behavior Driven Development,
Acceptance-Test Driven Development or Specification by Example are all
great ways to enhance the clarity of the backlog items that flow through
the system. They all rely on having clearer conversations about the scope
as part of readying the item for pull.
Try… Limiting and visualizing Work Size
Mature teams find that they work much more effectively once the vast
majority of work items falls under a certain size. Try establishing a policy
that sets a Maximum Work Size for items entering certain lanes – e.g.
Only Small items can enter development. Every policy is a guideline and
there can be exceptions. The important thing is to discuss exceptions as a
team and decide you are ok with them, and think how to reduce the
number of exceptions over time. In the graph below you can see a few
exceptions after limits were set, but the trend is clear.

Side Note: The smaller the items, the clearer they will be and the less
chance we will have for non-value-added work or lower priority work to
ride on the back of our work items.
Good Enough Quality
Assuming we have an effective granular definition of the scope we need,
we might still have a problem. There are activities that are even harder to
specify explicitly than scope. Quality Inspection is one of them. How much
testing should we do? Managers tell me that when deadlines are abolished
or taken on by teams rather than pushed onto them testing takes longer.
The hunger for perfection that was held in check by deadlines and
shortage of resources/time is set free.
Try… Tests and Examples establishing Quality Boundaries
Tests and Examples establish the specific Quality boundaries of each work
item.
Try… Establishing Quality Guidelines as Explicit Policies
It also helps to Establish general Quality policies that serve as boundaries
to the work, but are not specific to each item. Some examples can be “No
open defects”, “All tests running green, no disabled tests”, “90% test
coverage”. James Back talks about “Good Enough Software” (Bach,
1995)11
http://www.satisfice.com/articles/gooden2.pdf, Joshua Kerievsky, in
his LSSC11 presentation, talks about “Sufficient Design” (Kerievsky,
2011). Both are examples of less than perfect Quality policies. The
important thing is the clarity among all people working in the system what
exactly is the desired Quality and why.
Try… Establishing different Quality Policy Guidelines for different
classes of work
While having one clear Quality policy simplified things, in many cases it
makes sense to evolve towards a set of possible Quality policies, each
fitting a certain class/type of work. For example, Experiments in a
Sandbox might be released with lower Quality and Design thresholds than
updates to the production workhorse features. These different classes of
treatment can help us deal with variable loads across the system – for

example prefer pulling experiment work in case we have a testing
bottleneck.
Dangers of Pure Pull
Reinertsen’s (Reinertsen, 2009) Expansion Control Principle claims that in
product development we must control the expansion of work. Some work
in product development can behave like the perfect gas of physics. It
expands to fill the container, no matter what size of the container. One
problem with a pure pull system is for these kinds of work that expand, we
don’t have anything controlling the expansion.
C. Northcote Parkinson (1909-1993) first published the "law" -- "Work
expands to fill the time available for its completion." -- in November, 1955
issue of The Economist in an essay entitled "Parkinson's Law," republished
later in a book of the same name, currently published by Buccaneer
Books.
Try… Pull complemented by cadence
A lot of teams use Kanban Flow to complement or evolve their
Sprint/Iteration based Agile Process. I’ve worked with several of those
teams and in most of them there aren’t any energy problems. The fact
that there is some sort of heartbeat and deadline, even though it is
defined just as “Demo all done stories and then deploy/release them”,
introduces an energizing force into the system.
Try using some form of team/group cadence to control the expansion of
work. Use the cadence as an opportunity to review the items in progress
and decide whether continued investment in them is preferable to
completing them (or throwing them away) and moving on to something
else.
Try… Pull complemented by a per-item timebox
If you look at SLA-driven activities like Customer Support, work typically
doesn’t expand even if there isn’t a cadence like Sprints/Iterations. The
reason is that each work item has a time constraint attached to it – the
Service Level Agreement. If your team is not under SLA, you might want
to try creating some of the positive constraints SLAs provide. If we could
predict the exact timebox an item would need it would be great. Alas, in
our kind of work there is too much uncertainty/variability to predict the
timebox. What can we do?

Figure 2 Standard Gaussian Distribution
Let’s look at Figure 2 which describes a standard Gaussian distribution for
actual cycle times in our system. We can see that very few items complete
in under 5 days, very few in over 15, most are somewhere in between,
with 10 days being the most likely completion time.
How should we define the timebox for a new item that is now starting?
 If we use 5 days as the timebox, most items will not be able to complete in that
time. If items do complete there is a very good chance that some price was paid to
make it. Typical prices can be unsustainable pace of development or lower quality.
 If we use 15 days as the timebox, most if not all items will complete, but the
Expansion principle means that a lot of items that COULD have taken less than 15
days would take 15 days just because we provided that timebox as the
constraint/guidance.
 If we use 10 days as the timebox, about half of the items will complete in that
time with some work expansion waste, and about half of the items will complete in
that time or late with some unsustainable pace/quality price paid.
To sum up, none of the timeboxes suggested above are ideal. The problem
is mainly with the way we define the timebox, and the effect it has on
actual execution. Let’s now look at a couple of alternatives.
Try… Theory of Constraints style Buffer Management
The Theory of Constraints and specifically its Critical Chain approach to
project management describes a good solution for this problem. Let’s
assign a timebox based on the 50% point (10 days). We don’t consider it
a commitment though. We consider it guidance of what we might expect if
all goes well. If an item is 5-10 days in processing we consider it green
and let it flow without any special attention. If an item is already more
than 10 days in processing we can consider it yellow and start paying

more attention to it. If it’s more than 8-9 days in processing we need to
take pro-active action to ensure completion. This attention to times that is
DECOUPLED from commitments provides us with what I like to call “Soft
Constraints”. It is similar to the effect of a demo/delivery cycle every two
weeks. We don’t HAVE to finish our story by that time, but it’s certainly an
energizing factor. Sometimes even a bit too much.
Try… Learning from red items
Another thing we should do is learn from the items that spent the most
time in processing. What were the reasons for that? Can we identify an
action item that will reduce the chance that a similar item will spend so
much time in processing?
What we are nurturing here is a commitment to strive for shorter and
shorter but still sustainable cycle times. This in and of itself will energize
our system.
Try… Adjusting the constraints as the system changes
Over time the distribution of cycle times might change. Pay attention and
change the boundaries of green, yellow, red accordingly. This will make
sure the system continues improving.
Add more stuff here
The dangers of Slack
Working in real pull mode means that sometimes we will be signaled from
downstream that the queue between us is full and we need to stop and
wait until there is room in the queue. This should create some Slack in the
system. Ideally, we should complete our work as fast as possible and then
stop and wait. That would ensure we understand where the constraint is,
and maintain our capability to locally process the work as fast as we can.
It doesn’t always work that way though. We tend to slow down when we
realize there is no rush. David Anderson (Anderson, 2004) talks about this
effect and refers to the “Road Runner Behaviour
In TOC language, this stop-go
effect is often called “Road Runner Behavior” after the Warner Bros.
cartoon
character who only has 2 speeds—full speed and stop. Road Runner
behavior
may be bad for morale amongst the analysts. Hence, the Agile manager
must
be aware that the subordination step in TOC is dangerous and needs
careful
management attention during introduction.
Probably the best way to deal with this is to ensure that everyone
understands the Drum-Buffer-Rope principles and that they are aware of

the current system constraint. If they know that they do not work in the
CCR, they
should be comfortable with their new role being only partially loaded. This
technique of sharing an understanding of the system process and gaining
buy-in to changes has been called “?Fair Process” [Kim 1997]” as it is
known in the Theory of Constraints. For example if we see a congestion
building up in deployment , We as the development team might anticipate
our work being queued up as well and we will slow down. This means that
the “local cycle time” for development will be slower.
This has problem has several undesirable effects:
 When the congestion is solved, we might already have gotten used to the
slower cycle time and it will be hard to pick up the speed again. These problems might
also contribute to hiding congestion if the whole system just slows down to the lowest
common denominator.
 People don’t like to have too much slack. It goes against their feeling of
accomplishment/purpose. Being told to “not start” also goes against their feeling of
autonomy. It also affects their feeling of job security – I’ve seen examples of
organizations where people are afraid that prolonged slack will turn into layoffs.
 It becomes harder to see the real capability of the system. Constraints are being
hidden and it appears that there are no bottlenecks – everyone is working in the same
pace. Now where do we focus our improvement efforts?
Try… Exploiting Slack towards Improvement Activities
Since people on one hand don’t like to have slack and on the other hand
like to accomplish things and move on, let’s give them additional work
that they will be able to pull even under congestion. Let’s look at some
potential activities, by order of preference:
1. Ideally, help current work flow if you can (Help others in your area of
specialty or downstream)
2. If you can’t, pull activities that will increase the capacity of the current
constraint (E.g. work on automated deploy if deployment seems to be a bottleneck).
3. Pull improvement work directed at current improvement goals of the group –
Learn skills that the group has a shortage of, Improve Quality, Research an upcoming
activity.
4. Improve/Innovate as you see fit
Regardless of what activity you choose, it is important to track and
visualize it as part of your work system (Kanban board) – preferably as a
different class of work/service so it is clear it is in play and how much of it
we are able to process. This is important for people (who now feel safer
knowing that they are doing sanctioned work and that those around them

see that) as well as towards having a clearer picture of the system and its
capabilities and constraints. Local cycle time within each station should
remain fast.
Try… Establishing a better collective understanding and trust
around Slack and Subordination
Have a discussion including those managing the system and those working
in it. Establish a policy of how to deal with Slack. Emphasize the fact that
some Slack is desirable and that we will aim to make the best use of it
once we recognize it. Let’s be honest, if we find that for some reason our
line is so unbalanced that we need to intervene, we will. But explain the
belief that through subordination and changes in the handoff/interface
policies of how we do work we can have a major impact on the balancing
of the line, and that is the path we prefer. Intervening by adding/remove
people is the last resort. If we manage to generate the trust that this is
indeed our intention, we will be able to see the actual system and work to
improve it together.
Try… Measuring local cycle times AS WELL AS overall cycle times
The most important thing is the overall cycle time for delivering the
desired value in the desired quality. This should be clear to everyone
working in the system.
We can also measure local cycle times within processing steps with the
target of having the fastest possible local cycle time for delivering the
work item to the next step queue in the desired quality that will help the
next steps downstream have a fast local cycle time as well. Measuring that
will nudge us away from the local slowdown.
Note of caution – it should be really clear that the global cycle time
optimization is the important aspect. Pay close attention for what seems
like local optimization – e.g. delivering fast but with crappy quality that
costs more downstream.
Hurry up and Wait
Another problem is that the more inventory and slow-down I see
downstream from me, the slower I will become. This is what Reinertsen
calls the “Hurry-up-and-Wait” principle (Reinertsen, 2009). In systems
with high or non-existent work in process limits this can be a serious
issue. People know that if something is important it will be expedited, and
there is less urgency to finish normal work because they know it will
anyhow sit in long queues, so how important can it be to finish it?
You might suspect this is a problem when you discover a huge difference
between local processing times for expedited items versus normal items.
Expedited items will not spend time in queues so for sure will finish faster.
But the processing time should be comparable between expedited items
and normal ones, and differences can suggest “Hurry-up-and-Wait” is in
effect.
Try… Going to lower WIP levels

The solution here is to go to lower WIP levels to reduce queue lengths
wherever possible.
Try… Go to where the work is done and pay attention
Not all information about the system can be gleaned from Kanban Boards,
Flow diagrams or Cycle Time Control Charts. In order to sense the
health/energy of the system and the people working in it you need to
spend time where the work is done, listen in, pay close attention and talk
to people outside of formal status meetings or operation reviews. While
implementing a pull system or any change in the way work is done
Managers should allocate a significant slice of their attention/time to what
we call “Go See”/”Sensing”/”Go to the Gemba”.
Sensing the state of the System
So far we discussed several possible energy/health-related
patterns/symptoms and experiments you can apply to try to deal with
them. An important ingredient in enabling this experimentation is the
ability to Sense the state of the system. As we are talking about
experimentation cycles we want to have the ability to quickly Sense what
is going on.
Beyond that the ability of everyone to sense the system and work item
state helps energizing the system. We want everyone to see struggling
work and have a clear policy of how to deal with it.
Seeing dynamics of the system in a static picture
One of the challenges in sensing the dynamics of a kanban system is that
the kanban board itself is static. Each time we look at it we see a snapshot
of how the system looks right now. It is very hard to see which items are
flowing ok, which are struggling.
In order for the system of work to autonomously deal with struggling work
we need the kanban system to radiate this information visibly and clearly.
Let’s look at a couple of ways to increase the visibility to the dynamics of
the system.
Basically what we are looking for are ways to associate certain indicators
on the kanban board with movement, similar to how we interpret white
spots in a picture of a river with areas of fast-moving water and dark still
areas with slower-moving water.

Try… clearly marking blocked items
One of the most common examples is blocked items (also called
impediments/showstoppers by some teams). We typically indicate an item
is blocked by changing its color (typically to red) or assigning a special
small note to it.

Try… indicating when the blocker appeared
Providing this information can help a team understand how long the item
is not moving and escalate handling, especially with a big board with lots
of tickets.
Try… Collecting blocker items and learning from them
When a blocker item is cleared, keep it. Periodically look at the recent
blockers and look for common reasons. Try to find what is causing these
blockers and what you can do about it (You can use something like a Five
Whys root cause analysis exercise). Schedule work to pro-actively deal
with this kind of blockers. This is by the way risk mitigation activity as
described in (Tom DeMarco, 2003)
Struggling/Slowed down work
What about items which are not stuck but are moving very slowly? This
presents a few questions. What does it mean that an item is moving
slowly? How do we know? Do we rely on our feeling? On actual data?
There are a couple of ways to address this. Let’s look at a few
Try… People indicate health of their stories
One way is to let people indicate the health of their stories. The benefit
here is that we bring the issue to people’s attention and give them a more
explicit chance to report on slow-moving work. The downside is that it is
not a clear-cut decision when to mark something as healthy or sick.

Experiment with this approach. You might find that people’s instincts go a
long way, especially if it feels safe to report that something is struggling
and it helps people rather than earns them a micro-management police
tail.
Highlight cards based on lane-specific age threshold
Once your system is running for a while and you know more or less how
much time cards tend to spend in each lane (local cycle time) you can
have a policy of highlighting cards that are already too long in the lane. An
example from Amdocs shows exclamation marks on cards that are already
too long in the Requirements lane. Note that it makes more sense to track
this for “In progress” lanes than queues. Queued work in “done” lanes is a
function of system health rather than specific work items health. It might
make sense to show some indication of overall cycle time even when
queued, but not local cycle time.
Buffer Management Color System
Earlier when discussing TOC style Buffer Management we outlined a way
of indicating a work item health/pace using a green/yellow/red system.
Ideally work should be marked with those indications on a kanban board.
Zombie Cycle Times
An easy way to indicate item age is to mark that age on the card, ideally
with some cool metaphor that people connect to. Luke Smallwood
(Smallwood, 2011) uses babyzombies. A basic way is to use stickers and
for each day an item is in play replace the sticker with the next sticker. A
more “green”” way to do it is to have a mini-lane for each age and move
the items between lanes as they age. This is an easier way when tracking
local cycle times within one lane. Replacing stickers makes more sense
when tracking age across the whole board.

Avoid… tracking progress percentage
A word of caution. It might seem like a good idea to indicate progress
somehow. Effort hours remaining, % complete or similar indicators. I
personally don’t like this approach too much. The main reason is that we
know these indications are far from accurate, and an item is not done until
it is done. I prefer tracking progress by completion of work rather than
asking people to spend time estimating remaining effort.
Try… rolling up status of inner work
What you can try is rolling up the status of inner work. If a story requires
completing 5 tasks to move to the next lane then you can indicate 3/5
tasks done. If a feature is comprised of 10 stories and 2 of them are
complete you can indicate 2/10 or 20% done. You can mark this
information on the parent card.
Heat map example
Another way to visualize health is to put on some “Age Goggles” like
shown in the heat map here. With those “goggles” the main visual
indicators from the board will be age of the card. This allows focusing on
aging cards.
Try… Time lapse movies
With the advent of electronic tools and advanced gadgetry teams can
show a time-lapse movie of activity from recent days as part of their
review of the current status. As few teams are currently using this
approach, it is still early to say how much of an effective attractor this is

for energizing the team. Try it out and let me know if you find it helpful or
useless.
Why is seeing it so important
Why do we spend so much energy visualizing the dynamics of the system?
There are a few reasons.
 We will focus on late tasks which counteract the amplification principle which
says that the more late we are the more we will prefer to neglect the late items and
work on fresh items.
 We will encourage whole team attention/swarming to late items rather than
each of us focusing just on his own work.
 If we want to improve the system we need to sense/observe it. When trying to
improve how the system deals with work health/energies we need to visualize these
aspects as best as we can to improve the experimentation cycles.

What do we do when we see energy/health problems?
Kanban talks about making the process policies explicit. How we deal with
health problems is a great example for explicit policies:
 “Involve the expert” – e.g. normal items will by default be pulled by anyone,
or even specifically by those learning a new area we want to increase our coverage of.
But if item becomes yellow/red we involve the expert of that area to help converge the
matter.
 “Stop/Continue Forum” – We can decide that once an item reaches a certain
age, we start having a “Stop/Continue” discussion about it on a frequent basis e.g.
daily.
 Uber-Slicing Mode – We can decide that we allow Small and Medium work
items into the system. But once they reach a certain age, we require items to be sliced
down to Extra-Small slices. This might be better than spending the effort for slicing
and managing all items in this granularity. We can decide that at this point we start
managing tasks for example.
 Pairing – decide the policy for pair-programming. Do we want to start pairing
when work reaches a certain health threshold? Is there a point where we swarm even
further? Is there a point where we “stop the line”?
Having the discussion around the process policies makes the actual
counter-measure when seeing problems faster and autonomous with less
discussions in-band to the work.
Try… Breaking the flow
We keep talking about sustainable flow, sustainable pace, continuous
delivery all creating the picture of endless work at the same pace. Even if
this pace is sustainable, everyone needs a change of pace once in a while.
Think of physical exercise – we try to break things up by doing interval
training. In gaming we break things up by “Boss levels” and mini-games.
In product development I recommend a change of pace every now and
then – Slow down, Accelerate, use a different cadence.
In my 6-month programmer training in the Israeli army we had such a
change of pace every few weeks. Whenever we reached a certain level we
had a few intense days exercising the learning so far in the program. It
wouldn’t be effective to work at this pace the whole 6 months, but our
achievements in those days and the energies they introduced into the
whole experience were unforgettable.
You want to find those experiences that will bond people together. These
intense changes of pace tend to serve such purpose. Luckily for us, even
effective pull-based systems need to deal with the occasional expedite, so
there is plenty of opportunity to swarm around a difficult challenge. Just
make sure you make this a memorable experience not a painful one.

Enjoy the pressure and intensity. Get some pizzas together, go out for a
drink to celebrate when done, whatever works.
Conclusion - Start Simple
You might feel overwhelmed by the catalog of patterns described here. My
suggestion is to start simple. Sense for health/energy issues. If you do
feel there is some problem, choose one pattern and try it. See whether it
improves the situation or not, and then decide whether you need to try
another pattern or not. Add visibility information if you feel you need it.
Whatever you do, don’t go in all guns blazing and implement everything
here…

Energizing kanban systems

More Related Content

What's hot

Viewers also liked

Similar to Energizing kanban systems

More from Yuval Yeret

Energizing kanban systems