How Limiting Work-in-Progress Saved a Struggling Agile Team | Marina Lazovic

Summary

Episode Summary: How Limiting Work-in-Progress Saved a Struggling Agile Team | Marina Lazovic

In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages with Marina Lazovic, an experienced Agile Coach and Certified Scrum Master from Belgrade, Serbia. Marina shares a compelling real-world story about how implementing Work-in-Progress (WIP) limits transformed a struggling Agile team’s dynamics and productivity.

1. Introduction and Book Inspiration

The episode begins with Vasco welcoming Marina back to discuss team dynamics. When asked about a book that profoundly influenced her approach as a Scrum Master, Marina highlights "The Five Dysfunctions of a Team" by Patrick Lencioni:

Marina Lazovic [01:28]:
"One of the biggest ones that I can maybe advise someone to read is the Five Dysfunctions of a Team. I think it's really worth it."

Marina emphasizes the book's practical examples and its utility in identifying and addressing team dysfunctions, making it a valuable resource for both new and seasoned Scrum Masters.

2. The Struggling Agile Team: Context and Challenges

Marina recounts her experience with a small, cross-functional team comprising three developers and one tester focused on front-end tasks. The team faced significant challenges:

• High Work-in-Progress (WIP):
  The team had 50 tickets in progress, with many marked as blocked or awaiting feedback in Jira. This excessive WIP hindered visibility and progress.

• Environmental Issues:
  Persistent problems with development environments and dependencies on backend teams led to frequent disruptions and broken workflows.

• Product Owner Pressures:
  The Product Owner (PO) exerted pressure to deliver continuously, leading to micromanagement as they struggled to understand the team's actual workload.

Marina Lazovic [04:14]:
"When I joined the team, I couldn't really understand what the team was working on because it was a small team... 50 tickets in progress."

This scenario exemplifies the lack of transparency and excessive multitasking, common pitfalls that can derail Agile teams.

3. The Role of Micromanagement

The high number of simultaneous tasks led the Product Owner to delve into the team's daily activities, attempting to control and monitor each developer's progress closely. This micromanagement was counterproductive:

Marina Lazovic [07:17]:
"The product owner wasn't really happy. He didn't really understand... We have to get things done. We have priorities, things are coming. We cannot say no."

The PO's desperation stemmed from the inability to track progress effectively, exacerbating team stress and diminishing productivity.

4. Implementing Work-in-Progress Limits

To address these issues, Marina advocated for limiting Work-in-Progress. Here's how she approached it:

• Understanding the Root Cause:
  She began by engaging with both the team and the Product Owner to comprehend the underlying reasons for the excessive WIP.

• Introducing WIP Limits:
  Marina proposed setting a cap on the number of tasks each developer could handle simultaneously. Initially, the Product Owner was resistant, fearing it would impede delivery.

Marina Lazovic [08:42]:
"The first thing that I did... limit work in progress. Start with something. It doesn't have to be... it's usually eye-opening for developers."

• Gaining Buy-In Through Experimentation:
  To alleviate concerns, Marina suggested experimenting with WIP limits for a few sprints, allowing the team to gather data and observe improvements.

Marina Lazovic [10:34]:
"If you get them on board, at least try to experiment... maybe three sprints, that would be ideal."

5. Overcoming Challenges and Achieving Results

Implementing WIP limits required patience and persistence, especially in shifting the Product Owner’s mindset. Marina highlighted several key outcomes:

• Enhanced Focus and Productivity:
  With fewer tasks in progress, developers could concentrate on completing work, leading to faster delivery and fewer blockages.

• Reduced Stress Levels:
  The team experienced less pressure and a more manageable workflow, improving overall morale.

• Product Owner Alignment:
  As tangible results emerged over subsequent sprints, the Product Owner began to appreciate the benefits of WIP limits, moving away from micromanagement.

Marina Lazovic [12:19]:
"We need to be patient with them as well, because the product owners are also under pressure and we need to make them feel that we are there to help them."

6. Insights and Recommendations

Marina's story underscores several critical insights for Agile practitioners:

• Limit Work-in-Progress:
  Controlling the number of concurrent tasks is pivotal in maintaining clarity and enhancing delivery efficiency.

• Facilitate Open Communication:
  Transparent discussions about team challenges and dysfunctions can foster collaborative problem-solving.

