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

June 26, 2015

Featureban – notes for facilitators

Filed under: Kanban,lean — Tags: , , — Mike @ 11:06 am

It’s about time I posted the notes I email to people who ask about facilitating Featureban, so here goes…

Here’s a link to the latest powerpoint: (withheld – I’m happy to share but do please email me for this)

You might find it helpful to take a look at the slideshare embedded in Are we there yet?. Take advantage of the Creative Commons licensing and make your own customisations or translations! The checklists shown in the deck are now available via Agendashift in the Values-based Delivery assessment template, the basis for the Depth of Kanbanland 2015 survey.

Time priorities depend very much on needs, goals and audience. Typically I do either:

  1. Rounds 1 and 2 and a “here’s one I prepared earlier” on round 3, plus lots of time for Q&A on all things Kanban and Agile (the sessions I’m running at my current client are positioned as Agile training)
  2. All three rounds with a few minutes debrief for each

In the last meetup I did, I achieved #1 above in about 75 minutes. Your mileage may vary. The job of the debrief is to let people make the connection with the workplace.

There is now an fourth round which I use only when I have a couple of hours available (eg in a workshop). One option is to discuss this round without actually trying it.

I make a point of comparing the rules of round 1 and round 2; everyone should agree before playing round 2 that the only change is the WIP limit. I’m careful not to use the word “collaboration” myself until participants make the key observation that this improves significantly in round 2.

Stop round 1 as soon as most teams have delivered a couple of items. Most teams will have lots of WIP in the 2nd column. DO NOT reset boards between rounds 1 & 2. Advise teams to hold replenishment events when their backlogs become depleted. In later rounds, they might reuse “done” tickets to save time.

A WIP limit of 3 in round 2 works well. The fact that the limit is imposed by the facilitator rather than proposed by the team can be discussed later when you get to “improve experimentally, evolve collaboratively” (CP6) in the debrief.

One other tip I heard first from a couple of other facilitators and have now tested myself: the atmosphere and interaction around the game is improved if the board is mounted vertically (eg using a flipchart or taped to a wall). It means there’s less time staring down at a table!

May 23, 2015

Kanban from the Inside: 15. Economic approaches to flow

Filed under: Kanban,lean,Uncategorized — Tags: , , , , , — Mike @ 4:54 pm

We’re at chapter 15 of Kanban from the Inside, on economic approaches to flow. This excerpt expands on the third of three principles of Real Options as identified by Chris Matts and Olav Maassen [1, 2]:

  • Options have value
  • Options expire
  • Never commit early unless you know why

Never Commit Early Unless You Know Why

This looks like another truism, but it is well worth repeating. How different would most projects look if for every planned feature someone asked this question [3]:

What would have to be true for this option to look fantastic?

Where the answers to this question are unknown, a new layer of exploratory options can be generated.

Typically, the project provides the perfect mechanism for avoiding this question. Scope, duration, and cost are all decided before the questions are even asked, let alone answered. By design, changes to any of these cause drama and stress!

Contrast that to an options-based approach. Instead of a predetermined project backlog, we have a portfolio of options, a growing pool of uncommitted ideas that may or may not come to fruition. Options get exercised—that is, work gets pulled—when they will generate the most valuable information relative to all their alternatives.

Options thinking also does something interesting to risk management. Outside the development process, uncommitted options remain in the hands of those best placed to manage them, for example, those with the market knowledge to maximize opportunity. Once inside the system though, the risks change in both nature and ownership—there are expectations to meet. There is more than meets the eye in the act of pulling of work across these boundaries—it creates obligation and transfers risk. It is not to be done lightly.

[1]Chris Matts and Olav Massen. 2007. “Real Options” Underlie Agile Practices (InfoQ)
[2] Chris Matts, Olav Massen and Chris Geary. 2013. Commitment Hathaway te Brake Publications.
[3] Roger L. Martin, in Lafley, A. G. and Roger L. Martin. 2013. Playing to Win, How Strategy Really Works Boston: Harvard Business Press.


Next up: 16. The Kanban Method. Previously: 14. TPS and Lean. Start from the beginning: 1. Transparency.

May 16, 2015

Coming soon: Agendashift

[Update: Now cross-posted to Agendashift’s new blog. View on blog.agendashift.com]

