Value driven technical decisions in software development
NB: Have added longer article on Medium:
February 13th I was at SwitchON 2020 in Stockholm.
At the conference I got to deliver my talk "Value Driven Technical Decisions in Software Development" for the first time in public.
The talk consists of three parts.
In the first part I look into technical reasons why projects fail.
This is based primarily on the work by Søren Lauesen and the report "Damage and damage causes in Large government IT projects".
After this I jump into what I term "the overengineering triad" in software development. In the software development industry we have some learning fallacies, a tendency to introduce value proxies/substitutes and finally an inherent overengineering bias produced by equal parts cognitive biases and game theoretic phenomena.
In the last part of the talk, I go into specific things we can do to mitigate the risks and damages incurred by the overengineering triad. My current suggestions are:
1. Projects start out with at most 2 or 3 “risk tokens”
The idea with risk tokens is, at its core, to constrain development teams from taking to much risk on board in projects or products.
When "Risk" is a scarce ressource, it nudges teams discuss:
"Would we rather take on this risk A to get this value/gain X
or would we rateher take risk B to get Y?"
This encourages the discourse of value driven technical discussions and makes explicit that software development is, to a great degree, an exercise of managing risk. And risks should only be taken to get a corrosponding value.
2. Identify, evaluate and remove things that block or delay
The key-word here is evaluate.
Every time we see something in our work that creates friction, we should evaluate what we are trying to get out of it. I.e. what value is the process/tool/whatever creating the friction intended to create?
Could we get that another way, without or with less of the friction and negative impact?
3. When people disagree, identify what they value or weigh differently, resulting in their different conclusions
People probably have their reasoning close to correct, so it is often not the case that one of the people disagreeing is correct and the other(s) did not reason correctly.
It is often because they have different priorities or assigned importance to some of the factors going into the reasoning. More about this later.
4. Ensure developers know the user and customer
Please make sure you developers go on Gembas and get to see the place where they contribute value. It helps avoid value substitutes, it motivates people and it enables to prioritize their focus and identify low hanging fruit and be innovate incredible much.
Do we measure value?
I got a good question in Stockholm about how value is measured in the decision process.
This is a great question.
Most often it is not important exactly what value or weight we assign to some basic requirement to, or benefit from, our solution. E.g. scalability, ease of use, simplicity, etc.
But when we outline that we choose a specific solution over another, because we believe X to be important and Y to be much more important than Z, then we suddenly have hypotheses we are able to (try to) disprove or validate.
This brings us much closer to an actual objective evaluation tailored to the specific challenge we face in a given situation, instead of basing it on unconscious biases and kneejerk reactions. This is especially important when exploring the undelying reasons for disagreements about what solution to use. (i.e. when trying to identify what people value differently resulting in their different conclusions)
February 13th I was at SwitchON 2020 in Stockholm.
At the conference I got to deliver my talk "Value Driven Technical Decisions in Software Development" for the first time in public.
The talk consists of three parts.
In the first part I look into technical reasons why projects fail.
This is based primarily on the work by Søren Lauesen and the report "Damage and damage causes in Large government IT projects".
After this I jump into what I term "the overengineering triad" in software development. In the software development industry we have some learning fallacies, a tendency to introduce value proxies/substitutes and finally an inherent overengineering bias produced by equal parts cognitive biases and game theoretic phenomena.
In the last part of the talk, I go into specific things we can do to mitigate the risks and damages incurred by the overengineering triad. My current suggestions are:
1. Projects start out with at most 2 or 3 “risk tokens”
The idea with risk tokens is, at its core, to constrain development teams from taking to much risk on board in projects or products.
When "Risk" is a scarce ressource, it nudges teams discuss:
"Would we rather take on this risk A to get this value/gain X
or would we rateher take risk B to get Y?"
This encourages the discourse of value driven technical discussions and makes explicit that software development is, to a great degree, an exercise of managing risk. And risks should only be taken to get a corrosponding value.
2. Identify, evaluate and remove things that block or delay
The key-word here is evaluate.
Every time we see something in our work that creates friction, we should evaluate what we are trying to get out of it. I.e. what value is the process/tool/whatever creating the friction intended to create?
Could we get that another way, without or with less of the friction and negative impact?
3. When people disagree, identify what they value or weigh differently, resulting in their different conclusions
People probably have their reasoning close to correct, so it is often not the case that one of the people disagreeing is correct and the other(s) did not reason correctly.
It is often because they have different priorities or assigned importance to some of the factors going into the reasoning. More about this later.
4. Ensure developers know the user and customer
Please make sure you developers go on Gembas and get to see the place where they contribute value. It helps avoid value substitutes, it motivates people and it enables to prioritize their focus and identify low hanging fruit and be innovate incredible much.
Do we measure value?
I got a good question in Stockholm about how value is measured in the decision process.
This is a great question.
Most often it is not important exactly what value or weight we assign to some basic requirement to, or benefit from, our solution. E.g. scalability, ease of use, simplicity, etc.
But when we outline that we choose a specific solution over another, because we believe X to be important and Y to be much more important than Z, then we suddenly have hypotheses we are able to (try to) disprove or validate.
This brings us much closer to an actual objective evaluation tailored to the specific challenge we face in a given situation, instead of basing it on unconscious biases and kneejerk reactions. This is especially important when exploring the undelying reasons for disagreements about what solution to use. (i.e. when trying to identify what people value differently resulting in their different conclusions)