A Grand Unification Theory for Lean-Agile?

The job of chapter 3 of the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile is to introduce a number of important Agile, Lean-Agile, and associated frameworks. I have taken care to describe them not as alternative solutions that must be chosen between, but as patterns to be combined in interesting ways. That’s not a new idea, but what does seem remarkable is how helpful a right-to-left perspective is in explaining how they work together and complement each other. When I say right-to-left, we’re talking not just collaborative, continuous, pull-based, and so on (concepts conventionally associated with Lean-Agile) but something very explicitly outcome-oriented.

Almost verbatim from the manuscript:

  1. Scrum (and Scrum-based scaling frameworks, if that’s your bag): continuously iterating on and self-organising around goals (short term outcomes) in the pursuit of longer term outcomes – product vision, the team’s mission, broader organisational objectives, and so on
  2. Kanban, making progress on outcomes visible, concentrating effort on the ones that matter most, fostering a focus on completion
  3. XP and DevOps, right across development and production, providing the infrastructure of process, practice, and technology necessary to accelerate feedback on the delivery of outcomes
  4. Service Design Thinking (along with user research, user experience and so on), continuously discovering which outcomes are important
  5. Lean Startup, pursuing business viability through continuous deliberate experimentation, managing for impact (outcomes again), finding and continuously refining a business model that enables customer outcomes to be sustained

Here it really is outcomes that holds everything together, not (as you might expect) flow, collaboration, or some other shared value or technical principle. This way, we avoid saying “if you dig deep enough, they’re the same” (which I hear from time to time and strongly reject, believing that it does each framework’s creators and communities a huge disservice).

Neither are we saying “don’t use frameworks”, if (and it’s quite a big if) this means that you must always start from first principles. A sensible way to start is again outcome-oriented and has a measured and pragmatic attitude towards frameworks (quoting this time from chapter 4, Viable scaling):

  • Identify needs – looking at what kind of organisation you’re trying to be and at what you’re trying to achieve  – and the obstacles that currently prevent those needs from being met
  • Agree on outcomes, not just goals plucked out of the air, but the kind of outcomes that might be achieved when these obstacles are removed, overcome, or bypassed
  • On a just-in-time basis, prioritise outcomes and generate a range of options to realise them, using your favourite frameworks as sources of ideas (not excluding other sources, but valuing coherence nevertheless)
  • In manageably small chunks of change and through a combination of direct action and experimentation (choosing between those approaches on a case-by-case basis according to the level of uncertainty and risk involved), begin to treat change as real work: tracking it, validating its impact, and reflecting on it just as we would for product work

In a nutshell, I’ve described Agendashift, which is of course a right-to-left approach to change and transformation. Other engagement models exist – see OpenSpace Agility (OSA) for another excellent, well-documented, and highly complementary example. Whichever approach you choose, take care to choose one that models Lean and Agile values, lest the dissonance proves too great and you fatally undermine your work, a very real risk. To sow disengagement would be a truly bad outcome!

Related:


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, US*2, UK, Netherlands):

Also: Channel #agendashift-studio in the Agendashift Slack if interested in a cozy workshop with me at Agendashift HQ (Derbyshire, England).


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

 

Rejection, insight, and learning

Two questions:

  • When did you last reject an idea as a result of deliberate testing?
  • What did you learn in the process?

And a followup question:

  • How does your process encourage that kind of rejection and learning to happen?

If your process doesn’t keep asking the right questions, you can be pretty sure you’re over-investing either in stuff no-one needs, or in changes that won’t deliver the organisational benefits you expect. But if you program in the time to reflect on your rejected ideas (however sporadically they’re currently happening), the rest might just follow.

Here’s how at the end of the Changeban [1, 2] game we model that reflection and introduce two key concepts: the hypothesis and double-loop learning [2] (notice the two levels of learning identified by the red callouts):

changeban-retrospect-on-experiments-2018-12-03

