Category Archives: Fables

The Allegory of the Pork Ribs

There once was a village in a far away land, the leader of which had a strong hunger for slow roasted pork ribs (which were at the time the fashion in the capital)

He called upon the resources of his village and commanded his chefs to make him the biggest tastiest, most meaty and succulent slow roasted pork ribs that the land had ever seen.

Try as they might, they failed and failed again. Earning the wrath and scorn of the village leader.

Then one day a trusted advisor brought word of a travelling expert. The PorkRibMaster. For a hefty price the PorkRibMaster would come to your village and not only make you the biggest tastiest, most meaty and succulent slow roasted pork ribs that the land had ever seen; but also teach you the secret!

They sent word to the PorkRibMaster and arranged for him to visit their village and teach them the secret of The Slow Roasted Pork Ribs.

On the appointed day, he arrived at the village to great fanfare. The villagers greeted him enthusiastically and brought him the best of all the produce they had to offer; then sat quietly, waiting with baited breath for the magic of The Pork Ribs to begin.

Taking a deep breath, the PorkRibMaster opened the barrels he had been brought.

One contained jugs of the finest full cream milk.

Another contained a chest of the sweetest sugar.

And the third barrel was full to the brim with lush ripe strawberries.

And finally, he was shown to a deep stone pit which was cooled by an underground stream that brought ice water directly from the mountain behind the village.

“I cannot make you slow roasted pork ribs from this!” the PorkRibMaster intoned,
“These are the ingredients for Strawberry Ice Cream!”

“We know!” said the villagers,
“That’s why we needed to hire an expert!”

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

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 https://lasting-benefits.com/contact-us/.