The Hitchhiker’s Guide to Killing Agile (10/?)

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 guide

Here is a list of my favourite takeaways from “Scrum – A Pocket Guide”, and also an open thankful letter to Gunther Verheyen, the author of the book.

I especially want to thank him for pointing out that (disclaimer: the “Blade Runner” mood is mine):

– “[…] outstanding performance in the development of new, complex products is achieved when teams, as small and self-organizing units of people, are fed with objectives, not with tasks.”

Yet, I’ve seen things you people wouldn’t believe, like PMs micromanaging the development team just to keep them busy (instead of letting them try to achieve the sprint goal); or, maybe even worse, development team members who apparently prefer micromanagement over empowerment and self-organization…

– “The industrial mode to direct people as if they were robots impedes the rise of the collective intelligence of a team, thereby limiting their work results to mediocre levels.”

Yet, I’ve seen things you people wouldn’t believe, like an alleged proxy PO (a.k.a. old-style PBA) telling the development team HOW to implement user stories and even estimating development tasks on behalf of the team…

– “The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standards for releasable, and should be known by all players. […] Through the definition of done, quality is at the heart of what Scrum Teams do. […] The Development Team does all the hard work related to delivering working software that complies to the definition of done. A definition of done can’t be forced upon a Development Team. Neither can it be cut short by forces outside of the Development Team.”

Yet, I’ve seen things you people wouldn’t believe, like a Scrum Manager (sic) closing tasks just for the sake of a shining sprint review report...

– “The Scrum rules are one of the primary boundaries within which a team organizes its own work:

  • The Development Team collaboratively selects work that is ordered and expressed by the Product Owner […]
  • The Scrum Master has no interest in scope, budget, delivery or tasks but coaches and facilitates the complete ecosystem in using Scrum to manage them.”

Yet, I’ve seen things you people wouldn’t believe, like a SM assigning tasks to development team members, a not really collaborative team member assigning themselves a whole story instead of single tasks (always shielded by the alleged SM who was deliberately overlooking this form of egotism), and the same Scrum Manager (sic) previously mentioned closing not completed (or even not started) tasks on behalf of (defenceless/not on-site/increasingly demotivated) team members, sprint after sprint, just to keep showing “flawless” sprint review reports to the stakeholders…

– “Scrum […] is a framework of rules, roles and principles that helps people and organizations to develop a working process that is specific and appropriate to their time and context. Scrum implements empiricism as this is the most optimal process to enable control over complexity.”

Yet, I’ve seen things you people wouldn’t believe, like the alleged PO of an alleged Scrum team admitting during a retrospective meeting that, in his opinion, Agile/Scrum was not suitable for their complex product/project…

– “The utilization of Scrum is not about renaming or slightly reworking old techniques […]. Product people are not being asked to hand over a list of User Stories as a replacement for the old required documents.”

Yet, I’ve seen things you people wouldn’t believe, like an alleged proxy PO (a.k.a. old-style PBA) just handing over the same old-style, that is very long and detailed, documents sprint after sprint…

– “Your organization deserves active and explicit upstream support and promotion of Scrum. […] It takes a sense of urgency and the acceptance that there is indeed urgency. […] The goal of a lasting Scrum transformation as a step on the path to Agility is to get managers involved in the game through a structured, iterative-incremental change program. […] Such a change program doesn’t address organizational areas in a waterfall-way. […] A change program to transform an organization to Scrum addresses enterprise domains in parallel.”

Yet, I’ve seen things you people wouldn’t believe, like employees being fired just for pointing this out…

Anyway, thank you very much, Gunther, for explaining how to make the most of Agile/Lean/Scrum.

I’m confident that really wise organizations are going to understand all this!

List of references

(Sadly) real working life.

Adams, Douglas. The Hitchhiker’s Guide to the Galaxy.  London: Del Rey Books,1995 (first published 1979).

Verheyen, Gunther. Scrum – A Pocket Guide. Van Haren Publishing, 2013.

Blade Runner, 1982 [film]. Directed by Ridley Scott. USA.

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.
Thank you.