Scrum and Kanban revisited

Posted on August 29, 2017July 16, 2022 by Mike Burrows

Update: See the August 30th webinar by Steve Porter and Dan Vacanti titled Scrum and Kanban: Make your teams better by busting common myths [scrum.org]. It’s great to see such a collaboration happening, and I’m happy to acknowledge that they are the original source of the six numbered headings below (not the content – that’s still mine). Apologies to Steve and Dan – honest mistake, I should have dug a little deeper.

Late last week I was invited by Fasih Sandhu to contribute my reactions to a LinkedIn post on the topic of Scrum and Kanban. My initial reaction was “Oh, here we go, 2012 just called”, but I ended up leaving a comment big enough that I had to edit it down for it to fit. Here then is the director’s cut! I don’t for a moment suppose it will resolve the issues once and for all, but it does at least give an opportunity to explain how someone committed to thoughtful integration approaches it.

Do you think that combining the #Kanban principles and practices with the #Scrum Framework will enhance the collaboration across your agile teams?

Space did not permit me to address this question on LinkedIn, but had it not contained the phrase “enhance the collaboration across your agile teams” I would likely have not have engaged at all.

To understand why this phrase was so crucial, here’s the Agendashift True North [1]:

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

I’m interested in enhancing collaboration not just across agile teams (as per the question), but between teams (of all kinds) and across the organisation – the right conversations happening between the right people at the best possible moment, wherever in the organisation or outside of it they happen to reside. Do I believe that a combination of Scrum and Kanban can help to deliver this? Yes I do, and I can point to multiple projects where I’ve witnessed it happen.

In a week or so, I will be attending an event on #Scrum versus #Kanban and I am interested to the reaction of my LinkedIn followers to any of the following statements that will be discussed in that event:

1) Scrum is for product teams; Kanban is for service teams
2) Scrum is for complex work; Kanban is for simple work
3) Our Scrum team has evolved to become a Kanban team
4) We do Scrumban
5) We do Kanban because we can’t plan out for an entire Sprint
6) Scrum is revolutionary; Kanban is evolutionary

Oh dear. “Scrum versus Kanban”. 2012 really is calling. Moving on:

1) Scrum is for product teams; Kanban is for service teams

Quick gut reaction: Ugh. Propaganda (at best based on an error of logic, more bluntly a lie based on a misdirection).

Longer answer, explaining the above but leading to a much less controversial conclusion:

Yes, Scrum is, by design, for product teams. Scrum.org describes it as “a management and control process that cuts through complexity to focus on building products that meet business needs”. No argument there, and in that context it is well understood and well resourced. For some it’s the framework of choice, for others it’s a good starting point or something you have to know.

Is Scrum designed for service teams? Not really. Can Kanban help there? In other words, can service teams benefit from Kanban’s visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc? Many can and many do!

What is also true (and it’s what makes this statement so frustrating) is that visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc are also highly useful to product teams, whether or not they are using Scrum.

So… Kanban is not only for service teams, and Scrum and Kanban are not mutually exclusive. Boring, but true! And can your product teams afford to ignore the service dimension anyway? Probably not, and some would even start there…

2) Scrum is for complex work; Kanban is for simple work

Quick gut reaction: Double ugh. Like question 1, but with a dose of Appeal to authority thrown in.

I could give an extended answer here, but suffice it to say that if you don’t understand that Scrum and Kanban both seek – in their quite different ways, both technically and philosophically – to help their organisations (not just their products) evolve in the presence of internal friction and external competitive pressure, then you don’t understand them, Agile, Lean, or Lean-Agile very well at all.

3) Our Scrum team has evolved to become a Kanban team

Positive, negative, and mixed reactions might be appropriate here – it’s hard to comment on this one without knowing the specifics of the scenario.

Unfortunately a statement like this could mean a whole range of things, ranging from “We stopped doing a bunch of Scrum-related stuff and we don’t really know what we’re doing” to “We’re now using a number of new techniques in a the pursuit of flow, leaving some older practices behind once we established that it was safe and effective to do so”.

Minor technicality: By the design of both, ‘Kanban team’ isn’t as well defined as ‘Scrum team’, but I can see how this arises.

