"The TQB Iron Triangle" has long since been overhauled. Still, there is a tradeoff that we need to make - and we all do this, every day. Unconsciously. The Effort Distribution Triangle is one way to bring the tradeoffs we make into visibility, so we can have a meaningful discussion whether we're making the right choices.
|The label indicates "We aren't investing into it" and the opposing line indicates "Everything invested into resolving this". |
The normal condition would be somewhere in the middle.
We have 100% of our effort to distribute. We can invest it any way we choose into delivering features, improving technology and discussion about goals and methods.
Regardless of how we distribute our effort, 100% is 100% - so choose wisely!
Opportunity CostBy delivering features that might add value to our product, we do what development teams are supposed to do: create tangible business value. We always need to keep sight of business value, as this is the purpose of doing development work.
At the same time, excessive focus on delivery might cause us to neglect the underlying technology or communication.
In turn, the risk we run by spending too much time aligning and optimizing our technology is the time we lose on innovating and delivering things others need. This is our opportunity cost.
Technical DebtPhrased positively, "Continuous attention to technical excellence and good design enhances agility."
It allows us to get more things done faster, and make changes with less effort.
Taking a pessimistic view, everything that isn't as good as technically possible can be called "technical debt". We always have technical debt, so at best we can control whether we consider the debt pressing or not.
Sometimes, we just want to get something through the door, and we're cutting corners on a technical level. We might have skipped the occasional refactoring, or anything like that.
Without accusation, I have observed many developers who prefer spending time on improving technology over time spent in meetings. While there are bad meetings, the consequence might be that some people don't understand things they should understand - communication debt!
Communication DebtAs mentioned in another article, "communication debt is the communications we should have had that we didn't have".
Good communication provides alignment, transparency and clarity of purpose. It's the basis for autonomy and self-organization within a company.
Communication takes time. Scrum, for example, dedicates five Dailies per week, plus one Planning, a Review and a Retrospective plus occasional Refinements - for a total of roughly 15% of your calendar to pure communication, and it's incredibly difficult to function as a team by going any lower. And that doesn't even include work floor communication, such as whiteboard design sessions, pair programming, code reviews and whatnotever.
Communication effort is an integral part of your total capacity to do things.
While some effort put into communication is in fact part of your ability to optimize both delivery and technology - there is also communication aside from that: Like letting other people know what you're doing, letting them learn from you or learning from them.
Make your choiceTake your pick anywhere on the triangle. Discuss the long-term consequences of this choice with your team. This choice is never once-for-all, you can always change it. Yet, there are choices of strategic nature and choices of tactical nature.
Strategically, a delicate balance is most suitable to maximize sustainability. Tactically, the team might decide to go all-in on technical improvements or feature delivery. That's not viable - so the Scrum Master and Product Owner should keep an eye that the triangle doesn't get too lopsided for a prolonged period of time.