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

July 21, 2015

Kanban from the Inside: 23. Roll out

Filed under: Books,Kanban — Tags: , , , — Mike @ 1:08 pm

For this 23rd and final installment of excerpts from my book I have chosen a very short extract. I chose it not because it summarises the chapter (it doesn’t) or the book as a whole (it certainly doesn’t do that) but because it helps explain some of what I have been doing since publication. Agendashift (tagline: “values-based change for the evolving organisation“) provides tool support for the change management process described in this chapter. The existing work hasn’t stood still either; you can now access an online realisation of a much-improved version of chapter 23’s checklist by participating in our Depth of Kanbanland 2015 survey. And please do!


Roll out

I find it useful to think of Kanban implementation as a three-stage process:

  1. Planning the engagement: preparation in terms of participants, venues, tools, supporting material, and so on
  2. Shaping the agenda: approaching STATIK with the explicit aim of producing a compelling set of agreed upon priorities, goals, and actions
  3. Pulling change through the system: maintaining momentum into the future, ensuring that progress will continue to be both visible and meaningful

This structure can be applied regardless of whether your aim is to build a stand-alone kanban system, to introduce the Kanban Method for the first time, or to reinvigorate fresh cycles of change. You can even use it retrospectively, helping you to think constructively about an implementation that needs a stronger connection with its host organization.

I hope to show that there is no contradiction between introducing Kanban impactfully and remaining true to its humane ethos. Toward the end of this chapter we review the role that the values can play in motivating an implementation.


Previously: 22. Design kanban systems. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and Kindle at amazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is available via the djaa.com store also.

July 10, 2015

Kanban from the Inside: 22. Design kanban systems

Filed under: Books,Kanban — Tags: , , — Mike @ 3:52 pm

It hardly seems possible, but this is the penultimate installment! We have two excerpts this time, both from towards the end of the chapter 22. We’ll finish with reviewing your kanban board’s initial design, but first we’ll look at ways to limit work-in-progress (WIP).


Limiting WIP

A true kanban system incorporates some mechanism for limiting the amount of work in progress. Once again, there are numerous ways to achieve this:

  • Numeric WIP limits, each controlling the amount of WIP in a single column, a span of columns, or a horizontal swim lane.
  • Physical constraints, such as the number of horizontal swim lanes available.
  • Limits on the number of tokens (e.g., personal avatars) in circulation, and attaching them to tickets. The control offered by this mechanism is lessened if tickets are allowed to be in progress without such a token; in this case, it is limiting not the overall WIP, only the amount considered “active.”
  • Policies that control, for example, the amount of WIP per person or class of service.
  • Some external mechanism that releases work into the system only when there is capacity. Scrum achieves this by limiting the amount of work committed to in a timeboxed sprint.

There is a lot to be said for using multiple techniques in combination, for example:

  • Horizontal (e.g., class of service) and vertical (state) limits in combination
  • Physical constraints (e.g., on epics) combined with vertical limits (e.g., on features in active development)
  • Sprints combined with column-level limits, to curb multitasking and to encourage work to move from states of partial completion (e.g., “code complete”) and on toward deployment

When multiple crosscutting mechanisms have been properly calibrated, no limit needs to feel overly constraining on its own, and yet the combined effect is to reduce WIP to levels that might previously have seemed inconceivable. Each limit addresses a particular symptom or behavior, kicks in when needed, and helps to smooth flow overall.


Review

Given the wide range of design choices available, it’s a good idea to review the board design before deeming it to be your “initial” one (don’t ever think of it as “final”!).

Begin with some basic technical checks:

  • How does the board look when populated with work items? Does it organize them effectively? Is there enough room?
  • How much movement will we see between standups? Not enough? Too much?
  • Is it understandable by its intended users? Too complicated? Too simplistic? Ask them, or better still, involve them.
  • Does it make unreasonable demands or assume changes of process, organization, or role that aren’t yet agreed upon? (I don’t say “never” to introducing radical system changes at this stage, but I don’t usually recommend it.)

