Grooming will tear us apart

Grooming, or Product Backlog Refinement if you prefer, has always been a troublesome, not to mention kinda-boring concept in Scrum.

And in recent years it’s somehow turned into a meeting, which it seems most people hate, but do anything, because apparently they were told to. Apparently unless you don’t do something in a meeting then it’s not Agile (how ironic).

Having practiced Scrum for years without such a meeting I found myself wondering what people were doing in it. Turns out, at least in the cases I observed, that it seems to be mostly a combination of Planning Poker™, followed by demands for more detailed acceptance criteria and then arguing. Whatever floats your boat I guess, but it wasn’t my idea of a good time.

This “Grooming Thing” was also creating some kind of weird division, in what I’d always assumed was a Cross Functional Team. Suddenly the world was divided into The People Who Did The Work and The People Who Prepared the Work for The Other People To Do.

Weirdly, it was only The People Who Did The Work whose time seemed to matter, and was thus tracked and reported on in great detail, the preparation people were apparently free.

It was all beginning to sound like Waterfall, but with stand-ups and some other new thing called JIRA® (very useful for tracking how The People Who Do The Work are spending their days)

I however was keen to get back to the collaboration and cross-functional team stuff. I had good memories, it was both fun and effective. Neat!

But damn, Grooming is tearing us apart. How could we get the band back together?

What we were missing was a A Bright Line for Grooming. A way of describing Grooming that didn’t involved creating Groomers and Groomees.

And then it hit me, it’s so simple.

Grooming is any work you do that results only in a change to the Product Backlog.

Oh, you’re an idiot, I hear you say, we already knew that, that’s not new.

But hear me out. Because a simple example might make all the difference in understanding what I’m talking about.

Imagine a team that starts a story, and for whatever reason (it really doesn’t matter) the story is not finished at the end of the Sprint. We asked for a feature, a deliverable, but we don’t have that. What we have instead is increased WIP. No cause for panic. It happens.

What are the relevant Scrum Rules in this situation?

  1. Don’t demo the feature (mostly because it doesn’t exist)1
  2. Don’t put the feature into production (again, because it doesn’t exist)2
  3. Re-estimate the story to completion and return it to the Product Backlog

So what has the team done exactly? What’s their output?

A New Estimate.

What do we call it when the team estimates a Product Backlog Item?


The Team just spent the entire Sprint on grooming that story.

Wait a minute I again hear you cry (I really should get that web cam fixed)


That’s exactly my point, Grooming is an outcome not an activity. And above all Grooming is Work. It consumes both time and people3

Sometimes it’s obvious that we’re grooming, but other times we don’t know that we are until after the fact.

In my example, the only difference is that in this case the Team’s Estimate was based on coding, building and testing rather than (say) Planning Poker™.4

I don’t have my feature, but I do have an updated backlog, so you, my dear team spent the entire sprint grooming. ALL OF YOU.

What’s even more fun is that now we can finally make better sense of the Scrum Guide admonition that “A Team should spend no more than 10% of their capacity on Product Backlog Grooming”

It we take this rule into the my context for grooming it’s just saying “Hey Team! Try and spend 90% of your time on finishing things, not just starting or progressing things”5

To me that’s a far more useful interpretation than “Let’s disrupt the Sprint to ‘play’ Planning Poker® for 2 hours every Thursday”

And the best part? There is no longer an us and a them. There’s just us, because you never know when you’ll find yourself grooming.

  1. But that certainly doesn’t stop people from trying 
  2. If you’ve not finished a story, but you do have a feature you could demo and put it in production then you probably have another problem. You’ve definitely misunderstood a few things. 
  3. and souls if you do it the boring way 
  4. So yes, we’re also closer to finishing delivery of said feature. But the same is true of “other work” that many people relegate to the realm of Grooming, such as designing the User Interface”. It’s no different. Defining the end of Grooming as the start of coding is not particularly useful in my personal opinion. In fact I’d argue that if you’re doing anything to your Backlog Items that doesn’t bring them closer to final delivery, then you might want to think about why you’re doing those things! 
  5. A side effect of this is that you’ll need to start making things smaller if you want to achieve this goal. 

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.


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. 

Organisational Archetypes and Agility

A “classic” organisation basically has three archetypes:

  1. Doers
  2. Decision Makers
  3. Information Providers

These archetypes are pretty much self explanatory, and the operational model that they create should be familiar to most readers.

Doers perform the actual work; the work they do is directed by the Decision Makers. This is typically the “core” of the business. Often somewhat outside of this dynamic is a third archetype, the Information Provider. Their actions are also directed by “The Decisions Makers” and their work product is then directly consumed by the Decision Makers, with a view towards making better decisions.

Basically, in true traditional style, everything flows in and out of the decision making function, and decision making is kept deliberately separate from execution.

What happens when you Introduce Agile into this mix?

If you introduce an “Agile Bod” into this organisational dynamic, the system attempts to constrain it to one of the existing organisational archetypes.1 Where you end up depends on which archetype you most closely resemble.

ScrumMaster Shaped People

ScrumMaster shaped people are most often placed into the doer category, either in the form of “Process Police” or “Team Leader” or even “Project Manager”2

Agile Coaches / Consultants

For the Agile Coach role however, the only obvious choice is to make them Information Providers3

Thus the line between “training” and “coaching” becomes more an issue of delivery method than ontology.

What’s the problem then?

This mismatch fundamentally causes three problems:

  1. Bad ScrumMasters
  2. Unintended Power Battles
  3. Wasted Potential

Bad ScrumMasters

Even if you don’t know much about “Agile” you have probably at least heard the phrase “The ScrumMaster is a Servant Leader” or similar.

The problem is that the existing organisational archetypes don’t really allow for Servant Leaders4 – they allow for leaders as Decision Makers and Doers as Servants. Pick one.

Unintended Power Battles

So where does this leave the Agile Coach?

Agile Coaches are typically brought into organisations that are just starting out with Agile, or have tried and screwed it up somewhat.

One of the leading causes for Agile Screw Ups is of course the “not realising that this is a paradigm shift not a tweak” part.

And this is where it so often goes wrong; consultants are asked Waterfall Paradigm Questions that have Agile Paradigm answers.5

And worse, from the consultant’s perspective, the client is either not asking the right questions or focussing on the important things (at least wrt adopting Agility).

Since the consultant feels tasked (and at least partially responsible) for the client’s successful adoption of Agility, they react to this perceived lack of “correct focus” by offering increasingly impassioned unsolicited advice – which in the classic archetype model begins to look like they’re making decisions; and decisions only come from the people in charge; and consultants, if they are anything, are most definitely not in charge.

And thus you end up with an unintended power battle, the perception of a threat, where none was originally intended. Leaving behind it defensive, affronted management and a bewildered consultant who thought they were just trying to help. After all, they were just trying to save you from yourself…

Wasted Potential

So let’s assume lastly that for whatever reason no power battles ensue. We are still wasting potential here. Because the fact remains that (if Agility is the objective) the client probably is asking at least suboptimal questions and potentially directing their focus towards immaterial areas.

So instead of building a world class Agile capability, instead what you get is lots of people who are really good at Planning Poker™.

There is basically no dynamic apart from hiring on the coach as a manager (and thus letting them make decisions) whereby the organisation can benefit from anywhere close to their full expertise.

Rounding the corners

So the upshot of all this is that in order to really adopt agile, your organisation needs to be able to support and recognise at least two additional archetypes:

  1. Enablers
  2. Advisors

Enabling ScrumMastery

The enabler archetype is an oversight role which focuses on supporting rather than directing.

