Positive Incline Mike Burrows (@asplake) moving on up, positively

August 29, 2015

Feedback loops — a striking juxtaposition

Filed under: Kanban — Tags: , , , , — Mike @ 2:35 pm

I’m blogging here a little less frequently at the moment, but only because I’m busy on blog.agendashift.com and our Agendashift LinkedIn group, where I have been previewing new Agendashift functionality as it becomes available to its beta testers. I could easily have made this post there too, but there’s enough Kanban and Agile content here for me to show positiveincline.com some love. And why not!

This week I have been using Agendashift’s shiny new charting functionality to explore the results Depth of Kanbanland 2015 survey (which is still open if you want to give it a try — please do). I was very struck by this juxtaposition:

Screen Shot 2015-08-29 at 12.12.14

At the bottom of the transparency category we have one of the survey’s strongest responses right next to a much weaker one (easily the weakest of the category, though there are weaker scores to come in other categories). For frequent, progress-centric reviews — stand-up meetings and the like — we’re scoring between 3 (“getting there”) and 4 (“nailing it”). But for regular reviews of end-to-end effectiveness, the typical score is a 2 (“early gains”), with a significant number of 1’s (“barely started, if at all”). Hmmm.

Yes, the daily stand-up meeting is an agile practice I would wholeheartedly recommend, particularly when it takes a form that emphasises flow over activity. But how many organisations are struggling needlessly in both their delivery and change efforts as a consequence of their neglect of higher level feedback loops?

Even if you haven’t yet embraced the Kanban Method, David’s Kanban Cadences picture serves as a very useful checklist. For each of the feedback opportunities shown, do you have a good story? In our experience, grassroots adoptions of agile methods do often deliver early benefits, but quickly reach a plateau because there is only so much that a mainly team-centric approach can achieve. The Service Delivery Review meeting in the middle of the picture is a great way to break that constraint, providing as it does a fantastic opportunity to bring together data on effectiveness and progress on change and to share it with a wider audience that may include more senior leaders, outside colleagues, and customer representatives.


I know that I’m not alone among practitioners of Kanban and Lean/Agile methods in giving high priority to those bigger-picture feedback loops, but if the survey numbers are to be believed, we must be in the minority. I’d love to help change that!

February 12, 2015

Kanban from the Inside: 1. Transparency

Filed under: Books,Kanban,Values — Tags: , , , — Mike @ 8:46 pm

I’ll be posting every week or so some short excerpts from my book, Kanban from the Inside. Let’s start at the beginning, with chapter 1, the subject of which is the first of the Kanban Method’s nine values, transparency.

With Kanban, the purpose of visualization and other forms of transparency is twofold: to make the need for action visible and to help people make good choices. These operate at two levels:

  • Action in the form of work that needs to be done; good choices in the selection of work items
  • Action in the form of changes to the system; good choices in justifying, scoping, and implementing change

There’s a virtuous circle at play here:

  • The kanban system organizes the work.
  • People organize themselves around the work.
  • From their fresh perspective, people see that the kanban system could organize the work better than it currently does, and they change it.

Coming soon in this series: 2. Balance.

March 22, 2013

When transparency is not enough (or too much)

Filed under: Kanban,lean,Training,Values — Tags: , , , , , , — Mike @ 2:26 pm

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.

Powered by WordPress