cover your ass

I hate the word SIGNOFF.

I thought that once I got away from the horrors of waterfall software development it would disappear forever. But no, the menacing SIGNOFF has made it into agile software development teams. I was at Agile Testing Days in Berlin last week and I had an incredible time talking and listening to passionate people. On the other hand, I was surprised to hear how many people still talk in term of SIGNOFFS.

Overheard in Berlin:

“The user stories need to be signed off before you can start working on them”

“…then after our signoff we can deliver the software…”

And so on

This is my definition of a signoff:

“A point in time where my responsibility ends, so for errors up to then you can blame me, after that it’s your fault and I don’t give a rats arse.”

That’s what it is, it is a Cover Your Ass activity. There is no other reason why you would want to signoff on something unless you are trying to cover your own ass and blame somebody else. The fans of the Cover Your Ass manifesto are also the ones that would sing off on anything.

What’s the value of a signoff to our customers?

Signoff by High Five at the Dublin Java User Group

0 – Zero – Nil

What’s the value to the development team?

Less than zero because signoffs cause finger pointing and blame games

So, why the hell do we do signoffs?

I don’t know.

One thing I know is that the agile manifesto (among other things) says:

Customer collaboration over Contract Negotiation

That in my head translates into

Shared activities over Signoffs

In my team we have started a new trend, it’s called “Signoff by High Five”, it works like this: You get 3 people (possibly the 3 amigos) and you get them working on a task, for example writing a user story. They work together and when

they are finished they go: are we happy? Yes! “High Five!”

At this point you don’t need to have a document with a checklist and a signature of somebody to blame, you simply need 3 people agreeing and one simple “High Five”.

We also do this when we do exploratory testing together, at a certain point we look at each other and we know there is nothing more that we can do to add value then it’s “High Five!”

Sometimes we do that at the end of a demo, the high five there means the story is accepted.

So what happens if there is a problem and a bug appears on software we had wrongly high fived? Not much, we just worry about repairing the issue as soon as possible and delivering the missing value to our customer, no need for arguing over who fucked it up and how we can punish him. What we do is deliver value, that’s what we care about.