Breaking the Iron Triangle: Navigating Change in Agile Environments | Anuj Ojha

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: Breaking the Iron Triangle: Navigating Change in Agile Environments
Host: Vasco Duarte
Guest: Anuj Oja
Release Date: March 5, 2025

---

Introduction

In the episode titled "Breaking the Iron Triangle: Navigating Change in Agile Environments," host Vasco Duarte engages in a profound conversation with Agile Coach Anuj Oja. The discussion delves deep into the intricacies of managing change within Agile frameworks, emphasizing practical strategies and real-world experiences that Scrum Masters and Agile Coaches can implement to foster successful Agile transformations.

---

Understanding the Iron Triangle in Agile

Anuj Oja begins by recounting his early experiences with Scrum, likening the initial excitement of adopting Agile practices to diving into a swimming pool—simple yet unexpectedly challenging. He introduces the concept of the Iron Triangle, which comprises scope, cost, and time—traditionally fixed constraints in project management. Anuj explains how these constraints often clash with Agile principles, which advocate for flexibility, incremental progress, and quality without compromise.

Notable Quote:
"You should never fix all the three. The scope, cost, and time, if we are fixing this, it is not possible for you to be agile."
— Anuj Oja [03:00]

---

Navigating Constraints Through Flexibility

Anuj shares a pivotal lesson from his career: the necessity of flexibility within constraints. When faced with rigid project demands—such as delivering a fixed scope within a set budget and timeframe—he learned to negotiate adjustments in one area to preserve Agile integrity. For instance, if scope and time are non-negotiable, he advocates for increasing the budget to maintain quality and feasibility.

Key Strategies:

• Prioritize Requirements: Collaborate with stakeholders to identify and focus on high-priority tasks (e.g., P0P1 tickets) when compromises are unavoidable.
• Transparent Communication: Clearly articulate the implications of fixed constraints to management, fostering a shared understanding of Agile limitations.

Notable Quote:
"Agility in the first place came because there's uncertainty in the system. We have ambiguity with us and we are building a software product."
— Anuj Oja [04:30]

---

Mastering Stakeholder Communication

A recurring theme in Anuj's narrative is the importance of understanding and speaking the language of all stakeholders—leaders, customers, and team members. He emphasizes that effective communication is foundational to guiding projects through uncertainty and change.

Techniques for Effective Communication:

• Language Alignment: Learn the terminology and priorities of different stakeholder groups to ensure messages resonate and are understood.
• Collaborative Dialogue: Engage in open conversations to align goals, manage expectations, and navigate conflicting priorities.
• Educational Advocacy: Empower teams and stakeholders by educating them on Agile principles and the realities of project constraints.

Notable Quote:
"Need to understand the language from all of the stakeholders that you mentioned. Challenges are many and in software we will always find challenges we didn't expect to find."
— Anuj Oja [07:22]

---

Agility Health Assessments: Beyond Metrics

Anuj discusses the concept of Agility Health Assessments—tools used to evaluate the effectiveness of Agile practices within an organization. He cautions against over-reliance on quantitative metrics, citing Peter Drucker's adage, "What gets measured gets managed," which often leads to gaming the system rather than genuine improvement.

Insights on Agility Assessments:

• Focus on Outcomes Over Outputs: Prioritize meaningful results, such as team functionality and product quality, rather than superficial metrics.
• Ethnographic Observation: Adopt an observational approach to understand team dynamics and customer experiences, similar to how an ethnographer would study a culture.
• Long-Term Problem-Solving: Resist the urge to hastily address issues; instead, allow time for thorough understanding and collaborative solution development.

Notable Quote:
"We need to learn to sit on the problem for longer. And then over the time, let's brainstorm on solution and also not getting married to a solution because things may change."
— Anuj Oja [10:15]

---

The Art of Observation and Experimentation

Building on his previous points, Anuj underscores the art of observing as a critical skill for Agile practitioners. He advocates for continuous observation to gain authentic insights into team behaviors, customer interactions, and process efficiencies.

Practical Approaches:

• Continuous Monitoring: Regularly observe workflows, team interactions, and customer feedback to identify areas for improvement.
• Encourage Experimentation: Foster a culture where teams feel safe to experiment with new ideas and approaches, learning from both successes and failures.
• Adaptive Planning: Use observational insights to inform and adjust Agile practices dynamically, ensuring they remain effective and relevant.

Notable Quote:
"The art of observing, right? Like to understand people, to understand their languages, we need to be able to observe what is happening."
— Anuj Oja [11:37]

---

Conclusion: Key Takeaways for Agile Professionals

Anuj Oja's insights in this episode provide valuable guidance for Scrum Masters and Agile Coaches navigating the complexities of change within Agile environments. The key takeaways include:

