Why Agile needs some 21st century Lean thinking

Posted on March 21, 2017September 3, 2017 by Mike Burrows

At least as far as the textbooks go, 21st century Lean is quite a different beast to its 20th century forebear. The best of the more modern Lean literature is now explicit in its recognition that you can’t just take the Lean tools out of one context, drop them into another, and expect the same results. Just because it works for Toyota, doesn’t mean it will work for you. Just because it works in a car factory… I hardly need to complete that sentence!

Not unmodified, that’s for sure. The kind of Kanban I described in Kanban from the Inside that works so well for people engaged in creative knowledge work is almost unrecognisable from the canonical kanban systems of the automotive factory. Many of the underlying principles are the same – for example visual management, controls on work-in-progress, the quest for flow – but their physical or electronic realisations are very different. In one, cards move left to right (downstream) on a kanban board to reflect the progress of work; in the other, cards are sent upstream when some downstream activity wishes to signal a need for some just-in-time replenishment.

But that’s just technical detail. The best of the 21st century Lean authors have been humble enough to make an even more important admission: even within the manufacturing domain you can’t (as the 20th century writers tried to suggest) transplant the tools whilst ignoring the management systems that guide, support, and sustain them, and still expect good results. An important case in point is continuous improvement (or kaizen, if you prefer). Don’t get me wrong: continuous improvement will always be a good idea. Unfortunately though, it is rarely sustained for long through goodwill alone. Asking your workforce for continuous improvement as a low-commitment way to achieve real transformation will almost certainly result in disappointment, even harm.

We in the Agile community know all this of course – how often do we see retrospectives fall into a state of neglect once the easy changes have been made? Unfortunately, we make it harder for ourselves, and by design! As an end-of-century reaction to 20th century top-down and plan-driven management styles wholly unsuited to the challenges of rapid product development in uncertain environments, Agile rightly sought to wrest control back to the teams doing the work. The unfortunate side-effect: blindness to the power of the kind of internal structures that create regular opportunities for mutual reflection, support, and accountability well beyond the team. How is the Agile team supposed to help the organisation become more Agile when it is determined to live inside its own protected bubble? This is how inspect-and-adapt (Agile’s continuous improvement) runs out of steam. Even at team level it’s hard enough to sustain; expecting it to drive broader change without support is, well, optimistic.

I’m not looking to throw the baby out with the bathwater. I’m not suggesting any backsliding on Agile values. I’m not making the case for 20th century top-down management (in fact quite the opposite). I’m asking that we look beyond the delivery-centric processes and tool (most especially beyond the determinedly team-centric ones) and start to think about what that cross-boundary support and accountability could look like.

In particular:

What will drive Agile teams and their host organisations to help each other to serve their customers’ and each other’s needs more effectively?
Where are the joint forums for reflection?
What mechanisms will provide support and ensure follow-through, even when the necessary changes become more challenging on both sides?
Where are the opportunities for people to engage seriously in the development and pursuit of organisational goals?
What skills will be needed to make these things happen?

Outside the Agile mainstream, Kanban and Lean Startup have opinions (if not explicit guidance) on many of these questions. Helping people pay attention to concerns such as these is one Agendashift’s main motivations. Much of Agile however still seems to ignore them, sometimes recognising the need for end-to-end thinking but still wary of “at every level” thinking.

The good news is that these concerns are largely orthogonal to delivery. Agile delivery frameworks probably don’t need to be any bigger than they are today (let’s hope so). Some awareness of organisational context and its journey will be necessary though, and it may mean leaving aside the rhetoric of past battles. Welcome to the 21st century!

Why “continuous transformation”?

Posted on March 3, 2017September 3, 2017 by Mike Burrows

If you were wondering about the last couple of words of the new book’s title Agendashift: clean conversations, coherent collaboration, continuous transformation, here’s your explanation.

This picture sums up the challenge:

screenshot-2017-03-03-11-05-53

The good:

Yes, continuous improvement (in its many forms) is respectful – respectful (generally speaking) of people, respectful of current state, respectful of how you got there.
Yes, transformation initiatives do generally have a sense of ambition. Goals, rationale, sponsorship, and so on.

