A small departure from the book

Slightly technical, but if you’re interested in what we know to be a remarkably effective combination of Clean Language, Cynefin, and Story Mapping as practiced in most Agendashift workshops, read on…

One of the notable highlights of an Agendashift workshop comes when we take the list of outcomes generated by the 15-minute FOTO game [1], transcribe them onto stickies, and organise them 4-points style [2]:

cynefin-finished-2017-12-16

Through the experience of the ‘4 points contextualisation exercise’ (to give it almost its full name), participants are slowly introduced to the Cynefin framework [3], the facilitator trying all the while to avoid naming the model or using Cynefin terminology such as ‘obvious’, ‘complicated’, ‘complex’, or ‘chaos’ (trust me, it’s hard!). For participants familiar with the model, it’s always a funny moment when the penny finally drops and the realisation dawns that Cynefin can be so much more than just a conceptual model, especially when there’s a good supply of ‘narrative fragments’ – outcomes, in our case – to play with. For those that haven’t come across it before, it’s a great opportunity to explore why different kinds of outcomes need different kinds of approaches, a lesson that’s much more meaningful when it’s learned through interacting with your own data (‘sensemaking’) than it would be as a lecture.

Up to now – and as described in the book [4] – the translation from the Cynefin representation to one based on a story map has been a 2-stage process. First, a few minutes of organised chaos as stickies are moved to under their respective headings:

Second, as much time as we want to spend – anything from a few moments to an hour or more – prioritising stickies within columns, and through that process making sure that there is a shared understanding of what each of them means and their possible dependencies on other stickies. Anyone who has done story mapping before will recognise that this can provide an important opportunity for some valuable conversations; we’ve found this to be the case even in public workshops, with ‘teachable moments’ aplenty.

A refinement

Instead of the ‘organised chaos’ followed by prioritisation, work clockwise from bottom right, prioritising as we go:

  • Starting with the ‘obviously obvious’: Sticky by sticky, check that they really are obvious (ie we can all quickly agree what needs to be done and can be pretty sure of the likely outcome), put them in their correct columns, and prioritise. Prioritisation will be easy, as there’ll be at most a few per column, a mixture of quick wins and less important items.
  • The ‘borderline complicated’: For the items on the border between obvious and complicated, explore why they were placed there, and discuss what should be done about their non-obvious aspects (perhaps there’s some important detail that someone will need to get to grips with). Prioritise them relative to the already-prioritised ‘obviously obvious’ items in their respective columns (again, this should be easy)
  • The complicated, one sticky at a time: who might be delegated to run with this item? Should we get some external help? In its appropriate column, how does it prioritise relative to the items already there?

I could at this point say “and so on through the complex and chaos” but the facilitator will flag up here that anything in or bordering on complex is likely to be a good candidate for hypothesis-based change (a session later in the day, see also [5]), and so it’s a good idea to mark each item in some way so that they can be identified easily later. And for the borderline cases:

  • ‘Borderline complex’: Are the complicated and complex parts easily separable? How will we organise this, mainly linear with some room for refinement along the way, or mainly through iteration with some expert input or planned work at the appropriate time?
  • ‘Borderline chaos’: Is it urgent to address symptoms or or attempt some diagnosis now, or can we afford to wait until we see what’s thrown up in the course of other work?

I’ll be honest: it’s still early days for this change and there’s no slideware [6] for it yet – if any is needed we’ll learn that through practice and by partner demand. That’s usually the best way!

[1] 15-minute FOTO, our Clean Language-inspired coaching game
[2] Cynefin Review Part 7 – Finding Your Place on the Framework (adventureswithagile.com)
[3] The Cynefin framework (wikipedia.org)
[4] Agendashift: Outcome-oriented change and continuous transformation, Mike Burrows (New Generation Press, 2018), chapters 2 and 3 in particular
[5] The Agendashift A3 template (and chapter 4)
[6] The Agendashift partner programme

Finally, some opportunities to experience it for yourself:


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…

You can’t deliver a task

As suggested in the July roundup, this is the first of a few posts expanding on tweets that have sprung to mind while writing (or thinking about writing) my third book, working title Right to Left: The digital leader’s guide to Lean and Agile.

Years ago, in my past life as a manager (which I still re-enter from time to time as an interim), I learned that there was little value in me tracking tasks. What mattered to me was the deliverable. Interestingly, I noticed that when I visibly stopped taking an interest in tasks, most of my team members followed suit. I said “It’s completely fine by me to tasks on the board if that’s what works for you, but I’m not going to ask about them”, and soon the task stickies disappeared.

As a team, we made rare exceptions for features that failed our “2 day rule”, which is to say features that at a very rough guess would require more than a couple of days worth of development. Experience taught us that these were disproportionately risky, so it seemed justified to insist on some kind of plan. Of course what actually happened was that most of these big features got sliced into smaller features, and then everyone’s happy to go back to feature-level tracking.

