Tag Archives: Agile

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. 

An Agile Project is Not Distinct from its people

One of the more recent trends I’ve noticed is organisations having trouble with the Agile Convention (and Scrum Rule) of:

“The Product Backlog is estimated by The Team Who Is Going To Implement it”.

In fact some folks have so much trouble with the concept that they deny that it’s even remotely possible.

Digging a little deeper I’ve found that in many organisations there is (to my mind at least) an enormous gap between defining a project and executing a project; and that these two “phases” are typically conducted by two entirely different sets of people.

And yes they’re referring to these endeavours as Agile Projects.

In actuality, that’s basically Waterfall, and as such it’s missing out on a lot of the point.

There are two fundamental issues here:
1. How these Estimates are being used
2. How Knowledge in general is being transferred

Let’s talk about Knowledge Transfer first.

Tacit vs Explicit Knowledge

Waterfall is based around the concept of Explicit Knowledge. It operates on the fundamental assumption that we can (always) transfer knowledge between individuals through the medium of explicit information – i.e. writing it down.

It is this belief in the universal applicability of explicit knowledge that allows Waterfall to function. What is effectively (supposed to be) happening in Waterfall is progressive translation of the same information from one explicit knowledge format to the next. Much of the focus of management on Waterfall Projects is verification that this translation has occurred without error or omission.

Agile however is based around the belief that Explicit Information has its limitations and that one of the primary causes of failure in Waterfall projects is that progressive translation instead becomes progressive interpretation (Think of the children’s game telephone) – and thus the introduction of mistakes is inevitable.

As such, Agile leverages more heavily on Tacit Information i.e: the stuff in people’s heads. (Face to Face communication anybody?)

“Effective transfer of tacit knowledge generally requires extensive personal contact and regular interaction” [1]

What this means in practice is that Agile relies heavily on co-creation not interpretation; fundamentally every artefact in Agile serves as a tacit reminder of intent and purpose for those people who took part in that artefact’s creation. Eliminating or at the very least reducing the “telephone effect”.

And this is also why there is such a fanatical focus on producing and evaluating “Working Software” – because not only is it clearly possible for communication to break down at any step in the process of creating software; the arguably most important part to verify is whether or not the software solves its intended problem – and it’s those two “points” have the most layers of potential “re interpretation” between them.

If you’re unaware of the distinction between Tacit and Explicit information, then this will simply look like a waste of time to you[2] and instead you’ll think nothing of writing a 4 inch high stack of User Story Cards all by yourself.

In Waterfall, we initially have no choice but to interpret the words that come to us from the previous stage but then we are able to do whatever suits us as long as we can reasonably defend our interpretation.

In Agile however, we strive to intentionally interact and co-create value such that our words, should we write them down, are not subject to interpretation, but rather trigger memories of rich interactions.[3]

But of course, all of this can only happen if it was the same group of people.

Guessing about Grooming

So already you can begin to see the problem with separating the “Estimation” people from the “Implementation” people.

In these situations “Grooming” and “Story Writing” tends to drag on forever as:
1. We attempt to transfer all our knowledge onto paper (or into JIRA) – which is slow and lossy.
2. We have to guess[4] at when we’re done with Task #1 [5]

The results of this can either be “bad” or “worse”.

Bad

Bad is where the “Estimation People” spent sufficient time with the “Definition People” that they do[6] in fact have a solid tacit understanding of what needs to be done.[7]

Worse

In the worse scenario – the “Estimation People” are just as much in the dark as the ultimate “Implementation People” – and they’re also just interpreting whatever they were given.

The Real Point of Estimation in Agile

Fundamentally there are two main reasons why you might want to estimate a piece of work

  1. To aid in planning and prioritisation
  2. To clarify understanding

With point (2) being a fundamental requirement for Point (1).

Estimates can work as a useful “out of band” abstraction for a piece of work that when incredibly divergent – can act as a signal that understanding is not uniform[8]

i.e: if our estimates are greatly diverse – then somebody, maybe everybody’s understanding is wrong.[9]

Additionally, getting people to externalise a number aids in getting them to engage with the problem in a way that simply asking “Do we all understand this” – never will.

My Guesses become Your Shackles

In both cases above however, the clarification step is skipped and the externalisation effect ceases to have any merit.

What we end up with instead is a set of estimates that reflect a mixture of typically two things:

  1. What the stakeholders want the software to cost
  2. What opinion the “Estimation People” have of the “Implementation People”

What do we want this to cost?