And the questionable:

Continuous improvement may be guided by some sense of direction, but often that’s more about the comfort of those inside the system than it is about purpose. The lack of meaningful goals means that few are motivated to overcome serious organisational challenges.
Too often, transformation initiatives are about imposing someone else’s vision on the people who know how things actually work. Too much is invested in overcoming resistance to change, not enough in engaging people in an open process.
If the organisational design doesn’t support it, continuous improvement quickly runs out of steam. Almost by definition – and certainly by the textbook definition of project – most initiatives are set up to exist for only a limited time. Either way, sustainability is an ever-present challenge.

What if we could combine the best of both – respect and appropriate ambition – and at the same time confront the sustainability problem? This is what I am looking for in continuous transformation. I would define this as transformation that is:

Respectful of present and past, the current context and the open-ended journey
Appropriately ambitious for the future – – not grandiose, but with goals more ambitious than typically implied by continuous improvement, inspect and adapt, and the like
Not just reactive, but proactive and anticipatory
Happening all the time because – by design and by habit – the organisation’s core systems now demand and sustain it

If that sounds attractive, you’ve come to the right place. Grab your preview chapter. Join our Slack community and LinkedIn group. Check out our partner programme. And come to the next Agendashift facilitator day, in Manchester on March 23rd.

Agendashift as Good Strategy

Posted on February 9, 2017September 3, 2017 by Mike Burrows

[This is the third and last of a three-part series. Start from the beginning: Lean-Agile transformation as Lean-Agile process]

This post has been a while in coming. If you’ve been waiting, apologies! I’m going to cheat a little: what follows is lifted directly from the end of the just-written third chapter (Mapping) of the forthcoming book [Update – it’s now out: Agendashift, clean conversations, coherent collaboration, continuous transformation].

Is it Good Strategy?

To finish this chapter, the promised third reconciliation. This time a very quick reconciliation of your transformation map with Rumelt’s strategy kernel. This model comes from another brilliant book:

Good Strategy/Bad Strategy: The difference and why it matters
Richard Rumelt (Profile Books, 2011)

Three questions (Rumelt’s model, my words):

Diagnosis: Is your strategy rooted in an understanding of the challenges you face and the opportunities available?
Guiding policy: What gives shape to your strategy?
Coherent actions: Are your planned actions coherent with each other, your guiding policy, and your diagnosis?

By virtue of your transformation map’s construction you should be able to give positive answers to questions 1 and 2, and a partial answer to question 3:

Diagnosis? Witness the obstacles and their respective outcomes from Discovery, Exploration, and Mapping (chapters 1-3) together with the survey analysis that informed Exploration (chapter 2).
Guiding policy? Your strategy was given shape first by the values and prompts of the assessment (chapter 2), and then by the transformation journey steps of this chapter.
Coherent actions? You have identified detailed outcomes that you have reconciled with your broader goals. Moreover, most (if not all) those outcomes align with one or more of the values of the survey, and those values are themselves coherent.

We could add to point 3 that our overall approach to the transformation process is highly coherent with our Lean-Agile sensibilities. Hardly a minor point!

So we’re good then? Not so fast. A solid basis for a good strategy certainly, but a further level of detail is still required. We’ve said what we want to have happen, not the concrete steps we will take and what impact we think they will make. Cue chapter 4, Elaboration.

This was the third of three related posts:

See also Karl Scotland’s post Good Agile/Bad Agile: The difference and why it matters.

Agendashift as coaching framework

Posted on January 27, 2017September 3, 2017 by Mike Burrows

[This is the second of a three-part series. Start from the beginning: Lean-Agile transformation as Lean-Agile process]

What with last week’s London workshop (sold out!) and work on the new book I’ve got a bit behind my usual blogging schedule. Sorry about that! Every cloud though – here’s Agendashift partner Andrea Chiou debriefing (in Slack) her appearance this week at the Agile NOVA meetup in Washington, DC:

I said, using this style of interview, you can get managers in a room learning about each other’s vision for their most pressing problems, and in doing so you can then see where there is energy, as well as where there are solutions already inherently existing within the org

And:

