How I read the Scrum Guide

Overview:

  1. The good: Things the Scrum Guide™ reinforces that would otherwise get lost
  2. The ugly: Things that should not be accepted at face value
  3. How I approach it

I’m going to assume that you have at least a passing acquaintance with Scrum, either as it’s generally taught and discussed, or as defined in the Scrum Guide. The guide itself has been updated in the past few days, there now being a 2017 edition:

The guide is ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.

I haven’t checked to see when this license model was applied, but nice move.

1. The good: Things the Scrum Guide reinforces that can easily get lost

My biggest “Aha!” moment for Scrum was when I realised that it wasn’t about story points, velocity, Fibonacci numbers, and the like. Although tools like these do seem to work effectively enough for some people, others find them a recipe for (i) busywork or (ii) setting teams up for regular disappointment, making them a popular target for sniping. Rightly, there is no mention of them at all in the guide.

The guide instead talks of the sprint backlog as both a set of items selected for the sprint, and – crucially – a plan for delivering them. And get this: the sprint backlog is subordinate to something else, the sprint goal:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Imagine you’re working in an organisation that typically takes months or even years to deliver anything of note (I exaggerate not). Now give people the chance to work together on achieving a meaningful goal in a matter of days. And again. And again. That’s powerful. Could that be done without Scrum? Does it happen without Scrum? Of course it could and of course it does, but Scrum is often the vehicle by which people experience this for the first time, and that’s something to celebrate.

I also have to give credit to Ken and Jeff for being explicit about Scrum’s applicability:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

I don’t highlight this quote as some kind of backhanded compliment, a way to put Scrum back into its box. The domain described here is huge! And it’s important for reasons explored in chapter 5 of the Agendashift book. To operate a Lean, Agile, or Lean-Agile process worthy of that name, you must embrace the idea that the often challenging, sometimes messy, and always necessary work of helping the organisation to change must be treated as real work, to be carried out not just alongside delivery work, but integral to it. The ‘complex adaptive’ part of that quote might be unnecessarily jargony but it refers to the inability of any linear plan to deliver this vital kind of change effectively (see my “Change in the 21st century” keynote).

Taking these together, Scrum working well means:

  1. Meaningful goals regularly met
  2. The system – the team and well beyond – evolving commensurately

That’s harder to achieve and even harder to sustain than it might sound, and the guide is honest about the level of challenge involved. What it leaves unsaid is that as soon as Scrum comes to mean ploughing through the backlog, these benefits become increasingly difficult to sustain. It’s why we find support in complementary tools such as Kanban, Lean Startup, and now Agendashift [1] when the returns from Scrum on its own begin to diminish.

2. The ugly: Things that should not be accepted at face value

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

There are so many better ways in which the Scrum Master role could have been introduced, and it beggars belief that this section could be edited (yet again) in the 2017 edition and left like this. After an ugly paragraph easily construed as ‘your first responsibility is towards Scrum’ we see a very carefully circumscribed kind of servant-leadership that will surely be read in the light of what precedes it. There are more charitable interpretations, but they depend on assumptions that aren’t made explicit.

To be a true servant leader, your responsibility is towards your colleagues, your organisation, your customers, other stakeholders, even towards society. Where by-the-book Scrum helps you in those responsibilities, fantastic. Where it gets in the way, it might be time to do something not by the book. A true master at Scrum might find these situations rare, but pity the conflicted rookie! Even if only in the context of these sentences, if it doesn’t bother you that Scrum Masters are certified after just a couple of days of training, it should.

If we want our industry to do better, we have to look at its systems, ready to challenge a status quo that tends to preserve itself. Scrum has been around long enough to qualify for that kind of scrutiny and whatever their true intent, these widely-read sentences are too open to a cynical, self-serving interpretation.

In response to my tweet yesterday morning, Neil Killick was quick with this much better alternative:

With all due respect to Neil, that wasn’t so hard, was it?

3. How I approach it

I start from the perspective that Scrum describes some pragmatic solutions to common problems. Do you have multiple customers, far removed from the team? Then you’ll find it helpful to have a highly available Product Owner. Do you need someone to model and facilitate appropriate practices and behaviors? Then bring in a Scrum Master. Are your feedback loops too slow relative to the rate of environmental change? Then plan your work to fill short timeboxes and meet daily.

