"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 Model
 |
| 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 Cost
By 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 Debt
Phrased 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 Debt
As 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 choice
Take 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.
Hi Michael. I found you and your blog from Vasco's podcast. Thank you for writing on the topic.
ReplyDeleteIn regard to the technical triangle, is it fair to say that the common agile approaches - thinking scrum - address the communication debt (meetings) and opportunity cost (sprints and MVP) and "let technical debt take care of itself", or am I missing something?
oops...meant "iron triangle" and wrote "technical triangle"...
DeleteThanks for asking.
DeleteThe XP approach is clearly aimed at technical and communication debt, while minimizing opportunity cost through rapid feedback cycles, so it would fall somewhere right in the center of the Triangle if done well.
Yes, Scrum as per Guide totally ignores the Technical portion, although Scrum (and SAFe!) as often practiced also doesn't have a good look at opportunity cost.
One additional note: communication debt isn't anywhere settled with the Scrum ceremonies, these are just door openers to further communication which needs to happen, for example: "How is my coworker going to understand my code?" or "How can we know 3 years into the future why we did implement this feature?"
Scrum, done well, underlined by solid Engineering Practices and with due respect paid to the Agile Principles ("Technical Excellence" comes to mind) will be robust in the Technical Triangle. It looks slightly different for Cargo Cult Scrum, which often takes the worst possible approach and maximizes debt in each corner.
I was thinking of the Scrum sprint cycle as addressing the opportunity cost because of fast-er feedback getting the project to deliver more value earlier and I agree that communication debt is not settled with Scrum ceremonies but they are probably an improvement over the weekly project status review thus moving away from the communication debt corner.
ReplyDeleteI have experienced and, fortunately, escaped the Cargo Cult Scrum work environment and now I try to take a more holistic view of the needs of the team and project and the capabilities of components of different agile/lean methodologies and help the team pick the right fit. I think this is aligned with your last paragraph. Experiment in process...
Thank you for the conversation.
Thank you for coining the term "Technical Triangle". It's a great description and I will fly with it.
DeleteYou are right that Scrum addresses opportunity cost with faster feedback cycles (compared to preplanned quarterly/yearly agendas), especially when the backlog is flexible.
Unfortunately, I experience that many backlogs are so cluttered with worthless items that the PO is somehow intended to manage that delivering the most value first has become a practical impossibility.
It really depends. As I mentioned, Scrum done well is really solid here - although Scrum itself is no guarantee, as many organizations have a very poor understanding on the power of Scrum.
A good way to check how well Scrum is helping here is seeing whether the learnings from a Sprint Review actually affect the content of the next Sprint(s).