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!