From “What did you do yesterday?” to something better

Go for it! If the main purpose of your standup is to make sure that everyone is keeping themselves properly busy, then the questions “What did you do yesterday?” and “What will you do today?” are without doubt the basis of a great meeting format.

But be careful what you wish for. If your goals involve 1) the team meeting needs, and 2) learning from the process, those questions can hurt a lot more than they help. Honestly, I’m not a fan at all.

You could try these instead. Understand the pattern, and with practice, it runs itself:

  1. What are we learning from what we recently completed? And is it staying completed? Whose needs did we meet, and how do we know we met them?
  2. What can we get over the line?
  3. What is and isn’t making the expected progress? Are we clear about whose needs we’re meeting, what needs, how we’ll know, and what’s our approach?
  4. Do we have the capacity to look at what’s next, or is that enough until we next meet?

You probably won’t get to that overnight, so some things to try:

  • Instead of reviewing activities (what you did, what you’re doing, etc), try to focus the things that you as a team are trying to produce, in the context of the goals you’re pursuing
  • All else being equal (in bigger meetings, this pattern can work within other interesting ways to structure the work), try reviewing your work most-complete work first, not forgetting to start with celebrating and enquiring into work recently completed
  • Make a point of noticing how the conversations change as you work backwards, and develop your repertoire accordingly – by this stage you’ll likely be noticing not only a performance difference but a language change and changes to people’s expectations and behaviour, and you can build on that until they become habits
  • In all of the above, try keep in your mind and everyone else’s what you’re working backwards from: “someone’s need met” and “all the available learning fully accounted for” (my definitions of done and really done)

I’ve used this “right to left” technique in a range of settings, often supercharging something that really wasn’t working before – standup meetings, risk & issue review meetings, service delivery review meetings to name just three. Right to left is named after Kanban’s board review pattern (you start on the right-hand side of the board with work at or nearest completion) but it’s not hard to apply in other settings.

And it’s more than just a productivity hack. In my third book Right to Left (2019, audiobook 2020), I take that philosophy of working backwards from impact and learning and use it as a lens on the whole Lean-Agile landscape (and more). Further to it not being just a Kanban thing, the book shows how right to left fits very well with the best of Scrum. Contrast that with an all too prevalent left to right kind of Scrum that does the reputations of Scrum and Agile no favours at all, and that scales up in the worst possible way. Fortunately it’s fixable.

This post started out as a LinkedIn post, then a second:

  1. Go for it! (linkedin.com)
  2. Building on that last one… (linkedin.com)

And now a third:

Like, comment, share!

You can also take any questions you may have to one of the upcoming webinars – the first three (December 8th, January 12th, February 2nd) all finish with an AMA (Ask Mike Anything) session. Series link: The questions that drive us (eventbrite.co.uk).

Related:


Upcoming:


Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with Outcomes | Facilitator and Trainer Programmes

Links: Subscribe | Events | Contact | Mike

We help leaders and engaged team members at every level to gain fluency in the language of outcomes – developing and pursuing strategies together, innovating, learning, and adapting as the organisation renews and transforms itself from the inside.

The 1967 Manifesto for The Deliberately Adaptive Organisation

It may still too early to judge the 1990’s for its net contribution to organisational understanding. If much of what was published on the specific topic of change management had never been written, it might have been for the better! It’s not all bad though: I have recently enjoyed two books from that period, Karl Weick’s Sensemaking in Organizations (1995) and the 1994 first edition of Henry Mintzberg’s Rise and Fall of Strategic Planning. (Regarding the latter one, if you can tell me whether I should also read the 2000 second edition, do let me know.)

