Category Archives: Agile

Harder, Better, Faster, Stronger

Ask the average person today why they’re currently doing or planning on moving to Agile and they’ll probably say “it’s faster”.

It’s a very popular answer.

But faster at what exactly?

If pushed, they might elaborate “faster delivery“. And then give you a funny look as if to say “What other kind of faster is there?”

So whilst on the surface of it, this sounds like a purely good thing — there is, or at least there can be, a dark side.

This focus on faster delivery in my experience has often led to implementations of Agile which are nothing more than a relabelling of Waterfall, with stand-ups, “stories” and JIRA® added like props1.

The “agile” or “Scrum” part is applied only to the bits of the endeavour deemed to be “the delivery”, which in its most extreme form2 means “The part where the code is written“ 3.

This is what I believe most people mean when they say “Agile Delivery” — a practice which I would prefer to refer to as “Incremental Delivery” — but more on that in a separate post.

But what if that’s not all there is? What if there was more? What if there was better.? (Even if it was harder)

On the Origins of Faster

As ubiquitous as this “Agile is Faster” belief is today, it’s hard to pinpoint exactly when people started equating Agile with speed. After all, the term is “Agile” not “Speedy” and it’s the “Agile Manifesto”, not the “Go Faster Manifesto” so the origin doesn’t entirely lie with the name. eXtreme Programming also offers no real hints, the scrum is probably the point in a rugby match with the least amount of forward movement and Crystals, well they just sort of sit there4. So it’s not immediately intuitive. It’s certainly not misleading.

At a guess, I would conjecture a few things might be casual here:

There are two Agile Manifesto Principles5 which mildly allude to speed:

  1. ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and;
  2. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Which both sound at least a little bit urgent. Although they seem (at least to me) to emphasise regularity more than they do raw speed. At least the term “deliver” is there.

And then there is Velocity

Whilst a Rugby scrum may be relatively static wrt to delivery, one of Scrum’s6 most (in)famous contributions to the Agile canon along with The Sacred Lemming Mantra is velocity.7

If was a betting man, I’d put my money on velocity and it’s cheerleaders being the culprit here. Whilst the Agile Manifesto principles somewhat allude to speed – they don’t outright say it. Whereas the concept of Velocity absolutely does.

How fast is your Waterfall?

OK, so that’s where it might have come from, but so what? Velocity is great!

What could possibly be the Problem with Velocity?

Well, depending on your perspective, maybe nothing. Or maybe everything.

My personal problem with Velocity is that it’s just a raw measure of output. Even its biggest proponent Jeff Sutherland, talks about how he “rates his Product Owners on a dollars per point metric” — which signals very clearly that the Velocity metric itself, is completely devoid of any value or benefit component.

On an Agile Project, that’s kind of a problem. Especially if you’re not tracking anything else except velocity. It’s no good being early and continuous if you’re not being valuable.

But on a Waterfall project, that’s not a problem. Velocity and lots of it, is all you need. By the time we get to the delivery part in Waterfall, value is assumed. Value was pre-determined and fixed really quite early on in the project, sometime around the point when we got our requirements right and estimates acceptable and it was all signed off.

In this situation, Faster Delivery is absolutely a good thing. We know what we want, you just need to get it done.

Faster in this context also often defined as “Faster than your original estimates” — which is why claims of “move to Scrum get hyper-productivity” are so seductive.

It’s less of a state of being and more like a request “Can’t you get it done any faster?”8

Harder

But what if that wasn’t true? What if the requirements were not in fact right?

What if, <gasp> the estimates were wrong?

And what if, that sort of thing happened on a regular basis?

I mean, that’s absolutely ridiculous of course, and would never happen where you work I’m sure. But let’s just imagine it’s true, just for a moment, and explore what that might mean.

If this was the case, then when would you want to know that a mistake had been made? (Assuming you have rational and not political goals and additionally don’t have a job lined up at a competitor)

As soon as possible right? Would that be valuable to you?

Damn right that would be valuable. The more time that passes between having made a mistake, and finding it and correcting it, the more damage we do. We humans have a tendency to compound our errors — and this is doubly true with Software.

Therefore, in a world where we only have imperfect information and mistakes are made, then early detection and correction of those mistakes is something we’ll definitely want.

Work it harder

So how do we discover that something is not as we’d like it to be?

Perhaps we should just rely on our people to tell us.

Because people just love to show you that they’re wrong don’t they? I mean, if a developer suddenly knew that a requirement was wrong (and they’d know surely?). Then they’d ask somebody.

And if and when they asked, they’d also be taken super seriously too, I mean there is no chance at all that they’d be branded as a whinger and told to get back to work and mind their own business? (Which is of course delivery)

And further, even if the problem detected was nominally in their realm of responsibility, say the implementation approach or the estimated time to complete. Then there is no chance that said developer would be branded as incompetent having revealed this information?

It’s a good thing we have professionalism, because if any of those things were true people might be tempted to hide problems rather than face the possibility of criticism and ridicule.9

Not to mention the fact that a great many people just don’t like feeling incompetent. So they tend to hide the truth not just from others, but also from themselves. Oh right, professionalism totally fixes this too, I forgot.

So considering all of this, there would therefore be absolutely no need whatsoever to say, stop development every two weeks, on the regular, so that we could give feedback on what had been done to date, and then immediately act on that information? And there would also be no need to share a common definition of what it means to be done with something; because there is absolutely no chance that something might work on a developers laptop, and not at all once integrated with all the other changes and put into production. And that we showed you it now, because, well you were here, and we assumed that there would be no problems. Because we are, of course, professionals.

None of this is required obviously, because we don’t ever get angry with each other, not even passively and as a result people never want to hide their mistakes (because we’d also never decide to just stay back and fix them quietly) and because none of this ever happens, none of this is necessary.

The Horror of Harder

Because if you did do that, if you did stop to fix the issues when you found them, then that would impact your delivery schedule.

And that would be terrible. I mean, fixing mistakes slows down your delivery. (As does quality and testing, but that’s a story for another day)

Much better to simply raise a ticket. So when a stakeholder says “You better raise a ticket on that” you can professionally reply “I already have”. And then you will get a serious nod, so that you know that you have been sufficiently professional.

After all, a ticket is as good as a fix. Ask any user!

Raising a ticket allows the Developers to Continue On With Delivery and let some business proxy representative Showcase just how on schedule we are to anybody who doesn’t have anything better to do that afternoon.

Better

Unless of course we interpret the “early” in “early and continuous” to meaning gathering feedback early and continuously?

And not “early” as in “earlier than your pessimistic original estimates you lazy bastards”

Even the delivery focussed “with a preference to the shorter timeframe” principle could also be interpreted to being about getting real world feedback on what we’ve built ASAP as much as it’s about Capital D Delivery.

“Delivery” has such a ring of finality to it. A ring of correctness. Which is the way we like it in Waterfall. A land where everything is perfect and there are no mistakes. Just disappointments and failures.

And ironically if you focus on delivery, you’re more likely to be predisposed to ignore feedback you’re getting from your production users (assuming it’s going to the delivery team at all and not to some BAU or maintenance function)

So putting stuff into actual production quickly and regularly is really just another way of gathering feedback, really really meaningful feedback, as to whether what we’re doing is working or not.

The concept of Early from this viewpoint means “in time for it to be easily and cheaply corrected“.

Time to make it Better.

Defining Working

One of the key characteristics of “Agile Delivery” is that it runs off The Engine of Acceptance Criteria. When I first tried XP as a practitioner, a User Story was a sharpie scrawl on an index card. Most of the User Stories I see today would probably need to be printed out on a roll of toilet paper there are so many details and acceptance criteria. Which is why I guess, these days, User Stories rarely dare to venture outside of their JIRA® branded fortress.  Where they are very safe indeed.

In this case, “working” can and usually is, defined as “meets all the acceptance criteria” (or in some case “provisionally meets” as there will of course be a giant test phase at the end of the Project after the “Agile Delivery” is over). Once said “stories” have met these pre-contracted and comprehensively documented criteria, then and only then is it considered safe to “demo” them, as we are now sure there will be no surprises. And surprises are of course awful. 10

But what if there was another way to define working? One that actually required people directly affected by the software to use to the software before they could make the determination? I dunno, in some kind of regularly schedule review?

If we did that, we could save a bit of time on all these acceptance criteria, sure we might still need a few, but instead we’d be tracking towards whether or not we’d done something useful, instead of merely what we had been told (or could justify having done).

But that sounds like it would slow down delivery! I can hear at least some of you cry.

Faster

The good news here is that there is a different kind of faster available to us, not of delivery, but of faster problem solving.

This is what it means to me, that Agile is faster.

It does however mean that we have to start measuring from a different point. Faster Delivery by definition only starts at the point that you’re declaring that you’re ready for “delivery”.

At best, Agile Delivery looks something like this:

We are timing how long it takes from the point we’ve defined and designed our solution to when it makes it into production. You might be overlapping some of those “phases” and I hope you are, but we’re still tracking the same two endpoints.

Sometimes thou, Agile Delivery does not include deployment. In some places, that belongs now not to Agile (apparently) but to some newer, younger, cooler thing called “Dev Ops”11 — and thus Agile Delivery has in these places been redefined to this:

Or God Help us, this:

Faster Problem Solving on the other hand is measured from two different end points. Two points that are not even on the above diagrams — because they sit directly before and somewhat after Define and Deploy in our above Waterfall Hybrid Agile examples. Something you might hear referred to in Lean Circles as Concept to Cash.

To navigate down this little stream will require a degree of iteration. The linear left to right arrow is, I apologise somewhat misleading, and merely represents the passage of time, and not linear, even progress.

But problem identification and value realisation are not typically seen as IT issues, that is the domain of The Business! If you define the project like that, then we’d end up with Business People and Developers working together daily, and what would that lead to!

A prominent head of contract negotiation at a major bank once declared it to me as total madness. And pointed out that collaborating with the enemy IT Department is considered in many organisations to be treason. Punishable by lack of career progression.

Stronger

Solving problems creates value. There is nothing more valuable to a person, or an organisation, than solving a problem for them.

Everybody likes to talk a big game about “value” and as a result the term has become a little abused and ill defined. I’ve seen BA’s argue until they’re blue in the face that the requirements document that they just spent two years writing is VALUE. (Even thou 30% of the original users have now retired). Perhaps this is a legacy of the term “Value Add” (as in Value Added Reseller or VAR) — a world where simply doing extra things, was regarded as “increasing value”.

But my guess is that the problem with the term “value” is that it people take it personally. Deep down most people want their work to have value, so that they themselves feel valuable. If you’re a BA in the 21st century workplace, maybe you feel that you have to “declare value” at the point of writing your requirements, because the chances of you seeing them make it into production are terrifyingly slim12.

Which is why, for reasons of clarity and equanimity, I’m talking about Problem Solving. But if you’re a traditionalist, you can think of it as Value Creation if you like.

Either way, it’s a far bigger deal than just quicker delivery.

Makes us stronger

To me, the Working Software alluded to in the Manifesto has never meant software that merely compiles and runs. Software that can stay up for the 5 minutes required to “demo” it.

Frankly I’m not sure why anybody see it that way, but they do. I guess it’s easy. (See Harder)

To me, Software is only Working when it’s solving the problem that we originally hoped it would, or other problems that we didn’t even know we had, but are glad to have removed from our lives.

Software that is working for us.

Software like that does not live in isolation, but is part of a bigger thing. Part of a solution that makes us all individually stronger, capable now of achieving things we could never have done before without it13

Now you might end up with a result like that if you just focus on faster delivery.

But is that a risk you really want to take?


  1. This is of course only a problem if this was not what you intended to do. 
  2. Actually this is not the most extreme form, the most extreme form is “just some of the Software Developers on the days where it suits us” 
  3. By which I mean the coders, or programmers, or whatever else you want to call them. The whole concept of “developers” meaning everybody never really took off in any meaningful way and is at best confusing, so I think ideally we should give up on that one. 
  4. Regardless of colour. 
  5. Interestingly enough there is nothing that could even remotely be construed as providing or requiring speed in the Four Agile Values. 
  6. Although XP also had the concept of Velocity, it is, and always seems to have been, more closely associated with Scrum. Scrum thought leaders have certainly been the most active in promoting it. 
  7. And it’s slighter more attractive half sister from Florida — hyper productivity. 
  8. Said the Project Manager to the Pregnant Woman. 
  9. Unless being professional means never making mistakes in which case… 
  10. Unless of course you’re interested in gathering information cheaply and effectively, in which case they’re awesome. See my talk “Adventures in Advanced Product Ownership” for more details, or take an Information Theory course at a nearby University. There are probably other options, but those are the best two I can think of at short notice. 
  11. Now some readers might be under the impression that Dev Ops has something to do with Developers getting involved in deployments and operations! But according to some very Senior and very sure that they are correct Managers I have met, a “Dev Op” is a new kind of person in a new kind of team and the developers better damn well keep their nose out of it. 
  12. There are at least two factors at work here in my personal experience. I spent a few years consulting to one organisation which cancelled projects with an alarming regularity. Usually after they had been running for several years. Additionally if you work in a place where almost all projects are large, then depending on the industry it’s not unlikely that the lifespan of the project far exceeds the tenure of the majority of the people working on it. 
  13. Even if the only thing it does for us is give us back extra hours in our days, which might be the most valuable gift of all. 

A time box is both a limit and a commitment

Time Boxing is an interesting technique that’s found at all sorts of sizes in all sorts of places. My favourite time boxes probably belong to the Pomodoro Technique.

The Pomodoro Technique is not only a great practice in itself, it’s also a great way to understand what a time box is, and explain it to others.

If you’re not familiar with the Pomodoro Technique, the basics of it are insanely simple:1

  1. Pick a thing to do
  2. Do that thing and only that thing for the next 25 minutes
  3. Stop and take a five minute break
  4. Decide whether to continue to work on your original thing for another 25 minutes, or switch to a new thing and do THAT for 25 minutes2
  5. Repeat

You get the idea.

This also beautifully illustrates the dual nature of the time box.

On the one hand a time box is a commitment to:

  1. Focus exclusively on just one thing
  2. To maintain that focus for a full 25 minutes3

It’s the perfect antidote to today’s attention scattered world. You’re not committing to finishing something, you’re just committing to working on it and only it for the next 25 minutes. And if you’re not willing to commit to spending 25 minutes, then perhaps it’s not that important.

On the other hand a time box is also a limit

So whilst you have to work on your thing for at least 25 minutes, you can also only work on your thing for a maximum of 25 minutes.4

In my experience, this actually makes picking what to work on a lot easier. Knowing that the maximum investment is going to be limited to 25 minutes, you can worry less about ensuring that you’re working on the absolutely positively highest value thing. The time box caps the amount of time you can “waste”5 before you realise you should be doing something else.6

What’s brilliant about this system, is that it exploits the fact that humans best understand the following three things not by thinking about them, but by doing them:

  1. How important something is
  2. What’s important about it
  3. How long it’s really likely to take

So through this process, we not only Get Stuff Done, but also learn to make better, more informed decisions (in shorter amounts of time).

The commitment aspect helps us to get more done.7

The limiting aspect helps us to get the right things done, the right way at the right time. Thus maximising the return we get on our overall investment in time.


  1. Although like so many things of this nature, it’s very easy to make it more comprehensive if that works for you. 
  2. Now that I’ve written it out, it looks a lot like Lean Coffee, which in 2019 more people may be familiar with. The Pomodoro Technique, pre-dates Lean Coffee by a good ten years (at least) — and whilst it was originally designed as a personally productivity tool I have memories of running meetings using it. I remember running a planning day in 2007 using the Pomodoro technique which was both productive and exhausting. 
  3. Actually, you can focus for any length of time, 25 minutes is just the most popular, possibly because you can fit both the work and the break into a half hour, which makes them easy to schedule and plan with. It’s also just a good length of time for most personal tasks. 
  4. This can for some people actually be the harder thing to do. 
  5. I personally don’t think time is wasted if you discover what your real priorities are. I defy most people to do this well through 25 minutes of inaction. 
  6. Whilst at the same time allowing you to progress something that was important enough for you to start
  7. It’s a WIP limiting technique if you think about it, except it’s not using stickies, it’s using time. 

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. 

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. 

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. 

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?

Those Estimates are Wrong

So enough water has passed under the bridge now for me to feel comfortable telling this story.

Some time ago, I was working with a client who I had helped adopt an Agile Way Of Working (so far no surprises)

As a large portion of their work was what could be best described as “Software Development Work for Hire”, once they got the basics mastered for in house jobs, their attention quickly turned towards “How could we use this way of working to deliver software to our clients?” Quite frankly, they were sold on both the process and the results, and were keen on passing on the benefits.

So the discussion then quickly moved onto the age old question of “What am I going to get and when am I going to get it?”.

Since real money was on the line we embarked on a three day workshop using some fairly sophisticated risk and forecasting models to create what we all believed was a genuinely economically viable release plan and project cost. We were living the dream.

It was at this point that the account manager decided to join us in the conference room to see the fruits of our labour.

It did not go well.

His face went red, his temples began to pulse and spittle began to form at the corners of his mouth.

"I can't believe you spent 3 whole days on this and then GOT THE ESTIMATES WRONG" (he spluttered)

The Team was gutted and I was incredulous.

For my sins, I tried to explain that actually, as far as estimates go, these were pretty good ones. I foolishly started to explain the process and the science behind what we’d done.

It didn’t help. The Estimates were COMPLETELY WRONG.

Then I twigged. If our beloved account manager was claiming that our estimates were wrong (with absolute certainty I might add) , then clearly he must know what the right estimates were.

So I simply asked – “How do you know they’re wrong?”

His reply?

"Because I've *already agreed* what the estimates are with the client and they've signed off on them. "

“Regular” Products Iterate too…

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

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

My Refrigerator

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

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

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

Basically because we didn’t know how…

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

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

The refrigerator has iterated.

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

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

Refrigerator MVP

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

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

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

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

Don’t fight the iteration, instead admire the speed

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

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

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

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


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