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

April 30, 2015

Kanban from the Inside: 12. Theory of Constraints (TOC)

Filed under: Books,Kanban — Tags: , , , , — Mike @ 2:33 pm

In this series of short excerpts from my book Kanban from the Inside we’ve reached chapter 12, the second chapter of Part II (Models). As last time, this excerpt comes from near the end of the chapter. I must therefore explain for the uninitiated that POOGI is TOC’s Process Of Ongoing Improvement (acronyms are unavoidable here I’m afraid).


POOGI and the Five Focusing Steps

Like many Kanban trainers, I like to reference POOGI and the Five Focusing Steps when I teach Kanban. I particularly remember one class in which a small company’s entire middle management layer was in attendance. It dawned on us that if the company had a constraint (and surely it must), it had to be represented by one of those managers in the room.

All eyes turned to the finance manager. Everyone saw how important it was that she got what she needed when she needed it. Her colleagues resolved to remove from her and her small team its overhead of chasing for paperwork, clarifications, and corrections. Special priority would be given to activities that brought in cash. Everyone in the room determined that things were going to be better, not just for that team but for the company as a whole.

That’s a great story, but Kanban is not “POOGI with kanban boards.” The constraint—typically presented as some kind of bottleneck—is rarely the Kanban practitioner’s first line of attack. Get past the delicate issue that no person or team wants to be labeled a bottleneck, and you still have the problem of identifying them. How sure can you be of the location of your bottlenecks when WIP is high, there are orders-of-magnitude differences in lead times between work items, people can easily move between activities, and (give or take) everyone gives the impression of being equally busy?

Perhaps bottleneck should be added to that list of tools, concepts, and metaphors that don’t translate from manufacturing work to knowledge work quite as readily as some would have you believe. Chapter 14 identifies some more of those.

The bottleneck may not enjoy a first-class status in the Kanban Method, but POOGI will long continue to be taught. It promotes understanding, and there is still power in the idea that you need to keep on identifying and addressing your system’s constraints, especially when your mind is open to the possibility of much broader constraints—lack of knowledge, feedback, learning, trust, and so on, or the attachment to unhelpful ways of thinking.


Next up: 13. Agile. Previously: 11. Systems Thinking, Complexity, and the Learning Organization. Start from the beginning: 1. Transparency.

 

March 30, 2015

Kanban from the Inside: 7. Understanding

Filed under: Books,Kanban,Values — Tags: , , , — Mike @ 8:25 am

The seventh in a roughly weekly series of short excerpts from my book, Kanban from the Inside.


A Pattern for Purposeful Change

Let’s make the understanding principle more concrete:

FP1 (expanded): Start with what you do now, understanding

  • The purpose of the system
  • How it serves the customer
  • How it works for those inside the system
  • How it leaves customers dissatisfied and workers frustrated
  • How it can be changed safely

This contains practice as well as principle—it’s actually a highly distilled summary of , the implementation approach described in Part III. It works both for Kanban’s initial introduction and for subsequent changes.

Understanding the purpose of the system takes us from what we do now to why we serve our customers in the way we do. For my former team in Budapest, it took us from “We build and support energy risk-management systems” to “We build and support the systems that enable our company to help our customers manage their energy risks.” For a team that would struggle to get past “We are software developers” (and we definitely weren’t one of those), understanding purpose could be a big step.

We take the dissatisfactions and frustrations as indications either that there are obstacles preventing the system’s purpose from being fulfilled, or that we don’t yet understand that purpose well enough. Acknowledging them, their possible root causes, and their effects is a key first step toward making impactful change.


Next up: 8. Agreement. Previously: 6. Leadership. Start from the beginning: 1. Transparency.

November 25, 2014

Understand motivation for change

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

One piece of feedback I’ve received a few times on step 1 of STATIK (and therefore on chapter 18 of my book Kanban from the Inside also) is that “Understand sources of dissatisfaction” sounds rather negative. What about sources of satisfaction, pride, strength, and so on? Are those unimportant?

It’s a very valid comment, and with David at this week’s Train-the-Trainer class in Cascais, Portugal, we renamed this step “Understand motivation for change”. Ironically, this name existed already as the title for the accompanying class exercise!

We made the change to the Foundations deck right there in front of the class. Other decks and my book will be updated as soon as is practically possible.

