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

April 10, 2015

Kanban from the Inside: 9. Respect

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

The ninth in a roughly weekly series of short excerpts from my book, Kanban from the Inside. We’ve reached the penultimate chapter of Part I (Kanban through its values) and the last of the nine values.


Our ninth and final value is the third of our three leadership disciplines. What if all change could be conducted with understanding, agreement, and respect?

Respect underpins Kanban’s third Foundational Principle:

FP3: Initially, respect current processes, roles, responsibilities, and job titles.

It is sometimes suggested that this is redundant. Why would the humane, start with what you do now method need to state this principle explicitly?

I can think of at least three important reasons for its inclusion:

  1. It contains a pragmatic piece of change management advice: Don’t start your initiative by looking at roles.
  2. It points to an underlying philosophy: Find ways around obstacles to change.
  3. No other principle or practice expresses “respect for people” quite so directly.

Don’t Start with Roles

Changing the emphasis a little, let’s summarize some earlier advice:

  • Start with what you do, looking at how what you do meets (and fails to meet) the needs of people inside and outside the system.
  • Organize work; let people self-organize around it, allowing the system to change as a result.

A premature focus on roles would fatally undermine this process. If they need to be defined formally at all, roles can be aligned to process once it has been established—in context—that the process is sufficiently fit for purpose. Meanwhile, we’ll be making it very much easier for people to find that alignment for themselves. Why force the issue?


The Humane, Start with What You Do Now Method

Depicting Kanban as “the humane, start with what you do now method” highlights what I believe are two of the Kanban Method’s most differentiating features. They’re more differentiating than even the sticky notes and WIP limits, and that’s saying something!

Kanban is humane, not just because it has noble ideals, not just because it leads to better conditions for people, but because it is designed to be implemented in a way that is consistently respectful. Noble aims don’t justify unsafe organizational transformations. The goal of better conditions in the longer run doesn’t excuse riding roughshod over people in the interim. To my knowledge, few methods can claim Kanban’s internal integrity in its approach to implementation.

Also, there is something uniquely respectful in start with what you do now. It respects the journeys of all the people—past and present—who have brought the organization to where it is now. For all the good and the bad, it respects context, it celebrates survival, and it makes it easier to assume—however naively optimistic an assumption this might be—that people mostly did their best. I like that.


Next up: 10. Patterns and Agendas. Previously: 8. Agreement. Start from the beginning: 1. Transparency.

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 11, 2013

Hear me interviewed on SPaMCAST

I had the pleasure last month of being interviewed by SPamCAST’s Tom Cagley. It’s now up as SPaMCAST 224 – Mike Burrows, Kanban Values. I’ve never appeared in a podcast before and I’m very pleased with the result. Thank you Tom!

I reference these posts:

We touch on some more general aspects of leadership, on what it means to be a change agent, and on why some improvement efforts are ineffective. It may become apparent that the issues raised by “Potato, tomato” and “Agreement: it’s not about you” were on my mind at the time too.

London Lean Kanban Day deserves a link after I described it rather vaguely as being “in London, in March”. I’ll be doing a new version of “Kanban the Hard Way” that (naturally) features values. It’s not quite a values-centric talk – that’s in the works for LKNA13, more on that soon.

 

January 3, 2013

Introducing Kanban through its values

[German translation]

Introductions to the Kanban method tend to start with a description of the kanban card wall (a tool) and lead on to a description of its core practices. If you’re lucky, you’ll get to hear about Kanban’s foundational principles too.

Here, I’m attempting a different approach, one that gives equal weight both to the principles (which I believe should come first – they’re not called “foundational” for nothing) and the core practices by identifying the values that underpin them. In doing so we’ll cover most of the main elements of the method, so perhaps this works as a teaching framework too?

Regardless, the result is holistic (the values are widely applicable at multiple levels), remains true to Kanban’s purpose of driving evolutionary organisational change, and helps to address three misconceptions:

i.         that Kanban is somehow a software development process

ii.         that Kanban doesn’t have at its heart the kind of values that will both challenge an organization and guide its agents of change, and

iii.         that Kanban is only for number-crunching tool-heads in control-driven organisations (I exaggerate this last misconception only slightly)

Moreover, I hope to demonstrate also that a values-based description is useful for other, more constructive reasons.