In theory, if you have an organisational design that encourages double-loop learning, the rest of your process will soon catch up. In my experience however, it’s rare to see it outside of those organisations that haven’t already chosen to pursue a hypothesis-driven, outcome-oriented, ‘right-to-left’ kind of delivery process.

For example, heavily ‘projectised’ organisations typically learn painfully slowly. This is only partly explained by the fact that they do everything in large batches that take a very long time to process. There are deeper issues:

  • Once the scope of a project has been decided, the mere thought that there might be more needs to discover and respond to is often actively discouraged. If discovery happens at all, it is done by people outside the delivery team in preparation for future projects, greatly limiting the opportunity to integrate new learning into current work.
  • Similarly, when the ironically-named ‘lessons learned’ meeting finally arrives, it is already too late for the project in question to test any proposed process changes, and it’s unlikely that other projects will be ready to do much with the insights generated either.

Not that Agile has this stuff completely sorted either:

  • Backlog-driven Agile projects (four words that will never gladden my heart) remain susceptible to the scope problem, and typically they don’t make a habit of framing individual pieces of work in ways designed to invite challenge
  • Even where the delivery process is a good generator of insights, team-centric Agile tends to limit the organisational scope of any learning

In Right to Left [4] (due summer 2019) I will describe a style of delivery organisation that has i) managed to let go of that old left-to-right kind of thinking, and ii) explicitly created not just opportunities for organisational learning to happen but the clear expectation that it will will be happening all of the time, a natural part of the process, and ‘real work’.

Fortunately, there are enough real-world examples of right-to-left thinking out there that I know that it is no idealistic fantasy. Neither is it a doomed attempt to shoehorn diverse experiences into a single and over-complicated delivery framework or to extrapolate from the experiences of just a few. Rather, the right-to-left concept represents a concentrated essence of Lean, Agile, and Lean-Agile working at their best, a helpful metaphor, and a unifying theme, one that allows me to celebrate a wide range of models, tools, and examples. Each of those is unique and special, but a commitment to learning connects all of them.

In the meantime, don’t forget Agendashift [5, 6]! This is no stopgap, but rather an approach to change and transformation through which that same right-to-left philosophy runs very deep. If you’re in the business of change in what could broadly be described as the Lean-Agile space and are hungry for alternatives to 20th century change management, the book and the tools it describes could be just what you’re looking for.

[1] Changeban (www.agendashift.com)
[2] Changeban has reached version 1.0 (blog.agendashift,com)
[3] Double-loop learning (en.wikipedia.org)
[4] Right to Left (www.agendashift.com)
[5] Agendashift: Outcome-oriented change and continuous transformation (www.agendashift.com)
[6] Agendashift (www.agendashift.com)


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, Netherlands):


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 kind of Agile

I’ve alluded to my kind of Agile in previous posts, but let me spell it out. I’ve hinted at it for quite a while, most recently in my popular post Right to Left: a transcript of my Lean Agile Brighton talk, which helps to explain the necessity and urgency of a Right-to-Left treatment of Agile.

I’m in the process of reworking the second chapter of my 2019 book Right to Left: The digital leader’s guide to Lean and Agile. Verbatim, here’s a key passage from chapter 2, Right to left in the digital space:

In chapter 1, we saw some of the quite different ways in which Lean is understood. Before we get to Lean-Agile, let me describe my kind of Agile, a kind of Agile that should already sound familiar:

  • People collaborating over the rapid evolution of working software that is already beginning to meet needs, their teams placing high value on collaboration, continuous delivery, and adaptation

That’s my highly condensed and “from-the-right” summarisation of the Agile Manifesto (agilemanifesto.org), describing a sweet spot for digital, and widely applicable elsewhere[1].

If you want to know what Agile is, the manifesto is where you need to start. Agile isn’t a defined process, method, or framework; Agile means embracing manifesto values. To embrace them you must understand them, and to understand them you must catch something of how they reveal themselves in environments that have allowed them to flourish.