As it happens, I am very interested in the positive (the naming of my blog is no accident). My favourite retrospective format—a format that would work well in the context of a STATIK workshop—is the Stanford d.school’s “I like / I wish / I wonder” (“IL/IW/IW”) or “I like / wish / What if” (“IL/IW/WI”) which sometimes I abbreviate to “+/-/?”. In one simple exercise, we find out both what we’d like to change, what we’re keen to preserve, and what needs digging into further.

STATIK requires us to do this from two perspectives, internal and external. As my friend Markus Andrezak puts it, we need both self-awareness and empathy. Let’s strike the right balance between the positive and the negative also. It’s not all bad!

Source: Markus Andrezak

March 26, 2014

STATIK, Kanban’s hidden gem

As far as I can tell from my extensive research (two Google searches), I’m the first person to notice that the “Systems Thinking Approach To Introducing Kanban” could go by a nice acronym, STATIK.

Not heard of it? You’re probably not alone. It’s not widely regarded as a first-class component of the Kanban Method, but maybe (and I’m expressing just a personal opinion here), we could change that.

You may recognize the steps:

  1. Understand sources of dissatisfaction
  2. Analyze demand and capability
  3. Model the knowledge discovery process
  4. Discover classes of service
  5. Design kanban systems
  6. Roll out

Our training has included these elements for a long time and we now expect each of them to be taught in accredited training (except perhaps step 6, which is beyond the scope of Foundation level training). If STATIK has a short name already, it’s “Day 2”!

if that doesn’t explain its familiarity, perhaps you’re reminded of the equivalent steps in Lean:

  1. Identify value from the customer’s standpoint
  2. Map the value stream
  3. Create flow
  4. Establish pull
  5. Identify and eliminate waste

In both formulations there’s an implied “rinse & repeat”. They’re not exactly equivalent (STATIK is by design more specific to creative knowledge work) but the parallels are clear.

I’ve been doing a lot with STATIK in the past year and a bit. It’s the focus of Part III of my book; in my interactive workshop at LKNA14 we will explore the combination of STATIK, values, and serious games (I’ve been working with Luke Hohmann on key elements of this); and of course I’ve been teaching, coaching, and consulting. And it changes things!

So to the real point of this post: I’m learning to be a little skeptical when I hear of changes driven from the board – “improvements” to layout, policies or WIP limits designed to drive changes in behaviour. I’d much rather hear that discussion of customer dissatisfactions or team frustrations is provoking discussion on how system changes might achieve one or more of these three things:

  • make the impact of these issues more visible
  • bring suspected root causes closer to the surface
  • start in some testable way to address these issues

Changes to kanban systems then follow, as necessary.

I hope we’re agreed that change should be implemented with understanding, agreement, and respect (the three values I call leadership disciplines). STATIK is a highly actionable implementation of that guiding principle. I commend it!

May 22, 2013

Making a case for “leadership disciplines”

Evoking the 70’s bumper sticker “A dog is for life, not just for Christmas“, I suggested in my last post that

Agreement is not just for the kick-off meeting

Let’s extend that thought to the first group of Kanban’s values. What if we positioned understandingagreement and respect not as initial conditions for a learning environment but as leadership disciplines expected of everyone who has responsibility immediately around it?

Putting Kanban to one side, what would your Agile implementation or other significant change initiative have looked like had there had been sustained outside commitment to the following principles:

1. Understanding is a prerequisite for effective change

  • Change will be based on an understanding of genuine problems or opportunities, framed such that upsides and downsides can reasonably be demonstrated and managed
  • Change increments will be sized according to our understanding, safety never compromised (recalling J curves, bet-the-company bravado and so on)

2. Agreement will not be taken for granted

  • Change will be implemented through agreement between those (or between representative of those) who
    • request or recommend change (the instigators)
    • understand what needs to be done and estimate its impact good and bad (the designers)
    • will implement it
    • will be impacted by it

    Clearly, the more these groups overlap, the easier it gets.

3. Respect is a key test

  • Each change will be conducted respectfully
  • Collectively, change will
    • remove sources of frustration and other barriers to success
    • raise levels of trust and safety
    • create the space for creativity and excellence

What if the “skin” of your “culture bubble” was made up of a group of people who are committed to using their authority to represent and defend those three values? What effect would that have, both on the team and on the wider organisation? Rather than those inside the bubble, perhaps it is this group that should be our first concern?