Imagine a change process based on choice and collaboration:

  • You (an individual or team) take an assessment of your choosing, invite a coach to facilitate one with you, or opt to participate in a survey
  • You explore online an analysis of your own inputs and the aggregated inputs of your colleagues, identifying strengths, weaknesses, leading and lagging areas
  • You identify the prompts or categories that best describe your collective agenda for change
  • You track actions through to completion until it’s clear that they have taken hold and are delivering the benefits expected

No emailing of spreadsheet-based questionnaires. No being left wondering what’s happening to your inputs. No imposition of priorities from on high. No failure of ownership and follow-through. These are my “itches to scratch”. Whether you’re a consultant, a client, or managing without external support, Agendashift can help you too.

Right there are Agendashift’s four A’s: Assessment, Analysis, Agenda and Action. Of course it doesn’t have to be as linear as that: given time, Action should dominate, kept on track with periodic recalibrations from the other three.

You’ll see a free version launched in the next few weeks that anyone can try without obligation. A little after that, paid accounts will bring the ability to design new assessment templates and to manage client/team workspaces.

Agendashift will launch with a “Values-based delivery” template adapted for public consumption from my book with the help of some much-appreciated collaboration. If you have ideas for other templates (your own practice’s tools perhaps, or more specifically Agile or Lean than mine), do get in touch.

Meanwhile, leave a comment, follow @agendashift on Twitter or sign up at agendashift.com to be sure of receiving launch news.

May 14, 2015

Kanban from the Inside: 14. TPS and Lean

Filed under: Kanban,leadership,lean — Tags: , , , — Mike @ 5:27 pm

I really enjoyed writing this chapter! My goal was to illustrate the extent to which things can look radically different and yet share the same underlying principles and philosophy. The excerpt below comes after a description of a production line at Toyota; the “TPS” of the chapter title is the Toyota Production System.

Beyond the already-familiar “Kanban“, a number of Japanese terms are introduced. I use them freely in this chapter but rarely elsewhere (and I explain why).


This [preceding] description is rather simplistic, but there’s enough here for some striking characteristics of the system to be noted:

  • All three tools (kanban, heijunka, and andon) are examples of visual management.
  • Inventory of all kinds is limited. Neither basic supplies nor WIP (the subassemblies, or partially-built products) will be replenished until equivalent amounts have been pulled from downstream.
  • Even though, perhaps, it might seem more efficient to do so, the production line doesn’t work in large batches of similar items. Instead, it produces a variety of products spread over the course of the day.
  • Workers on the production line would rather stop the line (for everyone) than allow work of inferior quality to proceed.
  • This system and the kanban boards from Part I work very differently. On the production line, the kanban [1] are sent upstream to signal that there is demand to be fulfilled. On our boards, the cards represent work items as they flow downstream; signals are implied by the gaps between the actual amount of work in progress in each state and the corresponding WIP limits.
  • The heijunka box and our kanban boards both allow the mix of work to be managed.

It seems perverse, not only setting things up to work in this deliberately difficult and seemingly inefficient manner, but empowering workers to bring it all to a halt at any time! Clearly there must something special about the company’s culture for this to work at all, but why would they choose to do things this way?

TPS and Lean in Perspective

To answer that question you must understand TPS as a magnificent example of systems thinking.

It starts with a vision, a true north that gives the direction for change:

  • Single-piece flow, in sequence, on demand, with zero defects; 100% value-adding activities and security for the people performing them

The technology does not yet exist to make it economical to run the entire production line in batches of one (which is what single-piece flow means), but the pursuit of this perhaps impossible vision is what propelled Toyota from its struggles in postwar Japan—where land, factory space, plant, and materials were all in short supply—to the global market leadership position that it now occupies.

The tools support one or both of two purposes:

  1. Satisfying customer demand as quickly and as smoothly as (currently) possible with the minimum amount of inventory
  2. Evolving the company to take it closer to its vision, harnessing the abilities of its entire workforce to smooth flow, reduce inventories, prevent defects, eliminate other forms of waste, and (not least) design new products that customers really want and that can be produced both profitably and sustainably

The two pillars of just-in-time and respect for people are shorthand for those sub-goals.

Often missed is this crucial point: The pillars and the tools can been seen in their proper perspective only once it is grasped that Toyota’s pursuit of perfection is a multi-generational challenge. Toyota works not only to build cars, but also to build the company capable of delivering on its vision.

