There’s been a flurry of activity in South America and on the kanbandev yahoo group this week and some are noted below.
It’s been challenging to get to all the Kanban articles and discussions popping up everywhere.
If you should come across something worthy of this forum, please call my attention to it.
Using the Mutual Learning Model to achieve Double Loop Learning
by Benjamin Mitchell (@benjaminm) (50 min)
An entertaining video on learning. I like the part about, “The gap is greatest under conditions
of embarrassment or threat.”, where the gap in this case is the difference between what you say and what you do. http://vimeo.com/30599611
An older post by Karen Greaves, Kanban Evolution, resurfaced on twitter this week. While some of the terminology
has since changed (ex: “Balance demand against throughput, has been replaced with “Balance demand against capability”),
it’s still a nice concise overview of the Kanban Method. http://scrumcoaching.wordpress.com/2010/02/13/kanban-evolution/#more-20
Apologies for missing last week’s post. I was completely immersed working with a team in NYC helping them design their first kanban board. Hopefully the extra content will make up for the delay.
An article titled, “Scrum and Kanban: Both the same only different”, by Liz Keogh includes an especially interesting section, “Kanban visualizes what’s happening; Scrum visualizes an ideal.” It points out that with Kanban, a key ingredient is making process policies explicit, so they can be addressed and improved upon. http://lizkeogh.com/2011/11/20/scrum-and-kanban-both-the-same-only-different/
I believe that why we would use a kanban system and why the Kanban Method is an
appropriate approach to change are worth re-iterating.
Root Causes
The root causes are that knowledge workers such as software developers are
overburdened, and that they suffer from interruptions, task switching and too much
multi-tasking as a result of the overburdening. The overburdening comes from a
drive to manage for efficiency (or utilization), that knowledge work is invisible and
because the future is uncertain and hence we must always generate more options
than we will eventually use or need. As a result, demand always exceeds capability
to supply, and workers are always busy. Often they start more and more work without
a focus on finishing it. This in turn leads to long lead times.
Long lead times are correlated with poor quality. This is almost certainly
because the work is done by the chemical computers between the ears of the
individuals and much of the knowledge is tacit and stored across a network of
individuals and not completely inside the head of any one individual.
Much of the work is invisible and a shared understanding of the work and the
dynamics of the process that created it are often not achieved. As a result,
mistakes are made! Misunderstanding of invisible work require large amounts of
coordination effort to reconcile and rework is often needed. Insuring quality and
an outcome that matches with original expectations is a constant challenge.
The Value of Reducing Lead Time
Early delivery of knowledge work often creates additional value. However,
regardless of whether early deliver creates additional value or not, shortening
lead times (or cycle times within a single function or activity) is almost always
desirable.
Short lead time (or local cycle times) demonstrate agility. They also create
liquidity in the system. Hence, short lead times (or cycle times) are desirable
from a risk management perspective. If this can be achieved while avoiding
managing for utilization then the idleness that occurs provides options (and liquidity)
improving risk management and responsiveness of the business.
Kanban Systems
Kanban systems enable us to limit WIP and avoid overburdening by only pulling
work when there is capacity. Due to the variability in work and the dynamics of
the process, limiting WIP, will result in idleness of some people and an inability to
perform some of the activities in the workflow. Idleness is a signal that
there is an opportunity for improvement. Idleness also provides slack with which to
make improvements.
Kanban visualizations enable workers to engage their emotional intelligence to
see (and feel) the work and the dynamics of the process. This helps immensely
with shared understanding reducing coordination effort and improving quality.
Limiting WIP reduces lead time by reducing multi-tasking. Other kanban system
design strategies and staff allocation strategies may reduce task switching.
Altogether these improve quality. This is almost certainly because knowledge work
is processed by human brains (chemical computers) and the interactions of team
members. Knowledge is often stored between and across members of a network.
By keep the time from starting to finishing short, the risk of knowledge perishing
or information becoming stale due to external forces, is greatly reduced. The result
is a better product and usually a lot faster.
Kanban provides us with metrics that allow us to observe/study the capability of
the kanban system and to manage it in a probabilistic fashion. This enables us
to make promises we can keep and results in increased social capital (trust) in
the wider organization. More trust leads to greater collaboration and this can
provide the political capital to enable larger bigger changes that result in
even greater improvements.
The Kanban Method
What is needed to enable all of this is documented on the cover page for this
Yahoo! group and in the book, Kanban - Successful Evolutionary Change for Your
Technology Business - namely…
Visualize
Limit WIP
Manage Flow
Make Process Policies Explicit
Improve Collaboratively (using models & the scientific method)
It has been observed that teams and organizations following these 5 practices
have often (though not always) exhibited a series of improvements in capability
and a culture of continuous improvement.
To lead a cultural change and generate improvements with kanban systems, to use
The Kanban Method, an organization should follow the core principles of…
Start with what you do now
Agree to pursue incremental evolutionary change
Initially, respect current roles, job titles and responsibilities
Is lead time the only capability we care about?
No probably not! We care about throughput (expressed as value items delivered
per period of time). We care about quality. We care about the social capital of
the organization. We care about customer satisfaction. We care about governance
and risk management of the organization.
What we care about is always contextual and has to be based on a mix of customer
and other stakeholder expectations.
However, lead time is nearly always one of them because it provides benefits in
so many dimensions of risk that reducing lead time nearly always improves the
satisfaction for one or more stakeholders.
With no videos recorded at the recent Lean Enterprise Software and Systems conference (#LESS2011), we look at some write-ups and summaries posted by attendees. We also take a look at some kanban board design discussions.
News
Hakan Forss’s summary of LESS2011 focused on two of the four main tracks (Complexity & Systems Thinking and Beyond Budgeting). It sounds like Carl Savage’s presentation on “Overcoming Education Inertia” was a winner. http://hakanforss.wordpress.com/tag/less2011/
Alan Shalloway posted his notes from his “Non-Linear Birds of a Feather” session at LESS2011. And, as a bonus he included definitions of the three “M” words: Mura (unevenness of work) causes muri (overburdening of workers) which causes muda (waste). http://www.netobjectives.com/blogs/LESS2011-birds-of-a-feather
That “Birds of a Feather” session led to a series of twitter exchanges regarding kanban board design which then generated some interesting discussions on the topic. http://blog.brodzinski.com/
Lean Software Systems Conference – Boston 2012
Registration for LSSC12 is open. Check it out. The Twitter hashtag is #lssc12 http://lssc12.leanssc.org/
Please contact .(JavaScript must be enabled to view this email address) with questions.
In a twitter exchange of ideas about kanban board designs - primarily between Pawel Brodzinski and Jabe Bloom, concern was expressed that showing people other peoples’ designs can stifle creativity and cause harm.
Well, it depends. It depends upon the people, the project, the chemistry in the room, and other stuff. People have different learning styles. The creative people may want to start from scratch with their very own design. But the “I’ll know it when I see it” people appreciate the opportunity to learn from others to avoid reinventing the wheel.
I have found that it can be very helpful to show people a variety of board designs and let them judge for themselves how a given design may or may not apply to their work. People understand that these are just examples that have been uniquely tailored for someone else’s use and can be modified without limit. People take what they want and toss the rest.
Kanban’s board design system is a marvel of adaptability. I show many board examples both from development and IT services, as well as from operations. People understand that their ultimate designs are for them and for them alone. There is no standard. There is no best practice. Nothing is cast in concrete. Their designs are meant to be re-designed as their work changes.
Kanban board designs should be uniquely tailored for the current process in use. Board designs, in reality rarely stay the same. They are more likely to change – perhaps even tomorrow, from someone seeing something from another board that looks promising. Often, perhaps usually, it’s a big help to have a starting nudge from an example or two or ten kanban board designs.