Clearly, the manifesto values resonate with many. Meaningful conversations, the opportunity to build things that actually work for people, and the ability to keep improving the working environment to the mutual benefit of developers, customers, and the organisation – who wouldn’t want that? In other words, these things are valued for their own sake (which is why we recognise them as values).

For a values system to be more than just wishful thinking, there must be a clear relationship between the values, the kinds of behaviours expected, and the assumptions that underpin these behaviours. In the case of Agile, these assumptions are well documented – not least by the manifesto itself – and they go a long way to describe the behaviours:

  • Assumption 1: Direct, ongoing collaboration with customers is necessary to develop and maintain a mutual understanding of needs and potential solutions
  • Assumption 2: Collaboration across the entire process is what makes the whole greater than the sum of its parts – not just multiple perspectives brought to bear on complex problems, but new ideas created in the interactions between people
  • Assumption 3: The most effective way to build anything complex is to start with something that works[2], and ensure that it still works as it evolves. This is true not just for products, but for the working environment in terms of its technical infrastructure, processes, practices, organisation, and culture (not to mention all the complex interactions between those all of those internal elements, the product, and the outside world).
  • Agile’s breakthrough comes from bringing these assumptions together to everyone’s attention in the form of a compelling values statement. The underlying message is clear: wherever those assumptions are likely to hold, you would be wise to behave accordingly!

[1] I would stand by this definition outside of the digital space too and would argue that it is far more achievable than some would admit. But that’s outside the scope of this book.

[2] See Gall’s law, en.wikipedia.org/wiki/John_Gall_(author)#Gall’s_law, and John Gall’s rather wonderful book Systemantics: How Systems Work and Especially How They Fail (Pocket Books, 1978).

How does this resonate with you? Is there anything there that you would challenge?