Divorced from that kind of thinking, the tools of Lean can seem shallow. Without the tools, it can be even worse—too often we hear Lean reduced simply to a short-term focus on waste (perhaps to dress up exercises in cost cutting), or to continuous improvement (important, but very hard to sustain in isolation). The challenge of the Lean movement is to make sure that the thinking is packaged up with the tools so that people can apply them appropriately in context.

[1] “Kanban are like sheep” – One kanban, two kanban, …


Next up: 15. Economic approaches to flow. Previously: 13. Agile. Start from the beginning: 1. Transparency.

September 18, 2014

A process of knowledge discovery

Filed under: Kanban,leadership,lean,Values — Tags: , , , , , — Mike @ 3:32 pm

Creative knowledge work is a process of knowledge discovery. You might say that this statement goes a long way to define creative knowledge work and let the rest be left the imagination, but there is still plenty to be said about the process of knowledge discovery.

In Kanban from the Inside I make 16 mentions of “knowledge discovery” – clearly it’s an important term! They are concentrated in these chapters:

  • 4. Customer Focus, about the value
  • 10. Patterns and Agendas, which introduces the Kanban Lens
  • 20., 22., and 23., which take us through the STATIK implementation steps Model the Workflow (aka Model the Knowledge Discovery Process), Design Kanban Systems, and Rollout respectively

The presence here of the customer focus value is a clue that I leave precise technical definitions to others. Instead, I describe the coming together of attitude and actual practice, which (in general) values encapsulate superbly. My conclusions could be summarised as follows:

  • Aim not merely to take orders or to satisfy requirements, but instead to anticipate and meet needs at the right time
  • Be humble about how little you really know; proceed accordingly
  • Be humble about how inadequately your process uncovers needs; help it to adapt
  • Even after delivery, expect to learn more about how needs are being met; validate!

In short—and with apologies to Stephen Covey—begin humbly with the undiscovered need in mind.

I use the word “humbling” every time I retell the story of my first introduction of an explicit post-delivery validation step. Tired of seeing my teams deliver against unneeded requirements, I insisted on it out of pure frustration and with a “that will teach them” kind of negativity, aimed mainly but not exclusively at our customers. The effect on the whole process was however nothing short of profound; the end result being real collaboration at every stage of the process!

Nowadays, and with the advent of the likes of Lean Startup and Lean UX in which validation is formalized, we know that a commitment to validation is a highly repeatable way to catalyze a shift from requirements-driven to hypothesis-driven development. The Kanban Method doesn’t make this commitment explicit, but it is a widely recognized practice fully in keeping with the customer focus value and the core practices of “Manage flow” and “Implement feedback loops”. And for me personally, there’s no going back.

 

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!

March 21, 2014

The Kanban track at #lkna14

Filed under: Kanban,leadership,lean,Values — Tags: , , , — Mike @ 5:00 pm

