The Agile Golden Triangle

23 May 2014


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.

gurpreet-1.jpg

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.

Gurpreet-2.jpg

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
requirements/scope
Increased cost if deadline (time) is fixed Client is unhappy about the increased cost if it goes beyond the buffer
More features/change in
requirements/scope
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
Gurpreet-3.jpg
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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2 (2 ratings)

Comments

Tim Baffa, CSM, 5/23/2014 3:03:21 PM
Good points in the article around Scrum. A few observations:

1) I don't see any relevance between the beginning of the article and the "Golden Triangle" theme. The 12 topics listed are not addressed. Was this article taken from a much larger article?

2) I would not identify Agile as weakening the vertices of the iron triangle. If anything, the Waterfall approach allows manipulation of time, cost, scope, and quality to achieve project "success". Agile seeks to eliminate uncertainty and complexity by adhering to a rigid time, cost, and quality framework. The only true variable in the scrum world is Scope.

3) As a Scrum Master, it is critical to have both the business and the team abide by a definition of ready and a definition of done. The PO is certainly within their rights to offer stories that don't meet a DoR, but there should be complete understanding that the team is perfectly within their rights to not accept it.

4) Regarding your Situation 2, I don't see the impact of a team increasing their story point estimates. Story Points are a relative estimate that pertains specifically to the team doing the estimating. Why should anyone care if the number is high or low, as long as the estimates are relative to other estimates? Velocity should never be used as a metric to review team performance (i.e. - you should be completing more story points per sprint...)

I currently serve a team that estimates rather large story point sizes, but mostly because they still struggle with the smaller SP numbers. Which is fine, because if the team is relatively estimating correctly, the "scale" can be raised or lowered at any time, if the team so desires, and the estimated stories will have SP larger than stories smaller than them and smaller than stories larger than them.
Gurpreet Singh, CSP,CSM, 5/25/2014 4:00:28 AM
Thanks Tim for your kind & lengthy feedback. Please find enclosed my responses:

1) This write up is a part of my Presentation (to be delivered at a Conference). Thats why the questions are unanswered in this write up.

2. I never said Agile weakened the Iron triangle; I used 'Melted' so that it was more fluid (agile). Agile has definitely reversed the Iron triangle.

3. I have seen PO giving additional work (out of the queue stories / out of the scope stories) to the team as they assume that the team is normally free as they give bigger estimates to him during the planning meetings.

3. I have also seen Teams, SMs and the Organizations putting so much pressure on the Metrics (esp Velocity) that the Teams tend to play on these metrics. I agree with you that the estimations will be relative; however, the story is very sad (but true) at the implementation level. Good, bad or ugly; it is a failure of Agile.
Gurpreet Singh, CSP,CSM, 5/25/2014 9:57:28 PM
@tim: please share your thoughts on the same
Prashant Pund, CSM, 5/26/2014 4:46:37 AM
Good Article and I liked the idea of putting the 3 roles as vertices of Golden Triangle. However, the Iron Triangle is not melted at all the vertices in Agile. The "Assumed" and "Estimated" vertices differ. In traditional way, Scope is "Assumed" and the other two are "estimated" while in Agile; the same other two are "Assumed" and Scope is "estimated". Resources and Time are considered "Assumed" because of the fixed size of the cross functional team and target completion date respectively. The Scope is adjusted for bringing in "value" rather than delivering "features". So the "fluidity" applies more to the Scope. Also, I agree with Tim about story sizing.
Gurpreet Singh, CSP,CSM, 5/26/2014 8:40:59 PM
Hi Prashant,

Thanks for your feedback. In theory, I agree with you. However, in practice: the companies put immense pressure on the development teams to deliver XYZ scope (scope fixed) within the fixed time (sprint. This is indeed Mini waterfall timeboxed within a Sprint cycle. They do it under the BIG name of Agile.

@prashant: please respond with your feedback.
Tim Baffa, CSM, 5/27/2014 12:12:08 PM
Gurpreet, I am happy to share additional thoughts.

I would state rather strongly that while the misuse of story points by an organization may be a reality, it is in no way a failure of Agile. Instead, I would classify it as a failure in understanding and implementing Agile.

A main goal with Agile is re-establishing the trust between the team and business that doesn't exist in the old waterfall methodology. It seems your experiences continue to highlight the mistrust between the team and business, and there is little transparency being nurtured.

Business tries to submit additional work to teams because they neither trust the team estimates nor do they trust team members to work to the best of their abilities during a sprint. Teams then manipulate SP to counter business skepticism around their productivity.

You describe a very unhealthy business model that may be mitigated by Agile principles, but it requires the resolve and determination of a good Scrum Master to encourage the necessary change by all parties involved.

Good luck!
Neeraj Malkoti, CSM, 5/29/2014 3:58:20 AM
Great discussion, guys!

My 2 cents..

Situation 1:
Refer, Agile principle #2: Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage

PO keeps changing the priorities of the requests during the sprint. This is legal as long as they are not in scope of current sprint, meet DOR in next Product Backlog refinement sessions & PO wants team to pick these in next sprint.

If ask is to include them in ongoing sprint, everyone needs to understand motivation/ rationale. A conversation within Scrum team (PO+ SM+ Feature team) may be sufficient to reach consensus. For example, if rationale was to meet regulatory commitment or pay $10 million fine to regulators, then sanity will prevail. It's all contextual. Conversation is the key.


Theory Y believes that, given the right conditions, most people will want to do well at work. They believe that the satisfaction of doing a good job is a strong motivation. So if someone is not keeping up with the theme- then others need to muster 'Courage- an agile value' & ask why during Retrospectives or 1-on-1.

During retrospectives:
- SM's needs to hold up that "mirror" to the team & PO.
- Team needs to provide feedback on SM & PO during retrospectives so everyone can inspect & tune behavior.

Situation 2:
Refer, Theory Y above.
Refer, Agile principle #8- promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

If team is estimating incorrectly- it's ok. Estimates will never be right, as you said.
Key is to understand / clarify why does team think its necessary to inflate them?
Do they want to focus on engineering improvements?
Once Sprint starts, scope is frozen unless team has met sprint goals & wants to pick more "ready" items from the backlog. (which meant estimation could have been better!).
In this case, seems PO needs coaching. Scrum Master needs to step in.



Situation 3:
- If SM is new, he needs to learn quickly or seek help from SM community within organization.
- If SM doesn't get any better, team can decide to replace him with another SM.



Focus shouldn't be on metrics.
Refer, Agile principle #7: Working software is the primary measure of progress.
Focus needs to be on deliverable which is working software.

Burn down charts depicting Velocity are a mere representation of the journey within the Sprint. If team hits goals, charts merely reflect them.
Unfortunately, it never works other way round (which somehow always worked in waterfall :-)).

Just like any brilliant idea- agile principles, values aren't a problem.
Failure lies with interpretation & implementation. ( & mostly implementation without interpretation)

Great thread - I learned a lot!


Cheers
Malkoti

You must Login or Signup to comment.