Reading Mintzberg, what stood out for me wasn’t so much his concept of emergent strategy (arguably not much more than a fancy name for what really happens to our best-laid plans) but these five things:

  1. The limits of rationalism and control, and the apparent disregard shown for them not just by the mid 20th-century strategic planners but by their champions in academia
  2. The idea, attributed to Edelman, of experts being those who avoid (or merely bemoan) the pitfalls but fail to notice the grand fallacy (see point 1 above, and I suspect I may never hear the words ‘expert’ and ‘pitfall’ in quite the same way again!)
  3. Primed by my prior reading of that Weick book on sensemaking, the idea of strategy as the means by which we make sense and meaning of our decisions; strategies don’t just help us to act in the present and project ourselves into the future, their role in helping us reinterpret how we got here is important too
  4. And before we get too comfortable with strategy as story, strategy as theory – something to be tested, lightly held
  5. Brian Loasby’s 1967 Manifesto for the Deliberately Adaptive Organisation

I’m having a bit of fun with that last one of course. I’ve no reason to think that Loasby (now Emeritus Professor in Economics at Stirling University) had anything manifesto-like in mind, and the Deliberately Adaptive Organisation didn’t exist back then. Not even its sources: the Viable System Model (Beer) was not yet fully formed; the Deliberately Developmental Organisation (Kegan & Lahey) was decades off; Agendashift’s main architect (yours truly) was just two years old.

But check this out:

if, instead of asking how they can more accurately foresee future events and thus make better decisions further ahead, firms were to ask first what they can do to avoid the need to decide so far ahead, they might be led to discover important ways of improving their performance.

Brian Loasby, 1967, via Mintzberg

Let me recast that in the “this over that” style of a notable document familiar to many readers, the Agile Manifesto. Adding some flourishes of my own:

In the pursuit of business performance, we are finding it useful to see plans and strategies more as theories to be tested quickly than as predictions and commitments for the longer term. Through this change of perspective, we are learning to value anticipating and meeting needs over setting and meeting deadlines, open options over past decisions, and rate of learning over closeness of control. Not that deadlines, decisions, and control have no value, rather that when valued against needs, flexibility, and adaptability, it is the latter group that drives our development forward.

I am not seriously advocating a new manifesto – for me, that ship sailed long ago – but Loasby was definitely onto something all those years ago. Rewriting history, there is already something Lean-like about his heuristic, and for anyone trying it, I’ve little doubt that Lean’s explicit attention to people and to flow would soon be required in any determined application of it. Invite the customer inside that way of thinking and you get something quite Agile-like. And compared to Agile as first framed, much more obviously relatable to business agility too. Interesting!


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | Store

Links: Home | Subscribe | Become an Agendashift partner Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments 
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

If you are not already engaging on strategy, the time to get serious is now

2021 promises to be a big year for Agendashift and I want to share a train of thought that crystallised over the closing weeks of 2020 as I finished the 2nd edition*.

Most Agile process is built around the autonomous team. The uncomfortable truth though is that many if not most of those teams get little meaningful opportunity to participate in strategy. Surely it is a funny kind of autonomy when strategy is something that happens to you!

The flip side of the same coin: business agility depends on rapid adaptation, but it’s a funny kind of adaptive strategy when it doesn’t know how to listen and learn.

Tackle those two problems together and you get loads more benefit for free. With authentic participation in strategy you get engagement. And with that, ways of working and broader aspects of culture become natural and integrated ingredients in the way forward, neither compartmentalised off (sterile when separated from mission), nor imposed (almost certainly self-defeating).

This is of course where Agendashift comes in. Not only do we know how to facilitate those conversations, we give you the tools to keep doing it yourself. And it’s not just the workshops; how to make the process of continuous transformation self-sustaining is a key focus of ours, to the extent that much of the past 18 months has been spent digging deep foundations in systems, organisation, and personal development.

As I write, the four nations of the UK each enter new levels of lockdown, a situation sure to be echoed in different ways around the world. Yes, there’s some light at the end of the tunnel this time, but there can be no doubt that the world of work has changed forever. If you’re a leader and your strategy process does not already invite meaningful engagement, the time to get serious is now. And we can help, whether that’s directly, working with your internal coaching team, or through one of our partners. Get in touch or check out our partner directory right away.

