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

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 some undesired and dangerous Scrum roles…

After having opened the Pandora’s box some weeks ago and uncovered some unexpected issues found while working within a Scrum framework, I think it’s time to talk about some unexpected Scrum roles.

I guess I can assume most of you are already familiar with the typical roles that people working with Scrum play (you know, the Scrum Team, the Scrum Master, the Scrum Product Owner). I’m also pretty sure you know which responsibilities should be fulfilled by each of them, and how they should interact and work together in order to be able to successfully complete a project.

For this reason, I’m gonna stop talking about traditional and well-known Scrum roles, to introduce you to some other undesired and dangerous roles which might exist in your Agile team. 

To better explain my point, I’m gonna provide you with a (not comprehensive but hopefully pretty relevant) list of them. 

Let’s see if you recognize any in your team.

—

The verbose meeting guests

Although they don’t really have a special opinion about something, they are gonna pretend to have one, just to waste time, exercising their mouth and confusing other people.

What’s more, even when they profess to agreeing with someone about something, they need to spend at least half an hour to stress their agreement; not to mention if they pretend not to agree…

The blinkered subordinates 

They just do what their boss tells them to do. 

Even if somebody might consider this kind of workers are easy to be managed as they always nod to their boss, the fact they are not usually able to have a personal opinion about any relevant subject makes them practically useless in an Agile environment.

Curiously, in the remote event they decide to share what they “think” with the rest of the team, their opinion always matches exactly what their boss already said.

The misleading programmers

If a tester asks them about something weird he/she believes to have found in the application, they rapidly try to change the subject, focusing on something else (something similar, of course, but absolutely unrelated to the particular area affected by the tester’s weird feeling), just to make sure the tester can be distracted by a properly working functionality. 

By the way, what they probably do in the hope of making the tester resign themselves to this bothersome habit and just skip to another task/feature, might have the opposite effect, as the tester usually starts investigating that weird thing which caught their attention more in depth…

The blinkered test designers

For this kind of people it does not matter if a requirement does not make any sense at all. Instead of suggesting a requirement review, they just start working breathlessly in order to have a test case to verify nonsense as soon as possible.

So, once the test case is done and an open-minded reviewer realizes both the requirement and the test case do not make sense, there will still be a great deal of work to do for the team: a requirement to be updated, an implementation to be reviewed, a test case to be probably deleted, a new test case to be designed…

And even if it’s true that some of these things needed to be done anyway, in a less narrow-minded and more Agile environment some of them could have been done earlier, whereas others might not have been done at all.

The boycotter developers

Even though they are usually proud of having introduced and kept some defects in the application just for the sake of the project’s continuity, I wouldn’t bet on them being able to fix all these bugs. Moreover, their code is usually poor enough for nobody else to be able to change it, let alone refactor it. 

There is no need to mention that this kind of old-school and unethical behaviour might be especially risky for critical projects.

The generous incompetent ones

They are usually incompetent at almost everything, which wouldn’t represent a serious issue if they didn’t want to help with everything they are incompetent at. 

In other words, the problem is that the worse they are at doing something, the more they want to help do something.

Oddly enough, they usually refuse someone else’s help, maybe just to ensure they are the only people allowed to “help”…

The slow mood people

Last but not least, for obvious reasons people who think [PAUSE] and act [PAUSE] slowly [PAUSE], very [PAUSE] slowly [PAUSE], don’t fit very well into an Agile environment. What’s more, as they usually never feel under pressure, there is no way to make them go faster: they will just keep going at their leisurely pace.

So, even if they might be certainly useful for projects which work in other ways, they seem not suitable for a continuous delivery environment, where you are better off taking advantage of proactive and faster people instead.

—

Well, if you have read up to here, it’s probably because you’ve recognized some of these unexpected roles in your Scrum team. What’s more, some people seem to have a gift for boasting more than one of these characteristics at the same time. 

If so, you should seriously consider that, if you don’t get rid of them, they might dynamite your fragile environment, as they are (unconsciously or not) really eager to kill your (just apparently) Agile team, at least until they are on board the Vogon ship…