If not our first concern, then at least a different concern. A focus on leadership discipline at the boundary that promotes change inside in the direction we want (including but not limited to customer focusflow and leadership), sustained internally by the drive of the more practice-focussed values of transparencybalance and collaboration.

It strikes me that this formulation (a minor refinement to the model I presented in Chicago) begins to tackle two common misgivings around Agile and Lean.

Misgiving #1: Hierarchy vs collaboration

This misgiving is most commonly associated with Lean, although similar misgivings are sometimes expressed about Agile, in particular around the Scrum roles. How can an apparently hierarchical management system be reconciled with a culture of collaboration?

Let’s be clear about one thing: I have no interest whatsoever in replicating a shop-floor management hierarchy with its team leads, supervisors and so on. But what about leaders already at the periphery of the change initiative? If they’re expecting to see understanding, agreement, and respect and have learned to live those values themselves, won’t that have an effect? I see this expectation catalysing creative collaboration inside the boundary and facilitating collaborative problem-solving across it (thereby growing the initiative’s scope). Doesn’t this give a good picture what the effective leader (or manager) as coach looks like?

To further illustrate the potential for de-emphasising hierarchy, let’s see less of this (me, 2012):

alignment

and more of this (me, 2013):

change-team

Perhaps hierarchy is like iteration – just as it’s interesting and useful to see how far we can take these ideas (many people now assuming that they’re axiomatic to Lean and Agile respectively), it’s also interesting and useful to describe and explore universes that don’t depend on them quite so fundamentally.

Misgiving #2: The “mindset get-out clause”

I have long wished to challenge those who say that Agile can’t work here because the organisational mindset is wrong (or that Lean failed for the same reason). I find this chicken-and-egg excuse hard enough to swallow when expressed with genuine regret; when it’s accompanied by disrespect (of which “pigs and chickens” is but a mild form) I despair!

If we’re agreed that an incremental, evolutionary approach makes sense both for product development and process improvement, wouldn’t it make sense to approach mindset and culture in the same way? With some kind of plan of attack maybe?

Here’s my starting approach in two steps:

  1. Find the skin of the bubble: I’ve learned the hard way that improvement that isn’t end-to-end is often futile; reaching out upstream and downstream is therefore essential. It’s also natural for me to reach out (or up, if you like) to managers – I was one myself and I have no difficulty in identifying with them.
  2. Speak there the language of values: Don’t just gain an understanding of the problem for yourself; insist that shared understanding and agreement are essential, that respect is both a means and an end, and that their discipline as leaders will be critical not only to initial wins but to lasting success. Then explore the other values as you seek alignment between external and internal goals. Balance was for example a key theme of the early part of my last engagement, moving later into transparency and customer focus.

Real life is of course a little messier than I’ve described but I’m glad to have crystallised much of what I’ve been doing over the past few months.

Acknowledgements

Joshua Kerievsky for broadening my understanding of “safety” (see #techsafety) and Liz Keogh for “respect is a test”, both at #LKNA13Michael Sahota for “culture bubbles”; Steven J Spear whose book The High Velocity Edge (mentioned here) is still exerting its influence.

I’m grateful also to Jim Sutton and Martin Burns for feedback on earlier drafts of this article.

February 26, 2013

How complex systems fail

Filed under: leadership,lean — Tags: , , , , , , — Mike @ 7:40 am

From Steven J. Spear’s The High Velocity Edge, chapter 3 – How Complex Systems Fail:

In all the cases that we examined, there were common characteristics that led to painful results. People lacked a systems view – a full appreciation of how the work they did was affected by and affected the work of other people. Granted that, as Perrow pointed out, it was exceptionally difficult to understand all the nuances of how such as complex system worked, but the people in these cases did not advance their understanding when there were warnings that they should have. Rather than push for ever-better clarity as to how things should work, they were exceedingly tolerant of ambiguities regarding who was supposed to do what, how to convey information from one person to the next, or how to perform a particular task. And even when it was obvious that something was wrong, they worked around the problem, relying on extra vigilance and extra effort. Thus they imposed on themselves the same set of problems day after day, constantly turning down the chance to understand the complex interactions of people, technology, place and circumstances better and thus improve the system as its flaws were discovered.

Powered by WordPress