Voting without an opinion, whether for parliament or during Scrum poker

Tomorrow we choose a new Parliament. Parties have shared their positions in their respective programs on all sorts of fundamental and more topical issues that will affect our present and future lives. Some parties have a clear ideological (religious) bent while others are more pragmatic. Whoever you vote for, you effectively support a wide array of positions that may not be all your own and which can often only be fleshed out in a diluted fashion, but that’s what’s democratic coalition government is about. What you certainly can never have as an individual is an informed opinion on everything important.

There are principled and pragmatic positions, and many shades in between. Take the death penalty. You can really only have a principled opinion on that. You can assess how effective it is as a deterrent in other countries (not very) and compare its cost to that of a life in prison, but I doubt it will sway people’s opinions. The real question is whether it’s morally acceptable for the state to punish its citizens by putting them to sleep like a sick dog.

Anyway, there are other controversial matters of principle that we are invited to have an opinion about, one of them being nuclear power. Do you want a new nuclear power plant in the Netherlands? No single individual would be equipped, not even nuclear physicist and former Dutch Labour Party leader Diederik Samson. This is a function with an unknown number of variables. We know that construction and dismantling will cost many billions. It will take at least ten years before it’s operational. True, we will still need plenty of electricity in 2040, probably a lot more than today. But we don’t know what other sources are economically feasible by then. What will we pay for oil and gas? If you simply think nuclear power is scary you vote with your gut. I could rationally counter that by saying it’s a well-established (since 1951), relatively quite safe and clean source of energy. It’s just expensive and very slow to deploy. You can take the principled position that we should give preference to truly renewable energy. But since you don’t know all the facts (and never will) your position will be a subjective value judgement.

In Scrum teams we vote as well. We estimate how long it will take and how hard it will be to build or a piece of new software or update an existing one. We discuss our possibly opposing views on the work. Seldom we will be doing something that is exactly equal to what we have done before. That makes software estimation a tougher call than, say, a quote from a removal company or to have air conditioning installed. A trained eye can quickly judge how many person hours it will take to move the contents of your house into a truck, accepting a small margin of error. All the previous times they did this the circumstances were comparable and predictable. The bigger the job and unknown the territory, the less certainty. Drilling a metro tunnel through the marshland that is the old Town of Amsterdam, with centuries-old houses supported by wooden poles turned out to be full of very expensive black swans.

Ideally every member is equally well informed about the work you undertake as a Scrum team. This doesn’t always work out that well in practice. Especially Scrum teams with a diverse set of specialised skills will (need to) assign certain tasks with certain developers. This is a plausible tactic in a world where specialisation is becoming the norm. You can’t expect every individual to be equally well-versed in frontend, UI/UX, backend, testing and dev-ops. The Scrum Guide, which by the way nowhere mentions the concept of story points, states that the developers who will be doing the work are responsible for the sizing. That makes sense since they are best equipped to give a meaningful estimate. If you don’t have all the necessary details your judgement will have holes in it. You can remedy all that by making your organisation more T-shaped and create overlap between technical skillsets. I’m all for it, because it broadens your knowledge and opportunity to cooperate. Whether it makes good business sense is another issue. But if you do accept having specialisation silos in your team, please stop those silly poker sessions where the backend developer has to explain to the Angular/Typescript guru what it will take to implement OAuth authorization (“Easy, peasy, we did it before. Wink, wink, nudge, nudge three points). That’s an exercise in futility.