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

“I’m really excited to host my second guest article within this series: it’s from my friend and anonymous (oops, formerly anonymous) agilist/fragilist Ralph Fisher.” – Ileana Belfiore

Disclaimer: The views expressed in this guest article are those of the guest author only and do not necessarily represent those of the The Hitchhiker’s Guide to Killing Agile.

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 bird…

I’m a little at a loss, because my great friend and ex-colleague Ileana has invited me to be a guest contributor to her Agile blog, and I’m honoured to have received the invitation. This is a challenge. Or at least it was, until I found this Douglas Adams quote:

“The bird that would soar above the plain of tradition and prejudice must have strong wings.”

If you’ve understood how that quote contextualises with Agile, then feel free to move on to the next blog post/coffee/job offer in LinkedIn. Or keep reading, you might be amused, or maybe your contextualisation will be challenged.

The “plain of tradition” is obviously Waterfall, and the many bad habits and bad positions that have come with it. That’s a bold statement, which needs elucidation.

What are the bad habits?

1.     As a tester, with a couple of decades of experience in Waterfall projects, the most difficult part of transitioning to Agile was the lack of requirements, from which to derive test designs and test cases. There were only User Stories, almost always ungroomed. I found myself actually working (which was a shock in itself) with a programmer, designing functionality and web pages. This was absolutely new to me, and rapidly became very productive. At some point the project technical lead (see the “bad positions” part for my attempt to explain this crassly stupid idea) told me that “The stakeholders think you’re too tied to the methodology, but they’re surprised by how quickly you’ve got this far”. He didn’t respond to my reply “We’ve got this far so quickly because of the methodology (twat)”. The “twat” was silent”.

2.     If you’ve seen any of my blog posts in the Fragilist, you may have read the one about metrics. I once was lost, I’d been measured by defect metrics during my career, and now had a programmer who would often fix bugs before I had the chance to enter them into the holy defect management system. This initiated a struggle for my mortal soul, which lasted all of ten minutes, until I realised I had an opportunity to free myself from the chains of pointless documentation and from the curse of metrics.

I found it wonderfully liberating to be able to respond “I have no idea” when the QA director of the company asked me how many bugs I’d found. They went into a lack-of-metrics induced state of shock. This project lasted about five years, in the last four years I entered maybe ten defects into the defect database, all of them with the severity of “There’s not much point in fixing this”.

During the last two years of the project the users found as many defects as I’d registered. Something which apparently looked very bad to “upper management”, who are apparently incapable of understanding that two user-found defect a year is rather good, even if it does account for 50% of those in the database. I did however record some bugs found during Exploratory testing in an Excel, when, for example, the programmer was having a bad day, or had found something more interesting to do, and didn’t correct the problem immediately. Can you see where I’m going with this? If you can then you’re beyond help. I was asked to add the Exploratory test defects to the ones in the database, to make the metrics look “better”. Here I am, brain the size of a small planet…

3.     Believing that having read a two page article about something makes one an expert. Despite my conviction that Agile has been taken over by the dark forces of capitalism, I still feel that it’s essential to have had more exposure to the concept of the framework than to simply have read, and probably not understood, the manifesto. It’s also essential to buy in to the idea, which is something that a course will not necessarily provoke. Nevertheless, please do some courses before you, as “Product Manager” say that the person who is head of Worldwide Marketing and Communication of a company with 5.000 employees “Could be product owner”.

4.     Managing, as opposed to leading. Or vice-versa. This is the baddest of bad habits, the one that causes Agilists to feel deep despair and reach for either a nice Chianti, or a pistol. Since I became reasonably good at testing, my position has been one of “Look, you’ve seen that I’m very good at this, and I’m both smart and modest, so please leave me alone to get on with what I do well. While you attempt to find something that you do well.”

Even on Waterfall projects I’ve had managers who were smart enough to be hands-off. It’s been written elsewhere, and at length, that the leader/servant concept within Agile leaves a whole substrata of middle management feeling exposed, these are generally people who’ve “risen up through the ranks” and are the living embodiment of the Peter Principle. They enjoy the feeling of power that having the title of “Project Manager” apparently bestows upon them. They like bossing people around, they may also have red sports cars.

I started writing this on Easter Monday, so a biblical reference seems appropriate. This is clearly an enormous problem for the transition to Agile, but only because it takes a lot of balls to fire the entire middle management sect of an organisation. Or send them to re-programming camps (not re-testing camps, because testers tend to be well-rounded people, capable of adapting to changed and changing circumstances.)

And what are the bad positions?

In an Agile project team there are three roles: Product Owner, Scrum Master and Developer (or so it says here). Outside of the project team are the stakeholders, maybe dev ops, and the guy responsible for maintaining the coffee machine (this list is clearly in ascending order of importance). Nevertheless, in more than one organisation known to Ileana and me, there are other roles:

1.     Scrum Manager: So you’re managing a self-organising team? Think about it. You are redundant. I’ve heard of this title being used by someone who was in a Scrum Master’s role, which makes the concept event worse for me. Actually it makes my head explode to think about someone who thinks themselves a manager, in the Scrum Master’s position. Just pretending to be Agilist? In the real-life circumstances in which this person existed, he claimed to have a Scrum Manager qualification. Despite an extensive search, I’ve been unable to find a manner to qualify as a Scrum Manager.

2.     Product Manager: Instead of taking ownership of the product you’re managing it? I’m having another head-exploding moment here:

a.     A Project Manager can, theoretically, manage a project whose goal is to result in the production of a product. The key word here is manage, which defeats one of the thing I like most about Scrum: the idea of a servant/leader;

b.     A Product Owner can own a project and understand what the desired output is, they can use the product backlog to define what need to be done. What they of course must not do is define the time period in which the work needs to be done. Nor can they tell members of the development team which tasks they should carry out.

What I want to say here is: If you’re Agile:

a.     Don’t have managers;

b.     Do not have job titles that contain the word “Manager”, unless it’s used in a post-modern, ironic way;

c.      And, maybe most importantly, do not have people on the project, or in the company, who accept being called a manager.

3.     Project Technical Lead: Oh dear, there’s so much wrong with this job title, and with the qualifications of the person who filled it (this is something I won’t go into, well, not in any depth, except to question why a person with only client server and MS DOS knowledge was assigned as Technical Lead on a web project).

Have you ever worked in a team where the post of “Project Newbie Programmer” existed? Or maybe “Project Perpetual Naysayer”? The tendency where I work is for us plebs to electronically sign our emails as “Name, position, project”. For example “Tahra Dactyl (allegedly a real name), Programmer, Project 404”. So “Chris P. Bacon, Project Technical Lead, Project 404” has some redundancy.

Maybe you’ve worked on a project where a person was nominated QA Lead, while being the only QA person on the project? Ah, wait, to that one I can answer “Yes! And it was me!” Although now it occurs to me that this has its logic, I was the senior QA person, hence by default the QA lead, had it not been an Agile project, without leads.

How does this tie in in with Douglas Adams?

Being an Agile person, I’ve come to realise that my initial statement that “The “plain of tradition” is obviously Waterfall” needs to be improved. Waterfall projects require traditional roles, that’s clear. However people who fill those traditional roles are unfortunately in liberty and feel free to meddle with, and corrupt, Agile processes. I’ve also revised my possible cruel thought that these people should be sent to reprogramming camps, so I’m going to try to get funding for a B ark.

I realise that I haven’t touched the “prejudice” part of “tradition and prejudice”, largely because I forgot about it ran out of space. Maybe you can help me out? What prejudices have you experienced as an Agile protagonist? Please leave your comments (I may collate them into another article, if Ileana permits me!)