I have previously covered the issue of estimating to fit a commitment, suffice to say that separating your Estimators from your Implementors makes this task easier and the eventuality of it happening more likely[10], as the Estimators only have to make the client happy and know that they’ll never be on the hook for delivering to what they may well know is a ludicrous timetable.

The sad part about all of this, is that fixing the cost for Software Development Projects is a problem that Agile is pretty good at solving – as long as people let go of their old habits, like creating estimates for other people.

What do I think about you?

And lastly, if we’re having to estimate how long somebody else is going to take to do something, then we have to have some kind of impression about their ability. And this typically falls into two categories:

  1. I am competent, and they should take the same amount of time as me
  2. I am really competent, there is no way in which they will be able to get this done as quickly as me.

So this goes wrong in all sorts of ways, assuming that the Estimators are actually the more senior people, then choosing Option 1 usually ends up in underestimation, especially if the Estimators actually over estimate their own brilliance (which they are of course incentivised to do, as their own abilities are never actually going to be tested here)

But the downside of Option 2 is rarely considered.

Estimates become targets or commitments

The unspoken assumption behind separating out Estimation from Implementation is that the Estimate actually becomes a statement of “How long something should take” – if the people doing the work are:
1. Competent
2. Working Hard Enough

Thus doing the work within the prescribed amount of time becomes a new meta goal (which in certain pathological circumstances usurps the original goal of solving a Real World™ Problem)

This means that upfront, estimation puts a cap on our productivity and a damper on our creativity. The goal now becomes to expend the time, not to solve the problem, and certainly not to do anything clever or creative in order to solve the problem! (imagine taking way longer for one part of work because you’re building a capability which makes the rest of the work take 10th of the time)

And of course quality is the traditional sacrificial lamb in these scenarios:

“Well you didn’t ‘estimate’ me enough time to do this to any reasonable level of quality”

In Summation

The underlying belief here seems to be that for many organisations “A Project” exists as an entirely distinct entity from the people who will eventually build it. Much like a recipe in a cookbook. [11]

There are four problems with this however:

  1. Your Project is not a recipe in a cookbook [12]
  2. The clock is still running during waiting time [13]
  3. Time and Effort is wasted in both the project definition and at the uptake of execution – as the project definers have to spend additional effort in fleshing out the detail they assume the (unknown) implementers are going to require;
  4. Explicit Knowledge is imperfect. And mistakes are made not only in execution, but also simply in the understanding.

None of these four things are good. Put them all together and they add up to:

  1. Projects that cost too much [14]
  2. Projects that take too long – especially from the Customer’s Perspective
  3. Projects delivering the wrong thing
  4. Generally everybody focussed on the wrong thing [15]

An Agile Project is just as much about the people as it is about the plan

Agile ways of working solve this problem – not through process, but rather through understanding that people are, well, human.

  • Writing notes to your future self is more effective than writing them to somebody else
  • Estimating how long you’re going to take to do something is always going to be more accurate and motivating than figuring out how long somebody else might take to do it

I’m beginning to think that the concept of #NoEstimates may not go far enough some times. Maybe we should probably stop using the word “Estimate” altogether, at least for a while and start using slightly more precise terms such as “How Long This Would Take If I Was to do it”, “The Maximum Amount of money I’m willing to pay for this functionality” and “The amount of time I’d like this to take which is based off no information apart from how I feel about the situation”

