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

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 customer complaint which needs to be investigated

At this stage of our journey to try to survive The Hitchhiker’s Guide to Killing Agile, after having talked about some unexpected roles you may deal with in your fragile Agile team, I guess I can assume we all already know that, in an authentic Agile environment, everybody should be able to take on whatever task. Ideally, programmers and testers might even switch roles. At least, this is the theory, but we also know that, when referring to real working life, this process may get cumbersome, mainly when and where programmers and testers don’t share the same kind of professional experience, and even belong to different departments. In this case, what should be allegedly ensured is that workers sharing the same role are really able to take on any task within a particular sprint (in case of working within a Scrum framework, for instance).

Anyway, the implementation of the Agile principles is often not so straightforward as desired.

Actually, even people with the same function (that is, testers or programmers) within a SW team don’t necessarily share the same technical or soft skills, which sometimes makes putting theory into practice extremely difficult.

Someone who lacks critical thinking and analytical skills, for example, wouldn’t be a good match for an activity which requires some investigation.

Similarly, brilliant problem solvers would quickly get bored if a lot of not especially challenging tasks were repeatedly assigned to them.

The case of a friend of a friend, who works in a library because of her cataloging skills, even though she does not like reading, made me think about the fact that working life is full of wrong assumptions about job positions, roles, technical and personal skills.

Look at stenographers or archivists, for example.

They probably like to gather, collect and organize info, but this does not ensure that they will later be able to understand, process and reinterpret all this info. For this reason, the most likely outcome you are going to get from a stenographer or an archivist charged with a research activity (such as a customer complaint which needs to be investigated) is no conclusions at all. So, if you really need some info hoarders in your SW team, feel free to keep them in their place; yet it would be better not to delude yourself into thinking that they can work as an analyst, a researcher or a troubleshooter.

All in all, forcing such unnatural situations is just like trying to fit a square peg into a round hole. 

And now the question is: do all your team members fit your Agile environment?

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.