Transforming Agile Team Meetings, Less Time, More Value | Anuj Ojha

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode: Transforming Agile Team Meetings, Less Time, More Value | Anuj Ojha Host: Vasco Duarte Release Date: March 4, 2025

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in an insightful conversation with Anuj Ojha, a seasoned Agile Coach and Certified Scrum Master. The discussion centers around transforming Agile team meetings to maximize value while minimizing time investment.

---

Influential Literature: "The Five Dysfunctions of a Team"

Timestamp: [01:31]

Anuj begins by highlighting a pivotal book that has significantly influenced his approach to Agile and team management:

"The Five Dysfunctions of a Team by Patrick Lencioni... it's a game changer." ([01:31])

He explains that the book, although not exclusively about Agile or Scrum, offers profound insights into team dynamics that are universally applicable. The five dysfunctions outlined by Lencioni provide a framework for identifying and addressing common team issues, fostering trust, encouraging healthy conflict, building commitment, ensuring accountability, and maintaining focus on results.

---

Identifying and Addressing Team Dysfunction

Timestamp: [03:00]

Anuj shares a real-world example of a team struggling with multiple dysfunctional aspects:

"The first and foremost is about absence of trust... Then fear of conflict... lack of commitment..." ([02:10])

He details how these dysfunctions create a domino effect, undermining team performance and cohesion. By applying the principles from Lencioni's book, Anuj and his team were able to diagnose and systematically address each dysfunction.

---

Transforming Agile Team Meetings

Timestamp: [05:12] - [09:47]

Anuj delves into a case study where excessive meetings were hindering team productivity:

1. Initial Assessment

   • Conducted a health assessment to understand team dynamics and identify pain points.
   • Discovered an overburden of meetings, leading to frustration and reduced efficiency.

2. Streamlining Meetings

   • Daily Scrums: Transitioned to a more efficient format by removing managers from the meetings, encouraging team autonomy and open communication.

     "The meeting lasted for 20, 25 minutes... since that person wasn't there, the people were talking more." ([08:30])

   • Sprint Reviews: Shifted from mandatory demos to demand-driven reviews, aligning them with actual customer engagement needs.

     "They felt that we want to have a demand driven review... instead of just having a demo for the sake of demo." ([07:00])

   • Retrospectives: Moved from repetitive sessions to focused problem-solving forums where specific issues are addressed one at a time.

     "Let's focus on one problem to solve at a time... allow people to post about their problems throughout the journey." ([07:30])

3. Implementing Improvement Backlogs

   • Introduced a backlog of improvements alongside the product backlog, allowing continuous and prioritized enhancements.

     "We started adding the improvement tickets into the project management tool... people love it." ([10:27])

4. Enhancing Quality and Metrics

   • Reduced meeting fatigue led to more time dedicated to quality assurance, resulting in better DORA metrics and fewer bugs.

     "The team has got certain space from those too many meetings... quality and the DORA metrics also started showing better results." ([09:10])

---

Facilitating Continuous Improvement

Timestamp: [10:27] - [16:20]

Anuj explains how integrating improvement tickets into daily workflows fosters a culture of continuous enhancement:

"Backlog of improvements... owner people can vote for that improvements... based on the voting, it starts ranking at the top." ([10:45])

This approach ensures that team members are actively involved in identifying and prioritizing areas for improvement. By leveraging tools like JIRA and Slack, the team maintains visibility and collaboration, embedding improvement into their regular processes without the need for separate, time-consuming meetings.

---

Rethinking Sprint Reviews and Quality Assurance

Timestamp: [12:03] - [16:20]

Anuj addresses the challenge of maintaining quality without frequent Sprint Reviews:

1. On-Demand Demos

   • Transitioned to providing information on demand, allowing stakeholders to request demos when necessary rather than adhering to a rigid schedule.

     "Forecasting to the customer with confidence... we provide information so they can choose to come whenever they want to see what we have built." ([13:15])

2. Establishing Checkpoints

   • Implemented strategic checkpoints to assess progress and gather feedback without overwhelming the team or stakeholders.

     "Checkpoints... seek feedback at logical points... it's a necessity." ([14:00])

