On Accountability in Software Development
All businesses want accountability. It is part of making anything work. If you need to achieve results, you need to deliver something, and it would be great to know when it’s going to happen.
Accountability is still a trigger word for software teams though. When misused, it turns into strict (and sometimes artificial) deadlines. And those can be detrimental to teams in many ways. Why is it the case and why is it so hard?
To start, if you want accountability, you better get predictability first. If you can’t predict work (and timing of it), then it will be hard to become accountable. The positive conversation is on how to make teams more predictable, and thus able to be accountable for results. Accountability needs predictability. The main question is how to get there.
On predictability in software, there are two topics that are worth discussing:
- Variation in production processes
- How to tackle variation in software delivery
Variation in Production
You can expect variation in any production system, and it won’t be different in technology.
In any business, there are always variations, between people, in output, in service and in product. The output of a system results from two types of variation: common cause and special cause variation [1]
In the above, common causes are the consequences of the system, or how the work works. For example, if a team can’t focus on work, then we see more variation since the effort is spread across many different things. Special causes are out of the ordinary events that increase variation. That could happen if there was an incident and the team had to divert its attention for a significant amount of time.
We usually overestimate special causes over common causes. That is detrimental to variation. And acting on it in the wrong way will make results worse rather than better.
Again tying to the area of psychology; people think there is much less variation than actually exists. Therefore their natural inclination (without a sufficient knowledge of variation) is to suspect a special problem when actually it is just the natural variation in the system. Tampering, over-reacting to variation, is a common method of increasing variation — and costs! [1]
What about Software Delivery?
Variation is especially important in software delivery. It is a field where expected (common cause) variation is quite high. Software is naturally complex.
The specific challenge with it is that every feature adds more code, more logic, and increases the complexity of the whole system. With that, work becomes more complex, riskier and harder to predict.
Why is it a challenge?
The chart above is easy to understand. But in practice, when there is tension about delivery, it’s easier to find simpler causes. Causes which can create a push for more predictability.
And that’s when it becomes a problem. Stricter deadlines and demand for “better” estimates means treating common causes as a special causes. Instead of dealing with complexity, we deal with bad estimates. We then create and perpetuate a vicious cycle. One that will only increase variation and reduce predictability.
Once you get into it, the most likely results will be burn out and/or the constant reduction of product quality.
What’s the alternative?
This is not to say that teams should not aspire for predictability. They should and need to, after all we do work within business constraints.
The best action is to reduce complexity and increase predictability, by acting on the system (common causes). There are many ways to do it, and some of the ways in which the industry has tackled these problems are:
- Establishing better quality: Automated regression testing, continuous integration and deployment, alerting. These are all ways to safeguard development and make it easier to spot problems. With that reducing the complexity of delivering new code.
- Reducing code size and complexity: Taking time to simplify the system. Refactoring, splitting your system in smaller parts, removing unused code and features. All those make the system less complex and more predictable to work on.
- Simplifying solutions. Productive product teams focus on the customer problem they are trying to solve, iterating on the solution. It enables more effective technical solutions that reduce the rate in which complexity increases.
Acting on the system might take longer to result in change. But ultimately it’s what will drive better outcomes. In quality, time and cost.