The book is due early next summer; if you’d like to stay on top of developments and perhaps even get involved:

  • Subscribe to updates via the book’s landing page here
  • Join the Agendashift Slack community and its #right-to-left channel, the place for book-related conversations
  • On Twitter, follow @Right2LeftGuide &/or hashtag #Right2LeftGuide
    (Note: I’ve only just stopped using the more generic hashtag #RightToLeft, so don’t expect to find much at the new one just yet. I’ve renamed the account accordingly.)

Screenshot 2018-11-16 10.40.57


Upcoming public Agendashift workshops (Germany * 2, India * 2):


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…

Dealing with internal contradictions – if they can’t both be true at the same time, then what?

From my post Towards the wholehearted organisation, outside in (May 2018):

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 the draft of the Outside In chapter of Right to Left (2019) I’ve included a version of the above paragraph together with the Christopher Alexander quote that inspired it. However, it seems wrong for the book to raise the prospect of bringing contradictions out into the open without also suggesting some constructive ways of looking at them.

The key question in a nutshell: If X and Y can’t both be true at the same time, then what?

On the premise that it can often be helpful to make explicit the thought processes that lead to our decisions, (perhaps as an aid to creating an agreed precedent or policy for next time), I offer a breakdown of the main ways in which contradictions get resolved. If I’ve missed any important combinations or references, do please let me know!

X and not Y

  • X achieves our goals better (in some defined way) than Y
  • Y does not align with strategic objective, mission, or core purpose X
  • Y is incompatible with core value X

Caution: Whilst it may be good to exclude Y, it’s possible that this decision says little about the merits of X, which may not be better than other alternatives (including doing nothing).

X and not yet Y

  • X naturally precedes Y / Y depends on X
  • X is more urgent than Y / X has a higher opportunity cost than Y (see also Cost of Delay)
  • X has higher priority than Y (because reasons)
  • We choose X to precede Y (because reasons)

Similar cautions apply. Y’s deferral may not justify X starting. And might Y be deferred for so long that it ought to be taken off the table entirely?

An important variation on the first one that an outside-in review might generate: Not Y because we don’t have capability X, the X not previously identified. Begs the obvious question: should we make it a priority to build capability X?

Neither X nor Y, but Z

  • Some higher objective Z either delivers X and Y or renders them unimportant
  • Some prerequisite objective Z comes first, or in other words, Z and not yet X and Y
  • Z as an alternative to X and Y – superior in some way, a better use of our time

X and Y

  • Creative tension: contradiction as a motivation for innovation (see TRIZ)
  • Perhaps, after challenging the assumptions of the apparent contradiction, we can demonstrate that X and Y aren’t necessarily in conflict (see Evaporating Cloud, one of the six Thinking Processes in the Theory of Constraints)
  • Conflict felt at a personal level, needing mediation perhaps

Caution: Beware the cop out, dodging the difficult decision…


Upcoming public Agendashift workshops (Italy, Germany * 2):


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: a transcript of my Lean Agile Brighton talk

Friday was Lean Agile Brighton, a chance to catch up with friends in the community after the 3-day Brighton workshop with Karl. Here, from memory, is a rough transcript of my talk, the last one of the day (giving me the opportunity to refer back to other speakers), and just 20 minutes long. I don’t often do talks this short, but it was fun! 

PS Over the weekend, I knocked up a cover for Right to Left (the book). It’s in the first slide below, also at agendashift.com/right-to-left, where you’ll find an overview.

Slide01

Like Sal [Freudenberg, @SalFreudenberg, the previous speaker] I’m getting all misty-eyed about coming back to Brighton. My wife’s a Brighton girl, and my first job out of uni was in Lancing, just just down the road from here. My wife’s first boss later became mine (though not at the same time), and he’s in the audience today. Hi Peter! Thirty years!

Another reason to be excited: so many collaborators and influencers here: Karl [Karl Scotland, @kjscotland, one of the conference organisers] Steven [Steven Mackenzie, @busywait], and Liz [Liz Keogh, @lunivore] to name just three.

And I get to meet Caitlin [Caitlin Walker, @caitlinwalkerTA, opening keynote speaker] face to face at last! Her book [From Contempt to Curiosity] was quite an influence on the Agendashift book.

As I talk with colleagues and as I write my third book [see agendashift.com/books and agendashift.com/right-to-left], I detect a convergence: things happening in the Agile world that have long frustrated us but were hard to pin down we now have names for. And that’s good – instead of just complaining, we can begin to find solutions! Look out for couple of those in my talk today.

Slide02

Who here is a Lego fan?

Wow, that’s a lot of hands!

Slide03

If you had to describe Lego, where would you start? On the left with truckloads of plastic granules arriving at the Lego factory, or with children playing with the finished product? Plastic feedstock, or children playing? From the left, or from the right?

From the right of course.

Slide04

Let’s try that with Agile. Where would you start? On the left with backlog items in Jira* (*other tracking tools are available), or on the right with people collaborating over working software that’s already beginning to meet needs? Backlog items in Jira, or people collaborating over working software. Left or right?

Yes, from the right again. You have to wonder though… How often do you hear Agile explained from the left, starting with backlogs, item sizing, and stuff? Rather too often. That’s a problem! It’s very easy to completely miss the point when you start from the wrong perspective.

Slide05

We can do this with Scrum too. On the left we have the two levels of backlog, planning events, and so on. On the right: shared objectives pursued goal by goal.

Here we have two very different descriptions of Scrum, yet both of them entirely compatible with the Scrum Guide. And there are two mindsets represented here. Which mindset is the one more likely to encourage self-organisation, engagement, and innovation? The one that thinks mainly from the left, or the one that thinks from the right?

Again right, no question. Why then do we mostly hear the “from the left” version? Why do goals seem to be treated as though they’re some kind of advanced concept?

Slide06

Now to SAFe, and it’s almost identical: n levels of backlog (where n is a parameter determined by the height of your SAFe poster), planning events and so on (very much like Scrum), or shared objectives pursued goal by goal (the wording here is identical to the previous slide, and it’s 100% compatible with SAFe).

I ask again: Which mindset is the one more likely to encourage self-organisation, engagement, and innovation? The one where progress against plan is closely tracked by the PMO, or the one where teams are encouraged to self-organise around goals?

You’re with me: the one on the right.

I’m not a SAFe user myself, but friends of mine in the SAFe community whose opinions I respect tell me that this tension is already beginning to be acknowledged and discussed in the SAFe community. Some implementations are more one way than the other; sometimes different people on the same project take a different view. Awkward!

Slide07

We’ve done Scrum and SAFe but I’m not quite finished with this pattern yet. Let’s try it with Agile adoption. What’s your kind:

  • Here on the left: Prescribe a solution (or have it sold to you), justify it (manufacturing an inauthentic sense of urgency), roll it out regardless of what people think, and deal with the consequences: the resentment, the cynicism, the disengagement (which is very hard to undo once it’s there), not to mention the realisation that much time has passed, the world has since moved on, and we’ve got to do it all over again! Maybe that sounds a bit like a caricature, but from the nods I’m seeing around the room, I know that this hits pretty close to home for some of you.
  • And here on the right: Agree on some outcomes (a process we’re well practiced now in facilitating), generate some options (based perhaps on expert advice, but perhaps you’re already capable of more than you initially realise), and start to test some assumptions. Who here has worked with Lean Startup? [A few hands go up]. At least somewhat familiar with it? [Several more]. You’ll know that the way we make progress is by relentlessly testing assumptions, and trying to do it in such a way that we often realise some business value in the process. It’s the main engine of progress in Lean Startup, and also a great model for change. Do that for a while and change becomes part of the day job, real work done by real people, not spare-time work, hobby work, or something to outsource.

So which is it? Left or right? I hardly need ask.

The brokenness of that left-to-right model is a serious issue. Here for example is Martin Fowler [@martinfowler], a signatory of the Agile Manifesto:

Slide08

[See agendashift.com/engagement-model]

That’s quite recent, in a 2018 State of Agile Software keynote. But he’s been consistent about this over the years: teams must have choice in their process.

Slide11

[Again: agendashift.com/engagement-model]

Let me highlight this term, Engagement Model. When Daniel Mezick used it in the foreword to my book, I knew right away it was an important term, one that I might perhaps have run with in the book if we weren’t just about to go to print! It’s something I also recognised in Caitlin’s work – in fact the way she deliberately went about discovering and iterating on her engagement model is one of her book’s main threads, even if the phrase itself isn’t there. Of course whether they’re explicit about it or not, every Agile supplier has some kind of engagement model; the question is whether their model does what Daniel’s definition seeks: promoting staff engagement rather than destroying it (creating the kind of disengagement we heard about earlier).

There is a third level to this engagement model thing, and it’s the focus of some of the excited conversations I’ve had with Liz and other collaborators like those I mentioned at the start. As I said, I think we’re converging on something. It’s about teams, as they transform, engaging constructively with their surrounding organisations, not saying “don’t bother us, we’re busy being Agile”. We want both sides to thrive! Hunkering down might make sense for a short while as teams are trying out radically new ways of doing things, but to normalise this attitude is a disaster! How is that going to encourage the organisation as a whole to develop? What we need – and it’s something that Liz said in her talk too – are collaborations and feedback loops that deliberately span organisational boundaries, and we have some great patterns for that. The opportunity is enormous – think just of the opportunities created by cross-boundary participation in strategy, for example.

We have only a few minutes left but I want to give you a taste of what an overtly right-to-left and outcome-oriented approach to change can look like. And based on what we’ve experienced over the course of the day, it’s going to feel surprisingly familiar.

We’ll start with this True North statement:

Slide12

[See agendashift.com/true-north]

Let’s pause for a few moments pause to take that in.

You might remember “Working at your best” from Caitlin’s talk; in my book I give full credit to Caitlin for the inspiration.

Now, to get the conversation started, a question for your neighbour.

Slide13

In pairs: What obstacles do you see in the way?

You’ll recognise question 2 – it was one of the Clean Language Language questions we heard in Caitlin’s keynote:

Slide14

With your neighbour, and with respect to the obstacles you identified: What would you like to have happen?

We’re starting a process Caitlin described as “modelling a landscape”; here we’re modelling a particular kind of landscape, a landscape of obstacles and outcomes. We could dig into the obstacles, but instead we’re going to go deeper into outcome space – it turns out this is a much better use of our time (quick book plug: Solutions Focus):

Slide15

In your pairs: Then what happens?

People sometimes say to me “Oh, this is the 5 Whys!”. In a way it is, but here we’re going forwards into outcome space, not backwards into obstacle space. But now that we’re on the subject, I have to tell the 5 Whys joke:

Q: Why are the 5 Whys called the 5 Whys
A: Because with the 6th Why you get a punch in the face

We could break a relentless line of questioning with a different choice of question, perhaps one of the questions Caitlin introduced to us this morning. But let’s risk it:

Slide16

In your pairs: Then what happens?

Slide17

[See agendashift.com/15-minute-foto]

What we’ve done here is a super-quick, stripped-down version of our Clean Language coaching game, 15-minute FOTO. We’ve open sourced it, so you can download everything you need to play the full version. We do it in table groups of around 4 people, and in just 15 minutes, each group can easily generate 15 or more outcomes. Across a few table groups it can generate loads – it’s really effective.

Slide18

[See agendashift.com/overview]

In our workshops or as part of a longer engagement we actually use it twice: once as part of Discovery, to help explore our ambitions and aspirations, and for a second time in Exploration when we’re looking for the opportunities to take forward.

Slide19

[See agendashift.com/done]

I’m done, at least in the sense that my 20 minutes are up. I hope that someone’s need was met. Thank you very much.


Upcoming public Agendashift workshops (Italy, Germany * 2):


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…

Continuous Delivery demands Continuous Discovery

This is the second of an informal series of posts suggested in the July roundup,  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. In case you missed first one: You can’t deliver a task.

Tweet #2:

Do you recognise this pattern?

  • We get somewhat good at building stuff
  • Later,  we get somewhat good at testing it
  • Later still, we get good at deployment, so good in fact that we can do it at will
  • As work starts to flow, deficiencies in development and testing become more apparent, and they get dealt with
  • All of a sudden, the real bottleneck turns out to be outside of development – a lack of high quality ideas in the pipeline and/or frustrating delays in getting decisions made
  • Now what???

There is something almost inevitable in this sequence – in fact anyone familiar with the Theory of Constraints (TOC) will expect it! If you’re unfamiliar with TOC, it’s the model behind Eli Goldratt’s classic business novel The Goal, and much more recently the DevOps novel The Phoenix Project; TOC teaches that once you’ve addressed enough of your internal constraints, your key constraint will be found outside.

Although there’s a lot to be celebrated in that progression, no team wants to get to the “Now what???” stage. Your choices:

  1. Hope that it never happens (or not care, because teams are there to be disbanded)
  2. Plan to deal with it when it does happen
  3. Make Discovery (or “upstream” or whatever else you call it) a first class activity in your process

Option 3 implies some proactivity, but that doesn’t mean that it has to be difficult. Instead of dismantling that capability as your latest initiative gets off the ground, keep it going, even if at a reduced level. Instead of accepting requirements at face value, make sure that someone is taking the time to understand their authentic situations of need. Instead of fire-and-forget delivery, validate that needs are being met, expecting to feed some new learning back into the process. Simple changes, but as documented in my first book, the effect can be profound, even humbling!

You can of course go further. One of the most important moves made by the UK Government Digital Service (GDS) was to insist that every new service had a credible plan to sustain user research and ongoing service evolution – not just at the beginning but indefinitely into the future. “Start with needs” wasn’t just a slogan, it was a strategy, and a successful one! If government could do this in times of austerity, what excuse does your organisation have?


Public workshops (US, UK, IT, DE)

Make yourself known the #agendashift-studio channel in Slack if interested in attending another cozy 1-day or 2-day workshop for 3-4 participants in my studio office in Chesterfield, Derbyshire (minutes away from the Peak District National Park).


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…