More reflectively, a good design addresses multiple needs of a broader nature:

  • It brings transparency to what is happening and how it happens, helps better decisions to be made, and encourages self-organization and collaboration. Can you (collectively) picture those things with this design?
  • It helps to bring balance—between demand and supply, across different categories of demand, and so on. Will it do that, even if only tentatively?
  • It encourages both thought and action with respect to customer focus and flow. Refer to Chapters 4 and 5 and try using your board design as a thinking tool.

Lastly, and crucially:

  • In what ways does this design begin to address the specific dissatisfactions and frustrations you captured at the very start of this process (Chapter 18)? Don’t expect to fix all of them right away—it may be better not even to try—but will it bring their symptoms or causes closer to the surface than they are now?

These review considerations—and most especially the last one—apply not only when designing a board for the first time, but when evolving it, too. Better an ugly board whose changes are deliberately targeted than a beautiful one whose refinements exist for their own sake. Learn to see through the board to the system it represents; act on one for the effect it has on the other.


Next up: 23. Roll out. Previously: 21 Classes of service. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and Kindle at amazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is available via the djaa.com store also.

July 2, 2015

Kanban from the Inside: 21. Classes of service

Filed under: Books,Kanban — Tags: , , — Mike @ 1:11 pm

This week’s excerpt comes from the chapter’s conclusion. If you think that classes of service is just a technical topic that has no human (or humane) dimension, think again!


Toward a Healthy Mix of Work

This much should be obvious: You can’t plan to have everyone occupied 100% of their time on fixed-date work, allow them to be interrupted by expedited items, and still expect predictability. Even without the interruptions, 100% utilization on work that must meet stringent deadlines is a recipe not for efficiency, but for extreme unpredictability and delay, not to mention pain at the human level. Systems need slack if they are to absorb variation rather than accumulate it, and people need it too.

You might be wondering what a “safe” (or “humane”) utilization level might be. 90%? 80%? I believe that this approaches the problem from the wrong direction. From direct experience as a manager, and from clients sampled by myself and David, fixed-date items need make up no more than 20% of the workload of most organizations; often, it can be significantly less. After allowing (say) 10–20% for intangible work, and a realistic provision for expedited and other unplanned work, the biggest category of all should be the high-value, urgency-driven work. This is exactly as you would hope it to be, assuming that you seek to maximize the flow of value to the business. Happily, predictability is achievable, too, thanks to the presence in the system of work items that can safely be delayed when time-critical work needs to take precedence.

Classes of service and other categorizations enable some broad-brush prioritization decisions to be made independently of potentially contentious decisions about individual items. Making these explicit creates the opportunity both to align them to wider corporate priorities and to match them to customer needs. So long as there is the short-term flexibility to trade between categories, it should be possible to satisfy both constituencies.

For your workshops, questions like these help guide the overall mix of work in the right direction and prompt discussion about system design:

  • What proportion of our portfolio is necessarily date-driven? Are we entering into date commitments unnecessarily, and if so, can we begin to bring this proportion down? Do we make reference to available capacity when scheduling? Are we able to respond when dates are under threat?
  • How much capacity do we need to hold in reserve for expedited and other unplanned work? What steps can we take to reduce and/or limit the amount we are servicing at any given time?
  • Are we doing enough intangible work? What space do we give people to explore better ways of doing things?
  • What capacity remains for standard, urgency-driven work? Do our systems reliably bring the right items to the front of the queue first?

If these questions make you uncomfortable, perhaps they should! Could it be that people are over-organized—“projectized” or siloed? If your organization lacks the ability to self-organize when and where it most needs it, it is paying a heavy price.

I have in the past described Kanban’s ability to deal with variety as one of its “killer features.” Arguably, the way STATIK encourages organizations to embrace variety is even more powerful. If only it were better known!


