Agile and Broken Promises

Published 2021-02-24
When we invite Agile in, we enter into a deal; we make a bargain. But it's all too easy to forget our side of the bargain.

= = = = = = = = = = = =

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
www.developmentthatpays.com/webinars/p-and-p?ref=y…

= = = = = = = = = = = =

Agile Development. It promises so much. In theory, anyway.

In practice, it can be extremely frustrating to work in an Agile team.

One reason for that is when we adopt Agile, we enter into a bargain. But somewhere along the way, one side of the bargain gets forgotten.





-------------------
148. Agile and Broken Promises
#agile #DevelopmentThatPays

Once upon a time in a kingdom far, far away, there lived a king, a king with a problem, a problem of productivity. Projects in the kingdom seemed to be without end, the simplest thing taking months or even years to complete. The king had summoned wise men, and I hope women, from all four corners of the kingdom in the hope of finding a solution. And although many three-letter acronyms were proposed and implemented, nothing seemed to improve the situation. Productivity remained stubbornly low. Displeased, the king banished the wise men, and I guess women, from the kingdom. But he was no further forward. Then one dark and stormy night, there came a knocking on the door. Not exactly sure how you knock on the door of castle, but anyway. At the door was a mysterious stranger. And luckily for us, it was the custom in this land to welcome mysterious strangers who turn up on dark and stormy nights, and not only that, treat them to a banquet, a feast. And so it was that the king and the mysterious stranger sat down to eat, drink, and generally make merry. And eventually the conversation turned to the thorny issue of, yes, you guessed it, productivity. The stranger thought for awhile, looked the king right in the eye, and said, "I can show you exactly how to achieve twice as much in half the time." The king was dumbfounded. He'd have offered a ransom, by definition, in this case, a king's ransom, for a 10% increase in productivity, and here he was being offered twice the work in half the time He was no math genius, but he could see immediately that that was a heck of a lot more than a 10% increase, and at this point he got scared. Surely there would be a price to pay, and a heavy one at that. Would he have to give up his firstborn But the mysterious stranger was reassuring. He looked the king right in the eye and said, "There is a price to pay, and it is this. You must leave your teams alone for two weeks at a time." Well, the king couldn't help but burst out laughing. I mean, it was ridiculous. Was that all he had to do He thrust out his hand and said to the mysterious stranger, "Why not make it three weeks " And they shook hands to seal the deal. The mysterious stranger was as good as his word. His teams really did deliver twice the work in half the time. And as a result, the kingdom prospered, the king's approval rating skyrocketed, and they all lived happily ever after. At least, they would've done if it hadn't been for one small problem. You see, over time, the king forgot his promise, his promise to leave his teams alone for two or even three weeks at a time. Things didn't go well after that. I won't even tell you what happened to his firstborn. What was that story really about Well, I'm sure you picked up on the none-too-subtle references to Scrum, but note that with a tweak here and there, the story could apply equally to Kanban. The king in the story Well, that's our organization, or perhaps that should be the management. Now, why does management welcome or invite agile into the organization Well, think it often is on the promise of improved productivity. And just like the king, the organization or the management enters into a bargain. And part of that is to allow their agile teams to work uninterrupted for what are, let's be honest, fairly short periods of time. For a Scrum team, it's the duration of the sprint. For a Kanban team, it's, well, whatever their service level agreement is. In either case, we're talking days, a couple or three weeks at the very outside. And at the outset, that agreement is a no-brainer. But we humans, well, we have... I guess it's one of our strengths, in a way. We very quickly get used to whatever is the new normal. Before we know it, that two weeks or whatever it is starts to feel like an awful long time. And what harm would it do anyway to drop in a new requirement here and a new requirement there And at that moment, the bargain is broken, the promise forgotten, at least one of the promises. The other side
   • Agile and Broken Promises