What I really think about Scrum

[Comments on this post on LinkedIn]

Let’s look at Scrum through the lens of last week’s inverse square law of framework scaling, its power as a framework being the product of:

  1. The incisiveness of its point of view – its core paradigms, principles, values, and so on
  2. The ease with which its key patterns combine – both with each other and with those from outside the framework

Being small, Scrum should do well on both counts; I’ll take them in reverse before returning to how it scales.

The ease with which its key patterns combine

Scrum scores really well here.

Look at Scrum merely as composition of smaller patterns (dangerous, but bear with me just for a moment) and you have to give it significant credit for normalising the practices of daily standup meetings, small-scale planning meetings, retrospectives and so on. Not for everyone an unalloyed good (“too many meetings” is an easy complaint to make if for whatever reason it’s not working), but certainly a mark of Scrum’s success.

And it gets better: Scrum as a whole is small enough that it combines easily with other things. Scrum+XP has been a thing for a long time. I’ve worked with Scrum and Lean Startup in combination (in the government sector, no less). Scrum+Kanban (Scrumban) isn’t just one thing, but several; in Right to Left I describe four common combinations and elsewhere I have counted more (it’s not hard: just consider the different ways in which their respective scopes might or might not overlap).

The incisiveness of its point of view

Here’s where it gets awkward. Scrum isn’t one thing, but two:

  1. Left-to-Right Scrum: the team working its way through a backlog that is determined for it, mostly in advance
  2. Right-to-Left Scrum: the team iterating goal by goal in the direction of its overall objectives

Left-to-Right Scrum is a process that’s mediocre (or worse) to experience, and doomed to deliver mediocre results at best. And it’s easy to see how it happens:

  • Little room in the project for learning about the customer’s real needs or for exploring different ways of meeting them
  • Thinking that the job of Sprint planning is to fill the Sprint to the maximum, a misconception amplified by story points and velocity (the problem not being that they’re nonsense metrics that cause otherwise intelligent people to bestow mystical properties on Fibonacci numbers, but that they reinforce a dysfunction)
  • Reviews not of what’s being learned about the team’s customers, its product, and the team itself, but of progress against the plan
  • Retrospectives that lack the authority to address strategic issues, and that fail to follow through even on the issues over which it does have influence

I’m convinced that Scrum would be considerably less prone to these failure modes if only it would maintain a clearer point of view. Scrum’s tragedy is that it’s presented as a backlog-driven process so often that its core paradigm as an iterative, outcome-oriented process gets lost in the noise. And from that failure, disengagement. All that hating on Agile? You don’t need to look far for causes.

Scaling it up

For the most part, disappointingly predictable and predictably disappointing:

  • Take Scrum and layer on hierarchies of organisation structure &/or work breakdown structure
  • Plug it into a project/programme structure that almost inevitably works in left-to-right terms and is given no reason to think otherwise
  • Compounding it all, the rollout project – failure after failure, but still we do it!

Again, the tragedy is that it doesn’t have to be that way. Instead of layering on so much process that you disconnect teams from strategy and organisation development, invite them in! Instead of losing faith with self-organisation, invest in it! Instead of solution-driven imposition, outcome-oriented engagement! Honestly, it’s not that hard.

We’re in the business of building wholehearted organisations. Need help reorienting your Scrum implementation so that it can work as it’s meant to? Want to put authentic engagement at the heart of your transformation? Get in touch – we’d love to help!

Further reading:

cover right to left audiobook.001

My thanks to Teddy Zetterlund and Steve Williams for feedback on this post, and to Agendashift’s Friday #community Zoom group (details in Slack) for the conversations that preceded it.

Upcoming workshops

Agendashift™, the wholehearted engagement model
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Events | Contact | MikeSubscribe
Workshops: Transformation strategy | Transformation strategy | Short training
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

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!


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…


‘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, Scrum as a pattern of iterated self-organisation around goals:

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 I read the Scrum Guide


  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. Small wonder that they’re 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.

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].


[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

Blog: Monthly roundups | Classic posts

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