But if we can’t do that, then at least we should start socialising the concept that Agile Projects are made out of people and not paper.[16]


  1. Goffin, K. & Koners, U. (2011). Tacit Knowledge, Lessons Learnt, and New Product Development.  ↩
  2. Never time to do it right, but always time to do it over.  ↩
  3. Another reason to work in short cycles, the human memory fades.  ↩
  4. Or worse, somebody else has a made a universal guess on our behalf – and prescribed what a “Good User Story” looks like in the abstract. This is great for arse covering, but tends to be horrible for getting great stuff built.  ↩
  5. And because we tend to attribute failure to the (wo)man and not the method, the next time around we simply spend longer and write more. And thus miss the point yet again, but this time by a wider margin.  ↩
  6. Or at least think that they do. This is probably where it all starts going wrong.  ↩
  7. I will leave it as an exercise for the reader as to why then they do not then just go ahead and do the work themselves.  ↩
  8. This is why it’s so important that (in order to be useful) Story Points are regarded as Team Estimates and not Individual, or “skill class” estimates.  ↩
  9. If the estimates are all the same however, this does not necessarily follow that understanding is uniform however – beyond the size of the work. If the work unit is small enough, this should hopefully not matter too much.  ↩
  10. People like to be liked. And they also like to discount the future. In the vacuum of their being any other consequence, most people, if put in this situation, will come up with a number that makes the requester happy in that moment.  ↩
  11. Often coupled with the associated belief that the recipe is without fault, and that it’s only the cook who can fail to follow the instructions correctly.  ↩
  12. For a start, if it’s a half decent cookbook then somebody will have tried all the recipes first. Hell, I can almost guarantee that they iterated their way to creating the recipes. Nobody has tried your project first, at least not to completion; and if they have – save yourself a whole lot of time and risk and just buy it off them.  ↩
  13. From a accountant’s perspective they may however be happy that nobody is billing towards the project; however the users, who presumably had an actual need, are losing money – either real or opportunity terms.
    There is a secondary issue here as well, in that the longer we wait to deliver requested functionality, the more likely it is to be out of date by the time it’s delivered.
    To extend the analogy, what we are effectively doing with our projects is thinking “I’m hungry, what’s for dinner?” and then waiting for somebody else to write and publish a cookbook.  ↩
  14. Not deliberately however. I think the most common reasoning is that by separating out the planning from the execution, that money can be saved on finding the cheapest possible executors. See any of my more recent sessions on Agile Contracting for a discussion on this.  ↩
  15. Meeting the estimate, not solving the problem.  ↩
  16. Which given sheer amount of paper stuck to the walls on the average Agile Project seems mildly ironic 😉  ↩

Why Best Practice lives in a Shu Box

Shu-Ha-Ri is a popular metaphor in Agile Circles. 

It’s borrowed from Martial Arts (where it works well) and one way to explain it might be:

  1. Shu – Follow the rules
  2. Ha – Break the rules (adapting them to your context)
  3. Ri – Become the rules

It is most often used as a justification for why beginners should not question their ScrumMaster™ (or process) and simply follow the rules laid down for them by the methodology. 

Much like jazz, any given student1 is only permitted to rise to the next level of the process once they’ve conquered the preceding steps.  i.e. you don’t earn the right to break the rules until you’ve proved that you can follow the rules.2

What’s this got to do with Best Practice?

The term “Best Practice” tends to mean “Industry Best Practice” – people want to adopt Best Practice because it’s considered as something that has been proven to work elsewhere.  i.e. it’s a way to short-cut learning.3

If we say for the moment that we’re talking about authentic Best Practice here, then any deviation from the rules therefore means some kind of sub-optimal performance on the part of the implementers (and should obviously be avoided).

It’s a Good Idea, it’s how Humananity has managed to continue to make technological and societal progress that extends well beyond the confines of the average human lifespan.

The Democratisation of Excellence

There is only one problem. For something to be widely regarded as Best Practice, then it has to be somewhat democratised.  By which I mean it needs to be able to be widely implemented.

If something is widely implementable however, it means that it does not, by definition, take advantage of any organisational or personal strengths.

Thus if we return to the martial arts roots of Shu-Ha-Ri – your Kyū level training will teach you how to punch effectively and without breaking your wrists, but it won’t help you take full advantage of the fact that you’ve got shoulders that would put Schwarzenegger to shame.

By Definition, Ha means Abandoning Best Practice

“Ha” means to break the rules.4  This “right” accrues to the martial arts student upon the event that they are able to prove that they can follow the rules without deviation.

(Thus, we can safely assume that the rules are not being broken due to an insufficiency in ability)5

Once so gifted, students will then begin to break (some of) the rules in order to better adapt the techniques to their individual contexts – always in an endevour to produce superior results.6

For these students, Best Practice ceased to be enabling and had become limiting.

Best Practice is a step along the journey, it’s not the destination

There is actually a lot to discuss around Shu-Ha-Ri7, and I know that some people (Adam Yuret comes to mind)  dislike the concept simply because it creates an apparent hierachy, encouraging people to self identify as “Ha” or even “Ri” simply because that’s a higher grade.

But the simple point I want to make here – is the surprising position that Best Practice finds itself in.

It’s nothing more than the lid of the Shu-Box.


  1. Side thought – wouldn’t it be nice if we all regarded ourselves as students of Agile rather than practitioners, masters or gurus? I doubt you could find many Black Belts in Karate who actually regarded themselves as no longer being a student of the art. 
  2. Skipping this step in music is all that separates jazz from punk. 
  3. Afterall, who wants to be learning when they could be doing 
  4. Yes, the ones you just spent at least 5 years learning. 
  5. There is also the presumption that at least some level of understanding has occured. At the very least, once the student is able to revert to “best practice” at any time, they can now judge for themselves as to whether their adaptations are providing superior outcomes or not.  Also from my personal experience, truly studying a martial art instils a strong degree of humility. (Contrary to what much of Hollywood might portray) 
  6. As opposed simply for the purposes of saying “Hey look I invented my own Martial Art!  It has a different name, an extra few belts and I’m the GrandMaster!” 
  7. I think I have enough Blog Drafts on the topic to fill a book. 