3. Collaborative Forecasting

   • Ensured that the Product Owner and the team collaboratively identify incremental outcomes, enhancing transparency and alignment.

     "Product owner should be intelligent enough to identify the incremental outcomes along with the team." ([14:30])

4. Balancing Agility with Structure

   • Maintained agility by not confining the team to strict ceremonial boundaries, allowing flexibility to adapt processes as needed.

     "Staying agile, but not confining ourselves into the boundaries because it worked for everyone." ([15:00])

---

Conclusion

Throughout the episode, Anuj Ojha provides a comprehensive roadmap for transforming Agile team meetings to enhance value while reducing time spent. By addressing team dysfunctions, streamlining meeting structures, and fostering a culture of continuous improvement, teams can achieve higher quality outcomes and more efficient workflows.

---

Notable Quotes:

• "The Five Dysfunctions of a Team... it's a game changer." – Anuj Ojha ([01:31])
• "The meeting lasted for 20, 25 minutes... since that person wasn't there, the people were talking more." – Anuj Ojha ([08:30])
• "Backlog of improvements... owner people can vote for that improvements... based on the voting, it starts ranking at the top." – Anuj Ojha ([10:45])

---

For Scrum Masters and Agile Coaches seeking to optimize their team's meeting structures and enhance overall productivity, this episode offers valuable insights and practical strategies rooted in real-world experience.

Transcript

[Osco]

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. Welcome to our team Tuesday. This week we have with us Anuj Orja. Hey Anuj. Welcome back.

[Anuj Orja]

Hello Osco. Thank you for having me.

[Osco]

So, Anuj, yesterday we talked about your personal journey as a Scrum Master. And of course today we talk about a team's journey. But before we dive into that, do share with us what was the book that most inspired you in your career as a Scrum Master?

[Anuj Orja]

Oh, there's so many books Vasku. I have read and the name of the book that I'll tell you is actually not just about Agile or Scrum, they do not indicate about that, but it's the Five Dysfunctions of a Team by Patrick Lencioni. I assume you might have got a chance to read it yourself. Yes, this book is a game changer. It focuses onto the five dysfunctions that team is facing. And it came at a time when I was really struggling. That's where I figured out that how can I apply knowledge which is not context to the Agile or Scrum directly, but it is in context to any team across anywhere. Okay, so when we talk about this book, Lencioni has presented a five level model that explains possible issues a team might face and how these issues impact each other. Any of it could cause kind of a domino effect, let's say. What are these five dysfunctions? The first and foremost is about absence of trust, which is about building the strong foundation for your team to trust each other. The second dysfunction he mentioned is about the fear of conflict. We need to create a healthy work environment so that the conflict is encouraged. Then talks about the lack of commitment, which is about we should focus on building those commitment within the team. And there are obstacles which comes into making those commitment. And how can you overcome those obstacles? By not focusing on just making a decision and not letting your team fear about making a decision, but helping each other to know that everybody's ideas matter. We can also do some exercises like cascading messages for that. And then comes this avoidance of the accountability where we feel that to enhance accountability it's important that team members should have this openness to discuss about the problem, not just for the performance, but about each other's behavior as well. It's about taking the fear of talking about personal relationships is important. It's about building the respect for each other and creating a belief that can help. And last but not the least, it's about the inattention to research where we feel that many times because of status and ego, we lose our eye onto the most important aspect because of which this project team has been categorized or allowed to come together. It's about creating results, building kind of environment which can sustain. So that's where he talked about that and that's where I felt that reading this book and applying this knowledge to our context has helped me a lot.

[Osco]

Absolutely great book by the way. Often referred to here on the podcast. That's how important it is. It has inspired many people out there. So everybody be sure to check that out. The five Dysfunctions of a Team by Patrick Lencione. Great introduction, Anush. For those of you who didn't know the book, quite an old book already, but still valuable because it of course, as you said, talks about the teams and teams are the same no matter whether they are in place today or 20 years ago or whatever it was when the book got written. And teams are the focus of our next conversation. Anuj of course, because on TeamTuesday we discussed the maybe self destroying path that a team chooses to follow despite their best intentions. So Anuj, tell us the story of a team, walk us through that process like from the beginning to the end. What were those little things that came up in that team that eventually led to problems?