• Provide Evidence-Based Results:
  Allowing time to collect and analyze data after implementing changes is essential to demonstrate their effectiveness.

• Cultivate a Supportive Culture:
  Encouraging a culture where being busy equates to productivity can undermine team health and output.

7. Key Quotes

• On the Impact of Work-in-Progress:

  Marina Lazovic [10:33]:
  "Developers need to get things done and focus on unblocking things."

• On Cultural Challenges:

  Marina Lazovic [01:28]:
  "There was maybe even the cultural, organizational culture that people have to be busy."

• On Scrum Master's Role:

  Marina Lazovic [12:19]:
  "We need to be patient with them as well, because the product owners are also under pressure and we need to make them feel that we are there to help them."

8. Conclusion

This episode provides a valuable case study on the transformative power of limiting Work-in-Progress within Agile teams. Through Marina Lazovic’s experiences, listeners gain practical strategies to identify and mitigate workflow bottlenecks, enhance team focus, and foster a collaborative environment. Implementing WIP limits not only streamlines processes but also alleviates undue stress, ultimately leading to more effective and satisfied teams.

---

Note: This summary focuses solely on the core content discussed between Vasco Duarte and Marina Lazovic. Promotional segments regarding the Global Agile Summit have been excluded to maintain the summary's relevance and focus.

Transcript

[Host]

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 and this week. Joining us from Belgrade in Serbia is Marina Lazowicz. Hey, Marina, welcome back.

[Marina Lazowicz]

Hi. Hi. Nice to be back.

[Host]

So Tuesday is Team Tuesday. Of course. We'll talk about teams in a second though, because first we want to know, Marina, what was the book that most inspired you as a Scrum Master?

[Marina Lazowicz]

It's very difficult to name one, like going through different steps of my learning curve. There were a lot of different things that were very important at the time, but I'll try to name one or maybe a couple that I think are important, were important to me and could be useful, I think, to a lot of especially new Scrum Masters. One of the biggest ones that I can maybe advise someone to read is the five Dysfunctions of a Team. I know that's probably something that's not new that a lot of Scrum Masters recommend, but I think it's really worth it. There is so much to take away out of that book. Learning all the dysfunctions with so many good examples that you can really actually see in practice. For me, while I was reading the book first time, I found there were so many awe moments like, oh, this is why this happens. When you see lack of accountability and then behaviors, oh, so that's what it is. And you can point out to all of these dysfunctions. And really then I think it's very useful for Scrum Master to use all of this information, even share them with the team when they realized, okay, the team is having maybe this function, point it out and use it as a starting conversation with the team to discuss very transparently. Okay, I noticed that we have this problem or this challenge in the team. So let's try to see how we can overcome it. So I think that is one of very useful books that I would recommend.

[Host]

Yeah, absolutely. It's classic but it is an amazing book and filled with very actionable ideas too. Right. It's of course the patterns you can easily recognize, but a lot of ideas of what. So definitely check out the Five Dysfunctions of a Team by Patrick Lencioni. But of course, Marina, we're here to talk about the teams and how sometimes they create their own problems, just like in that tale or fable as Lencioni calls it, of the Five Dysfunctions of a Team. So tell us that story, give us a little bit of context so that we understand, you know, what kind of project it is, what kind of team it is and then walk us through how these small little behaviors developed, grew and eventually created problems for the team.

[Marina Lazowicz]

Well, I have this one team working. It's mostly like a, it's a small team, three developers working on mostly front end items. It's a cross functional team but like most of the work was front end fixes, creating some small adjustments. But there had a lot of challenges with environments not working and some things that are heavily influenced by the backend guys that need their support and things keep breaking up and so on. And the product owner was always pushing them to deliver like every product owner does. But the dysfunction or what happened to that team was they started working on so many things at the same time. And this is what happened. When I joined the team, I couldn't really understand what the team was working on because it was a small team, like three developers, one tester and they had 50 tickets in progress. You know, when you look at Jira, there's so many things that are read like blocked, flagged, waiting for feedback. We don't know what to do with it. We started this, we are, we, we need to stop and we need to wait for something there. So they were working at so for so on so many things at the same time and never getting things to done. Things were sticking for forever like in progress. And that led to on one hand a bit of micromanagement from the product owner because he was so.

[Host]

The product owner was kind of desperate, like what is going on? I have no transparency, Nothing is progressing. And they decided to start to go into the details. Is that what you mean?

[Marina Lazowicz]

Yes. He was trying to get to understand what the team is actually working on, what the developers are working on. Because there were like three or four tickets per developer. That's generally for my, how I like to do things a lot at the same time, depending on the team. But in general for that team looking at their board, it was too much like everyone has a couple of things. So it was really then leading to micromanagement that shouldn't be necessarily happening or should ever be happening, but that wouldn't maybe be happening by the product owner if, you know, they weren't having so many things done at the same time. Then the product owner was trying to manage each developer by getting into each detail. Okay, what's going on here? What's going on here?

[Host]

So they tried to unblock them, right?

[Marina Lazowicz]

Yeah, yeah, in a way. Trying to unblock them on one hand. On the other hand, I think he was also part of this big dysfunction, letting things be in that way. So that was one of the very big problems that I faced. One dysfunction that's really not so uncommon with the teams having too many things. So no limits or working process.

[Host]

Yeah. One of the things that comes to mind is like when we face a situation like this and teams that have a lot of work ongoing is a very common problem. Often because they are pushed to, sometimes because they just get interrupted, other times because there's stuff that just lingers from the previous Sprint and they don't really count it as the part of the new sprint and so on. There's all kinds of reasons for that. But you know Luke, our friendly Scrum master out there, he's just now working with one team that is going through the same problem. They have a lot of work in process. Every developer, two or three items just like that one. The product owner is trying to starting to micromanage the developers just like what you described. What could Luke do to help the team and the product owner?

[Marina Lazowicz]

Well, the first thing that I did, of course, what I think first the Scrum Masters should do is try to understand what's going on. Try to really understand why that is happening. Talk to the team, talk to the product owner, see where is the problem. But how to help a really fast resolve I.e. limit work in progress. Just limit work in progress. Start with something it doesn't have to be, you know, I know that. What? In my experience, mentioning this for the first time to product owners, it was very difficult for them to accept. Not so much for developers because they found it really like eye opening. Oh, there is a way that we don't have to do so many things at the same time. That's possible. Sometimes I found out that developers were not really aware that they don't have to do so many things. At the same time, in some companies, or basically in this company, there was maybe even the cultural, organizational culture that people have to be busy. It seems like if they're not, or at every moment, every second having something that they're doing that they are not being productive, that they're not doing enough. So when I brought up this work in progress limits option that, yeah, we can say we can limit the work in progress, we don't have to do so many things at the same time. It was usually for developers, something that it's like eye opening and they are in awe, like, oh, yeah, but how.

[Host]

About the product owners?

[Marina Lazowicz]

But the product owner, in my situation, the product owner wasn't really happy. He didn't really understand, like, oh, how, you know, we have to get things done. We have priorities, things are coming. We cannot say no. You know, that is a problem that a product owner's facing. So it took a while, and it usually taking for me a while to get product owners on board with WIP limits. But if you get them on board, at least try to experiment, say, okay, let's do this just for a couple of sprints. Maybe one sprint is not enough. It's often not enough to really show how things can change because you have to have longer, a bit longer period of collecting the data to be able to look at that data and see how things are changing. But maybe three sprints, that would be ideal if your product owner agrees to that, to see how that would change. And when I got my product owners to agree to not push things or to just be cool with, okay, we're limiting work in progress, we can't take new things. Developers need to get things done and focus on unblocking things. And then things start to flow faster and things start to get done. And you can see in a couple of sprints that the team is delivering more and they are not so stressed, they're not so pressured, then the product owners get on board, but they need evidence to show them the data and see how it works in practice.

[Host]

Absolutely. And we need to be patient with them as well, because the product owners are also under pressure and we need to make them feel that we are there to help them. And if we just go there and say, hey, you need to limit wip, they obviously might not think we're there to help, even though limiting whip is probably the best way for them to get their work done.

[Marina Lazowicz]

Exactly, exactly.

[Host]

Ironically. But that was a great story. Thank you for sharing that. Marina. 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, then 19th and 20th the conference day and Talinestone 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 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 Svendit'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 and 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. I'll see you there.