The Hitchhiker’s Guide to Killing Agile (8/?)
“I’m really excited to host my first guest article within this series: it’s from anonymous agilist Julian Bayer.” –
Disclaimer: The views expressed in this guest article are those of the guest author only and do not necessarily represent those of the The Hitchhiker’s Guide to Killing Agile.
Sadly, […] a terribly stupid catastrophe occurred. […] it is the story of that terrible stupid catastrophe and some of its consequences.
It is also the story of a book, a book called The Hitchhiker’s Guide to Killing Agile, not an Agile book, never published on Agile website, and until the terrible catastrophe occurred, never seen or heard of by any Agile team members.
Nevertheless, a wholly remarkable book. […]
It begins with a proof of concept…
This was the gist of the notice. It said “The Scrum Guide is definitive. Reality is frequently inaccurate.”
Many are increasingly of the opinion that Scrum, or “Agile”, will prevent them from participating in what has become known as a Death March. A project, that is, which has been managed in a way that makes it destined to fail. Demotivated engineers developing a product that will never see the market.
Now, suppose you want to prove them wrong. Suppose that someone has used a momentary lapse of judgement on your part to get you to sign off on a project using Scrum. But really, you don’t want to relinquish control. You feel you really do know better. So here’s a comprehensive guide to setting up a failing project using Scrum. Or, as you will henceforth call it: “Our own version of Scrum“.
The major problem—one of the major problems, for there are several—one of the many major problems with governing people is that of whom you get to do it; or rather of who manages to get people to let them do it to them.
First, you need someone with an idea for a product. It obviously can’t be you, because that would make you invested in the success of the product. That’s not what we’re going for here. Luckily, your company is stocked with capable engineers (I assume), so one of them will have an idea sooner or later. So, when they come to you with that idea, it is very important to appear mildly enthused. Just enough so they are motivated, but not so much that you would be tempted to make any promises. Do not ask for a business plan. Do not ask if there is a market for it. Just declare them to be the “Product Owner”, hand them a team of fresh-out-of-university engineers (preferably with a degree in anything but engineering) and send them on their way. An inexperinced Scrum Master with juuuust enough exposure to the agile manifesto to get them interested is also helpful.
Phase 1 (because, obviously, we need phases): The initial take-off
In the beginning the Product Backlog was created. This has made a lot of people very angry and been widely regarded as a bad move.
You can relax. For about the next three months, this team will be quite happily busy with itself. Between setting up “the Scrum Process”, writing and refining Product Backlog Items and all that agile stuff, they will be busy as bees. And as long as you give them the freedom to do all of that within the confines of their own team and project, this will do nicely. Don’t agree to any of those pesky invites to the “Sprint Review”, though. Send a Middle Manager in your stead and be sure to make it seem as if they were empowered to do stuff.
Phase 2: Stall
“So much time,” it groaned, “oh so much time. And pain as well, so much of that, and so much time to suffer it in too. One or the other on its own I could probably manage. It’s the two together that really get me down.”
More or less three months after the inital take-off, the Product Owner and Scrum Master will knock on your door and explain to you that you will need to start thinking about marketing and sales or some other thing you haven’t empowered them to do by themselves. Make it clear to them that this is not currently possible, because the marketing division is overworked or on leave or both. It will take at least another three months before marketing activities can start. Be surprised at their progress, congratulate them and become invisible again. Once the Marketing Divison is back and has been included in the project, insist that you are the one to talk to the Sales Department. Make sure to take at least six to eight weeks to do that.
Phase 3: Meddle
“Oh yes, well I managed to transmit a new entry off to the editor. He had to trim it a bit, but it’s still an improvement.” – “And what does it say now?” asked Arthur. – “Mostly harmless,” admitted Ford with a slightly embarrassed cough.
When the team starts to become more and more annoying about the whole Sales and Marketing thing it’s finally time to get hands-on involved. After all, we need to control this thing. This is where you declare that the product needs some convoluted and complicated feature (something like a licensing scheme or a self-implemented cryptography library). The team will dump your obscure requirements into the Product Backlog, estimate it and implement away. While they do that, remain vague about the specifics of the feature, but insist that all decisions must be made by you. By doing so, you finally reveal that the Product Owner is not, in fact, the Product Owner. Bask in the glory of their increasing frustration as they discover their disempowerment.
Phase 4: Take it apart
If any of them had chosen to look out of the window at that moment, they would have been startled by the sight of Ford Prefect dropping past them to his certain death and flipping the finger at them.
When the Product is not quite ready to be released yet, you announce that the team members are needed for strategically important one-person-projects. Give them a week to wrap up. They will scramble to save what can be saved. Now get in the thick of it. Make sure you prioritise just enough features that the team can get them done in a rush, but insist that they don’t need planning and all that overhead. Just get the thing done, okay? It has cost enough already. And why has it taken so long anyway?
Curiously enough, the only thing that went through the mind of the bowl of petunias as it fell was “Oh no, not again”.
The Aftermath – A warning label
Being the careful process consultants we are, we at the Guide want to give you a fair warning. If you implement the above process, you will retain control and kill any “agile” movement before it begins. People will leave though. But you know what they say: Processes and tools over individuals and interactions … right?
There was a point to this story, but it has temporarily escaped the chronicler’s mind.
List of references
(Sadly) real working life.
Adams, Douglas. The Hitchhiker’s Guide to the Galaxy. London: Del Rey Books,1995 (first published 1979).
Adams, Douglas. The Restaurant at the End of the Universe
Adams, Douglas. So Long, and Thanks for All the Fish
Adams, Douglas. Mostly Harmless
Fake review from The Fake Boston Globe
Seconds before the lab is demolished to make way for a new galactic device…
… a SW tester begins a journey through Scrum framework aided by quotes from The Hitchhiker’s Guide to Killing Agile (“A speck is about the most massively useful thing a software hitchhiker can have”) and a lab full of fellow team members…
Thanks for reading this article.
Feel free to recommend it or to add a comment.
Should you have any doubts about Agile, please contact me: I will be glad to help you.
On the other hand, if you want to get notified about my blog posts, please sign up through the BLOG > SUBSCRIBE TO THE BLOG NEWSLETTER menu.