4) We do Scrumban

As documented [2, 3, and elsewhere], my personal experience of Scrumban has been very positive.

To celebrate the Scrum part, the teams I worked with very much appreciated the focus of the sprint in the early days of each project; for organisations unused to achieving anything quickly, the experience can be amazing!

As to the Kanban part, this helped immensely in the pursuit of end-to-end flow (see my answer to question 3 above). This isn’t just better task management, this is integrating a process that starts well before development and finishes long after delivery into production.

I’m glad to be able to say that Scrumban is better resourced now than previously; see for example the book [4] by my friend Ajay Reddy and (from the same stable) some tools [5, 6].

5) We do Kanban because we can’t plan out for an entire Sprint

Quick gut reaction: I find it hard to see this as anything other than a feeble cop out.

Every team is subject to sources of unpredictability – in fact most teams seem to generate a fair amount of the stuff themselves! And yet there’s so much that remains under your control:

How often you plan is up to you (clue: choose an appropriate sprint size)
Whether or not you plan with zero wiggle room is up to you (clue: don’t)
The confidence you attach to your plans is up to you (clue: understand that this is crucial to the planning process, and that your choices here should be informed by both capability and need)

6) Scrum is revolutionary; Kanban is evolutionary

Quick gut reaction: Some truth there, exaggerated for effect, not on its own a useful value judgement.

Scrum is revolutionary if you’ve done nothing like it before. Over time and as there is more of it about, it will become less and less revolutionary, (a victim of its own success perhaps). And don’t forget that it has evolutionary goals (see question 2 above).

Kanban is often described as the easier of the two to introduce, but try introducing it in an organisation allergic to transparency!

Frankly though, discussions about what does or doesn’t constitute evolutionary change quickly get very dry, and in any case I don’t believe that this is a sensible basis for serious decisions about tool integration (and like it or not, every successful Agile adoption is an integration, not just a selection). Nowadays therefore, I prefer to take a more principles-based approach: Start with needs, Agree on outcomes, and so on [7, 8].

References

[1] A True North for Lean-Agile? (See also chapters 1 and 5 of [2])
[2] Agendashift: clean conversations, coherent collaboration, continuous transformation, Mike Burrows (yours truly) (2017, Leanpub)
[3] Kanban from the Inside (2014, Blue Hole Press)
[4] The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Ajay Reddy (2015, Addison-Wesley Professional)
[5] GetScrumban
[6] ScrumDo
[7] Agendashift in 5 principles
[8] (Non-)Prescription, frameworks, and expertise

What if we put agreement on outcomes ahead of solutions?

(Non-)Prescription, frameworks, and expertise

Posted on August 2, 2017September 3, 2017 by Mike Burrows

Let’s look again at Agendashift in 5 principles, 5 principles for organisational adaptability and 21st century change leadership:

Start with needs
Agree on outcomes
Keep the agenda for change visible
Manage options, testing assumptions
Organise for clarity, speed, and mutual accountability

Alongside those principles let’s consider also Agendashift’s description as “inclusive, non-prescriptive, and methodology-neutral”. Taking all of that together, what place is there here for skills and expertise in methods, frameworks, and so on? As it happens, quite a lot. It might seem counter-intuitive, but non-prescriptive is an excellent stance for the serious change agent to take.

Just one of the several cool things about starting with needs and outcomes instead of requirements and (pre-selected) solutions is that you give yourself the opportunity to generate and evaluate options (part of principle 4). That’s an interesting process in itself, and here are some of the ways in which a skilled facilitator can encourage diversity and innovation:

For every option that involves implementing a tool, we try to think of one that doesn’t (eg to “Implement Slack” we might add the alternative “Get out more”)
For every option that involves someone outside our circle providing more accurate inputs, we try to think of one where we we take the responsibility for better and timelier conversations (eg to “Better requirements documents” we might add the alternative “Spend time with customers”)

And some questions:

“What has worked elsewhere?”
“What would experts from different backgrounds recommend?”
“What’s the most radical option we could try?”