Misunderstandabilability

Back in, I think it was 2009, at the Lean Software Systems Conference in Long Beach California, I had the opportunity to have a brief conversation in the hallway with Barry Boehm. For those of you who don’t know the name, you may still be familiar with his most widely spread idea The Cost of Change Curve.

It looks something like this:

title

It’s most commonly used (in my experience) as a justification for Why We Must Use Waterfall.[1]

I mean, if you look at it, it’s obvious right? You want to get those requirements right! No good finding out that you’ve build the wrong thing once it gets into production! Waaay too expensive.

I gently called Barry on this; kind of / sort of blaming him for arming legions of Waterfall Enthusiasts with a deadly weapon of science and reason. After all you can talk Value until you’re blue in the face, but nobody wants their costs to go up – at least not by that much.

A strange sad expression passed briefly across Barry’s face as he asked me “What else could it mean?”

If you open you mind and look carefully at the chart again- it might just switch from being a mandate to becoming a warning.

A warning, that if you use a Waterfall Style Method, your cost of change WILL go up exponentially towards the end of the project. As it turns out, Waterfall is the cause (and for many people the cure)[2] of and for the Cost of Change Curve.

What had happened was that people (lots of people) had misunderstood the message.

I started to think about what else people had misunderstood (and as a result typically misused) in the world of methods and processes – and came up with what I called “The Misunderstandability Index”. Reflecting on the fact that (for example) Scrum rated very highly on the Misunderstandability Index, whilst the Kanban Method (again for example) ranked a great deal lower.[3]

I largely kept this idea to myself and a few colleagues until a few years later, when I was having lively conversation with Yuval Yeret at the Speakers Dinner after LKNA in Chicago.

We had been having a discussion around whether teams that had utterly failed to grasp Scrum could in fact do Kanban well, or at all. And additionally that it seemed often to be the case that Teams working in environments that were the least suited to Scrum, wanted to to do it the most.

In order to illustrate a point I brought up my story about Barry and my Misunderstandability Index. Yuval was excited, and asked me to publish something on Misunderstanability.

It’s about ease, not difficulty, in cognition

One key factor I’ve come to understand about misunderstanabilability over the last few years is that it’s about ease in cognition. Not difficulty.

Another example may help. At the same conference, Donald Reinertsen was also speaking. And he was speaking on dense economic models. Lots of maths, lots of big words. The stuff he’s famous for. Good stuff, but hard going.

In that room there was very little misunderstanding going on; largely because there was not a great deal of understanding going on. For many people it was all just too hard – but they knew it was too hard.

Misunderstanding occurs when you think you grasp something, but in fact you haven’t.[4]

It brings to mind the Twain quote:

It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so.

Misunderstanabilability is therefore the natural pre-disposition that an idea has towards being misunderstood.[5]

Ideas are not sufficient. If we’re constantly having to tell clients that “it’s not working because they’re doing it wrong” then maybe it’s time we stopped lecturing and started examining the level of misunderstandabilability in our messages.


  1. I personally first encountered the curve, in Project Management classes at University  ↩

  2. This is of course a cure in the same sense of the word that staying drunk is a “cure” for a hangover.  ↩

  3. The lower the score, the more the intent behind your idea is understood by others.  ↩

  4. In psychological terms, you’ve made a substitution in the first instance and are subject to confirmation bias in the second instance. It’s the second part that gets us into trouble, because once we have misunderstood, it’s very hard to suddenly start understanding.  ↩

  5. And in this way I would like to make a clear distinction between “misleading” which implies an intent to deceive and something that’s simply high in “misunderstandabilability” meaning that it’s highly susceptable to misinterpretation.  ↩

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

A Conversation between an Anthropomorphised Agile Manifesto and The Real World™

AAM: Ahem… We have discovered better ways of developing software…

TRW: Glad to hear it because you guys have seriously sucked at it up until this point.

AAM: Don’t you want to know how we did it?

TRW: Not interested, I’m assuming it’s a bunch of pie in the sky theoretical namby pamby that you’ve never tried. Certainly not on me, The Real World™

AAM: Well actually, it’s entirely based on experiential learning. Empiricism. We’ve discovered these better ways through doing it and helping others do it.

TRW: Blah blah blah Empire Racism you say? Edgy. But which bit of not interested did you not understand? Get to the part where you can finally tell me exactly what I’m going to get and exactly when I’m going to get it.

AAM: Well, about that. You see, this “better way” relies fundamentally on not answering those particular questions.

TRW: You have to be kidding me.

AAM: Instead we’ve got some much better questions for you to ask instead.

TRW: Steady on there. This was about you being less rubbish at your job. I thought you said you had discovered better ways of developing software through theoretical namby pamby?

AAM: We have! It relies almost entirely on Business People and Developers working together daily.

TRW: Say what now?

AAM: What you need to do is value customer collaboration, hire motivated people and then trust in self organising teams to get the job done.

TRW: Which part of “what am I going to get and when am I going to get it” did you not understand?

AAM: Ah about that. We’ve decided that’s better to respond to change than to follow the plan.

TRW: Like hell it is.

AAM: No, seriously. It’s for the customers competitive advantage! Even late in development.

TRW: DO NOT USE the term “late” and “in development” with me ever again.

AAM: But our highest priority is early and continuous delivery of valuable…

TRW: Finally something I can use. So you’re saying that you’ll deliver everything I want early from now on, using this “Agile”? Excellent.

AAM: That’s not quite what that means, if you’ll let me finish… the principle is “early and continuous“, you only get the early part because we don’t deliver all of it. It’s our highest priority I’ll have you know!

TRW: All I heard was early. And I’m finally beginning to like you, so I’m going to pretend I didn’t hear that last part about not delivering it all. If I was you, I might think about shutting up right about now before I change my mind and call that RUP guy back and subscribe to his newsletter.

AAM: But you’ve missed the parts about technical excellence, sustainable pace and the fact that processes are nothing but empty promises filled with lies!

TRW: Ooooo processes, gotta get me some of them. Whatcha got there cutie?

AAM: Well since you asked so nicely… But you will remember that it’s the people that do the work not the process won’t you?

TRW: Yeah yeah, people great. Process bad. Mung Beans even better. Got it. Whatcha got?

AAM: I’ve got an estimation system that looks like mystical ritual using a scientific looking number sequence, a daily meeting format that will make your office space looking like meerkat colony and some ambiguous concepts around the term commitment.

TRW: Sold!

AAM: Can we at least meet face to face to finalise the deal? We believe it’s the most effective…

TRW: No, I want it all in writing and I’m also sending you off shore. It’s cheaper. Also lay of the believing for bit, and focus more on the doing. People are going to think you’re some kind of nutter.

AAM: So much for maximising the work not done…

TRW: Seems pretty simple to me. I got a shiny new toy and everything is still your fault. Win. Now get back to work!

AAM: But the retrospective!

TRW: Can wait. You’ve got real work to do. Didn’t you just say that your highest priority was early delivery?

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. 

Using Narrative as an alternative to rules of Best Practice

In my last post, I spoke about the limitations of Best Practice.

I can imagine that some of you may be thinking:

“Well Mr Bennett, it’s all well and good to poke holes in rules of Best Practice, but what do you suggest we do instead!?  We can’t just have a free for all!  How will people know what to do?”

A free for all is not at all what I’m suggesting.  In fact far from it.  The deep and lasting irony about using Best Practice outside of its appropriate domain of use is that you get less actual control as people game the system to get around it.

Let’s use a concrete example to illustrate the point I’m talking about.

You might for example be using a process control framework (let’s call it Scrum) – and you can have a simple rule:

Rule A) “Only the Product Owner may abnormally terminate a Sprint”

OR

Rule B) “Only the Team may abnormally terminate a Sprint”

OR

Rule C) “Either the Team or the Product Owner may abnormally terminate a Sprint”

There have been passionate discussions (mostly online) as to which one of these rules is “right”, and evidence of one kind or another exists to support all of them.  Clearly, as written, they cannot all be right.

Which one is Best Practice?

Rules are used to guide behaviour and also provide an objective justification for punitive action towards rule breakers.

In our society we are all aware of the punitive actions associated with our criminal justice laws.

But terminating a sprint is a process rule, not a criminal justice law.  If a criminal justice law is broken, it is used in a court of law in order to provide guidance as to whether the rule was in fact broken and what the appropriate punishment should be.  When was the last time this happened on your project?

Process laws are therefore less about punishment and more about guidance.  But how suitable are rules for this purpose?

Rules like these unfortunately offer very little guidance for complex situations.   And the more general they are, the less guidance they seem to offer.  You could easily argue that Rule C could be replaced by “Anybody except the ScrumMaster may terminate a Sprint” – it may sound silly, but really, what is the effective difference between that statement and the rule as described?

The problem with rules is that to be clearly enforceable, they need to be pretty specific – which is OK when your rule genuinely is “Best Practice” because everything else apart from following the letter is going to be an undesirable outcome.  But if anything less than perfect is your aim, then simple statements such as “Only the Product Owner may terminate Sprints” begin to lose their utility and we instead direct people towards a “not terrible, but not great either outcome” – in many cases like these, the focus tends to be not on excellence but instead on preventing horrible failure.  The problem with this approach should be obvious, you drag down the great outcomes to protect yourself from the bad.  Maybe it’s me, but I don’t see a competitive advantage in that approach.

Narrative is a good option – in these series of narrative fragments I have provided an alternative to simple rules – and one in a very human form, one in which our race has been learning and passing on knowledge for centuries.

Instead of a single point, instead there is a rich tapestry of guidance and learning.  One in which the team and organisation can add to themselves over time as they share their successes and failures.

Rules & Narrative Fragments

Sprint Termination Narrative Fragments

NOTE: If you’ve arrived here directly this is a set of narrative fragments edited together to become a fable.  The purpose of which is to socialise desired behaviours within an organisation.  It is presented as an alternative to stating and enforcing simple rules along the lines of “Only the Product Owner may abnormally terminate the Sprint” and instead attempts to capture the richness and subtle involved in such decisions.  Like all good fables, it also contains several other minor lessons.

A LASTing Benefits Scrum Fable

Our Protagonists:

Bob – The ABC Corp Product Owner, recently married

Sally – The CEO of ABC Corp, & Bob’s boss

Gareth – The CEO of Company X

Jim, Gary & Peter (aka the Three Amigos) – schoolmates who now find themselves working on the same Scrum Team at ABC Corp. They all hold a large number of options in ABC Corp stock.

Betsy – the Scrum Mistress at ABC Corp, nobody’s boss

A Conscientious Product Owner

Bob the Product Owner being recently married is going on a long honeymoon. Knowing how important a Good Backlog is to the success of the ABC Corp Product, Bob grooms far ahead and spends quality time with his team ensuring that they have the information they need, and know what is expected of them whilst he’s away.

A Deal in the making

Sally (ABC Corp) and Gareth (Company X) having been working together on an exciting new joint venture for some time. They plan to build on the natural synergies between their company’s respective software suites and create an entirely new class of product which should take the market by storm.

Work needs to be done at both organisations. Their respective marketing departments have also requested that Gareth and Sally provide some kind of indication of when they think they can deliver it to the market.

Sally and Gareth get their respective software teams together to estimate how long the integration effort might take.

Both companies use Scrum for development. The estimates produced by the teams indicate that at the current rate of development, it’s most likely that the work will take between 4 & 6 “Sprints” to complete the integration. Marketing immediately calculates a calendar date from this information and starts working on Press Releases and Marketing Collateral.

Bob returns with a smile and a sunburn

The day after the deal is signed, Bob comes back to what appears to him to be a very different organisation to the one he left!

There is a note on his desk that he’s to see Sally the very instant that he gets into the office.

Swallowing back the fear that he’s going to be fired, Bob checks his grooming in the mens room before taking a deep breath and going to find Sally.

Sprint the First – Responding to Change over following a Plan

Sally briefly explains the deal she made with Gareth while he was away and directs him to start work immediately.

Bob explains patiently that he will most certainly prioritise the work in his “Product Backlog” but that “his” team cannot start on the work for a least another 10 days, as they’re currently “in Sprint”.

Sally explains to Bob, that time is of the essense, wheels are in motion and that 10 days is far too long to wait to get started.

“Bob, irrespective of what the team is currently doing, it cannot compare to how important producing the Joint Venture Software is. We need this.”

Bob stands firm.

“No!” he says, “I cannot break my promise to the team! As the PO I committed to not changing my mind about what the team is to deliver in each Sprint. If I break my commitment I’ll go to Scrum Hell! I’ve seen pictures in Betsy’s Scrum Bible, and it looks horrible!”

Sally considers firing Bob on the spot, but his mention of Betsy’s Scrum Bible reminds her of what’s in her bottom drawer. She opens it and takes out the gold plated plaque that Betsy gave her last Xmas. It is inscribed with something called “The Agile Manifesto for Sofware Development”, she scans it quickly to find the text she’d thought she remembered seeing.

She holds up the plaque and begins to read from it.

“We Value… Responding to Change over Following a Plan”

“Sounds to me Bob, like you’d rather follow your plan, than respond to the change I’ve just given you!”

“Um”, says Bob as he becomes increasingly fascinated with the top of his shoes.

“But wait, there’s more!” exclaims Sally

“We welcome change, even late in development, Agile processes harness change for the customer’s competitive advantage”

“Right Bob, I’m your bloody customer and I can see some obvious competitive advantage to hand here and I’m asking you to harness it for me!”

“But, Scrum Hell…” says Bob.

“You need to make a choice Bob, do you want to be Agile or do you want to follow the rules of Scrum to the letter? I had, until this point in time, thought that the entire point of doing Scrum was to become more Agile, not to be drowned in process and buracracy! It seems that I was mistaken!”

Bob is flummoxed. He thought he’d been such a good Product Owner, but now he felt himself torn between following the rules of Scrum and avoiding Scrum Hell or “being Agile”.

And then he thought of the solution.

Betsy. Betsy would know what to do. Afterall, this was a matter of process, why wasn’t she here?

Well Duh!

Sally called Betsy into her office, and they retold the story.

“No Prob” she said.

“Just Abnormally Terminate this sprint and then plan a new one. Bob avoids a painful eternity in Scrum Hell and you get your fancy new software built sooner rather than later. Just make you explain to the Team the reason as to why you’re doing this”

And so they did.

Sprint the Second – A series of unfortunate events

Jim, Gary & Peter have known each other since high school.

The news of the joint venture has delighted them as it means they now have a real chance to become squillionaires.

So when Bob announces the termination of the Sprint and the reasons underlying the change, they plan the new Sprint eagerly with the rest of the team.

And then they make a plan to celebrate…

And so they did.

Quite enthusiastically.

In fact they were so enthusiastic that they now can’t come into work for at least the next 6 days whilst their wives raise the bail money.

The rest of the Team optimistically soliders on for a few days, but after 3 days, all indications are pointing towards the cold hard fact that they’re on a Fool’s Errand. They can no longer deliver on their Sprint Commitment. Not a chance. Bail has been raised, but the three Amigo’s won’t be released from the county lock-up until the end of the Sprint at the earliest.

They ask Betsy what to do and she tells them that they need to tell Bob ASAP. She recommends that they agree to terminate this Sprint (as it’s no longer viable) and plan a new one, one that is achievable with the staff to hand but still progresses towards the overall project goal. Since Bob has just learned about abnormal sprint terminations, Betsy doesn’t forsee any problems and so lets the Team see Bob alone and heads off to her dentist appointment.

The Team meet with Bob. Bob goes ballistic. He tells them that he kept their commitment to them, and that they therefore need to keep their commitment to him.

The Team try to explain that the basis on which they made their commitment no longer exists. After all, if they could still deliver, why would they ever have originally needed 7 people to accomplish the goal?

Bob won’t hear a word of it. As far as he’s concerned, what the team is working on is “Super Duper Best Lucky Priority #1 Urgent Stuff” and he’s already terminated one Sprint already, surely terminating two in a row can’t be allowed. He decides it isn’t and tells the team so. Betsy said he could abnormally terminate a Sprint, not Sprints and anyway, he wants it done.

So Bob draws on his previous experience in “motivating” people and threatens the team: “If you don’t make your Sprint Commitment I’ll take the espresso machine out of the kitchen and dock all your bonuses by 20%”

The Team, horrified, nod acquiecense.

Dejected and feeling hopeless, they settle on a plan.

“Well, we could create the appearance of delivering this work, if we seriously compromised on quality and developed againt the current Alpha of Windows 9 – after all, it has a lot of what we need to do already built in”

“That’s hardly ‘Potentially Shippable’ though is it?” somebody asks.

“Who cares, he asked for something completely unreasonable, so let’s give it to him”

“Just make sure Betsy doesn’t find out about what we’re doing. She’ll go mental

And so they do.

Sprint Review

As per the plan, the Team develop a plausible facimile of the features requested. It only works on the latest Alpha Version of Windows 9 of course, but this is not at all apparent at Sprint Review.

Bob and Sally are both delighted. Bob secretly compliments himself on his management prowess.

Jim, Gary and Peter, recently released from the lock-up, sit at the back of the room, nursing their wounds and wondering how the team pulled off this miraculous achievement. But the mood in the room is so positive, that they say nothing.