[Anuj Orja]

This is a recent example. I want to talk about one of the customer that me and my teammates are consulting. What happened there? When we started this engagement we did a as is analysis, you may call this as health assessment to identify who they are, what they are doing, what is inspiring them, what doesn't inspire them and of course overall to find out certain insights which can help the team to improve not just to them but also to the leadership team so that they can also provide certain support. We figured out that first realization for me was I'm old. Why I felt so because they believe in a sync conversation and it works for them. Quite bunch of smart kids. Of course we believe that we should bring people together in the same meeting, let them talk about it. But in their case, they feel that staying connected matters more over coming to the Daily Scrum every day. So one bottleneck which we realized among the team where they were forced to come to the Daily Scrum, they were forced to update their tickets where it could have been automated in a way. Okay. So one thing we found out with the team was they were unhappy with the too many meetings. And actually there were too many meetings. So what we did, we took the plug out and then we put the plugin again. We asked the team that okay, at the start of the Sprint, we do have the goals that we need to achieve. Tell me what all meetings you find it as useless. And we can take off those meetings and we will experiment for a couple of sprints. How does it go for them? The first meeting that they wanted to hit was Sprint review meeting. They felt that the nature of our product is in such a way that we do not go to the customer or we do not share our outcome to the customer at the end of every iteration. That is a kind of arrangement which they have with their customers. Customers do not want to be available while we can talk and do anything with the customer and bridge that gap. But in that context it wasn't necessary. So they felt that we want to have a demand driven review, demand driven demo instead of just having a demo for the sake of demo. Then they talked about retrospective as well, where they figured out that we do all these things about what went well, what didn't go well. And we are repeating the same thing all the time. Time, what should we do? And that's when we figured out that this is not going to work like that. Let's focus on one problem to solve at a time. May take any time it could be. And let people have forum where they can post about their problem, not just in the retrospective throughout the journey, which will work for them. And then they were okay, they were very happy with the Daily Scrum. They wanted to continue it, but they want to make sure that it should be our meeting because in their environment it was happening more that it was a meeting for the manager, for them to speak. So we took the manager out of the chemistry and then we focused on how my team can group themselves together and are they having a good conversation. You won't believe Vasco where the dynamics a little bit changed. We took out some people who were not important, even the Scrum master, as a rule, when that person wasn't there, the people were talking more. The meeting lasted for 20, 25 minutes as well, because that was when they figured out it's daily regrouping, replanning. So the challenge that we have faced is it's time for us to know that the generation has changed, the mindset is changed. What they like, what they don't like is also different. We need to first listen to them, understand them and trust their intelligence. Possibly they may adhere to every value which Scrum can provide, but in a different way. Not wanting to bound themselves into the ceremonies and listen aspects. What we have today. One more thing I would like to add is quality is paramount. They are also concerned. It's like the repetition at stake. If you write a quote and it's found too buggy when we realize that team has got certain space from those too many meetings, they have spent more time on the quality and the DORA metrics also started showing better results, which earlier before was very stale for us.

[Osco]

Yeah. So first of all, the too many meetings problem is something that I'm sure many of us have heard. I found it very interesting how you went about solving it. Like for example, when you talked about the retrospective, you say, okay, yeah, let's drop it, but let's make sure we focus on one thing to improve at a time. And I'm considering, okay, that sounds reasonable. Also, because improvements happen one at a time, they don't happen all at the same time. Of course. But how did you find those improvements? Like, what did you build into the conversation with the team that would raise up and qualify the improvements that were important for the team at the time?

[Anuj Orja]