This differs from almost every other Agile transformation approach I know, except one (I mentioned Open Space Agility). And the reason it works is because it is values-based, and based on mutual exploration and dialogue with managers/sponsors.

I might add here that Agendashift is also about exploration and agreement with participants (not just managers and sponsors), but Andrea does a great job of explaining how Agendashift helps facilitate those early conversations.

Especially in the guise of the Agendashift facilitator day, you can view the Agendashift workshop as a demonstration of three things:

The power of a values-based and outcome-centric approach
How the different techniques we use integrate so pleasingly
An end-to-end transformation process that mirrors (and even exemplifies) a Lean-Agile delivery process.

Part 1 in this series expanded on point 3. Today, we’ll again review the five sections of the workshop, this time as a possible structure for a coaching engagement:

Discovery: Identifying the strategic goals and needs that any coaching must support, setting the right tone in terms of ambition without losing sight of where the real challenges and opportunities lie
Exploration: With or without the aid of the Agendashift assessment, exploring key areas of opportunity in more detail, identifying obstacles, and from those generating a set of outcomes that represent the scope, objectives, and priorities of the engagement
Mapping: Understanding the challenge in enough breadth to be sure of not missing anything important, and keeping the coaching process fed with fresh and important challenges to investigate
Elaboration: Generating, framing, and develop actions
Operation: Ensuring follow-through, maintaining appropriate transparency, accountability, and feedback in the relationship

Just as we discussed in the previous post, this isn’t a completely linear process, in fact much of this needs to happen on a frequent or ongoing basis. There are however some key conversations that do need to be had, and the earlier in the process, the better. A coaching engagement that stands on a platform of agreed needs, scope, and level of ambition is surely healthier than one based on the offer of technical help or of facilitating a process whose goals no-one is able to articulate.

The tools we use and demonstrate through workshops will be used more informally and naturalistically in a coaching context, but they’re still valuable. All the more so, some of them! What coach wouldn’t want to be able to ‘flip’ obstacles into outcomes, identify the drivers behind pet solutions (and thereby open up the possibility of alternative solutions), or turn the vague into something actionable? These are very teachable skills. So too are the highly reusable skills of framing hypotheses and developing actions. Many coaches will find what Agendashift says about organisational design interesting too.

Coming up in the next few weeks are opportunities to experience this for yourself, with events in Hamburg (Feb 9th & 10th), Manchester (March 23rd), Edinburgh (April 6th), and Oslo (April 21st). Don’t see one near you? Get in touch and we’ll see what we can arrange together.

This was the second of three related posts (posts 3 coming soon):

Lean-Agile transformation as Lean-Agile process

Posted on January 5, 2017September 3, 2017 by Mike Burrows

[Update: Section/chapter 2 previously named Analysis is now Exploration. Thanks to Mike Leber for the suggestion made at last week’s Agendashift facilitator day in London. 1. Discovery, 2. Exploration, 3. Mapping – that’s a nice progression! Some edits made to reflect this change.]

Did I mention that I’m writing another book? Writing begins in earnest next week, and the wait is killing me! Nearly three years after Kanban from the Inside, I again feel the compulsion. I have to do this!

The new book’s first five chapters mirror the five main sections of the Agendashift transformation mapping workshop:

Discovery: Identifying strategic objectives, obstacles, outcomes, and change strategies
Exploration: Debriefing your Agendashift values-based delivery assessment, prioritising opportunities, and agreeing scope
Mapping: Building a transformation plan
Elaboration: Generating, framing, and developing actions
Operation: Organising for continuous transformation

If you’re anything like me, you might thinking “Plenty of plausible-sounding words there, but what makes the process Lean, Agile, or Lean-Agile?” It’s a fair question – there are enough linear, top down, cookie-cutter, imposed, consultant-knows-best, and resistance-trumping models out there and we surely don’t need another one! Can we instead demonstrate collaboration, iteration, flow, pull, feedback and the rest?

There’s an old Lean trick that I’ll be employing in chapter 5: review the process backwards, from finish to start, from life at the operational sharp end and back to the fuzzy front end. Here’s a preview, and it describes a process for organisational transformation that with just a few substitutions could easily describe a Lean-Agile process in the product or service space.

