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!

Blog: Monthly roundups | Classic posts
Links: Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

[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:

1. Discovery: Identifying strategic objectives, obstacles, outcomes, and change strategies
2. Exploration: Debriefing your Agendashift values-based delivery assessment, prioritising opportunities, and agreeing scope
3. Mapping: Building a transformation plan
4. Elaboration: Generating, framing, and developing actions
5. 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):

1. Lean-Agile transformation as Lean-Agile process
2. Agendashift as coaching framework
3. Agendashift as Good Strategy

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.

Blog: Monthly roundups | Classic posts
Links: Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter