The Iron Triangle commonly serves as the basis for terrible product decisions.
Why is it such a terrible idea? 🧵
#productmanagement #agile #scrum
Why is it such a terrible idea? 🧵
#productmanagement #agile #scrum
1. False constraints
Delivering software faster and with higher quality doesn't necessarily mean increased costs:
- Reducing the time-to-market allows you to start getting benefits faster.
- The cost of fixing a bug increases in time.
linkedin.com
Delivering software faster and with higher quality doesn't necessarily mean increased costs:
- Reducing the time-to-market allows you to start getting benefits faster.
- The cost of fixing a bug increases in time.
linkedin.com
Many managers look at the triangle and think adding people ("resources") will speed up the work.
They forget that people have needs, and ambitions. Any change in the team can impact its work. Also, the complexity of communication increases dramatically with the team's size.
They forget that people have needs, and ambitions. Any change in the team can impact its work. Also, the complexity of communication increases dramatically with the team's size.
2. Invalid success criteria
According to the Iron Triangle, a successful initiative is defined as completed before the allowed time, within the allowed budget, and with at least the required scope.
But what if nobody wants to use your product?
According to the Iron Triangle, a successful initiative is defined as completed before the allowed time, within the allowed budget, and with at least the required scope.
But what if nobody wants to use your product?
A product is successful if it delivers value for the customers and works for the business. In other words, people desire the solution so much that they are ready to send you their money.
Meanwhile, value is completely ignored in the picture.
Meanwhile, value is completely ignored in the picture.
3. The scope is undefined
If you build a bridge, that initiative can be planned and executed. But it doesn't work with software.
- You discover what to build, and learn continuously.
- Products are never “done.” You release many times, especially if the product is successful.
If you build a bridge, that initiative can be planned and executed. But it doesn't work with software.
- You discover what to build, and learn continuously.
- Products are never “done.” You release many times, especially if the product is successful.
4. The exact development costs do not matter
As Douglas Hubbard explains: "Even in projects with very uncertain development costs, we haven't found that those costs have a significant information value for the investment decision(...)"
I recommend: cio.com
As Douglas Hubbard explains: "Even in projects with very uncertain development costs, we haven't found that those costs have a significant information value for the investment decision(...)"
I recommend: cio.com
Loading suggestions...