5. Operation

We meet frequently to review progress on the changes we have in progress and to share what insights we’ve gathered along the way. We’re validating the impact of our most advanced experiments to help us decide whether or not to adopt them formally. Some of our other experiments haven’t reached that stage yet – we’re still testing changes for their usability (there’s no point in endorsing changes that won’t stick). Still further upstream we keep a small backlog of prioritised and well-understood changes to work on as soon as capacity permits.

4. Elaboration

We’re careful not specify changes until we’re close to needing that level of detail – this isn’t big design up front (BDUF) but a just-in-time (JIT) process. Leaving it until the last responsible moment gives us the opportunity to incorporate feedback from previous experiments (successful changes or otherwise) and to take into account recent environmental changes outside our sphere of control.

Where appropriate (which is much of the time) we use the language of Lean Startup and A3 to frame and develop our actions. We take the outcomes that are the main units of currency of the transformation map and from them form hypotheses, identify who should to be involved in the change (to a significant extent we’re our own customers here, but therein lies a trap), design pilot experiments to test our assumptions, and so on.

3. Mapping

There’s much still be achieved, and it’s important to keep our ideas organised. Call it a planning tool if you like, we use a transformation map, highly analogous to a story map, except that the elements being organised aren’t features, user stories or job stories, but the outcomes we’d like to achieve through our transformation.

[Aside: The analogy is strong – the ‘so that…‘ elements of user stories and job stories are outcomes too of course.]

The categories under which outcomes are organised may describe the stages in a transformation journey or simply identify high level themes; sometimes one evolves into the other. This organisation comes under periodic review as we step back from the day-to-day and reflect on our overall progress.

We prioritise within categories before looking across categories and deciding on what we will work on next. In setting priorities overall, we may choose to give special emphasis to a particular category for a while, or decide instead that it’s better to choose a minimal set of complementary changes from across the board.

2. Exploration

Exploration keeps the transformation map both based in reality and connected with the vision, the output from Discovery. What do we know? What can we find out? What seems to be important? Who should we talk to? Where are the most promising opportunities? What’s our scope?

With Agendashift, exploration is a generative process. Informed by the results from the assessment tool, we collaborate on identifying opportunities and their respective obstacles, then ‘flipping’ those obstacles into the outcomes that will become either the work items or the organising themes on our transformation map.

We do enough of this up front to prime the pump and to get a good sense of what it is we’re really dealing with. We revisit it periodically; as our transformation progresses, so too does our understanding of what’s urgent, what’s possible, and where we think we’re headed.

1. Discovery

What would it be like if everyone were able to work at their best, individually, within teams, and across teams? What if we could have the right conversations between the right people always happening at just the right time? What if everyone always got what what we needed at just the right time too?

Why don’t we have that now? What obstacles lie in the way of achieving that? Can we go from all of that to a set of goals? What kinds of delivery approaches will be appropriate for the kinds of outcomes we seek? Who do we need to engage in the process?

This was the first of three related posts (post 3 coming soon):

If you’re a Lean-Agile practitioner and can see yourself using these tools, check out our partner programme. If you’re a sponsor of change and think this might work for you, check out our partner directory. In either case, check out our events calendar for a public workshop near you. If you don’t see one or you’d like one internally, get in touch.

The “obvious” question

Posted on December 13, 2016September 3, 2017 by Mike Burrows

First things first: the rename mooted in last week’s post has already been implemented. What was the “Agendashift debrief/action workshop” is now the Agendashift transformation mapping workshop. The same content in a more digestible order, with some additional and already-implemented improvements to be announced in the new year.

Anyway…

Remember this picture? It’s an example of the output from a Cynefin four points contextualisation exercise, taken from a training day earlier this year:

There’s a slightly tongue-in-cheek question I like to ask when debriefing this exercise:

What’s the obvious question to ask about the items in the the Obvious corner?

The answer I’m looking for:

Why haven’t they been done already?

After the teasing comes a serious point that has become a recurring theme for my workshops: Too many organisations are full of smart people who can tell you what’s wrong and can give you a long list of sure-fire fixes, but nothing changes.