It should come as no surprise that the Lean Kanban North America 2014 (#lkna14) conference has a Kanban track. What you might not know is that I’m its chair. I’m taking the opportunity here to say a bit about what we have in store:

Talk 1 is from me. I will answer three questions about the Kanban Method:

  1. How does Kanban help self-organizing teams make better decisions?
  2. How does Kanban help improve service delivery so that we can anticipate customer needs more effectively?
  3. What does Kanban have to say about organization and culture?

That should set up the other four talks nicely:

  • Eric Green tackles Kanban practices and team-level sustainability via a remarkable true story (about which I don’t want to say too much right now – you’ll have to hear it for yourself)
  • Russell Healy, well known as the creator of the awesome getkanban game, shares with me an interest in the “Inner Game” (I book I often recommend, John Whitmore’s book Coaching for Performance, is from the Inner Game camp).  Russell will be speaking on the “Inner Game of Kanban”. I can’t wait.
  • Another pillar of the Kanban community, Yuval Yeret, joins us as co-speaker with Yaki Koren, Limor Saden, and Keren Yahalom of Amdocs for “Amdocs SBG: Moving Thousands of People to Kanban within 16 Months”. Their case study is all about scale: large-scale change and service delivery at scale.
  • For the last talk of the track I have reached out to Frode Odegard. I expect Frode to challenge us to think harder about how Leadership at every level actually happens. His talk is called “Leadership as a Design Problem”.

In parallel with my Kanban track we have Beyond Budgeting and Evolving Product Management tracks; then Lean Applied, Managing Risk and Lean Startup the following day. These two “track days” are book-ended by two days of interactive workshops, each with its own program of keynotes and other plenary sessions. I’ll be leading a workshop called “Shaping the Agenda with Values and Serious Games” (more on that soon).

This all takes place May 5-8, 2014 at the Hyatt Regency, Embarcadero, San Francisco. Be there!

October 23, 2013

One method, three agendas

Working in the US last week with David on some updates to the Kanban curriculum, it struck me soon after writing my last post (where I was thinking out loud) that the Kanban Method speaks to multiple agendas:

  1. The continuous improvement agenda – kanban systems feeding the process of ongoing improvement[1], providing grist to the mills of Agile retrospectives, Lean improvement routines, collaborative PDCA and so on
  2. The service delivery agenda – using service orientation as a lens[2] on process and organisation, being clear about what we deliver, to whom and why, understanding and deepening the knowledge discovery process[3], catalysing collaborative, customer-focused delivery at scale
  3. The humane, start with what you do now agenda – the Kanban Method’s very distinctive, values-centric approach to leadership and organisational change

(Forgive me for presenting these in this inside-to-outside order – it aligns to my talk[4])

Many people both inside and outside the Kanban community find it easy to identify with that first agenda. For better and for worse, it integrates very comfortably with other frameworks, the “better” part being that it helps (a lot), the “worse” part being the limits imposed on Kanban’s reach by attachment to existing models.

I’ve majored all year on that last agenda; from my initial post in early January, explaining Kanban as a system of values has been very fruitful. Invoking Bruce Lee (yes, that Bruce Lee) with “be like water” and “no method is method”, David elevates Kanban’s approach to change to a philosophy.

But neither agenda adequately reflects the impact that Kanban can have from the moment it is introduced. It’s a paradox often observed: how is it that the start with what you do now method so often heralds such immediate change?

Perhaps we’ve invested too much in explaining how Kanban works and too little in describing its effects. We must allow the possibility that some familiar messages that continue to resonate strongly with those that deeply understand Kanban may do little for those that don’t.

The service delivery agenda is distinctive enough (actually quite radical in many organisational contexts) and gets quickly to the immediate benefits. We know from teaching to this agenda that it resonates. Yes, change management and leadership are necessary to bring it about and continuous improvement will sustain it, but those messages can come later.



[1] Or POOGI, the improvement cycle of the Theory of Constraints

[2] See David’s post The Kanban Lens and the kanbandev discussion

[4] Don’t forget LKUK13 (London) next week and LKCE13 (Hamburg) the week after!

October 4, 2013

My notes for the Portfolio Management panel at #lkfr13

Yesterday I had the privilege of sitting on a panel on the subject of portfolio management at Lean Kanban France. Our facilitator was Thomas Lissajoux and my co-panelists were Ian Carroll, Chris Young and David Joyce.

Thomas did us the great service of asking for some notes ahead of time. I found his headings really helpful, and I’ve decided to share my notes. And here they are…

How would you define ‘portfolio management’?

I see portfolio management as managing at that kind of level where maintaining the right balancing between competing projects is as big a challenge as any individual project.

What are the specifics of a lean/agile approach?

Depressingly, I see too many people talk about portfolio management like it was a sausage factory. The story goes like this: “just pay attention to the quality of ingredients going into the machine and success is guaranteed”. I doubt that this metaphor works very well even for sausages!

A lean approach means several things:

1)     Paying attention to the balance of demand and capability (supply), managing WIP relative to capacity and relative to lead time aspirations

2)     Paying appropriate attention to flow, because speed, predictability and timeliness matters (to the extent that there are economic penalties when we get these wrong)

3)     Expecting the way we manage the portfolio to keep evolving. That evolution needs to have some positive effects at project and organisational level that customers will recognise and appreciate, and there needs to be effective feedback in the other direction too (success and failures at project level should generate portfolio-level learning).

In which context/clients do you do portfolio management?

I’ve twice been in the role of portfolio manager myself, once with a $XXmillion annual budget, the second time at a smaller scale but with wider organisational impact.

Nowadays as a consultant I find that many problems on the ground point back to problems in portfolio management. Parts of the process get overwhelmed, and the organisational feedback loops aren’t fast or capable enough avoid real pain and cost. I’ve seen extreme cases where the whole portfolio seems to be grinding to a halt (there are reasons why this happens, a topic for another post maybe).

What about the previous situation and its shortcomings?

In many organisations, to get a project started it’s enough merely to sell the idea. The capability of the organisation to deliver and the impact on existing work is not given much consideration.

