Category Archives: Scrum

Scrum it like a toddler

Most people (reading this blog at least) are familiar with the format of the Daily Scrum, where everybody on The Team comes up with an answer to the following three questions:

  1. What did I do yesterday?
  2. What am I planning on doing today?
  3. What impediments do I see?

But what a lot of people don’t seem to realise is that this is pretty much all there is to Scrum.

Scrum is pretty much just these same three questions repeated over and over and over again.

Don’t believe me?

At the Sprint Review the entire Team answers the question: “What did we accomplish last Sprint?”

And at Sprint Planning the Team again answers the question: “What are we planning on doing in the next Sprint?”

And finally at the Sprint Retrospective we are ask and answer the question “What impediments do we have? (and what are we going to do about them)”1

And of course the very same pattern can and should continue to repeat at the Release Level if you have one.

It’s far too easy to get caught up in the mechanics of Scrum — at which point it starts looking like a laundry list of artefacts to create, time boxes to keep and meetings to attend – but IMO that’s overcomplicating it.

All you have to do is connect with your inner 3 year old and keep asking (and answering) the same three questions over and over and over again.

“Just keep Scrumming, Just keep Scrumming”


  1. Careful readers will notice that the meetings could be considered to be out of order. That’s because the Daily Scrum Questions IMHO are out of order too! It’s far more effective to discuss what has been done and what impediments have been uncovered before figuring out what you’re going to do next. 

Not Original Artists

When I was in school, there existed a very popular packaging of music which I remember as “Hits Picks 100!” – basically these were compilations of all the songs that had been “on the charts” for the last few months. I guess in many ways it was the precursor of Napster – teenagers wanting to consume giant bags of unrelated popular music instead of albums from a single artist.

Anyway, there was sometimes a catch. Occasionally a very sheepish looking individual would arrive at school the next day, having spent all their hard earned cash on one of these massive compilation albums and when questioned about how it was1 – the reply was “Not Original Artists”

I don’t know the specifics exactly, but to keep costs down to the bargain basement prices that have ever attracted the younger purchaser, the publishers of said massive compilations would not licence the original recordings, but instead have somebody else effectively “cover” the song for the album (with varying degrees of success I might add)

There were of course legitimate compilations made, but these tended to attract higher prices. The two products looked the same, and so the average consumer assumed that they were the same.

Now of course to protect themselves legally, the advertising and packaging had to contain somewhere the dreaded “Not Original Artists” labelling – but nobody ever said how big the font had to be…

Inspired by the movie…

A few years later, a similar thing started to happen with Movie Soundtracks, which were equally as popular at the time as the pop compilations were a few years early. I’m not talking so much about Epic Original Scores such as Star Wars here, but rather more pop culture outings such as the soundtrack to Bas Lurman’s Romeo and Juliet.

These again were compilations, but this time around they were based around a curated set of songs chosen as the background for a particular movie.

Now these albums were created from licensed music and they were also combined with the licensed movie property. (No wonder they were popular!)

Hoards of people descended on music stores to buy these soundtracks and reconnect with their favourite movie.

In some ways, the movies became ads for the CDs. I think this was especially “a thing” in the days when you had to wait a year or more to own the movie yourself or even rent it from a video store. The music however you could get right away.2

But the popularity of this format once again drove marketers to exploit this demand by creating something that looked like the popular thing but wasn’t actually the popular thing.3

I remember being given an apparent movie soundtrack by a friend, putting it on to play and then halfway through thinking “I’ve seen this movie twice, but I don’t remember any of this”

So I went back to see the movie a third time, then went home and listened to the soundtrack again – to once again be baffled. Until I inspected the case a little more closely and found the phrase “Inspired by the movie…”

Inspired by Scrum

So how does this relate to process?

I think there is a lot of “Inspired by Scrum” out there that people are calling Scrum.

Who knows the full set of reasons why people do this4, sometimes it might be because people never saw the (Scrum) movie and don’t know that what they’re doing isn’t really Scrum.

Sometimes it might be just like the Hits Picks CDs – Scrum looked too hard and too expensive, so let’s do a cover version instead! Hey, it looks right doesn’t it?

Or maybe Scrum just wasn’t plain right for you and you’ve come up with something a lot better. And for some reason you’ve decided to call it Scrum anyway.

But for whatever the reason, it’s not Scrum, so please don’t call it Scrum.

Why does it matter what I call my process?

I think it matters for a few reasons, but here is the main one:

There are no end of people and blog posts out there who say that Scrum is awful and should perhaps “die in a fire” and then they describe the process that they were following and yes, it’s usually awful, but it’s also never Scrum.

Just once I would like to hear or read an “I hate Scrum” rant that actually describes Scrum.

But this distracts from the real issue – and the real problem is that you can silence that argument with “Oh, but what you were doing wasn’t Scrum”

And that’s the problem.

Because that answer presupposes that Scrum was the right thing for these people to do.

That is to say that doing Scrum correctly would have solved all their problems. Now maybe it would have, but that’s beside the point5. You can no longer have a sensible discussion about it because we’ve placed all the blame on Scrum.6

You can’t judge a process if you’re not following the process.

So what should we call our process?

Scrum Butt?

Scrum Butt was a popular term, I dunno, maybe 5-6 years ago? If you don’t remember it, the concept came from people saying “Oh we’re doing Scrum, but we don’t deliver working software at the end of each Sprint”

As cruel as it sounds, it was useful in the beginning. Because the people who genuinely wanted and needed Scrum often skipped over the active ingredients of the process and thus didn’t get the benefits. And thus “Scrum Butt” was originally a playful way of saying “Yes, I’m totally on this diet, except I’m still eating as much as I want”

But at some point in time, it suddenly became “NOT OK” to say Scrum Butt – I remember one guy at an agile conference basically losing his mind at a panel who just told him that he was doing “Scrum Butt” because they were being abusive and not helpful (Frankly, they both had a point, what he was doing was not remotely Scrum, but telling him to simply do Scrum properly wasn’t very helpful either, because that simply wasn’t feasible for him. He knew what to do, it was his company that would not permit it)

So in these days of “little ‘a’ agile” saying Scrum Butt might seem harsh, but it was at least clear.

Scrum-like?

So in order to salve egos and increase sales we got Scrum-like. This to me is the “Not Original Artists” of process naming.

The problem with the phrase “Scrum-like” is that it begs the question “In what way?” – because 9 times out of 10 the primary way in which the not-Scrum process is “like” Scrum is in the way it looks.

Inspiration over Like-ness

I think it’s more accurate, and dare I say transparent to say that your process is “Inspired by Scrum” rather than “Scrum-like”

The “Inspired By” CD’s were true originals – both artists and content. Sure they weren’t in the actual movie, but a lot of the time that didn’t matter, they were still good songs. (most of the time)

And some people even preferred the “Inspired by” CD’s to the Sound Track CD’s and that was OK too.

So if you’ve been inspired by Scrum, in whatever way then own that. Don’t feel compelled to pretend you’re doing something you’re not. Don’t wimp out and say you’re “Scrum-like”7own your originality.

Claim inspiration and invention, not mimicry.

And then we can leave Scrum to mean, well Scrum.


  1. Which was code for “Can I get a copy please?”. Napster didn’t create the concept of “sharing” music it just scaled it. 
  2. And who doesn’t love a fast feedback cycle!? 
  3. In those days there was a less torrential stream of movie production. 
  4. Scrum is of course also not unique in this regard. 
  5. The is a secondary problem here which is we never get a decent chance to talk about the problems with Scrum itself – because we’re too busy telling people what they’re doing is not Scrum. 
  6. For what it’s worth, I’ve seen the same thing happen to kanban. 
  7. The process equivalent of using a really small font. 

The Problem with ScrumMaster® as Process Police

This is a common view.  “The ScrumMaster enforces the process”.

In fact, somebody enthusiastically told me this only last week.

It’s succinct, seemingly clear and it’s also close to useless.

Leaving aside that it’s probably a gateway drug to Theory X1, consider the following:

Most Scrum implementations these days are far from “by the book”; in today’s interrupt driven corporate culture, when was the last time you saw a team genuinely “ring fenced”?

And this is the problem – how do you enforce “the process” when the process is so incompletely and informally defined?  Most organisations don’t codify the fact that “Our Scrum Teams can be interrupted whenever we feel like it” and would you want to?

What process are we enforcing here exactly?

And would you even want them to?  (Imagine a ScrumMaster refusing to let Team Member’s attend to an urgent issue in live because that would break the rules?)

And who does the ScrumMaster serve anyway? Scrum as an abstract ideal?  Or the organisation that’s paying their salary?

I say it’s time to ditch the concept of ScrumMaster as Process Policeperson and replace it with the notion that:

A ScrumMaster mindfully considers the intersection of the process and the current situation and makes an informed judgement call for which they take full responsibility.

Afterall, if all a ScrumMaster had to do was “enforce the rules” we’d hardly need a human for the job.


  1. Theory X Management states that people are inherently lazy and thus must be “made” to work.  This is in contrast with Theory Y which states that people are able to enjoy work and thus are capable of being self motivated.  Both Agile and Lean are  strongly based on Theory Y – and thus having ScrumMaster’s that subscribe to Theory X thinking is deeply problematic if you want to get the best out of Scrum. 

The parable of the water

I was out for a walk the other day with some friends and their family. About halfway through the walk one of the boys declared that he was thirsty. No problem says Dad, here is $2, there are some shops, go buy yourself a bottle of water. The boy runs off. I think no more of it.

A few minutes later, the boy comes running back to his father, not with a bottle of water, but rather with the same $2 coin. He gives the coin back to his father and simply said “Mum says no”.

Curious I think. Why would a mother deny their child a drink of water?

Later, I discover why.

“I denied him the water, so that he’d learn to plan better next time, so that he’d learn to learn from his mistakes (however small they may be), and to eventually come to the understanding that almost all his decisions have consequences of some kind.”

At the time I thought “Wow, that’s a really great mother”

And this morning I thought “Wow, that’s a woman who really understands Scrum”[1]

These rules are here to help

I think something that has perhaps been a bit forgotten is that the Scrum rules, much like our mothers, are here to help. We may not always want to do what they’re suggesting, but oftentimes it’s exactly when we want to the least that we need to the most.

The most obvious parallel to my water bottle story is one of the most hated[2] rules in Scrum – being:

    The Product Owner may not change their mind during the Sprint

This is often quoted as the reason that Scrum is “not Agile”[3] but there are several good reasons for it.

The one I want to highlight today is simply “So that our Product Owners can learn to plan better

Imagine speaking to the ScrumMaster after they had denied the Product Owner a mid Sprint change if they explained:

“I denied him the change, so that he’d learn to plan better next time, so that he’d learn to learns from his mistakes, however small, and come to an understanding that all his backlog prioritisation decisions have real world consequences of some kind”[4]

Doesn’t sound so bad now, does it?


  1. Not the letter, but the principles. It’s quite possible that she’s never heard of or has any interest at all in Scrum. And I’m certainly not suggesting that she’s using Scrum to raise her children.  ↩

  2. And by association, one of the least followed.  ↩

  3. Often by people who define Agile as flailing around building random things based on whim.  ↩

  4. I can imagine that I’ve actually outraged some readers at this point by suggeting to them that their Product Owners don’t consider the consequences of their actions before acting. Well, I have two responses to that:

    1. I’m pretty sure not all of them do, so count yourself lucky if this is not the case for you

    2. Even some of the best PO’s may be new to the concept that their Backlog prioritisation decisions have immediate effects on both the finances and morale of the organisation. This seemingly annoying minor Scrum rule is designed to help them remember that.  ↩

“Regular” Products Iterate too…

Occasionally there is push back about the need to iterate on software projects. In fact just today I read a comment in a blog post that clearly stated “The only process that works is Waterfall – clearly define exactly what it is that the business wants, then figure out how you’re going to provide that and then build it” – well that’s a great idea – except around 9 times out of 10 we fail at the first step.

That’s not an isolated thought, it’s an honest one. Many people believe deep down inside that somehow iteration is failing1, or at the very least cheating and some people even call it waste.2

My Refrigerator

Those of you who sat with me at lunch on the last day of Agile Vietnam will know that I own a really nice refrigerator.3

Seriously, it’s amazing. It’s not just the best ‘fridge I’ve ever owned4, it’s one of the best products I’ve ever owned. Forget Apple, this thing just works.

And then I stopped to to compare it to the last fridge I had, and then the one before that – why were they not as unashamedly awesome? Why didn’t they just build fridges like this in 2008? 2003? 1977?

Basically because we didn’t know how…

Oh sure, we could keep stuff cool to frozen5 – and the door would open, and you could in theory see into it in the dark. But I’ve never loved a ‘fridge until now. I’ve never enjoyed using one before.

It’s probably important to point out at this point that I’m not talking about a massively expensive appliance here. The benefits are less to do with how much I’ve spent, and more to do with just how much refrigerator technology and design have come on since I last bought one.

The refrigerator has iterated.

