Maria Alfredéen (one of my behind-the-scenes collaborators on the LKNA13 conference version of Introducing Kanban through its values) recently prompted me to consider the limits of transparency, something most of us in the Kanban community value very much. Could too much of the wrong kind of transparency get in the way of flow, either because we’re looking at the wrong things or because it keeps our attention too narrowly on the concerns of one part of the end-to-end process (and “suboptimising”, the cardinal sin of systems thinkers everywhere)? In other words, can transparency and flow sometimes be in tension with each other?

At the BCS-organised London Lean Kanban Day last Saturday, Clifford Shelley spoke of productivity metrics whose publication would cause more harm than good. I couldn’t help wondering whether they should have been collected in the first place (which I think is Clifford’s view too, though I didn’t verify this). On Twitter afterwards, I discussed with Pawel Brodzinski and Paul Klipp whether the appropriateness and effectiveness of transparency was a function of existing organisational culture, in particular of the amount of trust that pervades the organisation. We had surprisingly different perspectives on that, but I think we mostly agree that transparency does have its limits.

Customer focus to the rescue

Without making major changes to teaching materials, keeping the Kanban value system at the front of my mind when teaching does seem to make a difference. For one recent group, customer focus was the value that seemed to touch the most nerves, got conversations going (both lively and reflective), and influenced even their initial attempts at kanban system design. To me it seems significant that one of the values that doesn’t immediately jump out from Kanban’s principles and practices should have this kind of impact when made explicit.

For example:

• When identifying work item types and their respective workflows, “Know what you’re delivering, to whom, and why” was the catchphrase (and it stuck – I had it played back to me the next day)
• When exploring what self-organisation really means – and it’s not “working with people you like” as Dave Snowden joked on Saturday – we saw customer focus supplanting excessive role focus and task focus
• Sensing near-completed work getting “pulled” towards the customer, this feeling strengthened by the deliberate way we reviewed board designs and later conducted stand-up meetings
• Considering the positive impact on team and customer behaviour (I’ve seen both) made by introducing post-delivery validation. Did we deliver to the customer’s satisfaction? Is it meeting their needs as hoped? Are we happy that what we did is supportable and sustainable so that the customer and team will stay happy?

Revisiting those conversations on transparency and flow I now wonder: is customer focus the thing that will keep them in balance? I have reason to think so. Seeing work pulled towards a customer whose interests we care about surely puts local efficiency into proper perspective. So too does measuring things that matter to the customer (lead times, predictability, quality) rather than things that don’t (lines of code, hours spent in the office).

I now see customer focus not just as something nice or important, but as one value (of three) that help give processes and process improvement a good sense of direction. Part of an “outlook for improvement” as the current draft of my Chicago talk has it.