You might say that these organisations are uninterested in improvement, but I believe that in many cases it would be more constructive to say that they are incapable of following through. There is little to no visibility or accountability around anything change-related; the feedback loops (whether formal or informal) that do exist are likely to be overwhelmed with urgent delivery-related issues, with no provision for understanding and tracking improvements the systems that allow those issues to arise in the first place.

If that’s true for the Obvious corner, how will they fare in the Complex corner? If they can’t track obvious changes, how will they manage the kind of change that involves experiments – even experiments-within-experiments (pilot experiments) – and all the uncertainty that goes with that? Not well.

Conclusion? If change isn’t happening, don’t blame your staff. Instead:

Make sure that improvement work is treated as ‘real work’, prioritised, tracked, and rewarded as such
Keep it visible to any managers and other stakeholders whose commitment will be required in order for the more difficult changes to be realised
Provide safety, treating success and failure as near equals. Better to keep learning than never to dare anything difficult

Let me leave you with the relevant prompt from the Agendashift values-based delivery assessment:

We ensure that opportunities for improvement are recognised and systematically followed through

How well does that describe your organisation?

The transformation map

Posted on December 6, 2016September 3, 2017 by Mike Burrows

Fantastic @agendashift workshop with @asplake today. I’d recommend to anyone responsible for organisational change. #lean #agile

— macs (@MacsDickinson) December 5, 2016

Big day yesterday – it was the occasion of the very first Agendashift facilitator day, the first of many I hope! Here, in all its glory is the transformation map we produced:

transformation_map_leeds_2016_12_05

For the name transformation map we have workshop participant Tony Richards to thank. One of those things that seems obvious in retrospect (but still all credit to Tony), it’s a particular kind of story map (I described it as such), one whose ‘spine’ is a transformation journey.

The detail is driven from the 40+ prompts of the Agendashift values-based delivery assessment. Category by category (value by value or journey step by journey step) we:

Prioritise prompts that represent areas of opportunity
Identify obstacles that prevent the full realisation of the future reality described by the prompt
“Flip” those obstacles into objectives (Clean Language provides some fun ways to do this)
(Optional) Generate actions for those objectives

To set the right context for the transformation mapping process we explore existing strategic objectives and assess the current situation. This process builds agreement, creates opportunities for alignment, and ensures that the resulting transformation strategy is coherent not just by construction, but in context also.

Other learnings

Learnings for me, that is!

Between the outer wrapping of that strategic exploration and the meat of the transformation mapping exercise, most of my workshops have up until now included a series of exercises around hypothesis-driven change (HDC). Here, we take a small number of high priority outcomes, generate actions for them, and then choose just one action to reframe (Lean Startup-style) and develop (A3 style). Yesterday, the transition from this deep dive to the breadth of the mapping exercise felt difficult for some participants.

I’ve not noticed this difficulty in client workshops, but it could be that the facilitator day’s lack of a shared organisational context amplifies a problem of which I was previously unaware. Anyway, I take it seriously.

Long story short, in the next iteration of this workshop, the HDC exercises will be postponed until after the transformation mapping activity. Transformation mapping is now very much the core part of the day, to the extent that I’m very much inclined to rename the workshop as a whole after it!

This change has further significance: deferring the generation of actions makes outcomes the main unit of currency for most the day. It is often natural to use outcomes and actions somewhat interchangeably, but nevertheless I’m sure that this development is healthy, perhaps bringing our consciously non-prescriptive approach into sharper focus. Remember: inclusive • contextual • fulfilling • open!

Keep an eye on our events calendar for more of these public workshops; feel free to ask that we hold one near you (perhaps you can help us make it happen). And if you’d like me or a friendly neighbourhood Agendashift partner to assist you in building your own organisation’s transformation map, don’t hesitate to get in touch.

A blocker waiting to happen (and it works both ways)

Posted on November 17, 2016September 3, 2017 by Mike Burrows

Dependency: A blocker waiting to happen

That’s a rather informal definition and it’s not strictly accurate (some blockers are unrelated to dependencies), but it will do! Certainly it’s more helpful than Wikipedia’s:

[A] dependency is a link amongst a project’s terminal elements.^{[citation needed]}

