Get certified - Transform your world of work today

The Agile Golden Triangle

05/23/2014 by Gurpreet Singh

Agile is a difficult word, and this world is even more difficult.

Charles Darwin's theory of the survival of the fittest still prevails, though in different forms.


Innovation started from the Industrial Revolution, and it impacted the IT revolution as well. Companies started working to create software products and classifying their ideas to make strategies or frameworks. Waterfall came into existence. However, the world is changing so fast these days that Waterfall could not be the answer to solve all issues. Other frameworks had birth; Agile was one of them. Agile is also not the answer to all issues. However, it is still a famous choice.

We will cover the following topics in this discussion:

  1. Why is Scrum a popular choice?
  2. Why is Scrum the most favorable version of Agile?
  3. Can "Welcoming the change" be welcomed by the client?
  4. What do clients perceive in "Welcoming the change"?
  5. Can "Welcoming the change" be welcomed by the team?
  6. Can companies look for some other framework (other than Agile) to solve their issues?
  7. Why can't we make our teams happy and still ask them to work to their best?
  8. How does Scrum try to solve most of the issues of software development teams?
  9. Why do we adopt Scrum of free will and then blame Scrum for failure?
  10. How does our rigid Waterfall organizational structure affect Scrum implementation?
  11. Why do companies want to adopt Scrum?
  12. Why are clients happy about Scrum?
These are a few tips of an iceberg, and this iceberg is enough to sink the Titanic (or any big project).

We have heard about the Iron Triangle of scope, cost, and time as it affects quality, irrespective of the method.


This Iron Triangle was very rigid during the Waterfall era. Hence, when the clients changed the requirements to a substantial degree, it became difficult for the teams to keep the clients happy -- and in the worst cases, the projects failed.

Variables Effect How is our client?
More features/change in
Increased cost if deadline (time) is fixed Client is unhappy about the increased cost if it goes beyond the buffer
More features/change in
If the cost is a concern, then the scope needs to be redefined, and few of the "agreed upon" features need to be dropped off to maintain the cost within the buffers; a new MVP (minimal viable product) needs to be launched The client is unhappy as a few of the agreed-upon features were not launched at the time of release

Hence, any substantial change in scope will affect the other parameters, cost and time. This might decrease the satisfaction level of our clients.

Agile tried to answer this situation by "melting" the Iron Triangle. The vertices of the triangle become fluid to accommodate the success of the project.

Now let me introduce another triangle, the "Golden Triangle" of Agile. This Golden Triangle consists of three vertices:
  1. Product owner (PO)
  2. ScrumMaster (SM)
  3. Team
Let's discuss these vertices one by one:
  1. The product owner is the person who will represent the business and will give the requirements to the team. Honestly, he is very concerned about the business and less so about the team. He will try to "push" stories to the team, even during the sprint. These stories might be "out of the queue" requests that were never planned in the sprint planning meeting.
  2. The ScrumMaster is the person who will ensure that the team is following the Scrum practices in the right Agile spirit. Also, he makes sure that the product owner does not pressure the team by pushing out-of-queue stories forward or by changing the priorities every now and then (during the sprints). He is a facilitator and he needs to facilitate a good Scrum atmosphere in the team and be sure the team raises issues and solves them (in the retrospective meeting and otherwise).
  3. The team consists of the developers, QAs, UX, UI, DB, system architects, etc., who will do the actual groundwork. They code, review, deploy, test, and go live. . . . They understand the requirements from the PO as laid out during grooming and planning meetings and they size the stories. They commit an ABC count of the stories that they plan to complete in the coming sprint.
Let's add some spice and pose a few hypothetical (yet true on actual grounds) situations:

Situation 1: The PO keeps on sending out-of-queue requests and keeps changing the priorities of the requests during the sprint.
  • The team stays silent; probably it is a bad state. If the ScrumMaster also remains silent, the state is worse.
  • The team says, "No" to such requests and the frequent changes in the priorities; however, the ScrumMaster is silent or on the PO's side. Things are not good. The team will lose trust in the ScrumMaster and will not raise issues in the retrospective meeting. No continual improvement can occur.
  • If the ScrumMaster is doing his duties well but the team is not vocal about the issues that are/were impeding their progress, then the ScrumMaster is helpless. Ultimately, he is a facilitator.
Situation 2: The PO is doing his duties well. He is sending crystal-clear, crisp requirements (story, user acceptance criteria, Definition of Done, etc.) to the team. He never changes the priorities or pushes stories on the team during sprints unless it is a fire-fighting situation (note that every situation can't be fire-fighting).
  • The team deliberately sizes stories incorrectly, to increase velocity. Estimates should be as accurate as possible, but they should also remain estimates. If the estimates are 100% correct, then they are not estimates. Scrum is based on the empirical model and sizing is done on a comparative sale, not on an absolute scale. For example, a completed story is taken as a reference to size current stories where the actual completed story was "closer" to our estimates. Now, coming back to the same question: If the team is sizing stories incorrectly to show that they have a high amount of work, this fails Agile! Neither the PO nor the ScrumMaster can trust the team.
  • If the ScrumMaster does not know this, or he does and he is keeping mum, he is failing the concept of Scrum.
Situation 3: If the PO and the team are discharging their duties well but the ScrumMaster is not available or does not put effort into facilitating resolution of the team's issues, then he is failing the concept of servant leadership, which is essential for Scrum.

If these three vertices of this Golden Triangle (PO, SM, and the team) work with each other, with honesty and dedication and without politics or ego clashes, then every product will be a golden (successful) one.