Conversely, if you don’t have all of these problems, you might not need Scrum. At the very least, tread carefully:

  • Don’t place obstacles between a team and its customers if they’re already collaborating (yay, manifesto values!)
  • Don’t add layers of process and ceremony where teams are already self organising effectively
  • Don’t allow Scrum’s timeboxes get in the way of rapid flow and rapid change – they needn’t [2], which is why I don’t present this as a technical objection to Scrum

Nice problems to have, you might argue. And well you might, which why I am significantly more pro Scrum than anti. But I don’t check in my experience, knowledge, or curiosity at the door. Where I see conflict between approaches, I dig deeper, fully expect to find agreement, and am usually rewarded handsomely.

For the most part, you can leave the self-serving stuff behind (I’ve learned to filter it out). If you are helping to bring clarity and agreement around purpose and goals (things Agendashift and the guide fully agree on), and if you start with needs, seek agreement on outcomes, and so on [3], it’s likely that you’re approaching things in a good way. As time passes you might find that things look less and less like anything you heard in class, but don’t let anyone shame you for that. Expert or rookie (and yes, tread accordingly), you’re responsible. You’re a leader!

[1] About Agendashift
[2] Scrum and Kanban revisited
[3] Agendashift in 5 principles

I’m grateful to Olivier My, Neil Killick, Johan Nordin, and Karen Beck for their valuable feedback on earlier drafts of this post.

While we here

Lean-Agile Strategy Days London (II) – 22-23 Nov, London, UK is just over a week away and there’s still time to book your place. Interested in Lean-Agile change and its relationship to strategy? You should be there! In case you can’t make both days, we’ve just added a strictly limited number of single day tickets.

5 key plays and how to accelerate them

In the context of a discussion about a scaling framework (it doesn’t matter which one), I was asked yesterday in the Agendashift Slack about recurring patterns I’ve seen or applied in my work in the and whether/how they’ve been affected by Agendashift.

For the sake of minimum argument, let’s say we’re already using both Scrum and Kanban at team level. Basic (and improving) processes are in place, work is visible, and teams are not massively overburdened. It’s not necessarily how I’d start but let’s call that easily-understood baseline ‘play 0’.

After that, here are five key plays from my playbook:

  1. Smooth/speed work through dev – often through managing dependencies better, identifying them before work starts, making them more visible, greatly reducing the appetite for starting work that can’t be finished
  2. Make the post-dev process more visible – make any issues there too visible to ignore
  3. Smooth/speed work through the post-dev process – better conversations at the start of the process (even before dev), better automation, better management of environments, etc
  4. Validation – retain ownership of work well past delivery, validating that the impact on user behaviour is as expected and that needs are being met
  5. Work on the team/organisation interface – risk management, change management, service delivery reviews (a favourite of mine), team sustainability (funding, recruitment, skills transfer, etc)

In what order? When do you do these things?

Of course it depends, but notice:

  • The need for plays 1-3 should become increasingly apparent to the teams themselves once play 0 has taken effect. More experienced teams are likely to notice the need for them sooner; the most experienced ones will not only contain people who know not only that bottlenecks move, but can guess in which direction (and they’re listed in the most common order). These changes happen fastest when they are encouraged and supported by people who know what to expect. An explicit drive towards continuous delivery is helpful, especially with regard to plays 2 and 3.
  • Unlike plays 1-3, plays 4-5 are unlikely to appear spontaneously through a process of introspection. They involve some important attitude changes:
    • Work is only truly ‘done’ when needs have been met (and demonstrably so)
    • It is recognised that the host organisation has needs too, and that unless you want live forever in a small Agile bubble, a certain amount (and style) of mutual accountability is healthy, not a threat.

If I’m working mainly at team level, it’s likely that the five plays will happen in roughly the order presented. Play 4 may involve developing some skills that the dev team might not have in abundance initially (user research & testing, service design, service management, etc). Play 5 may come a lot sooner if the right kind of sponsorship is in place, and it helps immensely if there are managers who can also be considered part of the team for at least these purposes (service managers, delivery managers and project managers in GDS projects, for example).

