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?
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.
mysoftwarequality 
I like this idea!! Sign-offs are like headaches..damned if you do and damned if you do not!!
Thanks Rumdak, so now you only have to go back to your team, share the activities and sign off with an High Five! Let me know how it works for you.
Great post! I have one suggested addition…
You wrote: “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.”
Very true. “Arguing over who fucked it up and how we can punish him” is absolutely, positively a waste of time. But, leaning isn’t. It is always good to _learn_ from _things_. Both good things and bad things. Both right things and wrong things. Notice I didn’t say “mistakes” because people are delicate, faberge eggs that usually go to pieces when they realize (or are shown) that they have made a mistake.
But, it is still important to _learn_ from the _thing_. That way, there will be even more confidence with the next high-five. *slap*
Hey Damian, thanks a million for the kind words, i appreciate them. I completely agree with you, learning from mistakes is fundamental and i might not have emphasized it enough in the post but we do! We take any sort of feedback very seriously and as well as acting upon it we also take the time to learn.
Good article thanks. Sign-off shouldn’t be an ass covering activity but does end up being that at organisations, usually because someone wants to get paid, or there’s a blame culture in the organisation.
Saying that, high-five is doing the same thing. You are getting closure from your team that everyone is happy. Sign-off is also about getting closure from the stakeholders involved that they are happy, just that it’s more formal. Usually a high 5 type process is done before the actual formal sign-off.
I don’t think the issue is the sign-off process. It’s the blame game culture that needs changing, high 5 will get the same blame when things go wrong in such a culture. If sign-off is being pushed through for the wrong reasons, it does need to be challenged.
Thanks for your feedback Richard.
There is a difference in my opinion.
The high 5 is a joint activity in which the team agrees on some deliverable.
With the high 5 the team takes responsibility, the focus is on the value delivered.
A sign off is an contractual activity performed by an individual, focus is on not making mistakes, can be used for finger pointing.
[…] Signoff by High Five – Augusto Evangelisti – https://mysoftwarequality.wordpress.com/2013/11/06/signoff-by-high-five/ Testing in a Big Data World – Vinaykumar Chandrashekar – […]
[…] [8] Sign off by High Five […]
It’s an interesting read. There’s also another dimension to the signoff. It also protects the team from doing endless change requests filed as bugfixes or tiny extra details about the initial requirements. Tiny stuff that might extend a project for months, block people on it and not provide money for the extra time spent…
It’s not always that the client wants you to work for free (although it might often be the case) as much as the product manager from the client side pushes as many features possible, while the upper management and financial departments have other concerns, such as timeline, budget allocation, which might be fixed.
Thanks for your feedback Taraganache.
I understand where you are coming from and I appreciate that in some situations having a contract can protect the team.
I would think that also in that situation you could try somehow some level of collaboration with your customers rather than defining your deliverable exclusively by contract, what’s your experience on that?
In my specific environment we release continuously, so what matters is our customers priorities and we don’t really care whether they are bugs or features.
Hi,
I was mainly talking about fixed-cost projects, not as much continuous integration. If you’re on a support agreement or have other arrangements, collaboration with the client is likely to improve.
But when you have a fixed cost project with a very general scope and SOW, things could get pushed on and on forever. Imagine working on a requirement such as “improve X” for a product update. Where does improvement ever stop? Not having clearly defined exit criteria (acceptance criteria) signed off could have you working 500% or get sued.
I’ve had the situation when a fixed cost and scope project was delivered fabulously (good collaboration with the customer, support contract in place afterwards, proper change request management and admittance from client). But that was because the client really knew what they wanted now, three months later and six months later (they had feature plans, we could clearly define scope).
I’ve also had the situation when a fixed cost project dragged for months after it should have been completed, because of generic requirements (you could work forever based on those requirements) and clients shifting ideas about what they want/need continuously (taking advantage of the ambiguous nature of requirements to fend off CRs and push more features). They are also happy with our team, but that’s because we helped them at our expense :). We preferred to see that project end ok even though it meant a hole in our budget/resources.
So my point is all the advice here is great, as long as all parties are fair to each other, know what they want and have reasonable requests. However, by using agile with clients that don’t necessarily plan a very long term collaboration, they can abuse it to get away cheaper or with more 🙂
Taraganache, agreed, you make a very solid argument. Thanks for your feedback
Thanks for your wonderful blog, I’m really enjoying reading it now and then and it’s proving more useful than many books I’ve stumbled upon 🙂 Take care and keep it updated!
Thanks a million taraganache, feedback like yours make it all worth it, I really appreciate it. I normally suggest blogging to anybody that has a true interest in a subject, I personally use it as a research tool to understand my thoughts better, think about it and let me know when you start blogging!