In our consciously inclusive and non-prescriptive way, the full version of the Agendashift values-based delivery assessment implies two kinds of dependencies:

1.5 We identify dependencies between work items in good time and sequence them accordingly
1.6 We identify and manage dependencies on external teams or services

The first of those is usually straightforward to deal with: we take care not to start a work item (some kind of deliverable – a feature, say) until we know that its dependent work items (other features or required infrastructure) will be in place. In the simplest case, we just sequence work items into some natural order and deliver them one by one. We must be a little more careful if we want to take advantage of our capacity to work on items in parallel, but still the advice mostly boils down to the mantra “Don’t start what you can’t finish”.

That mantra applies to the second kind of dependency also. Here, we know (or really should know) that we can’t finish a work item without some external contribution. Even the best cross-functional team will find itself dependent on others from time to time! Under these circumstances, if our work is to flow smoothly we must be take active steps to ensure that things will come together at the right time.

That in turn means being in the habit of identifying our dependencies in good time, keeping them visible so that no-one makes the mistake of starting work prematurely, and engaging appropriately with the people on whom our work’s completion depends.

2015-02-25-08-01-42 — A Story Map with external dependencies: note the red flags bottom right

Just-in-time: It works both ways

Most people will read “appropriately” as “early enough” – early enough to ensure that our work won’t be delayed. This is a slightly selfish view however, and it’s worth looking at this from the perspective of the team on who we depend. From their side, a piece of work that is started too early is a piece of work that can’t be integrated, tested, deployed, validated, and so on. Ugh! This is the kind of work-in-progress (or inventory) that the organisation as a whole really doesn’t want. If we’re really serious about flow in the presence of dependencies, the Lean idea of just-in-time (JIT) implies some two way commitment!

This is one reason why the concept of service is so helpful. Whether customer-facing or internal, an effective service combines two things:

A strong sense of what we’re delivering, to whom, and why
The ability to manage expectations around performance

A service-oriented organisation has both of these firmly established on both sides of all its dependencies, achieved through mainly bilateral coordination, not overly reliant on organisation-wide synchronisation. A very good thing to strive towards.

Do you find yourself continually struggling with dependencies or (the flip side of the same coin) excess organisational inventory? It’s a solvable problem. Get help!

What does the coin represent?

Posted on March 31, 2016July 16, 2022 by Mike Burrows

We’re about to play Featureban and we’ve reached the coin slide.

coin-toss — Redwood Photography, via Flickr CC BY-ND 2.0

“Everybody needs a coin – have you got one (or access to one)?”

Inevitably, some borrowing and lending ensues. “An exercise in trust, this bit!”

“Can you think what the what your coins might represent?”

Chance, you say? Decisions?

Those are both good answers, but not precisely the one I was looking for. Apologies for using a piece of jargon (we really do try to keep that to an absolute minimum), but the coin is a source of what we call ‘variation’.

I’m sure that nothing like this never happens in your company, but let me tell you about an effect I’ve noticed elsewhere. Sometimes, a 1-day piece of work becomes a 2-day, 3-day, even 8-day piece of work. Something we thought would take a day, takes eight! Shocking, isn’t it! But you never see it here, right?

Joking aside, it should not be surprising that in our line of work we see plenty of variation. How often do we start a piece of work with just a sticky note or email’s worth of information? Does anyone really know at this stage what’s involved? Of course not. And even after we dig into it, there are always new things to discover (it’s not called ‘knowledge work’ for nothing), dependencies to manage, people changing their minds (for good reasons as well as bad), bugs, absences (planned and unplanned), and so on.

Would it not make sense then to manage our work using systems that comfortably deal with variation – embrace it even – as opposed to pretending that it doesn’t exist or unfairly blaming people when it manifests itself? That’s what we’re going to experience in our game.

Some of you will get frustrated by this variation. Use that feeling! We’ll learn how to go about doing something about it too.

Footnote

In all fairness to Mr Deming (see On not teaching PDCA for why I have some making up to do), variation is a word forever associated with the great man. “Understanding variation” is part 2 of his 4-part System of Profound Knowledge.

What if we put agreement on outcomes ahead of solutions?