Next up: 22. Design kanban systems. Previously: 20. Model workflow. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and Kindle at amazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is available via the djaa.com store also.

June 26, 2015

Kanban from the Inside: 20. Model workflow

Filed under: Books,Kanban,Uncategorized — Tags: , , — Mike @ 11:33 am

The end is in sight – this the 20th excerpt from my 23-chapter book. This week, two excerpts for the price of one!


This chapter looks at three different approaches to modeling the workflow that our kanban system is going to support:

  1. Sketching it out
  2. Top-down decomposition
  3. Bottom-up organization

It’s important to remember that the result that we’re working toward is a working kanban system, not a static model. It’s best not to get too attached to the products of this exercise—they will quickly lose their value once the system begins to evolve.

I’ll keep this simple by assuming that there is just one main workflow involved. If you have more than one, you can take each workflow in turn or use one as the baseline by which the others are described.


Review

Before we move on, here are some good ways to check and improve what you have so far:

  • Quickly combine approaches to validate your model, such as:
    • Produce a sketch from your top-down or bottom-up model.
    • Make sure that actual work items map to your sketch or top-down model, then use the “what does this item need?” questions.
    • Consider whether it would be helpful to group, consolidate, or break down categories.
  • Check that queues are adequately represented and that you know where your commitment points belong.
  • Look to see where the dissatisfactions and frustrations discussed in Chapter 18 might originate.
  • Identify the kinds of knowledge discovery associated with each active state.
  • Seek to de-emphasize functional organization.
  • Present it to other people.

None of this should take long. Remember, sketchy!


Next up: 21. Discover classes of service. Previously: 19. Analyze demand and capability. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

 

June 19, 2015

Kanban from the Inside: 19. Analyze demand and capability

Filed under: Books,Kanban — Tags: , , — Mike @ 10:56 am

We’re two chapters into Part III and getting into the nitty-gritty of Kanban implementation using the STATIK model. This week’s excerpt comes from the chapter introduction.


The previous chapter was all about context and perceptions, mostly keeping implementation considerations off the table. This chapter is about gathering some specific qualitative and quantitative facts about the current process that will inform the design of kanban systems.

If you can do this collaboratively, you will further reinforce the work of the previous chapter. If that’s not practical, you will need to share and review what you find after you have done the legwork.

This analysis needs to generate both qualitative and quantitative understanding. Qualitatively:

  • Understanding the different types of work involved will help you to identify the different variations in workflow that need to be managed.
  • Understanding the different sources of work will help you to prepare for, shape, and manage demand as it arrives.
  • Understanding why the work is needed will help you to understand the types of risk involved so that they can be managed appropriately.

Quantitatively:

  • Understanding the quantity of work involved will help you choose a manageable granularity to visualize and control it.
  • Understanding the gap between actual process capability (measured in terms of delivery rates, lead times, predictability, etc.) and the expectations of customers and the wider organization will highlight what kinds of improvements are needed.
  • Quantitative analysis of work recently delivered, currently in progress, and waiting to be worked on may tell us where improvements are most likely to be found.

Next up: 20. Model Workflow. Previously: 18. Sources of dissatisfaction. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

June 13, 2015

Kanban from the Inside: 18. Sources of dissatisfaction

Filed under: Books,Kanban — Tags: , , — Mike @ 9:57 am

We’re at the start of Part III, which explains how to implement Kanban using the STATIK model.

Last November (two months after Kanban from the Inside was published, I posted here Understand motivation for change. Bear in mind as you read this week’s excerpt that any major revisions of the book will very likely involve a change of title to this chapter. Possibly one of emphasis too!


Any kind of deliberate change needs two key pieces of context:

  1. Its scope—some boundary around what we do now, within which the change will be focused—the “what” of the change
  2. Its objective—an expression of what we hope to achieve from the change, relative to how things currently are—the “why” of the change

In the beginning, it is unlikely that either of these will be known in any great detail. Don’t let that worry you unduly—it’s much better to start by exploring the problem space than to try to nail down solutions prematurely. And let’s be realistic about this: Scope and objectives are often determined more by what people feel is organizationally possible than by what is necessary. As change agents, we can find this very frustrating, but it’s okay: Let’s start with what’s possible; the impossible we can do later!

We start with sources of dissatisfaction because they lead very quickly to something much more positive: a set of things that people might want to achieve. Additionally, when we take the trouble to explore properly why these dissatisfactions are a problem to people, important issues like scope and sponsorship tend to become much clearer.

This is not the time for isolationism. You will need to talk to people! Be prepared to go out and meet them or to bring them in; make them part of the conversation.

Two Perspectives

Given even just a rough idea of scope, we can easily identify two quite different perspectives:

  1. The perspective of those working in the system—their first-hand understanding of the system itself, their impressions of how it is perceived externally
  2. The perspective of those outside of the system (customers, higher-level management, providers of related services)—how it helps to meet their broader needs (and what those might be), their impressions of how their immediate needs are serviced

Because we are getting people to look both inward and outward, it is no disaster if we later decide that we got the scope boundary wrong. Wherever we place that boundary, we learn a lot a by reconciling the two perspectives and accounting for any important differences. Opinions on the placement and nature of the boundary may be revealing, too.


Next up: 19. Analyze Demand and Capability. Previously: 17. Smaller Models. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

May 29, 2015

Kanban from the Inside: 16. The Kanban Method

Filed under: Books,Kanban — Tags: , , , , , — Mike @ 12:29 pm

Chapter 16 of my book Kanban from the Inside condenses into a single chapter the following:

  • Some historical context
  • The principles and practices of the Kanban Method
  • “Contextualized Kanban” — Personal Kanban, Portfolio Kanban, and Scrumban
  • So-called “enabling concepts” —values, agendas, the Kanban Lens, etc
  • Implementation guidance —an overview of STATIK, to be covered in part III (chapters 18-23)

This week’s excerpt comes from that “Contextualized Kanban” section.


Scrumban

Scrumban is a name coined by Corey Ladas, for what happens when what you do now is Scrum and you apply Kanban.

I stress again the cautions of Chapter 13: Kanban does not mean recklessly throwing out all of your Agile discipline; rather it’s a transformative process that takes time, thought, care, and collaboration.

This progression is typical:

  • Already practicing a degree of visualization, the team organizes work according to its “done-ness.” This extends beyond “code complete,” “demo-able,” or “potentially shippable” to cover acceptance, deployment, and customer validation states.
  • Increasingly, standup meetings are organized around the board.
  • Already limiting work-in-progress through the sprint mechanism, the team pays more attention to the amount of work started but not yet finished. As a result, they start to see work items getting completed sooner. Immediately or after seeing the board operating well, explicit WIP limits may be introduced.
  • With work items completed sooner and more visibly, greater attention is given to the later stages of the process. Impediments to continuous delivery start being addressed. The nature of the sprint begins to change as releases are planned independently (if they need much planning at all).
  • Having decoupled releases from sprint planning, the system now easily accommodates work of different types and speeds. The team pays attention to the cost of delay of individual items and to the mix of work overall. Mid-sprint changes become much easier to accommodate; classes of service may be offered.
  • The rhythm of sprint planning continues, but the meeting itself gets easier. Estimating the right amount of work for the sprint seems less important; it’s enough to ensure that there is sufficient work of high enough value and quality and that the riskiest items have been identified and broken down where necessary.
  • With the need for customer validation made more visible, new feedback loops begin to emerge.

Different attitudes toward the Scrum practices and roles will of course lead to different outcomes. It’s not unusual for teams to go through changes of the kind described here and for them still to identify themselves with Scrum. That’s completely fine with us—it’s “Kanban with,” not “Kanban versus.”

The team I’m currently [mid 2014] working with as its interim development manager is a long way down this path. The planning rhythm is still there and I’m in no hurry to see it disappear. The highlight of my working fortnight is the “Show and Tell” (the sprint review), a lively meeting in which the project team is outnumbered by customer representatives and outside observers (as a “digital exemplar,” one of a number of pioneering citizen-facing projects delivering services online for UK Government departments, we often receive visitors from other departments and public agencies interested in how we do things). Not only do we review progress and show what we’ve recently built, we often review pertinent videos of outside customers interacting with the live system or with prototypes. These are highly motivating—sometimes even moving—and the shared experience adds to its impact.


 

Next up: 18 Understand Sources of Dissatisfaction. Previously: 15. Economic approaches to flow. Start from the beginning: 1. Transparency.

January 3, 2015

Two years on

Filed under: Books,Kanban,Values,Work — Tags: , , , , — Mike @ 10:45 am

I deliberately delayed the usual end-of-year review to today, the 3rd of January. It’s the second anniversary of my post Introducing Kanban through its Values and I was curious to see how well it was holding up. It is after all the seed that grew into my personal highlight of 2014, the publication in September of my book Kanban from the Inside.

Although the margin isn’t huge, I am not at all surprised to find that this two year old post tops the list of most-read pages of 2014:

  1. Introducing Kanban through its values
  2. Kanban Values exercise released
  3. My book: Kanban from the Inside
  4. STATIK, Kanban’s hidden gem
  5. Announcing Featureban
  6. “How deep” rebooted: values-based depth assessment
  7. Kanban: values, understanding & purpose
  8. Pulling change through the system
  9. A process of knowledge discovery
  10. Understand motivation for change

#7 is representative of 2013 – a followup to #1 and part of a journey of rapid exploration. The 2014 posts represent the fruit of that earlier work, ideas and tools rounded out and made reusable through the writing of my book. I’m thrilled that others refer to STATIK without my prompting (I declared it a success in July). The values exercise and Featureban are popular on slideshare. Matt Phillip flew across to Europe to describe (among other things) his company’s use of the assessment tool (see his deck The Kanban Iceberg; the video of his London talk should be available soon).

What does 2015 hold? For the next three months at least, more delivery management work with Valtech on UK government digital projects. Some private training classes no doubt, and (fingers crossed) a new 1-day public class “Inside Kanban”, probably in partnership with our growing community of UK-based training providers. I have other irons in the fire, but beyond March I’m still open to offers, whether it’s consultancy, training, or interim management.

In the meantime we’re moving house. A second foster daughter joined our family last year, and a Georgian cottage built into a Derbyshire hillside no longer meets our accessibility requirements. The new house is a bungalow on the edge of Wingerworth – still Derbyshire, but flatter and much closer to motorway and intercity railway links. Can’t wait!

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

November 11, 2014

STATIK, Kanban’s Hidden Gem (my #lkce14 talk)

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

[Updated – see end of article]

The 2014 autumn conference season closes with Lean Kanban Central Europe 2014, one of my favourite events of the year. My talk expands on the STATIK part of last week’s keynote.

It starts with the underpants gnomes, who (like many) might implement Kanban thus:

  1. ???
  2. Put up a board
  3. ???
  4. Profit!

It finishes with purpose:

Know what you’re delivering, to whom, and why

For at least one audience member, the key slides are in the middle, slides 33-34. I described as “a little old fashioned” the idea that we deliver incrementally in order to get feedback. As per last week’s keynote, we need to be validating relentlessly right through the process; only then can we hope to anticipate customer needs. The change to “hypothesis driven development” isn’t just a change of jargon!

Statik, Kanban’s hidden gem from Mike Burrows

Update: This sketchnote captures slide 50 beautifully:

Sketchnote

I wish I could do that!

Older Posts »

Powered by WordPress