If you’re a practitioner in (Lean-)Agile, strategy, &/or organisation development – one of those is enough if you buy into our mission of building wholehearted organisations – you can be that help. From the start, Agendashift has been accessible and affordable. And there’s no time like the present: join the partner programme now and your discount on the February Deep Dive will cover your first year’s membership.

autonomy

*The 2nd edition gets delivered to the publishers tomorrow for publication this quarter

Upcoming

The workshops continue to evolve at quite a pace and watch out for some new developments this year. In the calendar so far:

All the usual discounts apply: repeat visits (not uncommon), partners, gov, edu, non-profit, country, un- or under-employment, bulk orders. If you think that one might apply to you, do please ask. Most of those considerations apply to private workshops also.

For the Deep Dive especially, if you think that you might become an Agendashift partner, partner discounts make it well worthwhile to get on board before you sign up to the workshop.


Agendashift™, the wholehearted engagement model
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Media | Events | Contact | MikeSubscribe
Workshops: Transformation strategy | Outside-in strategy | Short training
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

Agendashift roundup, October 2019

In this edition: Berlin; Working at the intersection / a monster post on SAFe; Right to Left; Changeban, Featureban, and 15-minute FOTO; Upcoming workshops – Berlin, Oslo, Malmö, and online; Top posts

Berlin

I have a free day in Berlin today, arriving a day early to avoid travelling on what threatened to be Brexit day before a private workshop tomorrow. That workshop is actually the first of three November engagements in Berlin, with a 2-day Advanced Agendashift workshop and (through happy coincidence) the Open Leadership Symposium:

I keep saying it and I will say it again:

  • The Berlin workshop consistently delivers – not just a full house and a great experience, but a reliable source of great feedback and new ideas. Thank you Leanovate not just for hosting but for participating
  • The inaugural Open Leadership Symposium in Boston last May was a key coming together of multiple communities and it launched a new one. I have high expectations of the Berlin event, which takes place on the 19th with a selection of masterclasses on the 18th & 20th. If you’re thinking of coming to the main event, ping me for a chunky discount code (big enough to make a real difference, so don’t miss out!).

Working at the intersection / a monster post on SAFe

This was just a quick picture posted to LinkedIn and Twitter, but it has struck a chord with many people and it has already established itself as a way to introduce both myself and the communities I participate in. You’ll see some of the language reflected on the Agendashift site, the partner programme page most especially.

Who/where we are on one slide: People working at the intersection of Lean-Agile, Strategy, and Organisation Development – bringing balance & perspective, focus on needs & outcomes, helping each other up their game in new areas

working at the intersection

That picture is a good scene-setter to a post that within 36 hours was my most-read post of the year:

Also doing well is a Kanban-related post:

And I can only apologise for this related tweet 😉:

Right to Left

Thank you Paul and Justyna! Two podcasts for the price of one, a book review and an interview:

After a long delay, Right to Left: The digital leader’s guide to Lean and Agile is at last available in EPUB format. That means you can download it as an ebook from more online booksellers, including Apple Books, Google Play Books, and Kobo – just search “Right to Left Mike Burrows”.

There were two more 5 star reviews on Amazon UK this month (thank you!), making eight so far. We’re still waiting for the first one on Amazon US though, so who will be first?

Changeban, Featureban, and 15-minute FOTO

Some news about three of our Creative Commons-licensed resources.

Changeban 1.3 is now the recommended version (it was in beta until properly tested). I’ll be making the equivalent changes to Featureban before making a separate announcement. Also, their respective Slack channels have merged into one, #featureban-changeban.

The updated 15-minute FOTO cue card is definitely an improvement and it too is out of beta. A new ‘Lite’ (gentle introduction) version of the game has been through a number of iterations and we’ll announce it soon. It’s available to try if you know where to look! Slack channel #cleanlanguage, and it’s enabling some new #workshops (we’ll announce those properly soon too).

Upcoming workshops – Berlin, Oslo, Malmö, and online

Top posts


