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

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 movie

After recently reading an insightful article by Mary Poppendieck, I feel the urge to revive The Hitchhiker’s Guide to Killing Agile.

As you can guess, I definitely agree with Mary that “We need to stop giving our software teams training wheels: tasks and priorities. It’s time for them to tackle real problems, make critical trade-offs, recover from mistakes, make adjustments and keep moving.”

What’s more, I believe it’s also time to stop telling them that, in order to come to grips with better ways of developing software, they just need to wax on and wax off, as though they were impersonating the main character of the movie The Karate Kid.

I’m actually sick and tired of seeing how excessively meek teachers or snake oil consultants abuse a questionable cinematographic analogy to make the argument that, in order to master intellectual skills, one needs to start off by blindly practicing rituals, without understanding their purpose.

Now, as far as I know, martial arts (although recommendable for physical, mental and spiritual development) have nothing to do with knowledge work, let alone with Agile values and principles.

So, why do some “professionals” insist on applying to software development what might work just for karate?
Isn’t this the umpteenth perverse way of fostering cargo cult?

The Agile coach becomes the development team’s teacher and, slowly, a surrogate father, hero or police officer figure.
The aforementioned guru begins the development team’s training by having them perform laborious chores, such as spending more time on estimating how long it will take to do something than on actually doing it, mastering tribal terminology sponsored by a popular tool vendor, recklessly automating useless test cases, or learning to simulate joy while looking at a burndown chart.
Each chore is accompanied with a specific ritual, such as answering meaningless questions while standing-up, participating in despotic planning meetings aimed to make sure people will be busy 100% (or even more) of their time, or succumbing to futile retrospective activities hindered by a serious lack of psychological safety.
The development team members fail to see any connection to their training from these hard chores and eventually feel frustrated, believing they have learned nothing of Agile software development.
When they express their frustration, the evangelist reveals that the development team has been learning Agile practices through muscle memory learned by performing the chores.

Does it sound familiar?

If so, it might mean either you perfectly remember the amazing story starring Mr. Miyagi and Daniel or a better comparison for your allegedly Agile team would rather be a low-budget commercial motion picture.

To wrap up, I hope you agree it’s time to stop forcing software teams to wax on and wax off, and to start treating their chance of asking questions like something other than a bothering habit or a pointless luxury.

After all, as knowledge workers in charge of tackling real problems, they have the right to understand why they are doing what they are doing, don’t they?

List of references

(Sadly) real working life.

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

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.