Slowly I’ll grant you; but this is not a new product, it’s an iterative build on the product that came before it.
And that’s why it’s awesome.6

“Real” products – like ‘fridges, cars, dryers iterate. The products I have today are generally recognisable and serve largely the same core purpose, but they are not the same products by any margin as the ones my parents bought.

Refrigerator MVP

But it was not always thus. Visit any stately home in Europe and I’ll bet 9 out of 10 of them have a cellar, cool room or ice room.

Once upon a time (not that long ago – I bet it’s in the memory of your grandparents, if not your parents) – ice in a box was basically the state of the art.

Ice in a box was the MVP7 for home food cooling.

Granted, no single organisation ever owned the entire process from home ice delivery through to the French Doored, humidity controlled LED lit ‘fridge of my dreams, but the market as a whole certainly did (even if it took it the better part of 50-60 years)

Don’t fight the iteration, instead admire the speed

Once you accept that all products exist only to solve problems – to create outcomes desirable enough to pay for, you can clearly see that iteration is not a failure or a cheat – it’s basically the way in which the world works.

The difference with software is the speed at which we can accomplish this.

It’s not a failure to develop your software in an iterative fashion. It’s a privilege. An exciting time to be alive.

When we accept this process as natural we can take our ideas from blocks of ice to stainless steel wonders in a fraction of the time it took our forefathers.


  1. Who precisely is failing here however seems to rely entirely on your perspective. 
  2. Somewhat missing the point I know; but waste is both a tricky concept and an emotive word. 
  3. No kidding, I think we talked about my fridge for about an hour. I think it made us all feel cooler. I cannot for the life of me however remember how the subject came up in the first place. 
  4. One of the upsides of changing which country you live in every 5-10 years or so, is that you’re basically forced to upgrade your white goods. 
  5. Although I’d have to say that the majority of the freezer compartments I had in London operated around the concept of mostly frozen
  6. Imagine if people thought about their cars like they think about their smart phones – I hate this new Audi! It has the same form factor and user interface as the last one! Boooooring! I’m so going to switch to {insert brand here} car which moves the doors and steering system around every time they release a new one! 
  7. Minimal Viable Product 

Have you Mastered the Basics?

So I’ve noticed a trend in recent years. Whereby a lot of people are hungry for “advanced” Agile and Lean techniques (whether it be at a conference, in the classroom or in a coaching engagement)

So far so good, both Agile and Lean have been around for decades – and so it should not be a surprise that people are passed the basics and ready for some more advanced stuff.

But a conundrum often arises in these situations whereby the organisations and people most eager to learn the more advanced techniques are the very same ones that are yet come to grips with (let alone having mastered) the basics of Agile or Lean.1 (This is obviously a generalisation and not true in every case, but it’s sufficiently widespread for me to consider it a trend)

As I tweeted back in January:

And talking to other established consultants, trainers and practitioners it seems that I’m not alone in this observation.

So what’s going on?

There seem to be two fundamentally different views on what “the basics” are actually comprised of.2

And these two views may be an attribute that is unique to (or at the very least exacerbated by) the very nature of Lean, Agile & Systems Thinking.

(So again making a gross generalisation here)

Many people tend to class the basics as things that you do.3

Whereas “we in community” tend to class the basics as concepts you understand.

And thus many feel that they have mastered the basics when they can go through the motions – they write things on post-it’s or enter them into a tool – perhaps they set WIP limits, and they almost certainly know which three magic questions lead to hyperproductivity

But because they’ve not mastered the basics by the community’s definition – they often fail to yield any benefits from these changes (sometimes they do however, but that’s a topic for another time) – and thus they feel the hunger for something more advanced. Something more to do.

So this explains the phenomena – at least to my satisfaction – but it does not necessarily provide an answer 😉

Except perhaps that we should more carefully consider how we use our language and how we label things; because Basic Practices != Fundamental Concepts.4


  1. This does however put me in mind of an episode of House (“House vs God”) – where Wilson convinces a child who believes that he is a saint and thus does not need surgery to have surgery through the argument that an actual saint would have the humility to believe that they were in fact just sick and not in fact special. 
  2. This being an entirely different question to “what the basics actually are” – I’m arguing ontology here. 
  3. As soon as you do that, it’s also easy to apply models like Dreyfus 
  4. Ease of measurement and evaluation plays a big part here too. It’s much quicker and easier to determine whether or not somebody is having a 15 minute Daily Scrum than it is to determine whether or not everybody has internalised the value of (say) slack.