Leading change in the 21st century? You need a 21st century engagement model!
Links: SubscribeHome | Partners | Books |Resources | Events | Contact | Mike
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

A question among the good luck emails

There’s a contact button on the landing page for Right to Left, and through it I got this question which I have permission to reproduce:

Keep up the good work, and btw how do you use the Kanban Method these days, after your current progression?

My reply (verbatim):

In Right to Left you’ll see Kanban as just one of a set of complementary patterns in the Lean-Agile space (none of them more important than the others), and a more general approach to organisation development and the leadership that goes with that.

In my own work, Kanban is still in the mix but I’m very definitely needs & outcomes first, not solutions/framework first. STATIK tries to do a bit of that* but it does rather presuppose the answer! I prefer Reverse STATIK anyway, and my very occasional Kanban training uses that. The principles and practices are abstracted in the values, and they live on through the Agendashift delivery assessment (a conversation-starter, not a checklist of practices).

*To be fair, it does this quite valiantly and self-consistently compared with peer frameworks, but my comment stands.

And a PS, sent moments later:

One thing to add: this is not to diminish anyone’s work on Kanban (my own included) or any other framework. Testing boundaries is learning. But it’s also healthy to draw back a bit and broaden one’s horizons from time to time. And integration is also learning.

Some links to help with decoding the above (I knew my correspondent to be familiar with most of them):


Autumn workshops
– Stockholm, Athens, London, Istanbul, Berlin, and online

Leading change in the 21st century? You need a 21st century engagement model:

Blog: Monthly roundups | Classic posts
Links: Home | Partners | Books |Resources | Events | Contact | Mike
Community: Slack | LinkedIn group | Twitter

A Grand Unification Theory for Lean-Agile?

The job of chapter 3 of the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile is to introduce a number of important Agile, Lean-Agile, and associated frameworks. I have taken care to describe them not as alternative solutions that must be chosen between, but as patterns to be combined in interesting ways. That’s not a new idea, but what does seem remarkable is how helpful a right-to-left perspective is in explaining how they work together and complement each other. When I say right-to-left, we’re talking not just collaborative, continuous, pull-based, and so on (concepts conventionally associated with Lean-Agile) but something very explicitly outcome-oriented.

Almost verbatim from the manuscript:

  1. Scrum (and Scrum-based scaling frameworks, if that’s your bag): continuously iterating on and self-organising around goals (short term outcomes) in the pursuit of longer term outcomes – product vision, the team’s mission, broader organisational objectives, and so on
  2. Kanban, making progress on outcomes visible, concentrating effort on the ones that matter most, fostering a focus on completion
  3. XP and DevOps, right across development and production, providing the infrastructure of process, practice, and technology necessary to accelerate feedback on the delivery of outcomes
  4. Service Design Thinking (along with user research, user experience and so on), continuously discovering which outcomes are important
  5. Lean Startup, pursuing business viability through continuous deliberate experimentation, managing for impact (outcomes again), finding and continuously refining a business model that enables customer outcomes to be sustained

Here it really is outcomes that holds everything together, not (as you might expect) flow, collaboration, or some other shared value or technical principle. This way, we avoid saying “if you dig deep enough, they’re the same” (which I hear from time to time and strongly reject, believing that it does each framework’s creators and communities a huge disservice).

Neither are we saying “don’t use frameworks”, if (and it’s quite a big if) this means that you must always start from first principles. A sensible way to start is again outcome-oriented and has a measured and pragmatic attitude towards frameworks (quoting this time from chapter 4, Viable scaling):

  • Identify needs – looking at what kind of organisation you’re trying to be and at what you’re trying to achieve  – and the obstacles that currently prevent those needs from being met
  • Agree on outcomes, not just goals plucked out of the air, but the kind of outcomes that might be achieved when these obstacles are removed, overcome, or bypassed
  • On a just-in-time basis, prioritise outcomes and generate a range of options to realise them, using your favourite frameworks as sources of ideas (not excluding other sources, but valuing coherence nevertheless)
  • In manageably small chunks of change and through a combination of direct action and experimentation (choosing between those approaches on a case-by-case basis according to the level of uncertainty and risk involved), begin to treat change as real work: tracking it, validating its impact, and reflecting on it just as we would for product work