To people and teams already familiar with a framework (Scrum, for example), it makes total sense to try things that have worked for similar teams, so long as there’s a decent chance that it will help you achieve the outcome you’re currently focused on. For non-trivial problems, it also makes a lot of sense to understand how other people have solved similar problems outside your framework. For all but the most unusual problems, an expert worthy of that title will have ready access to a range of options and will be able to provide insight into when and why some options work better than others under different conditions.

Industry experience and framework expertise come into their own again with principle 5, organising for clarity, speed, and mutual accountability. Many frameworks have their own answers (technical answers, at least) to how communication and decision-making should work, but only a fool would pretend that it won’t be a challenge to change how organisations operate, especially at scale. Without a good understanding of i) what’s possible and ii) how to help make it happen, you’re stuffed.

The majority of Agendashift partners have deep expertise in at least one Lean-Agile method or framework and a working knowledge of others. No less valuable are the remaining partners that come from the organisation, facilitation, and change side as employees or external consultants, who are used to working respectfully with the technical experts (and vice versa).

If this inclusive (“it’s all great”), non-prescriptive, methodology-neutral thing sounds attractive to you, give Agendashift a closer look. Check out our partner directory, either to find some local expertise or to help you decide that you’d belong there yourself. If you’re a practitioner, check out the partner programme. If a potential sponsor, the unbenchmarking service and the transformation mapping workshop will give you a flavour of the services we and our partners can offer. And for depth, there’s the book: Agendashift: clean conversations, coherent collaboration, continuous transformation.

Agendashift in 5 principles

Posted on July 25, 2017September 3, 2017 by Mike Burrows

If you see from me a list of five things, chances are that it maps forwards or backwards* to Discovery, Exploration, Mapping, Elaboration, Operation, the five sessions of an Agendashift workshop and the five chapters of part I of the new book.

Here then is Agendashift in 5 principles:

Start with needs
Agree on outcomes
Keep the agenda for change visible
Manage options, testing assumptions
Organise for clarity, speed, and mutual accountability

You can read these as 5 principles of 21st century change leadership or 5 principles for organisational adaptability.

1. Start with needs

If you don’t know what the user needs are, you won’t build the right thing [gov.uk]

It’s no secret that I’m an admirer of the UK Government Digital Services’ focus on needs. At GDS, “Start with needs – user needs not government needs” isn’t just spin, but a statement of strategic intent. I can tell you from firsthand experience that if your UK government digital service fails to demonstrate a serious ongoing commitment to exploring and meeting needs, you can expect trouble!

Whether it’s change to products and services or to organisation and process, if your idea of driving change consists of handing down requirements from your ivory tower, you don’t get the needs thing at all. Face it though: you can satisfy a long list of requirements and still not meet needs. (See also: Better user stories start with authentic situations of need).

Neither do you get it if you think it’s ok for your improvement efforts are mostly inward-looking, attending mainly to your team’s efficiency and comfort. If you don’t take time to understand the needs of people outside your four walls, how do you know that you are improving in any meaningful sense?

2. Agree on outcomes

You’d be forgiven for thinking that 20th century change management was all about overcoming resistance to change: trying to convince people, and when all attempts at persuasion have failed, going ahead anyway.

Whether or not that’s fair (certainly there’s truth in it), I believe that 21st century change management is different. Just as we put needs ahead of requirements, we put outcomes ahead of solutions. Agreement on outcomes is gold; once you have that, it’s just a question of how those outcomes will be achieved, the kind of problem that motivates people (not everyone perhaps, but enough people if the outcome is sufficiently meaningful).

3. Keep the agenda for change visible

Agreeing on outcomes and then forgetting them would be quite a waste of effort! To quote the last chapter of my first book (published in 2014):

Shaping the agenda … with the explicit aim of producing a compelling set of agreed upon priorities, goals, and actions

Little did I know it at the time, but chapter 23 of Kanban from the Inside would be the springboard for Agendashift – you can even see where the name came from! Ever since, I have been motivated to help organisations produce their own compelling agendas for change, agendas that whilst remaining true to the Start with what you do now principle still manage to convey a sense of challenge and ambition. You see that sense of challenge and ambition in my proposal A True North for Lean-Agile?, my distillation of what we strive towards.

4. Manage options, testing assumptions