My starting point

From Kanban’s Foundational Principles in their usual sequence I identify four values: understandingagreement,  respect and leadership. The first of these requires a little justification but the other three can be read directly into the principles as they are typically worded.

The values behind Kanban’s six Core Practices are a little trickier, not because the they aren’t there but because the correspondence isn’t exactly one-to-one. I chose another four (that’s eight so far): transparencybalance, flow and collaboration. However, I found it helpful to depart from the this obvious sequence and was compelled to add an additional one – customer focus – making nine in total.

As I expand on each of these we’ll uncover a few more candidates for inclusion – I’ll highlight in bold anything that looks like a value (abstract nouns, basically). These however are less important, less axiomatic, less “core”.

Nine core values of Kanban

1.    Understanding

Understanding is one of the less obvious values of Kanban. I read it into the first foundational principle,  “Start with what you do now”. Understand the thing you’re changing, whether it’s the nitty-gritty details of a process, the way a process performs under conditions of stress, or something as abstract as your organisation’s overall approach to change.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
The Process Myth, Rands in Repose

In our Kanban training we teach a Systems Thinking approach that places understanding very high on our list of priorities. It’s right there in our early introductions to the method, the basis of the very first class exercise. Where does work come from? What characterizes different kinds of work? What approaches to the problems of change and improvement tend to succeed or fail, both generally and in your organisation specifically? Why might that be?

By definition, the absence of understanding is what characterises cargo cult implementations. Even with good intentions there’s a likelihood that understanding will be lost when change is driven top-down, justified weakly (over-relying on appeals to best practice for example) and passed unthinkingly between organisational layers.  It’s no small surprise therefore that change projects have a tendency to disappoint. Unfortunately for the lazy or unskilled manager, understanding and its allied values of learning and alignment take effort.

2.    Agreement

Agreement is right there in the second foundational principle, “Agree to pursue incremental, evolutionary change”. I like to turn this around: would you reasonably expect to be successful in implementing change without it? Could it be that it’s lack of agreement that’s limiting your progress? Or perhaps there is some agreement but it’s not deep enough – you’re agreed on the existence of a problem but not on its impact or causes (see understanding)?

This principle might seem to suggest another value, that of incrementalism. I would however shy away from describing this this as a core value, for the reason that we promote incremental, evolutionary change because it has a high chance of success, not because its alternatives in radicalism or conservatism are never better alternatives. And if pragmatism is a value, it is a rather slippery one.

3.    Respect

Respect for people” is a pillar of Lean. Kanban applies this to the problem of organisational change in its third principle, “Initially, respect current roles, responsibilities & job titles”.

As in life, respect is a good guide when implementing change. Will it increase your chances of success if you start by implying that people are doing a bad job, or their roles are worthless? Probably not. Is it helpful to assume bad motives? Again, probably not. But does respect just mean “be nice”? Again no:

Showing respect for people does not mean you have to like them, agree with their views, and fail to challenge any half baked reasoning.
Stephen Parry

That kind of respect takes courage, taking us to our next value.

4.    Leadership

Leadership features in most stories of success but it was only in 2012 that it was added as a foundational principle, in the form “Encourage acts of leadership at all levels in your organization – from individual contributor to senior management”.

Much has been written on leadership and I won’t add to it here except to make a few quick observations:

i.         You might wish for an autocrat – a Steve Jobs (or a Steve Ballmer) perhaps – but the “at every level” kind of leadership is something different.

ii.         Not only is leadership something to value, management isn’t inherently something to despise either (remember respect?).

iii.         Furthermore, neither leadership nor management precludes self organisation, where individuals, teams and systems have the capacity to adapt without central or senior direction. Rather, good leadership and good management create the conditions in which self organisation thrives.

iv.         Good leadership involves challenge (we’ve used this word already). As agents of change we must be prepared both to challenge and to be challenged.

5.    Flow

Turning to the practices, we start with the third one, “Manage flow”.

The management part of this practice speaks of tactical organisation and decision-making aimed at progressing work for optimal outcomes (effectiveness). At some level – though with widely varying degrees of success – this is universal.

Flow adds something much less common, a sense of smoothness and predictability; addressing impediments to these systematically is a powerful improvement approach, exemplified in Lean.

