The illusion known as “signoff”
I am baffled by people talking about “signoff” and what a great thing it is. I find it especially common when coming from UX / Visual designers. “Oh thank god, the designs have finally been signed off!” they say. Or the corollary, the frustrated cry of “My work still hasn’t been signed off!”. The concept of “signoff” is a curious relic of Waterfall and has no place in Agile software development.
What “signoff” represents
The basic idea behind getting “signoff” for some artifact is that some stakeholder has confirmed that this is what they want. The developers then have confidence that they can go ahead and build it, since it will not change. And it can’t change because it has been “signed off”, right? Wrong.
Signed off things can change
Anyone who thinks that it is impossible for something “signed off” to change is stupid or naive. I once worked on a project where a whole bunch of design was done, the designs were all “signed off” by a senior stakeholder. Then a few weeks later, the stakeholder said “I’ve changed my mine, I want something different. Change it.”
The UX team spluttered and waved their arms around, pointing to the “signoff email” as proof that this was not on. The stakeholder’s response? “Maybe you didn’t hear me right. I said I’ve changed my mind, I want something different. Change it.” What can you say at this point?
You might reply “But this is rigged, he wasn’t following the process!”. That’s an irrelevant point. The stakeholder was in charge of millions of dollars of work, and had decided he wanted something different. And he was NOT going to let some hipster UX designer tell him what to do.
So the designs changed. What value or meaning did this “signoff” have then? Absolutely none whatsoever.
Signed off things sometimes SHOULD change
You’re probably thinking “No! Those people have got it wrong, they weren’t following the process. We need signoffs! We need to lock down the designs!”. Again, this can mean any kind of design, but often refers to UX or visual designs. And it’s a foolish line of thinking.
Those people weren’t breaking the process, the process is broken to begin with. Don’t hate the player, hate the game. The fact is, sometimes things should change, sometimes they need to change, sometimes they will be forced to change whether anyone wants them to or not.
Signoff is, therefore, meaningless
Watch these requirements disappear!
Signoff is meaningless and a waste of time. The fact is:
- Managers can change stuff that is signed off anyway
- The only way to stop them doing that is to wrap cumbersome change control processes around them; avoiding such things was one of the fundamental reasons for creating agile in the first place
- Things often need to change (or are going to be changed due to external factors).
We need to be able to change, we just want to make sure we are doing it at the right place at the right time for the right reasons.
But then how do we get certainty about what we are working on?
You can’t. Deal with it. If you want flexibility and being able to change, then you have to accept things changing. Trying to herd people to lock things down is a waste of everybody’s time. Remember the Lean (manufacturing, not startup) principle: Defer Commitment, i.e. decide as late as possible. If you hand over the designs for whatever is going to be worked just before (as in, the day before) they are worked on, you pretty much eliminate the chance of someone coming along and changing the designs before they are worked on.
But that could mean rework, right? And rework is bad, right?
Yes, kind of. If someone wants to change something just after someone starts working on it, that’s a new user story. It goes into the product backlog (NOT the sprint backlog!).
This “change request” does not and cannot go into the current sprint, because the team decides on the scope of the sprint at the initial sprint planning meeting. And the scope doesn’t change (unless the team, NOT the product owner, NOT some random stakeholder, decides to change it, which should be extremely rare). It’s just a work item, and you can analyse and prioritise it just like any other work item (with tests, story points, etc).
Rework is an interesting topic and I’ll do a whole article on it later. But for now, I’l just say that, much like change, rework can be bad if done for the wrong reasons. Or it can be good if done for the right reasons.
Question: have you found the concept of “signoff” to be useful? Or a detriment?
