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.


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


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


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!


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?


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!

Blog: Monthly roundups | Classic posts

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!

Blog: Monthly roundups | Classic posts

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.

Blog: Monthly roundups | Classic posts

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

A blocker waiting to happen (and it works both ways)

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.

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:

  1. A strong sense of what we’re delivering, to whom, and why
  2. The ability to manage expectations around performance

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!

Blog: Monthly roundups | Classic posts

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