“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone”
President John F. Kennedy
September 12, 1962
I had an interesting conversation today with our Product Owner (Proxy Product Owner, but that’s another story) about Scrum.
The conversation focused on the issue of demonstrating completed work. We have found that some pieces of work haven’t lent themself to being demonstrated. We’ve let those slide, we’ve cut other corners too.
Today I suggested that it’s time that we start taking things like this more seriously and we should start by at least facing up to the challenge of finding a way to demo everything we build.
The PO (or PPO I guess) is of course the intended beneficiary of these demos, so you’d imagine I’d have an enthusiastic ally. Turns out, not so much. She argued reasonably cogently that it wasn’t necessary to demo EVERYTHING.
Her reasoning basically amount to this. If something can be demoed then great. If demoing will take a lot of effort, then I’m willing to trust the team. If they say it’s done, I’ll find out fairly quickly if it’s not.
On the face of it it’s hard to argue with that, and who doesn’t like being trusted?
I believe that the reason this particular Product Owner is so trusting is that she is in fact a Proxy Product Owner, sitting close to us, and constantly aware of what we are doing. In short, she is in a privileged position that makes the benefit of demos less obvious.
Once you establish that demos are desirable rather than mandatory, you give the team an out that they may abuse.
Woah, hold on there Richard, now it sounds like you don’t trust yourself and the team! What ever happened to self organising, empowerment, all that touchy feely scrummy stuff?
Well, yes, but there’s something to be said for the words of another US President, “Trust, but verify”.
We don’t verify because we believe the developers will pull a fast one, we verify to make sure the developers knew what they were supposed to be delivering. We also verify because it focuses the developers minds on a higher bar than merely “checking something in”
Am I suggesting that the team might claim something was done that wasn’t?
No. Not deliberately, but I do think there’s a chance that the team might think something is done when it isn’t.
Am I suggesting the team might not bother to demo some things that they would be generally be capable of demoing?
Yes, categorically yes, I believe that allowing people to avoid following procedure when it’s too “hard” will serve only to redefine what we consider “hard”. In short, making things optional is likely to lower the bar.
What we are trying to do here is raise bars, not lower them. We’re trying to empower teams so that they can improve from within. We should trust that challenging a team is likely to achieve better results than making the hard stuff optional.
Will we always come up to the standard we set?
No. But that doesn’t mean we should take our failure to do so lying down. Failing to demo something, or indeed cutting any corner should be a big deal, an exception, “too hard” is not in itself a sufficient reason.
We want to maintain a clear and shared understanding of how important it is to not cut corners, without becoming dogmatic. That’s a very fine line to walk.
It is precisely in the things that are hard to demonstrate that demonstrating is most useful. The job of finding a way to demonstrate a feature will in itself challenge us to think differently about the software. Perhaps the difficulty stems from a bad design, or a decent design that could be better, or perhaps it stems from not really understanding the value of the feature to the users.
Even if we have a Product Owner who trusts us and who is willing to give us a pass on some of our responsibilities, we should decline. For our own sake and for the sake of the team.
We, as a team should choose to demonstrate our work and do the other things that our process or framework or methodology commit us to, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone.