Best for me, best for now (Practice)

In my last post, I covered the concept of “Best for Me” Practice.

In this post I want to extend that a little further into “Best for Me, Best for Now” (Practice).

The Tyranny of “Best”

“Best Practice” is often held up as a gold standard – something to aspire to, rather than to do.[1]

This leads broadly to two dysfunctions:

  1. Aiming too high
  2. Aiming too low

Aiming too high is akin to somebody who desires to increase their fitness through running and reads that “best practice” for fitness running is to run 5km, in under 45 minutes three or more times a week. They walk out onto the street, never having run a step in their life and hop to it.

Aiming too low is akin to somebody who reads the same advice and decides that “well, given that I’m 80kg overweight and struggle to walk down to the shops, I could never do that.”

Neither case is likely to ever reap the benefit. (And if it’s not obvious, aiming too high can rapidly lead to aiming too low, with a short bout of depression and self loathing in the middle)

Focussing on Outcomes, not Activities

Ultimately the real problem with Best Practice, is that it places the focus on the means and not the ends. There is a massive leap of faith that by doing this, we’ll get that. And if you’re not getting this fast enough (or at all) then just do that harder.

Rather than trying to run 15km a week, both our hypothetical couch potatoes would be better off taking on board a “Best for Me, Best for Now” approach.

The outcome they want is a longer healthier life; and the best first step is probably along the lines of:

  1. Walking a little more than they currently do
  2. Making some dietary changes
  3. Adding other physical activities that they enjoy and will sustain and won’t cause injury [2]
  4. Tracking some metrics – looking for correlations[3]

“Best” Practices, like MVP’s[4] should be considered as hypothesis

If you did those four things – then you would rapidly[5] become a different person with a different capability (and potentially even different goals).

And thus Best for you, Best for now would change.

And that’s a good thing.


  1. And if it is seen as something to do, then often the question turns to why aren’t you doing it now?!  ↩

  2. When you focus on the outcome, you free yourself up to explore other alternate paths to reaching it. Running is a way to get exercise, it’s not the only way. Considering that when it comes to weight loss, exercise is more about improving mood than it is about burning calories, it’s doubly pointless to do something that you don’t enjoy.  ↩

  3. Perhaps measuring this with a FitBit and some bathroom scales. Noticing that on the weeks they walk more, they lose or at the very least maintain their weight and feel better to boot.  ↩

  4. Minimal Viable Product  ↩

  5. OK, this would depend also on your age, starting weight and whether or not you had any pre-existing glandular or metabolic conditions, but hopefully you get my point.  ↩

Best (for me) Practice

What do we mean when we speak of Best Practice?

Best Practice is a rather polarising term. Very few people are neutral about it. It’s either the watchword of an organisation or an instant irritant. But what does it actually mean?

Genuine Best Practice

As previously discussed, in Authentically Simple Systems – the term “Best Practice” is entirely valid. Given the current body of knowledge, there is One Best Way to perform this task.

To do otherwise would be, by definition, either inefficient or unecessarily prone to error.

But this term is used widely outside of the Simple Domain; and not ironically.

Best (for me) Practice

A lot of the time “Best Practice” is really just a shorthand for “Best for Me” Practice.

But this shorthand can actually hide two completely different intents…

Best (for me) Practice, given that I don’t want to take responsibility for my own actions

This is, at least for me, is the darker and more frustrating meaning I’ve encountered.

It often equates to “just tell me what to do”, with the subtle undertone of:

“If this doesn’t work, then it’s not my fault, because you told me it would work. I didn’t fail, the practice did. And so did you for recommending it.”[1]

Best (for me) Practice, given my context and your knowledge

If you’re not a Complexity Geek, then you’re probably not as hung up on the term “Best Practice” as much as some people are.[2] To you it infers something actually far more wooly, subtle and frankly more complex[3]:

“Given everything you’ve seen about our situation so far, combined with everything you know and your general experience, what are the best recommendations you have for us?”

Which to me, seems fair enough. Even if I still rankle occasionally at the term.

So how can we tell the difference? (And also avoid a pointless argument about nomenclature?)

Practice or Principle?

One aspect of the concept of “Best Practice” that is I think universal (regardless of the meaning you adhere to the term), is that a Best Practice is something that’s been tried before by somebody else[4]

The logic is sound (if not overly courageous):

Somebody else has already taken this risk, figured this out and now I’m going to reap all the rewards, while taking none of the risk.

This all seems fair and theoretically puts a new spin on our two “Best for Me” cases above, effectively merging them. Both are simply risk adverse and wanting help.

But now we’re back to square one – because it’s only for systems that live in the Simple Space that cause and effect is infinitely repeatable.[5]

And if that’s true, then Best Practice may not be as simple as it seems after all[6]

Fundamental Attribution Error and confusing correlation with causality

Just because somebody has tried something before and they were successful (even repeatedly so), doesn’t mean that it was those practices in particular that caused (or even contributed) to their success.[7]

As science progresses, every day we’re discovering new evidence that much of what we considered causal is now correlated at best, and in some cases completely unrelated.[8]

Best Principles? (or how to tell the difference)

And this is how you can tell the difference between a “Best for me in my context” and a “Best for not taking any responsibility” intent.

Those folks who are genuinely interested in better outcomes for their problems in their context will take on board the concept of Best Principles – Principles and heuristics that successful organisations use in order to develop their own (evolving set of) Best Practices.

And those who are interested only in shirking responsibility? They’ll listen politely and then quietly insist that you tell them what to do.[9]


  1. You could argue that this is precisely why branded methods are so popular. They’re less about buying a solution than they are about acquiring a scapegoat.  ↩

  2. Also, well done for reading this far.  ↩

  3. Ironic no?  ↩

  4. And hopefully shown to work. because otherwise we’ll have to class “Tilting at Windmills” as Best Practice too.  ↩

  5. To make this clearer at the very least you’d have to be doing exactly what the other organisation was doing – in which case I would question where your competitive advantage was coming from. But even then, you’re almost certainly doing it with a different set of people.  ↩

  6. Pun partially intended.  ↩

  7. I’ve met the odd entrepreneur that attributes Apple’s success directly to the less cuddly parts of Steve Job’s personality; apparently nobody else at Apple does jack squat.  ↩

  8. By which I mean there is no scientific evidence to support any kind of relationship whatsoever; however likely or plausible it might seem to the layperson that there is a link. This seems especially true of dietary advice.  ↩

  9. Whether or not this is because of an innate character flaw or simply that this is what they’ve been incentivised to do is a topic for another day.  ↩

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 

Have you Mastered the Basics?

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

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

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

As I tweeted back in January:

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

So what’s going on?

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

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

(So again making a gross generalisation here)

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

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

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

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

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

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


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

Using Narrative as an alternative to rules of Best Practice

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

I can imagine that some of you may be thinking:

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

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

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

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

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

OR

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

OR

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

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

Which one is Best Practice?

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

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

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

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

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

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

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

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

Rules & Narrative Fragments

Sprint Termination Narrative Fragments

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

A LASTing Benefits Scrum Fable

Our Protagonists:

Bob – The ABC Corp Product Owner, recently married

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

Gareth – The CEO of Company X

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

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

A Conscientious Product Owner

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

A Deal in the making

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

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

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

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

Bob returns with a smile and a sunburn

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

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

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

Sprint the First – Responding to Change over following a Plan

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

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

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

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

Bob stands firm.

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

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

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

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

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

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

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

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

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

“But, Scrum Hell…” says Bob.

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

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

And then he thought of the solution.

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

Well Duh!

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

“No Prob” she said.

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

And so they did.

Sprint the Second – A series of unfortunate events

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

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

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

And then they make a plan to celebrate…

And so they did.

Quite enthusiastically.

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

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

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

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

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

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

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

The Team, horrified, nod acquiecense.

Dejected and feeling hopeless, they settle on a plan.

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

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

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

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

And so they do.

Sprint Review

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

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

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

Unintended Consequences

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

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

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

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

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

Sprint the Third – Life is hard and then you die

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

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

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

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

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

Bob discovers calm rational thinking

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

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

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

The Team stares at Bob blankly for a moment before replying

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

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

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

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

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

“Which are?” asks Bob

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

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

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

“But it can be done?” asks Bob?

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

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

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

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

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

And so they did.

Sprint the Fourth – Plain sailing

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

At the end of the Sprint it all integrates perfectly.

Jim, Gary and Peter start to peruse boat catalogues…

 

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

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

Best Practice is not a panacea

Best Practice is a term that’s bandied around a lot these days.

It ascribes to wishful thinking, and speaks to our fundamental human fear of the true nature of reality.

The very idea that there is “one right solution” helps provide the illusion that the world is a well ordered place.  Or at the very least could be, if we just tried hard enough.

However, as students of complexity are well aware, the only legitimate domain to apply “Best Practice” is in the Simple Domain.  This is a domain where Cause and Effect are obvious to all, and also endlessly repeatable. (And as such prime candidates for codification)

607px Cynefin framework Feb 2011

But most of life, especially knowledge work, does not fall into this appealingly controllable space, as much as we might like it to.

To increase our feeling of control, we often like to codify our notions of Best Practice into rules.  After all, if something is truly “best” then all other options are inferior and should therefore be avoided.

We then distribute these rules out to the population of humans whose behaviour we wish to control and sleep soundly knowing that our job is done and the world will be a better place from now on.

Because of course, everybody will follow the rules, and thus both their behaviour and the outcomes that they produce will therefore be “optimal”.

But what if we don’t trust people to follow our rules?

Why then, for the people’s own good (remember we we’re talking about the one best way here) we select some people that we do trust and have them enforce both our rules and their precious Best Practice payloads.

In the average corporation we might call these Best Practices by other names such as “policies”, “rules” or “procedures” and we call our trusted caste “managers” which we can then arrange in a hierarchy so that spatial position corresponds to the level of trust we place in each of them.  Everything is now ship shape and Bristol Fashion!

However, as I’m sure we’ve all experienced first hand.  The human mind likes to game the system.  We do so for all manner of reason: for fun, for malice, for personal gain and oftentimes just to get our job done.

The map does not always match the territory.  Maybe the rule is outdated, inapplicable to our current circumstance or simply badly or meanly written. Regardless, if it conflicts with our superordinate purpose then it gets in the way of the creation of value and betterment.

Regardless of the motivation, the instant a rule is created, people will be looking for ways to get around it, but without risking censure.

The unspoken mandate then becomes to follow the letter, but not the spirit of the rule, and therefore the same applies to the application of the “best” practice it was designed to engender.

This can lead to an arms race between the rule makers and the rule breakers. And so, rather than simply having one rule to follow, we have many.  Each describing the “Best Practice” version of the events that our incoveniently highly variable universe has chosen to throw at us.  Each created in retrospect for a situation which may never arise again.

Which brings us all the way back to the concept of attribution error that I spoke about here.

The rule makers’ attribution error is almost certainly that they believe that every problem is Simple and that Best Practice is therefore universally applicable to every situation.

If that’s your belief, then when you discover that the rules are not in fact engendering your desired outcomes, your reaction to fixing the situation is almost certainly to add more rules, or find ways to enforce the ones you have.  It will keep you busy, that’s for sure, it might even keep you entertained.

But it’s not going to give you better results.

If it’s the wrong tool for the job, it’s irrelevant how skilled you are at using it.

You cannot fix a broken watch with a chainsaw.

But once you see the world for what it is.  That it can be complicated, complex and chaotic, then you can achieve success through applying methods appropriate for managing those domains and give your rulebook a much needed rest.