Representing a real alternative to prescription, Agendashift is generative twice over (generative squared?). It contains repeatable and transferable tools first to generate outcomes, and then to generate options for their realisation.

We’ve adopted Lean Startup language for framing options as hypotheses, we take an initial look at assumptions when deciding on which options to select, reject, or hold, and we use an A3-based tool to develop this thinking further. At all three levels of detail we’re bringing assumptions to the surface and devising experiments by which they can be tested. Relentless validation becomes the engine of change; we learn and adapt quickly because we have both the courage and the humility to be wrong.

5. Organise for clarity, speed, and mutual accountability

… it reads like a list on how to align to purpose

Exactly! That was Damian Crawford commenting in the Agendashift Slack on alternative wordings to #5, endorsing this one.

We’re talking transparency, leadership, autonomy, alignment mechanisms, knowledge discovery processes, feedback loops, and so on. Right conversations, right people, best possible moment (an Agile-influenced element of our True North proposal). Pushing authority to the information (David Marquet, author of the fantastic Turn the Ship Around!). For leaders, it means more than just clarity of intent, it means a genuine commitment to the people who will carry it out. And it’s not just about personal style, it has significant implications for organisation design.

Recap

Here again is Agendashift in 5 principles:

Start with needs
Agree on outcomes
Keep the agenda for change visible
Manage options, testing assumptions
Organise for clarity, speed, and mutual accountability

Whether for 21st century change management or organisational adaptability, what principles would you choose? How do they align to these?

*See Lean-Agile transformation as Lean-Agile process for a backwards example.

Video: Exercises in Lean-Agile transformation

Posted on June 20, 2017September 3, 2017 by Mike Burrows

Two weeks ago I led a big Agendashift-style Discovery session (chapter 1 of the book) for 80+ people as guest of Adventures With Agile’s London meetup. Here’s the video:

Last week I was at Agile Yorkshire. Tomorrow (Wednesday June 20th) I’ll be doing my third meetup in three weeks, when I’m at Agile Peterborough. 75 people signed up so far!

A True North for Lean-Agile?

Posted on May 22, 2017July 16, 2022 by Mike Burrows

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?

Agendashift: clean conversations, coherent collaborations, continuous transformation (part 1) – out on Leanpub since May 11th
Lean-Agile Strategy Days, London – June 7th & 8th, see day 2
Caitlin Walker’s From Contempt to Curiosity, whose explorations of “working at your best” inspired the Agendashift exercise.

Screenshot 2017-05-22 13.42.56

What if we put agreement on outcomes ahead of solutions?

If you’ve read Kanban from the Inside…

Posted on May 15, 2017February 23, 2020 by Mike Burrows

…what should you expect from my second book?

TLDR: Agendashift wouldn’t have happened without Kanban from the Inside. It is however very much its own book. I think you will enjoy it 🙂

Not only is Agendashift not a book about Kanban – in fact it is very consciously method-neutral – it makes few assumptions about the reader’s knowledge of Kanban either. In terms of detailed content then, the overlap is minimal and both books stand alone. The resonances between the two are however very strong:

The titles of the first six chapters of KFTI make an appearance in Agendashift chapter 2 (Exploration) as the headings of the Agendashift values-based delivery assessment. These are the values of Transparency, Balance, Collaboration, Customer focus, Flow, and Leadership. If you’re wondering what happened to Understanding, Agreement, and Respect (KFTI chapters 7, 8, and 9), they belong with Leadership (which shouldn’t be a big surprise).
Reverse STATIK (which was developed while KFTI was nearing completion) reappears in chapter 3 (Mapping), not as an improvement process, but to provide a sense of narrative flow to the transformation map, something the values can’t easily provide.
The same sense of respect for a broad range of models described in KFTI part II, in particular Agile, Lean, Lean-Agile, Lean Startup, Cynefin, Systems Thinking, and Scrum. If anything, the appreciation is deepened thanks to experience and integration.

Moreover, you can see the final chapter of KFTI (chapter 23, Rollout) as the springboard for Agendashift, a more thoroughly exercised how-to – not for Kanban, but for continuous transformation, a term not found in the older book. Expect these themes from chapter 23 to be developed more fully:

