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…

#RightToLeft works for Scrum too

Here’s a “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…

Emergence, Fast and Slow

One word that came up a few times in last week’s workshop (which got a 12 out of 10 by the way) was emergence. It’s a funny kind of word, one that gets some people excited and leaves others completely cold. That’s due in part to its scientific overtones, but there’s more to it than that.

In its slow form, emergence – as in emergent architecture for example – is regarded as a close cousin of evolution, a process whose results (structures, phenomena, properties) emerge from the repeated application of certain rules and constraints. Done deliberately, it looks something like this:

  1. We start where we are, with what we do now, or with a simple but probably inadequate design
  2. We wait until we’re dissatisfied somehow with the status quo
  3. Following some defined rules and keeping within certain constraints, we make what we hope turns out to be a step forward
  4. Rinse and repeat (starting with a new what we do now)

To its fans, it’s reliable way to cause a design to become increasingly fit for purpose – even when the environment around it is continually changing. Two things come with experience of the process:

  • Confidence in the outcome – the details of which aren’t planned in advance but familiar patterns and consistent properties do tend to repeat themselves
  • The realisation that the process can be guided and accelerated, for example using transparency to promote the activations of steps 2 and 4

Unfortunately, to those that haven’t experienced it, emergence and evolution can be a tough sell (which is why I don’t talk about them much). To some ears, these words evoke a process that’s highly wasteful and almost geologically slow, involving speculation, dead ends, and highly unpredictable outcomes. To others, it looks passive and directionless, change happening only in response to external pressures. No-one wants their organisation to go the way of the way of the dinosaur, and when proactivity is called for, it seems safer to stick to planned approaches with their up-front commitments and rigidly defined outputs – never mind that outputs and outcomes are two very different things!

I’ve hinted that in expert hands, emergence can be speeded up. Sometimes it can be very rapid indeed. Take for example the process we facilitate in Agendashift’s Discovery and Exploration activities through our 15-minute FOTO game:

  • Seed the process with a list of obstacles – things that block our path toward our generic True North (for Discovery), impede progress towards specific prompts prioritised from one of our assessments (for Exploration), or some other list
  • Identify the outcomes that lie immediately behind those obstacles
  • Identify the outcomes behind those outcomes, repeating through several layers, searching deeper and wider into outcome space

At Friday’s workshop we calculated that we were generating outcomes at a rate of nearly 2 per minute per table group. Two table groups were able to produce nearly 60 in just 15 minutes! As facilitator, I can’t predict what specific outcomes will be generated (I’ve stopped trying), but I’ve done it enough times to know that it’s a highly productive process, and that what emerges with the detail is a shared sense of both agreement and ambition. That’s gold!

Agendashift’s tagline is “Outcome-oriented change and continuous transformation”. With apologies to Daniel Kahneman, this is “Emergence, Fast and Slow” – the rapid emergence of agreement on outcomes and the emergence of a fitter, more adaptable organisation in the focussed follow-through. Agreement without the follow-through would of course mean the waste of a few hours or days of work. A much greater waste would be to implement change in the absence of agreed goals, the committed support of the host organisation, and the meaningful engagement of the people affected. They need each other!


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 evolution 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…