It’s here! Agendashift (part I) is published!

Posted on May 11, 2017September 3, 2017 by Mike Burrows

Part I of Agendashift: clean conversations, coherent collaboration, continuous transformation is available now on Leanpub in MOBI (Kindle), EPUB (iBooks, Google Books, and other e-readers), and PDF formats, also via Leanpub’s online reader. Buy it today and you’ll still have time to recommend it to your colleagues for the weekend 🙂

If you plan to read it on your iPad or iPhone, note that we have encountered a couple of formatting bugs specific to Kindle on the iOS platform and I’d recommend downloading the EPUB format and reading it in iBooks.

In celebration, we’re offering a discount on Lean-Agile Strategy Days, London (June 7th & 8th). For the next week, you can use the code BOOKLAUNCH for a discount of 10%. It just goes to show that launch codes can sometimes be used for good…

What next?

In the next week or two I’ll be sharing plans for Part II and some thoughts about next steps for Agendashift more broadly. To stay tuned, join our LinkedIn group and/or Slack community. Meanwhile, enjoy part 1!

The Agendashift book (part I) goes to press on the 11th

Posted on May 4, 2017September 3, 2017 by Mike Burrows

When I say “press”, I mean that it will be available for purchase and download in multiple formats from leanpub.com/agendashift.

The teaser:

How do you bring about continuous transformation, and how do you do it without resorting to the questionable top-down and bottom-up approaches of the 20^th century? Agendashift describes an inclusive, values-based, and methodology-neutral approach fit for the 21^st century, based on genuine participation and integrating the best of modern techniques.

And the main blurb:

Imagine… everyone able to work consistently at their best:

Individuals, teams, between teams, across the organisation
Right conversations, right people, best possible moment
Needs anticipated and met at just the right time

Fun to imagine, but how do you begin to bring that kind of Lean-Agile vision to life?

This book has some answers, exploring new ways to scope, launch, or re-energise your Lean-Agile transformation, integrating some powerful techniques from Clean Language, Cynefin, Agile, Lean Startup, A3, and Kanban.

Modelled on the Agendashift transformation mapping workshop, this book covers:

Discovery – identifying strategic goals, obstacles, and outcomes
Exploration – prioritising areas for attention, generating outcomes, agreeing scope and approach
Mapping – building your transformation plan
Elaboration – generating options; framing and developing actions
Operation – organising for continuous transformation

Read this book if any of the following apply:

You’ve an interest – whether as a practitioner or potential sponsor – in Lean-Agile change (perhaps under a banner of “Agile transformation” or similar)
You’d like to see what a 21^st century change management approach can look like, and how that might inform your work as coach, consultant, or some other kind of change agent
You’d love to see a model for Lean-Agile change that properly reflects Lean-Agile values and demonstrates Lean-Agile process and thinking in operation

Triangles!

Posted on April 11, 2017September 3, 2017 by Mike Burrows

I don’t mind admitting it: I was struggling a bit with chapter 5 (the last chapter of Part I and the main obstacle to initial publication). Then came London Lean Kanban Days 2017 and corridor conversations with Karl Scotland, Greg Brougham, Patrick Steyaert, and Ray Edgar that continued on Slack afterwards.

I was only too happy to scrap my first attempt and start again. What got the juices flowing again was this simple picture:

Screenshot 2017-04-06 05.34.27

It occurs to me that there’s a trap that Lean, Agile, and Lean-Agile folks fall into more often than they realise: believing that responsiveness (of delivery) implies adaptability, the ability to develop new capabilities and new levels of capability in the organisation. There’s a correlation certainly, but the trap is another way of describing the issues I raised a few weeks ago in Why Agile needs some 21st century Lean thinking. To what extent is responsiveness just a local optimisation, doing what we do increasingly quickly, but never breaking out of our comfort zone?

The rewritten chapter 5 takes the Agendashift Values-based delivery assessment and refocuses it on adaptability. The original version doesn’t completely ignore capability and adaptability but as its name implies, it is mostly about delivery. It turns out however that necessary modifications are very modest, an almost mechanical translation: yes there definitely is a relationship between responsiveness and adaptability, a kind of duality even.

These dualities aren’t new. Lean Startup demonstrates that tools for process improvement can be applied to product development, and vice versa. If your organisation can get to understand that change is work and value them both the same, much of the rest follows.

Grab the preview intro and first chapter of the forthcoming Agendashift book
Contribute to the conversation in Slack and LinkedIn

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.

Free preview: Read the introduction and first chapter of the forthcoming Agendashift book

Posted on February 22, 2017January 2, 2018 by Mike Burrows

[Update: The completed book is of course now available here]

It’s taking shape – Agendashift: clean conversations, coherent collaboration, continuous transformation. Part 1 – “Facilitating the transformation process” – is due out by the summer [Update: it’s out now, at the above link]. Meanwhile, you can request a free PDF containing the introduction and first chapter, Discovery.

You’ll definitely want to read this book if any of these apply to you:

You’re dissatisfied (if that’s a strong enough word) with transformation approaches that seem either disrespectful or feeble
You’d like to see what a 21st century change management approach can look like, and how that might inform your work as coach, consultant, or some other kind of change agent
You’ve an interest – whether as a practitioner or potential sponsor – in Lean-Agile change (perhaps under the banner of “Agile transformation” or similar)
You’d love to see a model for Lean-Agile change that reflects Lean-Agile values and demonstrates Lean-Agile process and thinking in operation

Also, check out the related Resources page. Find out how to obtain:

Cue cards for our Clean Language game 15-Minute FOTO, a description of which is included in chapter 1 (the preview chapter)
The Agendashift values-based delivery assessment, described in chapter 2
Our white paper 6+1 Essential strategies for successful Lean-Agile transformation (referred to in chapter 3) and the related video Servant Leadership un-neutered
The Agendashift A3 template, referred to in chapter 4
Featureban, our Creative Commons-licensed simulation game (not referred to in the book, but it’s still great!)

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.

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.

Agendashift