Making the agenda for change visible
Pulling change through the system
Making a connection between purpose and transformation
Identifying increments of change
Managing change visually
Recognising different kinds of change (and choosing appropriate tools)

The section Identifying increments of change contained the seeds for the Agendashift values-based delivery assessment, which in turn gave rise to the transformation mapping workshop and our now well-rehearsed routines for identifying priorities, obstacles, outcomes, options, actions, and so on. These are covered in chapters 2-4 of the new book.

In short, Agendashift wouldn’t have happened without Kanban from the Inside. It is however very much its own book. I think you will enjoy it 🙂

Read them both:

Agendashift: clean conversations, coherent collaboration, continuous transformation (part I) [leanpub.com]
Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact [amazon.co.uk, also on amazon.com]

agendashift-part-1-cover

From the Department for Dodgy Mnemonics: DUL and POWT

Posted on April 18, 2017September 3, 2017 by Mike Burrows

From DfDM, the Department for Dodgy Mnemonics, two for the same day, April 18th, 2017.

Mnemonic 1: DUL

Don’t blame Schein for the awful nmemonic, but do thank him for the process:

Discomfirmation: when we come to the (perhaps difficult) realisation that past assumptions, values, or solutions either don’t hold, cause as many problems as they solve, or must make way for something else
Unlearning (or unfreezing): when we work through the implications of that realisation, and become open to alternatives
Learning: when we begin to work with a new set of assumptions, values, and solutions

Source: Organizational Culture and Leadership, Edgar H. Schein. I can vouch for the audiobook also.

Mnemonic 2: POWT

Or if you prefer, POOO, or GOOO. It’s a pattern we use repeatedly:

Prompts (or prioritised goals): We prioritise assessment prompts (or similar descriptions of how we would like things to be) because we realise that they represent – in a positive way – something that isn’t working as it should. See also DUL.
Obstacles: We identify things that stop those prioritised prompts or goals from being realised as we would like. See also DUL.
What would you like to have happen?: We identify outcomes hiding behind those obstacles.
Then what happens?: More outcomes – the outcomes behind the outcomes.

Worst case, we get to discover what’s beyond our most immediate outcomes. Better (and quite likely) case: we agree on outcomes more interesting and achievable than the ones we started with.

Why Agile needs some 21st century Lean thinking

Posted on March 21, 2017September 3, 2017 by Mike Burrows

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!

Why “continuous transformation”?

Posted on March 3, 2017September 3, 2017 by Mike Burrows

If you were wondering about the last couple of words of the new book’s title Agendashift: clean conversations, coherent collaboration, continuous transformation, here’s your explanation.

This picture sums up the challenge:

screenshot-2017-03-03-11-05-53

The good:

Yes, continuous improvement (in its many forms) is respectful – respectful (generally speaking) of people, respectful of current state, respectful of how you got there.
Yes, transformation initiatives do generally have a sense of ambition. Goals, rationale, sponsorship, and so on.

And the questionable:

Continuous improvement may be guided by some sense of direction, but often that’s more about the comfort of those inside the system than it is about purpose. The lack of meaningful goals means that few are motivated to overcome serious organisational challenges.
Too often, transformation initiatives are about imposing someone else’s vision on the people who know how things actually work. Too much is invested in overcoming resistance to change, not enough in engaging people in an open process.
If the organisational design doesn’t support it, continuous improvement quickly runs out of steam. Almost by definition – and certainly by the textbook definition of project – most initiatives are set up to exist for only a limited time. Either way, sustainability is an ever-present challenge.

What if we could combine the best of both – respect and appropriate ambition – and at the same time confront the sustainability problem? This is what I am looking for in continuous transformation. I would define this as transformation that is:

Respectful of present and past, the current context and the open-ended journey
Appropriately ambitious for the future – – not grandiose, but with goals more ambitious than typically implied by continuous improvement, inspect and adapt, and the like
Not just reactive, but proactive and anticipatory
Happening all the time because – by design and by habit – the organisation’s core systems now demand and sustain it

If that sounds attractive, you’ve come to the right place. Grab your preview chapter. Join our Slack community and LinkedIn group. Check out our partner programme. And come to the next Agendashift facilitator day, in Manchester on March 23rd.

Agendashift