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?