Without it, Servant Leadership, and thus ScrumMastery becomes nothing more than empty rhetoric6 or passive aggression.7
With it however, you open the doors for an entirely new category of management; which includes genuine ScrumMastery.

Advising on Agility

So the final “Enabling Archetype” is The Advisor. And allowing Advisors to exist and thrive in your organisation8 is Step One in terms of accelerating Agility (or the adoption of any other paradigm shift for that matter).

To borrow a term that the 1980’s rendered somewhat cringeworthy; it allows for true synergy between client and consultant.

It allows for a consultant / client dynamic where the consultant is allowed to take information in, then synthesise it with their deep domain knowledge and then spit out useful advice. Genuine contextually relevant advice. Not Best Practice. Not what the last client did. But rather what you should probably do.
It allows consultants to offer strategic, structural and operational suggestions clearly and concisely, without fear of reprisal, not hidden under one thousand layers of politics and double speak (lest the advice be mistaken for decisions and thus be perceived as a shameless grab for power)
In this way your organisation can safely and quickly navigate a paradigm shift; using Advisors as living bridges instead of seeing consultants as nothing more than expensive walking dictionaries.

  1. And if it can’t it will just spit you out. 
  2. I don’t place Project Managers fully into the category of “Decision Makers” here as they are typically tasked with overseeing that a decision is executed correctly not with making the original decision itself. 
  3. We all know that Agile Coach as “doer” is ridiculous ;) 
  4. Or more accurately Servant as Leader, as was the original phrasing that re-introduced the concept in the late 20th Century. This is clearly an even worse deviation from the norm. Many people read that statement as “And the Meek Shall inherit the Earth. Right Now” with the immediate follow-up thought of “Screw That”. 
  5. Or as Alistair Cockburn puts it, “You’ve just asked me a Shu level question that requires a Ri level answer.” 
  6. There is probably a 4th Universal Organisational Archetype – “Ballast” or “Window Dressing” – into which ScrumMaster and Agile Coaches can also be put. “We don’t really know what function these people have, we suspect none, but you’re expected to have them anyway”. This is however a slightly separate problem, because here, Agile is assumed to have no effect beyond the desirable qualities of adopting the brand. 
  7. I will forever be reminded of an Open Space session where a “ScrumMaster” proclaimed that they once tried letting their team self organise, but when they checked up on them “They were doing it wrong”. 
  8. And recognising that Agile Coaches should probably fall into this category. 

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


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

Carnivorous Vegans

A year or so back, I was asked to perform an extensive Agile Assessment on a particular organisation.

At first it was fairly typical for a gig of this kind – in short “Agile” had been popping up here and there in an organic almost mould like manner. Sufficient “Agile Mould” had however grown across the organisation that it had come to the attention of the PMO – and thus they wanted their “Mould Assessed”.

So I did.

As part of the engagement, I was asked to put together a formal briefing for the PMO and present my findings.

During the course of the engagement, I had been fortunate enough to speak to several clients and senior stakeholders – and so had insight into not only the current state of their “Agile Practices” but also how their customers felt about the project scoping and delivery process in general. I figured this was useful information, so I decided to incorporate these findings into my briefing.

Once we got to the “findings” section of the briefing I announced that I had Good News and Bad News.

The Bad News was that the Agile I had encountered was really not very effective. That is to say, like so very many organisations, only the window dressing had been adopted, and the fundamental processes and mindset’s hadn’t really shifted at all; as a result neither had any of the project outcomes.

The Good News was however, that Actually Doing Agile would be an excellent approach to working towards solving their clients’ frustrations – pretty much every client lament fell directly into the Agile Wheelhouse. Their clients would be delighted with an iterative incremental approach to both delivery and planning. It would have literally saved millions.1

The Head of the PMO was outraged. I mean really really angry.

Here I was going “Have I Got Good News for You” and he’s reacting like I’d just run over his dog, while his wife was holding it.





and so the meeting ended.

I have no idea what happened next (I did get paid if you were curious), but on reflection I regard the engagement as a great success, because it was pretty clear that they had no real interest in making Agile work and thus it would have been frustrating for everybody to have tried.

In fact, the Idea of Agility was completely repugnant to them. Agile (or Scrum) was only appealing while it appeared to be institutionalised micro management – they saw a meeting that appeared to be tracking developer activity on an hour by hour basis – and figured that that was an appealing adjunct to their existing Project Management Processes. MOAR CONTROL!

As bizarre as it might seem, I can respect that. They knew who they were and what they wanted and when I helped them understand the implications of what they’d asked for they made a clear choice.

I hope they feel the same way about me. I didn’t try and “Talk Them Into Agile” (beyond reporting that their clients really liked the idea) – instead I respected their (informed) choice to reject it as an approach.

As such I think we both dodged a bullet and saved a lot of unnecessary confusion and suffering.2

But if I hadn’t outlined the end game so clearly, what might have been the alternative?

Carnivorous Vegans

Over the years I feel that I’ve gotten better and better at explaining both Lean and Agile; some of you, after reading the above, however may feel as if I’ve gotten too efficient at it for my own good.3

The alternate thou is something I’ve come to call “The Carnivorous Vegan”

Doesn’t make sense? Let me explain.

Imagine for a moment, that Veganism becomes the absolute trendiest thing in the whole world. Basically you can’t get a date or job unless you’re Vegan.

So to survive you need to be seen to be being a Vegan.

But deep down inside, not only are you not a vegan, you’re actually the opposite, you crave meat and deeply dislike vegetables.

In fact even the thought of vegetables makes you sick.

So instead of actually being a Vegan, what you do instead is “Play a Good Game” – you give lip service to the rhetoric and join the Vegan Society but that bowl of carrots you appear to be having for lunch is in fact shaved cocktail wieners dyed orange.

And if enough people start behaving this way, then the word Veganism slowly begins to lose its meaning.

In this scenario, Being Vegan stops being a choice and instead becomes a watchword for mindless cargo-cult hypocrisy.4

And this is what I’m seeing happen with Agile.

Unlike the typical coaches lament, where an organisation genuinely wants the Agile Benefits but is struggling to put in the Agile Hard Yards, these Carnivorous Vegan organisations don’t even want the benefits. They need to be seen to be “Doing Agile”, but deep down inside they really just want Waterfall to Work.5

For Agile to mean anything, it needs to be a choice not a default.

And Waterfall also needs to be a seen as a choice not an enemy.

Yeah, sure, you can prefer one over the other and even be passionate about your choice and even encourage other’s to make the same choice. Believe me, most die hard Vegans and Paleo’s are passionate about their choices.

But being passionate is not the same as being a closed minded zealot.

Respecting people’s right to choose is important.6

Because if “Doing Agile” stops being a choice, and instead becomes the “Required Default” it’s slowly but surely going to stop being “Agile”.

And that’s something I’m passionate about preventing.

  1. This may actually have been the problem. 
  2. So this relates only to the PMO. The clients are probably still suffering, perhaps more so, depending on whether the proposed additional controls went into place. However, the clients were not my client – but perhaps they should have been.
  3. So let’s be clear here. The same approach often results in the reaction “Awesome – Give Me Some of That Please”. These gigs turn out well because people know what they’ve bought, why they’ve bought it and what they’re getting themselves into. 
  4. So interestingly perhaps, this is more true of vegetarianism. I’ve seen people profess to be vegetarian and then immediately eat a roast chicken. Actual Veganism however largely steers clear of this trap by having a very clear bright line as to what it means. No Animal Products. At All. 
  5. It is interesting just how many people think that Agile is a set of techniques that make Waterfall Projects work better. 
  6. And thus take responsibility for the the consequences, both Good And Bad of those choices. 

Adapting to Context is great, interpretation is terrible

Let me tell you a story about the worst Sprint Review I’ve ever seen. 

I had been invited along as part of an engagement to rescue an Agile Project in serious trouble. 

It was held in a Board Style Room the kind with the long oval table and the Product Owner sat at the head of the table and the remainder of the “Scrum Team” sat at the bottom of the “U”.

There was not a computer in sight.

And then one by one, each person gave a report to the Product Owner – basically listing, in quite extraordinary detail what they’d done over the past two weeks.  Imagine a small child giving a report about “What I did over my holidays” and you have the flavour.  It was a litany of relentless activity.  I could barely keep up. Most developers were reading from quite detailed notes that they’d obviously pre-prepared.  Most timesheets aren’t this detailed!

But at the end of each speech – the PO would smile benevolently and say “Well Done, Next” – and then the next person took their turn.

This went on for well over and hour, close to two.

At the end of the meeting I had to ask “What meeting was that?”

“Sprint Review of course!  Surely it was obvious!  You’re the expert!”

“How, was, that, A Sprint Review?” I replied.

And then I was parroted back a line from some Scrum Guide or other “At Sprint Review, the Team demonstrates to the Product Owner what they accomplished”

“Software I said, Software, that they, as a team, managed to build”

“Oh, we don’t have any Software Ready, never do”

Velocity and the Sunk Cost Fallacy

2015 seems to be the year of Velocity.  For whatever reason both the haters and promoters have been out in full force for a lot of this year.

So there has been a lot of discussion about it recently in both coaching and client circles.

But one of the more surprising facts for people who are attempting Scrum is that not all work counts towards Velocity and that this is by design.

Groom to Ready, Sprint to Done

The majority of the time there are two strands of work going on inside a Scrum Team – Grooming and Delivering.

The Delivering is the part that most people are familiar and comfortable with.  Given a set of defined planned deliverables, how many were we able to complete to a pre-defined and fixed level of quality?

Scrum, being almost aggressively Agile however, only regards “Software as its measure of progress” and thus only counts Delivery of Software as progress.

Thus Grooming never really contributes positively to Velocity, but it can detract from it.1

The Upside Of The Divide

So if your skills primarily fall under what Scrum would class as “Grooming” then you may feel a little hard done by all this.  Where are your points!  You worked hard!2

Until you come to the realisation that in order to get points you have to estimate points.

Not so keen now are you?

Nobody really likes estimating, but there is a massive difference between an actual estimate “I think this can be done and I think this is roughly how long it’s going to take” and a forced estimate “I actually have absolutely no idea how long this is going to take, but you’re forcing me to give you a number, and so here you go, do you like this one? If not, I have others…”3

Much (but it has to be said, not all) of what we do in Grooming is rather open ended – Design, UX and so forth – and it also doesn’t tend to fit neatly into two week time-boxes.4

And this is precisely why Grooming doesn’t count towards velocity – it encapsulates the “fuzzy part” of Software Development.  

The stuff we have trouble quantifying upfront.  

It’s actually kind of cool.

Creating Pressure to Do Something™

So here is the interesting part.

Grooming doesn’t directly contribute to your velocity per se – but it certainly can affect it!

Think about it like this.

Imagine a Team that has a Nominal Starting Velocity of 20.

Now imagine that they only have 8 points of “Ready Backlog”

If they’re playing by the Strict Rules of Scrum5 then this means that even thou they have the “capacity” to deliver 20 points of “stuff” they only plan in 8, and thus their Velocity will only be 8!

This “sub optimal” Velocity has a simple cause6 – not enough stuff is “Ready” – and the only way increase Velocity is to get more stuff ready. (Which is what I’m assuming my hypothetical team actually spent their time doing)

Starting a Project the Scrum Way

So the upshot of this is that if you start a Project with Scrum – there is a natural pressure to stop navel gazing and start trying things.

Because it’s only when you start trying things that you’ll start generating the oh-so-popular velocity that all the kids are talking about.

If you’re working in two week sprints and spend 6 weeks “getting ready” then it’s going to look like you spent 6 weeks not delivering anything (probably because that’s exactly what’s happened – at least from an Agile Perspective)


You don’t start doing Scrum until you’re Ready.

For a bunch of reasons a lot of places don’t use Scrum as described above.

Instead, even once they’re “post Agile” they still spend a lot of upfront time figuring out what they should do.  A lot of time “Getting Ready”7

Perhaps it’s out of habit or organisational convention, or perhaps it’s simply out of a deep rooted fear as to what an idle developer might get up to.  For the purposes of this post however, it’s sufficient to know that it’s been done.

Sunk Costs Sink Submarines

So now, imagine that instead of starting off a Scrum Project and feeling a subtle pressure to start delivering something and getting feedback on it8 instead there is a different pressure.

This pressure is the pressure to realise some value out of all the time and money that “we’ve” already spent.

If you spend 6 months and $500K before you start sprinting – then the sunk cost fallacy9 is going to drive you (or more likely your customers and stakeholders) to try and realise some value out of that exercise.  Whether or not that’s even possible.10

To make matters worse, your customer will also probably be positively allergic to non determinism and exploration by this stage; because from their point of view that nonsense should all be done by now

As such – they’re going to want to see a lot of Velocity and Story Points on everything.  We know what we want – deliver the damn thing!  Yesterday! MOAR VELOCITY!

Sailing the Seas or Hiding from the Waves

The bottom line here is that discovery and delivery are both equally important.  Delivery without discovery may well be pointless and discovery without delivery definitely is.

Scrum is far from perfect, but it does provide a mechanism whereby we can attempt to balance the two and successfully navigate our way across the choppy seas of complexity to Project Success Island.

But perhaps unsurprisingly it works best when embraced holistically and whole heartedly.  And part of that is coming to terms with embracing uncertainty navigating through it rather than trying to hide from it by ducking under the waves in the Discovery Phase Submarine.

  1. Considering that a well behaving Scrum team will never start work on Backlog Items that are Not Ready then it’s more than possible that such a Scrum team will be unable to plan a “Full Sprint” worth of work – and thus  their “velocity” is throttled by the amount of “Ready” work available. 
  2. The Problem here however is not Scrum, Velocity or even Story Points™ – the problem here is with your organisation’s understanding and misuse of Velocity. 
  3. Forced Estimates are interesting.  And by interesting I mean evil.  Because they’re just completely and utterly made up they tend to reinforce all the pre-existing stereotypes that many organisations already have regarding estimates in software development.  Most people are actually quite happy to agree to a completely new estimate if the original estimate was completely fabricated to begin with; as the objective here is clearly to supply a number, not the creation of a meaningful delivery forecast. 
  4. And trying to force it to usually ends badly. YMMV. 
  5. This phrase always makes me think of the golfing scene in Goldfinger.  Ironically, this is where James Bond cheats in order to win the game. 
  6. Which if you’ve ever been a jobbing ScrumMaster® is actually a nice change… 
  7. With the ironic position being that even after all this time, because “Scrum” has not been considered to have started, no Backlog Items are actually “Ready” yet. 
  8. Which also means starting to reveal some of our assumptions. 
  9. “Throwing Good Money After Bad” – the sunk cost fallacy or “Escalation of Commitment” is a cognitive bias which drives people to continue down a course of action simply because they have invested so much it in to date.  It is specifically a problem when the chosen course of action is now known to be the wrong one.  The fallacy itself prevents decision makers from even considering that they are taking the wrong course of action.  For a personal example – if you are at a fixed price all you can eat buffet – you are falling victim to the sunk cost fallacy if you eat well beyond your comfort level (especially if the food is not good) – because you feel the need to “eat your money’s worth”. 
  10. And guess who’ll be getting the blame if it’s not possible to realise any value… 

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. 

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.