1. Flexibility Within Constraints: Understand and negotiate the Iron Triangle's constraints to maintain Agile principles.
2. Effective Communication: Master the languages of all stakeholders to facilitate alignment and collaboration.
3. Beyond Metrics: Utilize Agility Health Assessments thoughtfully, prioritizing qualitative insights over quantitative measures.
4. Continuous Observation: Embrace the art of observing and adapt practices based on real-time insights and experimentation.

These strategies empower Agile professionals to lead their teams through change effectively, ensuring sustained productivity, quality, and organizational agility.

---

Stay Tuned:
For more actionable advice and inspiring conversations, continue tuning into the Scrum Master Toolbox Podcast. If you're interested in deepening your Agile knowledge and connecting with industry leaders, consider attending the upcoming Global Agile Summit in Tallinn, Estonia, featuring an array of thought leaders and specialized tracks tailored for Agile Business, Product, and Development professionals.

Transcript

[Vasko]

Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon. Hello, everybody.

[Anuj Oja]

Welcome to our Wednesday, the Leading Change episode.

[Vasko]

This week we have with us Anush Oja. Hey, Anuj, welcome back.

[Anush Oja]

Hey, Vasko, thank you so much. It's fun talking to you. Go ahead.

[Anuj Oja]

Absolutely. Likewise. We've learned a lot this week and we're going to learn even more. And let's start with the change process. And change is something we are always working with as Scrum masters. So, Anuj, share with us a change process you were involved with and walk us through the steps like, you know, from the beginning to the end. How did that change process unfold? And as you go, highlight for us the tools, the tips, the tricks and the techniques you learned back then that you still apply today.

[Anush Oja]

Absolutely, Vasco. So when I got into the world of Scrum with a few project teams that I was working with, I felt that it's like a swimming pool. Come on, how big it would be. Let's go, let's swim. It's so simple, just a small guide. Let's do it. And then comes the questions which I wasn't ready for. The management thrown at me that, okay, let's talk about the Iron Dragon, the scope, cost and time. We have limited budget and these are the requirements which are must have, we want to make it happen. Okay. And again, making sure that we have to deliver this project in three months of time. And now your place grown, now you show us your agility, let's see how it happens. And make sure quality is sacrosanct. You are not going to compromise the quality. And I was like, oh my God, what happened here? Because we were talking about failing faster, creating incremental outcomes, working together, collaborating. And now I may need to go and ask the team that, hey, you have to work overtime if you not be able to finish everything. And that was something I didn't want to choose. So I got my lesson about this change. We need to learn first of all the language which leaders talk in. We need to understand the language which customers talk. We need to understand the languages the team talk. And when you understand the language, you need to know how to communicate, how to ensure that we are guided towards the right path by applying the right approaches. So what happened? I figured out that you should never fix all the trees. The scope, cost and time quality, sector sanction should never be compromised. But the scope, cost and time, if we are fixing this, it is not possible for you to be agile. Let's accept that agility in the first place came because there's uncertainty in the system. We have ambiguity with us and we are building a software product. Of course the bugs will evolve. It has to come. Okay, so when I started getting into the management events, the leadership discussion, I figured out that you should never fix all the three. You can still fix the two, but keep the one arm loose. It means if the management asks you that you know what the scope is fixed, let's say some 200 tickets we need to finish and you know the time is also fixed, three months of time, then you should ask the management, Fair enough. Good, thanks for telling me. Now give me this much more money. Your cost should be changing. You can ask, okay, give us 1 million more dollars. Possibly we will be able to finish everything. And then they may say, no, no, no, no, no, no, it's not, doesn't work like that. If suppose the cost and time is fixed, suppose the budget is $200,000, suppose the time is again three months. In that case, suppose you couldn't finish all what you have in this list of 200 tickets. You may always go back and say that in this scope, These are the 80 tickets which you prioritized as P0P1 could be taken care of. Okay, so just an example here that it's very important for us to understand and even put your food down to talk about it. So I faced the situation and I also ended up adding pressure to my team in my early career. And then that was the time I realized that this is not the way how it's going to work. And also I'll tell you sometimes when the code, we are working on a litigation code, okay, that time the technical debt becomes too high. So it's very important that how we build up days and go to the leadership team and other stakeholders into buying for the time and budget for fixing that legacy code, refactoring it, if you put it that way. So that's also the situation where I figured out that we changed the course of action by saying it's not always coming from the customer or product. The requirement would come from anyone. We need to learn, we need to think about it. Because if we only and only focus on DVF that any requirement comes and it's about finding the desirability, viability and feasibility, okay, then we are all we need to be mindful that what is the source of it. It should not be just always about desirability of the customer. If customer is desirable, need to find the viability as well. But imagine this part, that it's viable for the business, it's viable for the customer, but at the same time, making it feasible is such a challenging job for the team because it's such a old code they have to work on. So we need to ensure, before we put that as a requirement, we need to respect how things are going also at the level of the board. So that is one example where I would like to say I worked on with our customers, educated them with our key stakeholders internally in the organization, working with the team so that they should not be hesitant, they should not feel that we just have to make do the magic with whatever we have. And later on we've seen a significant spike into the productivity because the quality has improved. Now we are not into the spaghetti code, we have simplified the code, we have put in CICD pipeline in place and it also helped us into automating the build process altogether. So how we can go hand in hand is where we have seen that change could be driven across the organization. That was just one example, but we can have many examples.

