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:
- Why is Scrum a popular choice?
- Why is Scrum the most favourable version of Agile?
- Can “Welcoming the change” be welcomed by the client?
- What do clients perceive in “Welcoming the change”?
- Can “Welcoming the change” be welcomed by the team?
- Can companies look for some other framework (other than Agile) to solve their issues?
- Why can’t we make our teams happy and still ask them to work to their best?
- How does Scrum try to solve most of the issues of software development teams?
- Why do we adopt Scrum of free will and then blame Scrum for failure?
- How does our rigid Waterfall organizational structure affect Scrum implementation?
- Why do companies want to adopt Scrum?
- Why are clients happy about Scrum?
We have heard about the Iron Triangle of scope, ost, 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 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:
- Product owner (PO)
- Scrum Master (SM)
- Team
Let’s discuss these vertices one by one:
- 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.
- The Scrum Master 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).
- 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 Scrum Master also remains silent, the state is worse.
- The team says, “No” to such requests and the frequent changes in the priorities; however, the Scrum Master is silent or on the PO’s side. Things are not good. The team will lose trust in the Scrum Master and will not raise issues in the retrospective meeting. No continual improvement can occur.
- If the Scrum Master is doing his duties well but the team is not vocal about the issues that are/were impeding their progress, then the Scrum Master 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 Scrum Master can trust the team.
- If the Scrum Master 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 Scrum Master 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.
Does Scrum Also have the Golden Triangle?
- All projects Agile or Waterfall or whatever be the philosophy they take after, will have contending requests from these 3 perspectives – Scope, Time and Cost.
- Give me a chance to make an inquiry: If you have 5 individuals in your team and have a multi month plan, do you figure I can continue including increasingly scope things to the overabundance and you will in any case complete on time?
- You may think about an answer like, I can in the event that I include 2 additional engineers or on the off chance that I get multi month additional time however you as of now addressed my inquiry – No, you can’t. On the off chance that you settle the team measure and the calendar, the measure of programming highlights the team can deliver is constrained (expecting you don’t influence your team to work 16 hour days)
- Get the photo? Be that as it may, I haven’t unequivocally addressed the inquiry, have I?
- Does Scrum likewise have the Golden Triangle – Explicitly No.
- Astounded?
- In Scrum the Product Backlog is certifiably not a settled substance like waterfall. The scrum team endeavors endeavor at working the same number of highlights of the product (in need request obviously) however there is no responsibility that the team will fabricate the greater part of the highlights in the overabundance. We have a committed Product Owner who assumes the liability of modifying the product scope in light of need and the teams speed. Subsequently we don’t have a Golden Triangle in Scrum. We just have a Time versus Cost Trade-off in Scrum since extension is constantly factor.
- The Time versus Cost Trade off (With Scope Being the Evolving Constant)
- The most effortless approach to diminish a project span is by including more individuals – this has been the maxim of managers since project management turned into a calling (this is additionally the motivation behind why programming designers abhor project chiefs)
- At any rate, in many companies, each product has a guide of highlights and furthermore has timetables to hit the market with those arrangements of highlights. Along these lines, Time part of development is quite often settled and does not change except if something intense happens. At the point when time can’t change (and degree is developing), fetched needs to change to adjust to the circumstance – there is no other decision. We add more individuals to the project with a specific end goal to address the projects’ issues.
- For instance, assume a project would take multiyear for 1 individual to wrap up, an additional individual could most likely outcome in a general timetable of around 7 months. Including someone else may bring the timetable to around 4-5 months and including more individuals may additionally abbreviate the calendar however not precisely by a numerical factor since we likewise need to consider overheads on correspondence and coordination between the diverse gatherings included. At any rate, including more individuals implies the project turns out to be more costly and this where the exchange off amongst calendar and cost comes into picture.
- All things considered, Senior Managements over all organizations and companies push for bringing down of cost or costs. Thus, it may not be for all intents and purposes attainable to have an unending spending plan. In any case, having said that, an organization that needs to put up an product for sale to the public can’t be exclusively centered around the cost of building it in light of the fact that, discharging the product with greatest highlights and inside submitted courses of events is significantly more imperative that sparing expense. On the off chance that you are asking why, think about this – Todays showcase is profoundly aggressive and fourteen days postponement could be the contrast between a product being a win or a disappointment. On the off chance that our rival discharges a comparative product half a month in front of us wouldn’t customers pick their product finished our own?
- This is the reason, experienced scrum experts will attempt to get the different distinctive partners in the scrum project like Architects, UI Designers criteria to work consistently together to keep the postponements because of overhead as negligible as could be expected under the circumstances and keep the calendar as short as would be prudent. Indeed, even in companies where taken a toll isn’t generally an issue, scrum experts still endeavor to upgrade the team measure and not rely upon interminable employing just to meet the contending timetable or extension requests.
For more blogs: https://blog.aleph-technologies.com/
As a company comprised of individuals who have seen the vast number of improvements the Agile mindset can bring, It has become our resolute mission to bring Agile practices to every workplace the world over.