What key practices/tools/artefacts/meetings/metrics do you use?

  • The sheer number of projects (relative to the capability to manage them effectively)
  • Their value (with an understanding of the relationship between value and urgency)
  • Planned, potential and actual burn rates (making sure we have the capacity to deliver; too often the sum of all promises doesn’t match the sum of available effort)
  • Lead times
  • Amount of work in certain key states
  • $WIP

Tool-wise I’ve had success with

  • A3, as a means to test project rationale
  • Changes to portfolio reporting (feedback loops)
  • Customer validation – for its own sake and as a catalyst for process change
  • Regular customer meetings (cadenced)

What about the Kanban principles and practices at portfolio level?

They need to be applied with imagination. Add the phrase “Find ways to…“, perhaps “Find multiple ways to…”.

Core practices:

  • Find (multiple) ways to visualise work at portfolio level (transparency).
  • Find (multiple) ways to limit work in progress at portfolio level (balance).
  • Look at how policies can drive better portfolio performance (transparency again).
  • Pay attention to the feedback loops (and again!)
  • Keep improving and evolving (collaboration)

Foundational principles (or rather, their underlying values):

1)    Understanding: Make sure change is based on genuine understanding of how things work now, taking both internal and external perspectives

2)     Agreement: Always have the right people (ie those with a stake in the solution) solving problems at the right level, seeking agreements that will hold in practice

3)     Respect: the first two, plus creating the expectation that improvement will benefit people, not just the numbers

4)     Leadership: grow the next generation of portfolio managers (growing yourself in the process)

Additionally I would add that the portfolio mindset and Kanban are really complementary. Identify

  • different kinds of projects
  • different risk profiles
  • different stakeholders
  • different budgets/appetites

Make these dimensions visible (I mean an in-your-face, Kanban’s-killer-feature kind of visible, not just a filter on a report), aim for a healthy mix of work. With success comes trust in both your ability to deliver and the underlying principles and techniques that make it happen.

What challenges did you face?

Pretty much everywhere, far too many projects and projects that take far too long to deliver.

  • In one company, more projects than there were people, not just in IT but in the whole company!
  • In another, projects taking multiple years, little thought given to the possibility of incremental delivery

What key advice would you have for ‘change agents’ about to dig into portfolio management questions?

  • How is demand managed against capability?
  • Are lead times too long? (a very different question to the one of whether projects are late – dates tend to be genuinely critical on no more than 20% of a typical portfolio – though the long projects tend also to be ones most prone to delay)
  • Can you put a value on the amount of WIP (I refer to this as $WIP)? High shock value!
  • Another great metric once you understand it: What is that WIP costing in delayed business opportunity and delayed feedback?
  • Is the typical project process set up just to deliver to spec or to meet an evolving customer need? See recent posts Stand up meeting, thinking tool, leadership routine and Anticipating needs ahead of time.

What are the next steps? How can you improve/scale?

Quantify, visualise, sanity check. Look for imbalances. Look for sources of unpredictability, especially waiting. Look at the relationship between project size and predictability.

And remember that scale comes with addressing coordinating costs and other kinds of friction end-to-end, not from rolling out more process or adding layers on top.

September 24, 2013

Anticipating needs ahead of time

Filed under: leadership,lean,Values — Tags: , , , , , , — Mike @ 10:00 am

Last week’s post Stand up meeting, thinking tool, leadership routine included this line:

In what ways do the activities of this stage help us anticipate what will be needed?

“Anticipate” and “will”: two very future-focused words.

That emphasis on the future is captured very nicely in the closing words of the Toyota Customer Promise that I found displayed on a plaque behind the customer service desk at my local Toyota dealership:

…anticipating the mobility needs of people and society ahead of time

Think of a service on which you personally rely. Wouldn’t you be delighted if they anticipated your needs ahead of time? What process innovations would be needed in order for that to happen? How could that thinking be translated into your workplace, and how would it then be sustained?

These are important questions. They’re questions of customer focus, of flow, and of leadership, the three direction values. They’re important because an organisation that works on its capability to anticipate and meet future needs is a fitter organisation, and it’s the fittest that thrive.

There’s more where this came from! My book is going to be a while, but in the next few weeks you can hear me speak on Kanban’s values at:

Unfortunately I must report the postponement of the UKSMA annual conference at which I was to give the keynote. I’ll mention it here when it has been rearranged.

Older Posts »

Powered by WordPress