How Agendashift changes things

Let’s recast these plays as outcomes to be achieved:

  1. Work flowing smoothly through dev, dependencies managed well
  2. Effective management of the process end-to-end
  3. Good collaboration end-to-end and an effective technical platform for rapid delivery
  4. Proactive alignment of team and customer, more ‘right thing’ than ‘wrong thing righter’
  5. Proactive engagement between team and organisation, setting the tone, metrics consistent with values, better alignment overall

As soon as you have agreement on outcomes like these, the opportunity is there for the taking. Of course there are right ways and wrong ways of going about things (and Agendashift provides some help here), but as per my previous post, Getting to Agendashift’s “Why”:

Because when you have agreement on outcomes, the rest is “just” the how…

Agendashift creates the opportunities for outcomes like these to be articulated and agreed upon, even before deep-seated pain points are fully exposed, thereby accelerating the process. They can be tackled in sequence or in parallel, via off-the-shelf practice or innovation, with or without reference to frameworks. The choice is between you and those that you work with and for, defined to some degree by your role already or left open. Where choices are open, make best use of that opportunity: consider a diverse range of options and make progress by testing assumptions relentlessly (advice that works for product development too).

While we’re here

November 8th (tomorrow) is a key day:


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
):
8th Nov, Cape Town, South Africa22-23 Nov, London, UK

 

Agile and Lean are just toolkits, right?

Agile, Lean, Kanban, Scrum, SAFe, … plenty of tools to choose from, so why does ‘toolkit’ set my teeth on edge? Perhaps it puts me in mind of the journeyman worker who knows his tools but never really excels at anything.

To be more than a mere journeyman and to progress towards mastery, you need to know more than just the distinguishing features of each tool or body of knowledge. If I were looking for expert advice or inspiration I’d want to see:

  1. Some respect for how these different schools came into being, the conditions prevailing at the time, the problems being solved
  2. An understanding of the values and principles that explain their design choices and implementation strategies (and I don’t mean just being able to parrot them; values in isolation of practice are meaningless)
  3. An ability to describe their ‘lessons’ – key takeaways that you can apply non-prescriptively, perhaps using alternative tools

Some examples of these lessons:

  1. From Agile: the power of working collaboratively in carefully controlled chunks goes way beyond what you’d learn from studying psychology or queuing theory separately. It’s not magic (it’s easy enough to explain technically and it’s not hard to bring about) and there’s a positive reinforcement feedback loop there, one in which success breeds greater success.
  2. From Lean Startup and Kanban (bedfellows almost from their respective beginnings): make the processes by which you learn about your customers, your product, and yourselves as visible as you can make them. You make rapid progress by continually testing your assumptions about all three.
  3. From Scrum: don’t underestimate the value of rhythm. It’s not just the ritual and the predictability, it’s also the opportunities to achieve something meaningful in between (see lessons 1 and 2)

I’d love to see more of these. Can you describe a ‘lesson’ non-prescriptively?

Related:


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | AboutPartners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
):
8th Nov, Cape Town, South Africa22-23 November, UK

Scrum and Kanban revisited

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


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

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

(Non-)Prescription, frameworks, and expertise

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

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. 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-cover-thumb
Blog: Monthly roundups | Classic posts

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

Agendashift in 5 principles

Screenshot 2017-07-25 16.31.36

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:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. 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:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. 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.


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

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

Recommended reading

From the “behind the scenes” sections of each chapter of the Agendashift book (part I published on Leanpub in May) I’ve extracted a list of recommended books and other references.

By chapter, you’ll find reading recommendations on these topics:

  1. Discovery: Clean Language, 1-2-4-All (the facilitation pattern)
  2. Exploration: Cynefin, “plan on a page”
  3. Mapping: User Story Mapping, Impact Mapping, Strategy
  4. Elaboration: Lean Startup, A3, Toyota Kata
  5. Operation: Organisation, culture, Systems Thinking, Kanban

Find it here: Recommended reading. See also our Resources page. Enjoy!


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

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