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.

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!

Outcomes, alignment, and changes to our A3 template

Posted on August 10, 2016September 3, 2017 by Mike Burrows

Last week’s post Two new tools* and how I’m finding them useful has generated a lot of interest – after just six days it is already the 3rd most popular post of the year!

*Spoiler: Clean Language and the Cynefin Four Points Contextualisation exercise

One piece of detail I neglected to mention is a tweak I have made to the A3 template we use to guide people through the process of framing and developing their actions as hypothesis-driven changes. The header area at the top of the page has gained a new field: “Aligned to objective”.

It’s a chance to identify:

a pre-existing high level objective to which this action aligns, or
a summary outcome shared by this and other actions (a theme, if you like).

Better still, both at the same time – this is after all what alignment and strategy deployment [availagility.co.uk] are all about. Without alignment, so-called improvement can easily descend into just fixing stuff – interesting locally perhaps but unlikely to be important in the grand scheme of things.

Resources

Improvement and Alignment are strategies 4 and 5 respectively in our white paper 6+1 Essential strategies for successful Lean-Agile transformation
The PDF for the Creative Commons-licensed A3 template can be downloaded directly from the blog post A3 template for hypothesis-driven change. For the source XLS, just drop me a line. There’s a German translation available too.
Interested in facilitating an Agendashift workshop or using the tools in your coaching or leadership practice? Very soon we’ll be licensing the material and widening access to the online tools beyond our existing beta users. Again, get in touch!

A3 template for hypothesis-driven change

Posted on April 28, 2016July 16, 2022 by Mike Burrows

[Update 23-Sep-2019: The version shown here has been updated a few times since publication. The latest version of this and several other Creative Commons resources may now be found at agendashift.com/resources; clicking on the image below now takes you to the relevant resource page]

[Update 10-Aug-2016: The latest version is still downloadable here; see Outcomes, alignment, and changes to our A3 template for a description of recent changes]

As mentioned in On not teaching PDCA, I’ve been using an A3 template in my training classes and debrief/action workshops. I’m now releasing under the same model as Featureban – I’ve given it a Creative Commons Attribution-ShareAlike license, you can download the PDF here, and drop me a line for the original .xlsx file if you want to translate it or adapt it in some other way.

I typically cover it in this order:

Hypothesis
Assumptions & Dependencies
Pilot Experiments (potentially spawning new A3’s)
Risks
Pilot Experiments (again, if prompted by the risks)
People
Insights.

Enjoy!

What if we put agreement on outcomes ahead of solutions?

Stand up meeting, thinking tool, leadership routine

Posted on September 16, 2013February 13, 2018 by Mike Burrows

[Originally posted on positiveincline.com September 16 2013, restored to blog.agendashift.com February 13, 2018. Links are to web.archive.org.]

My last post was on the provocative side; to restore this blog’s usual balance, here are some antidotes to some of the problems I described. These are ways to use your kanban board to help you look at your process from the perspectives of customer focus and flow, two values from that middle direction layer [2018: the other one being leadership].

Imagine you’re facilitating a stand-up meeting in front of your board. If you have a physical board, you’re probably heading (in your mind at least) towards the board’s right hand side so that you can stand looking left across the board. If you use an electronic kanban tool, you can achieve a similar effect by turning your laptop or monitor monitor to the left a bit (ok, I’m kidding).

Now scan the board from right to left (in other words working your way backwards from the end of your process towards the start) and ask these questions of the columns:

Customer focus

Whose needs are explored in this stage of the process, and how? Whose aren’t, and what risks does that pose?
What do we learn in this stage that we don’t (or can’t) know earlier? In what ways do the activities of this stage help us anticipate what will be needed?
What is still to be learned? Are outstanding uncertainties best dealt with by pressing on or by going back?

Flow

How do work items leave this stage in the process? By what criteria do we know that they’re ready? How are those criteria expressed? How is the state change communicated?
Typically, how much time do work items spend in this stage? How much (if any) of that time is spent in active work?
What are the most significant sources of unpredictability? In the work in or the waiting? Waiting for internal availability or for external dependencies to be resolved?
How much of this stage’s capacity is absorbed in rework? Or in failure demand, which arrives only because previous work failed to meet customer needs adequately?
How do work items arrive into this stage? How do we know that they’re ready to be worked on?

You may find it helpful to ask some of these questions of individual work items too.

What we’ve done is to turn a popular protocol for standup meetings into a thinking tool. You can try it with other values, for example transparency (is it sufficiently clear what’s going on here?) or balance (are we overburdened here?), or some other concern that seems relevant.

Caution: questions like these already assume the following:

That the process has sensible objectives (to deliver the right kind of things)
That the work flow is scoped sensibly (starts with the right kind of questions, finishes with the right kind of result)
That the work flow is organized sensibly (sequenced to generate high value learning as quickly as possible)

I’ve encountered plenty of processes where these assumptions are open to challenge. For example:

A change management process whose objective was the approval or rejection of design changes, disconnected from any actual implementation process. Needless to say, any customer satisfaction delivered out of that process was somewhat short lived.
My bank’s account opening process. A frustrating process and several weeks later and I still don’t have online banking, let alone two additional products that I would be willing to pay for. I sense an institutionalised lack of curiosity into my needs and what might be in the way of delivering on them.

Some acknowledgements are in order:

The first set of questions questions are heavily influenced by Michael Kennedy and the model of the Knowledge Discovery Process. That’s a Lean product development model, but I find that many processes are usefully understood in those terms.
The “whose needs?” questions (the first bullet) point to the very important question: “who holds a veto on delivery?”. This is one of many good customer focus takeaways from Lean Software Strategies by Peter Middleton and my friend Jim Sutton.
The idea of understanding a process by walking through it backwards is an old Lean trick. I don’t know for sure how it was discovered and popularised, but Steven Spear describes very well its use as a leadership routine inside Toyota in his book The High-Velocity Edge.
Failure Demand is a concept I associate (in the nicest possible way) with John Seddon.

These are all great ideas. Combining them with visual management and practised routine makes them (as well as the values) accessible and actionable, don’t you think?