Stop tracking tasks, and no longer does the tracking system drive the developer to work in a way that doesn’t seem natural. A bit over here, a bit over there, then back to the first bit… if the tests say it’s fine, it’s fine! Two people with different skills working together on the same feature? Go for it! And at a stroke it eliminates the anti-pattern of “tasks for quality” – ie separate tasks for unit tests, refactoring, and the like (in the global department I ran more than a decade ago, these tasks disappeared when I asked why these things weren’t happening as the code was being written; I guess my predecessor didn’t see things in quite the same way).

And then there’s the whole question of when a task can be said to be “done”. How do you that some low-level piece of work is really done if the feature as a whole isn’t yet working? Somehow I think that this may have come up before….

Screenshot 2018-05-05 06.23.15Our handy, referenceable, Definition of Done

Public workshops (US, UK, IT, DE)


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…

‘Right to Left’ works for Scrum too

Update: See the landing page for the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile (due summer 2019)

Here’s a conventional, left-to-right [1] description of Scrum:

A Product Backlog (all the stuff we’d like to do), a Sprint Backlog (the stuff we plan to do this sprint), then a Sprint (a timebox) that culminates in a potentially shippable increment, a review, and a retrospective. Rinse and repeat.

To me, this is how NOT to describe Scrum. Is it a straw man, put up just so that I can knock it down? Hardly! Not all descriptions of Scrum follow this narrative, but it’s common enough. Complete with a video, here’s a nicely-produced example from a reliable source, the Scrum Alliance: Learn about Scrum (web.archive.org). It’s one of the first pages returned by Google in response to the question “What is Scrum?”.

The bullet points below are the first few from that page’s 30 second summary, and they’re very close to the commentary on the video:

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.

If you wanted to describe Waterscrumfall, would you describe it any differently? Perhaps “the team is arm-twisted into pulling a implausibly large amount of work into the sprint (or the project manager helpfully does it for them)”, but little else changes.  Would it help if the process description were prefaced with mentions of agility, complexity, and so on? That must depend on the reader’s frame of reference; if they don’t share our understanding of those words, they’re just noise.

Let’s try a right-to-left description:

A Scrum Team moves towards its Product Vision goal by goal, the team collaborating around a shared goal for a timeboxed interval called the Sprint, at the end of which the team reflects on how well the Sprint Goal was achieved before it prepares for the next one, organising around a new goal. The team’s best understanding of the work required to achieve the Sprint Goal is represented by a Sprint Backlog; options for future sprints are maintained in a Product Backlog.

The same process, yet so different, and with much less room for misinterpretation. This – I think – is much more like the Scrum that people love. Do you agree? Would you describe it differently?

Thanks to Steve Porter and Thorbjørn Sigberg for their feedback on earlier drafts of this post.

[1] Understanding Lean-Agile, right to left

Suppose you had to understand Lego – and I mean really understand it. Where do you start? With children playing, or with plastic feedstock?


Upcoming workshops


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…

How the Leader-Leader model turns Commander’s Intent upside down

If you’ve heard me speak in recent months, it won’t come as a surprise when I say that L. David Marquet’s Turn the ship around! [1] has become a favourite book. It’s the story of how Marquet, a US Navy captain, turned around a poor-performing nuclear submarine with its crew, taking it from “worst in fleet” to “first”. I can also recommend the audiobook, which is narrated by the author himself.

51inQ8o4t9L

Commander’s Intent [2] is an important model from the military which (rightly) receives attention in business circles. In this model, leaders make a habit of expressing objectives and the rationale for them, controlling the urge to specify in detail how that objective should be achieved. In short, the what and why, not the how. As explained in Stephen Bungay’s The Art of Action [3], it was developed in the 19th century by Carl von Clausewitz, a general in the Prussian army, and has since become firmly established in military doctrine around the world.

Marquet turns Commender’s Intent upside down, but in so doing proves its point!

Suppose now the intent is expressed not by the leader to a subordinate, but by someone under their command and in the other direction. That person is showing initiative, might even be attempting something innovative. The commander has a choice: to trust them to get on with it, to provide support, or to suggest alternative course of action. Either way, they are mutually accountable, the one for his or her actions, the other for providing an appropriate level of support (in a context in which safety is paramount). If you can establish these leader-to-leader conversations as a new habit, then through countless such encounters and through essentially unlimited opportunities for people at every level of the organisation to show leadership, the organisation grows.

Marquet’s ultimate intention was no different to Clausewitz’s – to turn an organisation stuck in the ways of the past and barely fit for the present into one capable of thinking for itself and innovating its way into the future. Understand Commander’s Intent in those terms and Marquet’s Leader-Leader makes perfect sense.

How frequent are the opportunities for statements of intent in your organisation? Do colleagues (whether seniors, peers, or otherwise) both offer appropriate support and hold each other to account when intent has been expressed? It’s a great way for people and teams alike to grow in capability and for leadership to develop.