We also value flow in Csikszentmihalyi’s sense, that very positive state of complete absorption in what we’re doing. This kind of flow is hard to find when distraction, interruption and constantly changing priorities dominate the work environment.

6.    Customer Focus

We haven’t finished with “Manage flow” yet! An expanded version of this practice might read something like

Manage to timely completion the smooth flow of customer-recognised value over a range of timescales

Value is meant in the sense of purpose (understanding the customer’s “why”) as much as in any monetary sense (taking care not to confuse utility with mere cost). A customer-focussed concern for completion means going beyond an activity-centric “task complete” or a product-centric “potentially shippable product”. In my experience, this is a surprisingly challenging concept whose impact can be dramatic.

Work done but not yet benefiting the customer is just sunk cost. We’ll return to this issue and address the “over a range of timescales” phrase when we look at the value of balance.

7.    Transparency

Transparency underpins three of Kanban’s core practices: the first, “Visualise [work]”, the fourth, “Make policies explicit”, and the fifth (another 2012 addition), “Implement feedback loops”.

Kanban creates transparency at multiple levels:

i.         In making work visible

ii.         In making visible the workflows that work items go through and the states that actual work items occupy at any given time

iii.         In making visible the parameters, policies and constraints that guide decision-making and ultimately drive the overall performance of the system

iv.         In making visible the impact of all the above in customer-focussed measures of performance

The first two types of visibility flow naturally from the kanban systems after which the Kanban method is named. The first three together create leverage points – points in our systems at which significant change can be effected for relatively little cost or effort. The fourth (a feedback loop) tells us that change is taking us in the right direction.

Kanban then is a way to evolve systems that learn and adapt, a strategy for organisations to find greater fitness relative to the competitive ecosystems they inhabit.

8.    Balance

The second core practice is “Limit work-in-progress (WIP)”. Limiting WIP across a process has multiple benefits:

  • Thanks to Little’s law, lead times (and therefore feedback cycles) tend to shorten; the customer is satisfied sooner and learning accelerates.
  • Work gets started only when capacity becomes available. This creates flow from the work item’s perspective and keeps supply and demand in balance from the team or worker’s perspective (respect!).
  • With just a little extra sophistication we can easily find balance between different kinds of operational work and between operational work and improvement work.

This last point suggests another principle, “Embrace variety”. Systems that behave well in the face of variety can be described as having a resilience that is good for customer, organization and worker alike, another example of balance. Kanban’s help in evolving resilient systems that can deliver predictability for a variety of work item types with a range of performance expectations (timescales perhaps ranging from hours or days to months or more) really is a killer feature.

For more on the role of balance in Kanban see David Anderson’s talk When is Kanban not appropriate [video] [slides]. My talk Kanban the hard way [video] [slides] includes an exploration of variety and resilience.

9.    Collaboration

Collaboration features in the sixth (and last) core practice, “Improve collaboratively, evolve experimentally [using models [and the scientific method]]”.

Building on agreement, respect and customer focus, collaboration creates the expectation that we will look beyond our own team’s boundaries in addressing impediments to flow.

The full version of this practice (with the two optional parts included) speaks of working systematically in a way that improves understanding through observation, model-building, experimentation and measurement (empiricism).

Using models” has a second sense that suggests values of curiosity and even generosity. Kanban actively encourages its practitioners to look outside the method to a growing body of knowledge. Kanban acknowledges roots in Lean, Theory of Constraints and Agile, foundations in queuing theory and complexity science, influences as diverse as Lean Startup and family therapy. Individual practitioners have their own personal favourite models – I for example draw on A3, GROW, and Influencer.

Why stop at nine?

It bothered me that the Lean value of customer focus can’t be inferred in any obvious way from the standard wordings of Kanban’s foundational principles and core practices – you could say that I had to cheat! I think though it fully deserves its place.

Less so these others that I’ve identified:

  • Learning and alignment have strong associations with understanding. I fully recognise that a strong case can be made for each of these but I’ve gone with the one that I think best reflects Kanban’s roots in System Thinking. My most-referenced article emphasises learning, so this was a tough one!
  • Challenge (also vision) and courage overlap sufficiently with leadership that I don’t regard them as axiomatic. See related post Dole out the 3C’s.
  • Self organisation would rank high as an organisational design value but respect seems to be an adequate guide for the change agent. All else being equal, respect would prefer a solution allowing or building on self organisation over one that doesn’t.
  • Resilience features strongly in my thinking but it describes outcome more than approach. Smoothness and predictability similarly.

Putting values to work

Let’s see our nine values together then:

Understanding, Agreement, Respect,
Leadership, Flow, Customer Focus,
Transparency, Balance, Collaboration

Admittedly, that’s quite a long list – longer than the initial three or four that I have quoted at every opportunity for some time – but not so long that we’re incapable of debating, remembering and referring to them.

Do any of these resonate with you more strongly than others?  What does that say to you?  I might explore that one at a leadership retreat – the differences between practitioners might be revealing!

Do any seem to be missing in your current environment? Again, what does that say to you? Does that suggest to you some things that really need to be put right?

For example, I can look back at times where lack of the right kind of agreement either slowed the pace of change or resulted in change that could revert too easily. From what I read, I don’t believe I’m unique in this.

Reflection

I’ve made values explicit – this is transparency at work – creating an opportunity for challenge (namely that I want to see customer focus feature more explicitly in the core method), and increasing my understanding of at least one source of ineffectiveness. In an eat-your-own-dog-food kind of way, the system works! I like that.

Whether you or the wider community would choose the same values is an interesting question worthy of group exploration. How else might you go about it? I’d love to see some alternative attempts. Could the values I’ve chosen benefit from some additional structure or from being sequenced differently? Or are values so fragile that they’re better left unsaid?

Continuing a line of thought started a couple of months ago in my post How Deep is “How is Your Kanban”, could values provide a better foundation for a second-generation Kanban assessment tool? Does the current tool’s emphasis on practices hide the method’s true purpose? I really think that it might.

As to whether this is a good way to introduce Kanban, this can only be answered by testing it. I intend to!

[Update: I’ve written some stronger conclusions in a followup post, Values, understanding & purpose]

May 31, 2012

More than mere tinkering

Not that I have ever needed much excuse to tinker, but LSSC12 has prompted me to make some significant updates to the materials for DJAA‘s 2-day class Successful Evolutionary Change with Kanban. And I don’t suppose it will be long before other providers follow suit.

