The day before
the Lean & Kanban 2011
Benelux conference started I was still undecided as to whether I
should head for Antwerp that evening as planned or take an early
train the next morning (my Sunday was proving to be busier than I had
envisaged). I eventually plumbed for the riskier option of the early
train (departure 6 am), which was possible because my colleague had
gone to Antwerp as planned and secured the room in our hotel. I had
unwittingly set a marker for myself; early rises and mental
gymnastics would define my week. I had also exercised real
options.
I arrived in Antwerp as
scheduled. Having had just enough time to catch up with my colleague,
register and marvel at the industrial aesthetics of the
revamped
hangar where the conference was taking place, I settled in for
the first keynote: “Rethinking Deming” by
Don
Reinertsen. Given the context, it seemed that someone was
spoiling for a fight. Those of us who enjoy (intellectual)
confrontation, especially when peppered with rhetorical flourish,
were not disappointed. Not knowing
Deming
(or statistics) as well as I might I took the whole thing at face
value; food for thought. I did however enjoy his trashing of the
red
bead game (“an entertaining con”) and identified with some of
his reservations about the deeper (“terrifying”) implications of
some elements of systems thinking (the well-designed system aims to
totally emasculate the individual). Reinertsen also introduced the
idea of random drift – an accumulation of (random) events affects
events in the future (by changing the system through incremental
feedback) – I'm sure if this idea was developed, chaos, tipping
points and complexity theory generally would quickly come into play.
For the rest of the
morning I followed a case study. Three different speakers (or speaker
pairs) took us through their experiences with specific transitions
which they had guided or were busy guiding. This session delivered
plenty of practical know-how and it was followed by a lively
discussion. Although I had hoped to pick up some pointers on dealing
with that most difficult element of change processes – the sceptic
- we didn't get much farther than a version of “build it and they
will come”. Which is fine, but it introduces a chicken-an-egg
problem; how to demonstrate without investing?
After lunch on day one
I followed the Real Options and
BDD/Testing
track. The notion of Real Options appeals to me, as do its cousins
set based design (which
Michael
Kennedy talked on on day 2) and BDD. Here again however I was
left wondering how to convince the sceptical that set based
design/real options was worth a try as an economically sound way to
realise value (when not given the opportunity to actually
demonstrate).
As if in tune with my
concerns generally on aids to persuasion,
Mark
Robinson brought the afternoon to a close with a refreshingly
old-style presentation in which he used an ingeniously simple
spreadsheet to demonstrate the effects of various WIP limits on
throughput. Limiting WIP is anathema to many managers as they think
it will reduce their efficiency, which it might, but I feel its
efficacy we should be after and not total(ly illusory) efficiency.
Dave
Snowden delivered the afternoon keynote. The gist of his talk
(and I do his erudition, learning and sense of humour no justice by
summarising it thus) was that context should be instrumental in
determining appropriate action and that only well understood theory
could help us decide what to do when faced with varying contexts in
practice. Snowden continued in the combative spirit displayed by
Reinertsen in the morning keynote by energetically stepping on some
absolutist toes, claiming for instance that systems thinking was
Talyorism
by another name. His message was that kanban is not Truth and neither
is Lean, nor is it Scrum, or anything else for that matter; context
determines truth. Whereby Snowden of course cleverly laid claim to
the Truth (There is no Truth, only truths). I was enjoying myself
thoroughly!
On day 2
Alan
Shalloway's opening keynote was also informed by the tension
between the individual and the system. For the sake of argument he
had chosen to state that it was “all about the people” but the
point that he was actually making was that
it is all about the
interplay of individuals and the system which they inhabit/cause to
emerge. Complex systems and their constituents co-evolve.
Matter
is both particle and wave. Man is both nature and nurture. It's all
about the feedback.
After
lunch I attended Bob
Marshall & Grant
Rule's double session on understanding effectiveness and the
possibilities that Rightshifting
delivers for managing same. This was all so completely new to me that
I won't trouble you with half formulated thoughts on it. Suffice it
to say that I am busy studying the Marshall
model and hungrily consuming anything I can find on chaordic
organisations.
And
then there was Jim
Benson, what a delight this guy was! He's allergic to powerpoint
and delivered his utterly engaging and frequently funny talk
strolling back and forth between two flip-charts; one was his kanban
and the other was his whiteboard so to speak. As he spoke and wrote
and drew, he moved sticky notes appropriately on his planning chart
thereby breezily guiding his impressive delivery while keeping his
process & progress transparent to all. It was a virtuoso
performance in the application of kanban. The subject matter was
substantively different to that which had come before too; we were
talking the psychology of kanban.
I
liked Benson's idea of existential
overload. As I mentioned, my week was to be one of short nights
and heavy cerebral exercise - my 2 days at LKBE were followed up by
three days of CSD training with Ron
Jeffries and Chet
Hendrickson. At one point during that training Ron, in explaining
one of the positive side effects of test
driven development, told a story of how TDD had effected his
wife's (!) life for the better. Ron, as he was sure many of the
programmers in the room were too, was smart enough to keep many
things in his head at the one time, and be dealing with many issues
simultaneously, and investigating a few options in different areas
from various perspectives all at the same time while also wondering
how he might approach that other problem but that if his wife came to
ask him what he wanted to eat for dinner that evening at that precise
moment, that he would suddenly yell at her at the top of his voice
that he was damn well THINKING, HOW COULD he
know what he wanted to
have for dinner?!?!?!?
TDD allowed Ron to deal with things; start something, develop it,
finish it. And so on. It helped him keep a clean, clear mind, with
plenty of room for dealing with unexpected pleasantries like an
invitation to dinner from his loving spouse.
On
the other hand, I was troubled somewhat by another phenomenon that
Benson mentioned; the Zeigarnik-effect.
According to studies conducted by Bluma
Zeigarnik we retain memories of unfinished work better than we
retain memories of that which we have brought to completion. That
strikes me in a way as a slightly depressing finding. If completion
is equivalent to success and that which is unfinished represents
failure, and we remember failure at the expense of success,
then we're doomed to be pretty
miserable animals aren't we? But if that's what the science says...
Luckily there is somereason to doubt the veracity of Zeigarnik's findings but that
doesn't take away from the general guideline; getting stuff done
feels good.
Most
interestingly, in the light of the undercurrent of (largely good
natured?) tribal nettle throughout the conference, Benson spoke about
methodologies as liberation theologies: Our life sucks because we're
oppressed by some methodology-or-other. But, then
some-NEW-methodology-or-other comes along and liberates us, we feel
good because we are free and we decide some-methodology-or-other is
okay. But as time goes on, we get all caught up in the rules, aren't
going anywhere and are feeling all oppressed again. He called it the
cycle of Liberation, Redemption & Addiction, which he laid on top
of the story arc; Birth, Life & Resolution, which he laid on top
of the kanban lanes; Ready, In-Progress & Done. It was all
getting very universal.
John
Seddon - “It's the system stupid!” - delivered the
conference's closing keynote. He came to wipe the floor with
everybody who had gone before and did that with an abrasive elan.
Reinertsen had upset him, Snowden was full of it, other systems
thinkers hated him. He really didn't care because he knew nothing
about software development except this one thing; if you did as he
said you should, you would do it better! What he said was, "Study,
study, study!"
Surely
safe-to-fail
probes, set-based
design and real options, OODA
loops, PDCA
cycles, and/or study, study, study are all variations on the
theme of “inspect & adapt”. In order to inspect meaningfully
and adapt successfully, systems must be extended incrementally via
short iterations - it's all about the feedback stupid!
There
will always be a better way to do things.