Unintended Consequences

As part of the arrangement between ABC Corp and Company X, at the end of each ABC Sprint, ABC delivers the latest codebase to the Company X team. All this happens without the knowledge of the ABC Corp Scrum Team.

When the Company X team get their delivery, they are unsurprisingly less than pleased. The code is effectively useless, there are no tests, it’s full of bugs and it ONLY runs on a version of Windows that’s not expected to ship for 3 years.

They immediately tell Gareth, who turns a deep shade of beetroot red and immediately leaves to meet with Sally in person.

After her meeting with with Gareth, Sally considers taking a leaf out of Don Drapers book, but thinks better of it and settles for a deep breath and a walk around the block before going to see Bob. This time she remembers to make sure Betsy’s there too.

After some spirited discussion and finger pointing, Betsy soon uncovers the the root cause of the issue. She patiently explains to Bob and Sally that if the Team thinks the Sprint is no longer viable, and they can point to clear reasons why they think this is so, it’s probably better to listen to them than rely on wishful thinking and threats.

Sprint the Third – Life is hard and then you die

After a few false starts, and the addition of three new members to Alcoholics Anonymous, ABC Corp is ready to start work on the deal of the century.

With a full team, and an adjusted release plan, and under the watchful eye of Betsy, the Team plan to fix up the mess they made last sprint and then start on some entirely new functionality.

The Sprint Plan looks good, and they get to it.

However, halfway in, they discover that the map is not the territory. Design information that they had been given by Company X, information on which they’d based their initial estimates has turned out to be completely incorrect. To make matters worse they’ve also discovered areas of the Company X codebase riddled with technical debt. This is going to take a lot longer than first expected. So long in fact, that the seemingly perfect Sprint plan now seems impossible.

The mood is dark, most of the team would rather quit than ask Bob to terminate the Sprint again, but Betsy is adament and the three Amigos are game.

Bob discovers calm rational thinking

Bob, somewhat a changed man from his experiences to date, listens patiently. Bob and the Team discuss what the problem is, and what the impact is likely to be. They identify work that clearly cannot be done this Sprint, and descope it from the Sprint. Bob agrees to communicate this upwards to both Sally and Gareth. Sally should be pleased at least that this time it’s Company X at fault.

However, the team is concerned that this is still not enough and push to terminate the Sprint again.

Bob furrows his brow in deep concentration and asks them “So tell me why you want to do that?”

The Team stares at Bob blankly for a moment before replying

“Well it’s obvious isn’t it? We are no longer certain that we can meet our commitment, so we have no choice but to terminate the Sprint!”

“And then plan a new one…” says Bob.

“Yes, of course and plan a new one” chimes the Team.

“A Sprint Plan to do what exactly?” asks Bob.

“Turn the Product Backlog Items of Highest Priority into Software of Potentially Shippable Quality” the Team parrots back.

“Which are?” asks Bob

“Whichever ones you say are the highest priority, Product Owner, Sir! Yes Sir!” the team says in unison.

“Well I say the ones remaining in the current Sprint are the highest priority” said Bob.

The Team goes quiet until somebody mutters “But the code is a mess, we don’t know how long it’s going to take to do this…”

“But it can be done?” asks Bob?

“Well yeah, we’re pretty sure about that, just not how long”

“Do you think that there is a chance that you can pull it off in the time remaining in the current Sprint?”

“Well yeah, sure, there is a chance” says the Team “And even if we don’t get it all done, by then we’ll probably have a clear idea of how much longer it’s going to take, because we’ll have come to terms with it”

“Well, then get out of my office and go to it! We’ve agreed to descope the work that there is no chance of getting, and I’ll set expectations upwards about that. We’ll use the Sprint Time Box as a safety net. Try as hard as you can to solve the problem and we’ll see where we stand at the end of the Sprint.

“You know what to do so I’ll leave you alone for the rest of the Sprint to get on with it. Go wild, be creative, do whatever you need to do to figure this out and get this project back in control, if not moving forward”

And so they did.

Sprint the Fourth – Plain sailing

Sprint 4 proceeds without incident. Now aware of the technical issues and having fixed many of them this time around the team commits to a comfortable amount of work, and produces it all to the pre agreed definition of Done.

At the end of the Sprint it all integrates perfectly.

Jim, Gary and Peter start to peruse boat catalogues…

 

Creative Commons License
Sprint Termination Narrative Fragments by Simon Bennett is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Permissions beyond the scope of this license may be available at http://lasting-benefits.com/contact-us/.