Lean and Kanban 2011 BE - A narrative

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.

A commuter's rant

This morning was one of those mornings; when the alarm clock went off, I felt like throwing it against the wall. Instead I turned it off and lay back down so that I could ease into the day. I promptly fell back to sleep and woke with an even bigger start some twenty minutes later. I let my colleagues know that I would be late.

As we know random events cluster – today they clustered at a railway near me!

I caught a later train and as it rolled to a halt at its first port of call, the conductor announced that we would go no further as there had been a crash further up the line. The advice proffered, which I duly took, was to return to the station from which we had just come and follow an alternate route. Half an hour after I had left my local train station I was back there waiting on an overcrowded platform for the next train to Den Haag. As the scheduled departure time came and went without any sign of our train, and the crowd of unhappy commuters continued to swell, it was announced that there was a problem with a switch near one of the main stations on our route. I rang the office and let them know that I would be working from home...

My commute normally consists of a ten to twelve minute walk, a train journey of some 46 minutes and a tram ride of not quite 15 minutes. Most days I can get to work in about 90 minutes. The journey home is less predictable because it starts with a tram journey – tram schedules are not strict – and can take up to, and on the odd occasion more than, two hours (the difference usually made up almost entirely of waiting).

Why don't I drive? Well, I don't have (nor have I ever had) a driver's licence. Besides that pertinent impediment, there are the issues of gridlock, congestion, pollution and carbon emissions. But I will readily admit that if the only problem were gridlock I would without doubt have converted to the car long ago. Travelling by car is generally quicker and much more fault tolerant - if you step into your car 5 minutes late at the end of the day, chances are you will be home 5 minutes later than normal. If you leave the office 5 minutes late on the way to catch a train, your journey home may end up being extended by a half an hour or more.

If even well organised and largely dependable public transport (as the Dutch system surely is) results in significant delays at least a few times a month and the freedom that travel by car offers all too often equates to the freedom to sit idle in a traffic jam, what can we do to keep things moving?

There are a few obvious stop gap measures; teleworking may help somewhat in combating congestion and should be considered a useful tool but its efficacy is limited as teleworking is detrimental to team work. Flexible working hours could reduce pressure on transport systems during peak hours but any potential tends to be nullified by the demands of the rest of our lives (opening hours for crèche, school etc. may not be flexible) and here again, the issues that flexible hours raise when working in a team are not trivial. Carpooling is another option but it shares many of the drawbacks of public transport and can be socially taxing to boot.

Traffic needs to flow, maybe there are answers to be found in queueing theory. Take my journey as sketched above; I tend to leave myself  13 or 14 minutes to get to the station in the morning even though I know it generally takes around 10 minutes to walk the short distance required. I have to build in slack – if I aim at arriving on the platform as the train pulls in, an extra long wait at a traffic light might be the difference between happily catching the train and being left on the platform panting and cursing under my breath as I fumble for my phone, my connection riding into the distance. The greater the potential for variation in my journey to the station the more slack I'm likely to build in to allow for the unforeseen. Hand-offs are expensive.

More frequent trains would alleviate my problem somewhat – I wouldn't be as worried about missing a train if I could catch another less than 5 minutes later. The rail-road has limited capacity however and a large increase in the number of trains is not easily realised – unless the trains were significantly shorter on average (smaller batches). Thereafter cycle cost needs to be considered; the ratio of manpower & material to customer-kilometres would limit the extent to which batch sizes could be reduced.

If we were to remove hand-off and radically minimise batch size, say to one traveller, would we not simply arrive at travel by car? Yes. But. We still need to consider WIP - Work In Progress; allowing your WIP to rise above certain levels will be detrimental to throughput, alternatively; maximising the use of capacity (efficiency) will, after a certain threshold, reduce flow. If you get out on to the motorway on time in the morning you can whiz on through to your destination. If you're that little bit later, the road is chock-a-block and although capacity is being used efficiently (no. of cars per m² of road), you will not be going anywhere in a hurry.

In short, if we view travel by public transport as the waterfall option (silos, hand-off, long queues, large batches) and travel by car (as we know it) as the chaos or cowboy option, does that offer up any agile solutions to the traffic problems of the 21^st century? Possibly. If there were a system put in place to ensure that the capacity of the motorway was never utilised beyond around 70%, the issue of gridlock could be so atomised as to no longer exist. Cars would be allowed onto the motorway via many slipways, managed centrally by a  control system of traffic lights which would monitor and manipulate (motorway) utilisation, queue length (on the slipways) and batch size (entering traffic). In that way the motorway could actively pull traffic as opposed to playing the proverbial gullet, packed so tight that it can only choke...

To complete the agile/lean allegory; there is even evidence that self-organising traffic is the safest, although I must admit that I'm not sure I'd like to be the one testing that hypothesis on a high-speed motorway.