This post is the third in a series of three, introducing three core themes to be developed in my next book (my third, out I hope about a year from now in early summer ’19) :

  1. Right to left: the effective organisation – see Understanding Lean-Agile, right to left
  2. Outside in: the wholehearted organisation – see Towards the wholehearted organisation, outside in
  3. Upside down: the supportive organisation – this post

Working title (as of this week!): Right to left: A leader’s guide to Lean-Agile.

Meanwhile, the Agendashift book [4] is a book not about Lean-Agile but about outcome-oriented change. It is steeped in those themes, but by design it assumes them more than it explains them (though they begin to become explicit in the final chapter). If you like, Right to left is Agendashift’s prequel. Join us in the #right-to-left channel in the Agendashift Slack to monitor progress and to discuss any of these three themes.

[1] L. David Marquet, Turn the ship around!: : A True Story of Building Leaders by Breaking the Rules (Portfolio Penguin, 2015)
[2] Commander’s Intent (en.wikipedia.org)
[3] Stephen Bungay, The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results (Nicholas Brealey Publishing, 2010)
[4] Mike Burrows, Agendashift: Outcome-oriented change and continuous transformation (New Generation Publishing, 2018)


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…

Towards the wholehearted organisation, outside in

It’s one of those often-cited, non-enough-read books, Christopher Alexander’s The Timeless Way of Building, the classic book on architecture and the built environment that inspired the patterns movement in software (think Gang of Four Design Patterns, PLoP, etc).

It’s a rewarding read – philosophical in a way that is both surprising and delightful, and (whether intended by the author or not) full of ideas that are just asking to be carried over to other domains. I read it with organisation design in mind.

This favourite quote isn’t specific to building but it is loaded with metaphor:

Screenshot 2018-05-26 11.52.59

It got me thinking that I would love to be known for being in the business of helping organisations to be more wholehearted – less at war with themselves, their contradictions identified and owned so that they can be resolved in some pleasing way. If squeezing out excess work-in-progress is a key strategy for improving our delivery processes, perhaps squeezing out the contradictions is the way to improve our organisations for the mutual benefit of all concerned.

In my keynote talk Inverting the pyramid, I use this quote to introduce a section on outside-in reviews – for example the strategy reviews and service delivery reviews that follow the kind of outside-in agenda as described in chapter 5 of the Agendashift book:

  1. Customer
  2. Organisation
  3. Platform
  4. Product
  5. Team

Juxtaposing these different perspectives – each one presented by the people who are best equipped represent them – increases our chances of not only bringing our inner contradictions and misalignments to the surface, but of finding better ways to meet external needs too. Within each agenda item, a right-to-left [1] structure: what we’ve recently learned about how things are, what we’re beginning to learn through experimentation, and what experiments we plan to conduct as capacity permits.

Some context and an invitation: As mentioned a few days ago, I have just begun work on my third book: a no-nonsense, leader’s guide to Lean-Agile, organised around the three themes of right to leftoutside in, and upside down. Join us in the #right-to-left channel in the Agendashift Slack to monitor progress and to discuss any of these three themes.

Related posts:

[1] Understanding Lean-Agile, right to left


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…

Understanding Lean-Agile, right to left

Suppose you had to understand Lego – and I mean really understand it. Where do you start? With children playing, or with plastic feedstock?

 


Now suppose you had to understand Lean-Agile. Where do you start? With people collaborating over software that is already beginning to work for its customers, or with backlogs and projects? Working software, or JIRA?

With the Agendashift book [1] only just out of the door, I’ve begun work on the prequel, a no-nonsense guide to Lean-Agile, the kind of book you’ll give to your manager and hope that they’ll pass on to theirs. And yes, we’ll start right to left, beginning at the point where needs are met [2] and working our way upstream. We’ll describe what it’s like to have Lean and Agile already working well, and demonstrate powerful ways to understand, manage, and improve almost any kind of delivery process.

There’ll be two more themes: outside in and upside down; more on those soon. Join us meanwhile in the #right-to-left channel in the Agendashift Slack [3] if any of these themes are of interest to you. Perhaps you have relevant examples or models that support these themes, or are already beginning to wonder about how they might be applied in your current situation and have questions.

[1] Agendashift: Outcome-oriented change and continuous transformation
[2] My handy, referenceable Definition of Done
[3] Agendashift on Slack


Upcoming Agendashift workshops:


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…

My handy, referenceable Definition of Done

Now in handy, referenceable [1] form, my working definition of “Done” [2]:

Done

[1] agendashift.com/done
[2] A good working definition of “Done”, also Better user stories start with authentic situations of need

Handy links to closely-related resources:

  • agendashift.com/book – chapter 3 in particular
  • agendashift.com/true-north – “…needs met at just the right time”
  • agendashift.com/principles – Start with needs” is principle #1

Upcoming Agendashift workshops:


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…