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: Explore strategic objectives, obstacles, outcomes, change strategies
Analysis: Debrief your Agendashift values-based delivery assessment, agree scope
Mapping: Build a transformation plan
Elaboration: Generate, frame, and develop actions
Operation: Organise 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. Analysis
Analysis here simply refers to the important legwork that keeps the transformation map properly informed 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, analysis isn’t navel gazing, it’s a generative process. Informed by the results from the assessment tool, we collaborate on identifying opportunities and their respective obstacles, and on ‘flipping’ those obstacles into the outcomes that will become the work items or 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’s needed in order for people, teams, and the organisation to succeed? What would it be like if everyone were able to work at their best, individually, within teams, and across teams? Why don’t we have that now? 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?