Key changes, trailed by David at the conference after some testing on kanbandev:

  • Kanban’s foundational principles are gaining a fourth member on the subject of leadership, to be encouraged at every level from individual contributor upwards. I believe it fits very well – just as with the original three principles (which I like to summarise as “understanding, agreement, respect”), without leadership can you really expect success?
  • We are gaining an additional practice too (a 6th, to be inserted at #5): “Develop feedback mechanisms at workflow, inter-workflow and organizational levels”. A leaf out of Influencer‘s book, a good bit of Systems Thinking, and another reminder that Kanban is a method for driving organisational change, not a software development process, project management framework or process tool. Feedback mechanisms are a key part of what I’m already doing in the portfolio space and there’s no doubt in my mind that there is a lot of mileage in this practice.
  • References to “scientific method” have been replaced with “safe-to-fail experiments”, tying the improvement practices we already teach to the organisational understanding of Dave Snowden and other folks in the complexity community. Experiments were an important topic at LSSC12 and this change seems very timely.
  • There’s another acknowledgement of great thinking from outside the Kanban community in our adoption into our material of Michael Kennedy’s language concerning the “knowledge discovery process“. I love that we have found better words for what some of us already knew deeply but could explain only clumsily.

None of these changes are fundamental – rather they help to crystallise out some thinking that runs right through what we teach in our classes and bring to our consulting clients. That makes them easier to take away and to apply in imaginative ways, and that’s exciting.

My next public classes are in London (June 18th-19th) and Edinburgh (September 19th-20th) and you can register through our UK partners TeamProsource. And you might do yourself and your organisation a favour by sending your managers along to our 1-day event (June 11th). Not that managers (or for that matter non-techies) should feel the least bit excluded from our regular classes – some of the best designs of kanban systems I’ve seen in our classes have come from managers from outside of IT; they get it!

May 23, 2012

“Who moved my risk?” and one of Kanban’s killer features

Filed under: Kanban,lean,Portfolio — Tags: , , , , , , , , — Mike @ 8:20 pm

This is followup #3/n to my LSSC12 debrief.

I’ve put the slides for my scheduled LSSC12 talk “Who moved my risk?” up on slideshare.

Overview:

  1. There are risks inherent in each piece of work; some of these are unique and specific to that piece of work but there are some easily-recognised varieties of risks based on time and expectation. Time does funny things to priority – it has a habit of making a nonsense of any priority scheme that is fixed in time. And don’t think that risks based on expectations aren’t real risks!
  2. There are additional risks that relate to the (in)capability of the system (lead time and throughput performance/predictability especially) when faced with a volume of work. Capabilities differ between systems, but less capable systems can still offer high capability on limited subsets of work, those subsets perhaps based on the varieties of part 1 above. It is a “killer feature” of Kanban that we can easily make variety explicit so that good risk-based judgements can be made within teams on a day-to-day basis. Furthermore, it is relatively straightforward to design resilient kanban systems that consistently deliver good results in the face of variety, something that many systems deal with rather poorly.
  3. Don’t get so focussed on the system that you can’t step outside of it to see what’s really possible. Avoid “backlog driven development” (I’m sure you can work out what this means) – quite apart from its grim economics, you need to be spending time with different kinds of stakeholders concentrating on working out what’s important – using imagination, thinking the unthinkable (good and bad), filtering out the noise, creating good possibilities and heading off the bad ones. To put it another way, backlog grooming (on steroids or otherwise) is no path to success. But there’s good news: limit your WIP, shrink your backlogs and work on growing shared understanding outside your system and your risk will seem very different. Who moved your risk? You did!

Watch out for the “triple” win of improvements that are good for the customer (effective), good for the organisation (economic), and good for the team (humane). To my mind, “effective, economic, humane” in my estimation beats “better, faster, cheaper”; less catchy perhaps, but where’s the humanity in the more traditional test?

How did it go?  That’s quite a lot for a 45 minute slot and I should probably have pruned it more. Also, I made a tactical error in thinking that we could do an interactive exercise before we had all warmed up.  Lessons learned.  Despite those improvement areas the feedback was pretty good and sufficient people were kind enough to tell me of the useful thoughts they took away that I’m happy enough with how it went.

I’ll write up my unscheduled talk on portfolio level problems soon.

May 20, 2012

Portfolio stuff (sic) at LSSC12

This is followup #2/n to my LSSC12 debrief.

As I mentioned in my debrief, I organised an evening meeting on portfolio “stuff” to take place after the speakers’ reception. What kind of an idiot arranges a meeting for 20:45, after drinks, and with a deliberately vague title?  23 people showed up at that late hour, demonstrating a significant level of interest. If you’re one of those 23, thank you!

“Portfolio stuff” became “Portfolio-level problems” in my bonus talk the next day (my slot was extended due to the next speaker dropping out).  I’ll write up my talk more fully in the coming days, but what both titles indicate is a desire to spend some time identifying the problem rather than to announce that we have cracked how to do portfolio management.  To describe the problem (if there is indeed only one) in the terms of the presence or absence of a particular kind of solution is a kind of sloppy thinking I wish to avoid.

I must make plain that I take seriously the evolutionary approach of Kanban and its principles of “start with what you do now”, “respect current roles and responsibilities” etc. I use “understanding, respect, agreement, leadership” as a way of bringing together both these principles and some of the Systems Thinking approaches that we teach in our classes.

So lets start with a little understanding.  What does the problem space look like?

Limiting myself to the past 4 years, my direct experience ranges from leading a team of 15 (the whole of IT in that small company), responsibility for a team of 70 within a big name global enterprise, and looking at the work of an IT organisation of hundreds within one division of a major enterprise.  That’s quite a spread.

My Monday night group reported projects (if that’s the right word) ranging in duration from days to months. I’ve seen worse, ie years passing before anything gets delivered.  Orders of magnitude differences.

We defined “portfolio level problem” as problems seen, managed or originated (ouch!) above the organisational level of teams of individual contributors.

These include:

  • The challenge of translating the objectives of the organisation into actual work
  • The reverse of that challenge, seeing how actual work on the ground corresponds to organisational needs
  • Managing flow day-to-day, ensuring that important work has the help it needs to progress to completion
  • Managing and improving flow system-wide

Steering clear of:

  • Allocating individual people to their work (it distresses me that some writers seem to think that this is even a problem, let alone a solution).
  • Push, meaning any approach that seems to value starting over finishing. Includes any system with stage gates or focussed on backlog grooming that lacks strong mechanisms to balance supply and demand further down the pipeline.  It is not enough to limit what you start.

It’s a very interesting and wide-ranging problem space. “Portfolio management” might be the right name for it but I’d love to have a better one that didn’t carry the baggage of failing approaches.  “Portfolio Kanban” works well if it implies the method and thinking, less well if it means only stickies on whiteboards.  Perhaps we need to do some work to reclaim the phrase.

Upcoming posts will explore the applicability of the Kanban method and offer some techniques for use in this space.  Stay tuned. Meanwhile, a reminder to use hashtag #ppm for related posts to kanbandev.

June 14, 2011

On remote coaching

Filed under: Kanban,lean,Work — Tags: , , , , , , — Mike @ 1:04 pm

This week I did my first Skype-based coaching session (my first at least as consultant rather than manager) and I’m pleased to report that it was a satisfying experience all round. An away-from-the-Kanban-board discussion avoids getting sucked into day-to-day minutiae; instead it’s an opportunity to step back, review and plan. It has a lot in common with the Agile retrospective, but a good model is A3: we need to get behind the annoyances and what may be over-personalised issues and work hard on finding the words to express root causes and potential ways forward in ways that lead to positive change.

Away from the board we can think bigger too. How can we work better with teams upstream and downstream? Are we involving the right people promptly and effectively enough? Can we help bring about higher level change that would have greater and longer-lasting impact on projects beyond our own?

Of course it helps immensely that I already know the client well, having working relationships and collaborative partnerships that go back several months, spending weeks on site (abroad) getting to know both the issues and the people. From the client’s perspective, it’s a cost-effective way to ensure that progress is reviewed regularly and that appropriate interventions are made before we get to the point where more hands-on support is again warranted (which will happen!). From my perspective, it creates the capacity to support multiple clients at once. Mutually, we learn from each other’s experiences and manage the peaks and troughs in demand. How very Lean!

April 29, 2011

Lines not boxes

Richard Veryard’s recent post on Emergent Architecture reminds me of the architectural meme “lines not boxes”. It’s a powerful approach that I followed explicitly in much of my time in enterprise architecture and web-centric development (“trust in open protocols and formats rather than closed technologies”) and I believe that it has value as a metaphor for process and organisational design too.

People aren’t boxes

Traditionally, we organise people by assigning them roles defined in terms of skills and tasks. Whilst some people seem to need the certainty that goes with this, it’s a practice I have actively resisted, whether as team member or manager. Putting people into boxes constrains opportunity, responsibility and creativity.

It seems to me more humane and more supportive of learning and growth if instead we make visible what needs to be done, define what good results looks like, maintain the minimum set of policies needed to ensure reliability, then create the space in which people can perform. And it can work for whole teams, where responsibility and creativity become manifested in self-organisation.

“Done” is only the start

Where there are different teams supporting different parts of a process, an over-emphasis on “what done looks like” has the effect of holding work back even when unfinished work could have considerable value downstream. In our “lines not boxes” metaphor, this is like defining the interchange formats to be used between systems but neglecting the communications protocols that carry them. An extreme example is the stage-gated waterfall approach to projects, where documents need not only to be completed but also reviewed and signed off before they may be acted upon in later project phases.

Under time pressure and faced with document-centric hurdles, smart teams learn to reach out and collaborate outside of the formal process. Smart organisations encourage this – making collaborative problem solving part of the process, building on successes rather than merely defending uneconomically against every eventuality (not to mention protecting every rear end). Once this is allowed to happen, it is my experience that artefacts start to get delivered in negotiated chunks and lead times take a significant turn for the better.

This is good news indeed: organisations build structures and introduce process overheads as they grow and rarely do they encourage flow. It is a relief to discover that bottom-up, flow-based approaches such as Kanban can prove effective even in the face of functional silos, not only helping teams to work more effectively within their functions but highlighting where a small investment in collaboration between silos will reap big dividends.

Older Posts »

Powered by WordPress