In a nutshell, I’ve described Agendashift, which is of course a right-to-left approach to change and transformation. Other engagement models exist – see OpenSpace Agility (OSA) for another excellent, well-documented, and highly complementary example. Whichever approach you choose, take care to choose one that models Lean and Agile values, lest the dissonance proves too great and you fatally undermine your work, a very real risk. To sow disengagement would be a truly bad outcome!

Related:


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, US*2, UK, Netherlands):

Also: Channel #agendashift-studio in the Agendashift Slack if interested in a cozy workshop with me at Agendashift HQ (Derbyshire, England).


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

 

A True North for Lean-Agile?

You may have noticed that the blurb for our workshops and for the new book always starts with this:

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, met at just the right time

It’s taken from one of our Discovery exercises (chapter 1), an early opportunity for participants to explore different ways of working not from the perspective of prescribed practices, but in terms of what it is like – how it feels, what’s different, and so on.

Some of the groups I’ve facilitated have found the exercise so cathartic that they ask repeatedly for more time. It’s not hard to see why:

  • If you feel that you’re rarely given the opportunity to work at your best, your team doesn’t work well, or you’re painfully aware that teams aren’t working work well together, it can come as a relief to be given the chance to imagine a different reality
  • Whether you’re a front line worker or a manager, conversations happening at the wrong time (or not at all) can be very frustrating
  • For most of us, knowing that we’re meeting needs is crucial to finding meaning in our work

The current text of the book doesn’t identify these words as a True North statement (a compass direction rather than a destination), but it probably should. A True North for Agendashift certainly, and I’d like to put it forward as a True North for Lean-Agile also. It’s consistent with the Lean pillars of respect for people and just in time. Consistent with the Agile manifesto, it elevates individuals and interactions, combining those with a sense of timeliness (I joke that Agile seems to imply lots of meetings, the beginning – one hopes– of true collaboration).

In its favour as a worthy True North:

  • It is easy to understand, worth striving for, and will remain always just out of reach. Transformation must be continuous, not a one-off project
  • It works at every scale – from individual to organisation, and at scales in between
  • In its last bullet, it conveys much-needed senses of proactive discovery (needs don’t get consistently anticipated by accident) and purpose (needs being met)

Also, it’s not specifically about software, or even about product development. That’s a departure from the Agile manifesto, but I have no doubt that this is in its favour too.

So… Does it work for you?

Related:

Screenshot 2017-05-22 13.42.56


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | Store

Links: Home | Subscribe | Become an Agendashift partner Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

Lean-Agile Strategy Days, London

June 8th is a special day: not just because the UK general election is (somewhat inconsiderately) being held on that day, but because I’m pairing up with Karl Scotland for a 2-day public workshop in London, Lean-Agile Strategy Days.

I like to think of it as “pure & applied” strategy deployment. On day 1, we’ll be experimenting with Lean approaches for engaging people in the development and implementation of strategy. On day 2, we’ll use Agendashift as a model for continuous Lean-Agile transformation, a serious question of organisational strategy if ever there was one.

This workshop is a first, and I’m proud to be doing it with Karl. We describe the workshop as an opportunity for collaboration, and this isn’t just hype. As a key collaborator in the development of Agendashift, Karl did much to push Agendashift upstream, suggesting (and bravely testing) ways to develop the Discovery tools, also to better integrate the Cynefin-related material. He has a gift for nudging me in productive directions, and I would be surprised if something new and exciting didn’t come out of this event.

You can be part of it! Book your place here.

Read Karl’s post: Lean-Agile Strategy Days: An X-Matrix and Agendashift Fusion

PS Did I mention I have a book coming out? May 11th!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Why Agile needs some 21st century Lean thinking

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!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

 

Lean-Agile transformation as Lean-Agile process

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


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter