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

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 four values

Right in the middle of our journey to survive the The Hitchhiker’s Guide to Killing Agile, let’s resume this series going back to the basics: let’s inspect and adapt our direction by talking (seriously) about the Manifesto for Agile Software Development.

Let’s carefully dissect each of its four statements and see what they really mean (to me) in practice.

Individuals and interactions over processes and tools
If the employees working at your organization are not able to decently interact, to speak with and (even more important) to listen to other people who might be (either directly or indirectly) affected by what they are doing or going to do, don’t even consider adding processes and tools to the equation.
In other words, if people don’t naturally (and effectively) talk with each other, if they don’t usually take other people’s needs into account, no tool/process will magically fix this issue: there’s actually no magic wand which will make them speak with and listen to whom they should.

Working software over comprehensive documentation
If you are not able to build decent working software (iteratively and incrementally), there’s no point in writing comprehensive documentation about something nobody will be able or willing to use.
Which does not mean you should not document at all.
It rather means your documentation should be so concise and helpful that everybody would be happy to read it, as needed.

Customer collaboration over contract negotiation
If you don’t talk with your customers, either because you (allegedly) have no time to do that or because you think they are basically a pain in the ass, there’s no point in putting your agreement with them in writing. Your relationship is never going to work out anyway.
By the way, chances are you also are a pain in the ass for them…

Responding to change over following a plan
If you haven’t understood yet that the worst moment to make a decision is when you don’t have enough information (yet) to make such decision, if you keep planning everything upfront as though you were able to predict the future, if you pretend to be in a digital/cultural transformation but you panic every time something unexpected happens, please stop gazing into the crystal ball and start acknowledging that you might need to make peace with change and accept that, whether you like it or not, at some point something unexpected will be happening anyway…

That’s all.
That’s what the aforementioned manifesto basically means (to me).
I hope my humble interpretation of such a well-known (yet too often misconstrued) piece of paper can be useful for you too.

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, 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.