[Vasko]

So for me, the aspect that struck.

[Anuj Oja]

Me and I would like to highlight is this need to understand the language from all of the stakeholders that you mentioned. Challenges are many and in software we will always find challenges we didn't expect to find. So we can't prepare for them, we can only react to them. And that aspect of understanding each of the stakeholder groups language is incredibly important as it allows us to then communicate productively. Right. Like you talked about the specific context. So understanding the iron triangle and communicating the constraints, what's possible, what's not possible within that.

[Vasko]

But there are many other situations we.

[Anuj Oja]

Could talk about, right? Like increasing the size of the team or getting more teams or changing the technology or whatever. Right. Like as you said we need to listen to everyone to figure out what needs to be done next and then we need to communicate it to make it happen through that conversation that we have with the different stakeholders. So what are your tips and tricks when it comes to learning to understand everybody's language? So all of the stakeholder groups language and then also of course taking it in and using it in practice.

[Anush Oja]

I'll tell you about one thing that usually happens in a agile industry which is called agility health assessment. Okay? Many times it happens. So the inquiry that we get from the customers is about we want to know how effective is agile in our organization as okay. And we always start with the first statement that what gets measured gets gamed. Like the Mr. Great Peter Drucker has said that what gets measured gets managed. But it's very important that while you have invited us or while you're calling us to do the certain assessment, we want to tell you that the assessment is purely based on how functional is your team, not dysfunctional. Because the pattern that we have seen was initially when we conducted multi team agility assessment and whatever at the portfolio program and other levels. The results of the first assessment, if we do it like anonymous and people should be doing it, they should, they are the one who should give the scoring against the different frames of thoughts we found out the results are fantastic when we conduct the first assessment. Reason why? Because they have a fear. They think that based on the score of the GBT has assessment they will get evaluated and they will be scored. And you know, of course in the organization there are anti patterns like they try to recognize and give awards to people to the teams at times, but they do not know that it's demotivating in a way because then people will start goofing up at the numbers. Okay? So it's very important first of all that we need to know it's outcome which is better over output. So when we see how things are happening at the level of organization with the level of the team, it's important how you curate the plan for them. And that's where the entire game is. It's always start with observing because we call it as ethnography. Right? When we go to a fancy restaurant and we see there is a guy who is well dressed, doing nothing, trust me, but standing in one corner and observing everyone. And you know what happens at the end of the day this guy speaks, hasn't spoken for entire day maybe, but at the end of the day this person speaks by saying, you know what? This is what the customer feel when they see the menu. You know what, when people enter one restaurant, they prefer to sit on this table the most. You know what, when they look at the food, they smile or they do not smile. You know what? At this time, we are, we are most busy and this time we are not. So it's, it's about observing. It's about understanding. You cannot just make a decision based on an assessment which has some 90 statements or questionnaire and tell the team and tell the leaders that, you know, this is how it's working. So it's, it's very, very important to let this sink in. It's important for us to do not rush to solve the problem. We need to learn to sit on the problem for longer. Okay. And then over the time, let's brainstorm on solution and also not getting married to a solution because things may change. Okay. And then how you can build up the trait of experimentation. Possibly that's where I believe, Vasco, we might be able to make a move.

[Anuj Oja]

Absolutely. And one of the things that you said which is really important is the art of observing, right? Like to understand people, to understand their languages, we need to be able to observe what is happening. And of course, assessments are one way to observe, and they are, I guess we could call them highly effective way to observe, but they are not long observation. They are like just that moment.

[Vasko]

Right.

[Anuj Oja]

So it's important to recognize that it also has its limitations.

[Vasko]

But thank you for sharing that story. It was a great story.

[Anuj Oja]

Thank you.

[Anush Oja]

Thank you, Oscar.

[Vasko]

Hey, friend. Thank you for staying here. Is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. And then 19th and 20th, the conference day. And Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sig Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on, for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example, Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations. Agile Product for product managers, product owners and innovators. An Agile Developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the Scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket [e-mail] I'm really looking forward to seeing you all in Tallinn, Estonia in May.

[Anuj Oja]

I'll see you there.