Absolutely. Thank you, Vasper, for asking that. It's very important for us to create a forum where we may see the backlog of improvements along with the backlog of work. So, backlog of improvements. Imagine that the product backlog is the list of items that we want to finish in the order of priority. It is not list of user stories. It is not just a list of tasks. It is list of things that we need to finish to achieve the desired goal. Let's say the list of things or items that you want to finish also include concerns that we as a team facing. So what we did, we asked them, why not we add it as a ticket in our JIRA or ado? Okay. And now when we are meeting again to talk about what we have achieved against what we have planned, we will have a look at that improvement ticket also. We want to do it so we already have a space. We always have a space to keep on adding the improvements. We can have. Owner people can vote for that improvements. Is this something that we need to look up at? And based on the voting, it starts ranking at the top. Okay. And trust me, people love it. And when you integrate it with Slack and every other tool that we have, it makes it easy for people to share what they believe in. So in that approach, we started adding the improvement tickets into the project management tool that we are using. And over the ticket, people started talking about, we started collaborating even in the daily Scrum. Now we don't have to wait for the retrospective meeting to happen. Even in the daily Scrum, since it's a ticket which is visible. We want to talk about all what we have planned for. We also talk about what are we doing for improving what we are struggling with. So that's how Vasco it worked for us.

[Osco]

Another aspect that is really interesting for me is the dropping of the Sprint review. Now, I totally understand that sometimes customers are not interested in what we are producing every week or even every two weeks, right? Depending on how long the Sprint is. And that's fair, right? But in Scrum, there's also the perspective that the team and the product owner themselves demo to each other. Now you mentioned let's do on demand demos. So I'm interested to hear like, how did that work in practice? Like, were the demos really happening? Who was asking for the demos? Because of course it wasn't the customers, presumably from what you described, the customers would want a release every month or every two months, whatever, and that would be fine. But of course quality is not supported by releasing one month or every month or every two months. Right? Quality is supported by checking things as they are developed. So how did that dynamic work in that team?

[Anuj Orja]

Definitely a very fantastic question. First and foremost, we need to understand that we need to call few keywords here. One is like a forecast instead of calling it as commitment. Commitment, okay? Then comes second point is a checkpoint. Okay? We need to add. We need to understand there is a checkpoint for everything. And then comes another element where we need to know what is important for an individual to vet or the work which they are working on. And as a group, what we want to know, okay? Because it might happen certain information the other members of the team may not be interested into. It might take too. It may be too much of detail for them and it might create unnecessary fatigue in their thought process. Okay, so what we did here is we first of all made sure a product owner should be intelligent enough to identify the incremental outcomes along with the team. Partnering with the team, not just alone. When that incremental outcome for us is forecasted even to the customer, so that while they may be saying in two months we want to have the result, they should know that when what capability we have built. And in case they would be interested to know, knowing how they. How it works, we will of course go and present them. First thing is providing information so that they can choose to come whenever they want to see what we have built. Number one, number two. For us, it's important that when the incremental outcome checkpoints are identified, okay, it might happen within 10 days of time, we may achieve two or three of them, or it might happen within 20 days or a month, we may not be able to achieve. Depends on how mammoth that nature of the work is. And we do not want to do half cooked only. We want to seek feedback, but feedback also at a logical point, it should not be just a routine, it should be a necessity. It should be where really someone can improve upon it or with that information, somebody can make a decision, an informed decision. So based on that, we have identified certain checkpoints. Okay. And. And trust me, it might sound that we are not doing reviews we don't have. I'm saying it's. It's for that team. There are of course a lot of teams that we can sell to, but in that context of the team, which is very interesting, they figured out that when we identify the checkpoint, sometimes it is not just for the product owner, it is also for the dependent team. It is also for the SMEs to consult from them. It is also for the architects who can help us into deciding that do we need to make a change at the platform level itself. Okay. And then they identify certain spike which they want to go through so that some answers which they are looking for has been identified. So first thing, forecasting to the customer with confidence. It's very important. We cannot say maybe we might be no with confidence. This is how we want to achieve this product. Okay. Second comes the point is checkpoints. With all the people from whom we can know, we can learn we are on the right path or not. That was the second aspect that we helped into. I would say staying agile, but not confining ourselves into the boundaries because it worked for everyone. Okay. And that's where Vasco.

[Osco]

Absolutely great story. Also on learning to listen to the people involved. Hey, friend. Thank you for stations in the right direction about the Global Agile Summit to make Great story. Thank you for sharing that 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, 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 the 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 a contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our development 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 to seeing you all in Tallinn, Estonia in May. I'll see you there.