
Marina Lazovic: How to Introduce Data-driven Decision Making to Skeptical Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: . Marina...
Loading summary
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 Wednesday the Leading Change.
Wasko
Episode this week with Marina Lazowicz. Hey Marina, welcome back.
Marina Lazowicz
Hey Wasko, nice to be back.
Wasko
So Wednesday's change day here on the podcast, of course, so we want you to dive into one of those change stories that you have to share. So pick a change process and then walk us through the whole process from beginning to end. And as you go through that highlight for us, the tools, the tips, the tricks and the techniques you learned back then that you still carry with you in your toolbox today.
Marina Lazowicz
Oh, okay. A couple of examples that I could think of maybe let's if, if we have enough time, try to cover them. But one first maybe that comes to my mind like a good story of change was the first time I started, I started using data, a lot of data to make some help, make some informed decisions, you know, and they by data I mean, don't mean just story points and tracking velocity because that's like the basic that we all start with. I know every Scrum master and every company. The first thing that we start with, yes, estimations and story points and then we use the velocity and so on. But at some point I discovered that there's more, there's more data that we can use. There's more really tangible data that's more, maybe even helpful. So that was the time when I started with Mateen. It wasn't just me, of course. I had support from my Agile coach from other Scrum masters. How we wanted to do is start using different data, but slowly introduced it to the teams, to the product owners, starting collecting different data that really there are tools out there, but if you don't that you know that are required some expensive subscription subscriptions and so on. But if you don't have access to those, if everyone can start to. I'm guessing that most scrum teams use Jira at least, I think at least 80% of them. Even if it's not Jira, any like ticketing system or any tool for delivery has some kind of way of looking at data, I'm sure. But JIRA is enough even. And now lately JIRA has. For those who have this enterprise, jira, I think again a lot of companies do. JIRA has been developing a lot of ways to track data that weren't previously available.
Wasko
Tell us a little bit more about that data. So you, you started looking into I guess JIRA and you started collecting this data. What did you do with it? Did you like, did you have like a proposal for solutions? Did you try to answer specific questions you were getting? How were you introducing data to the teams and the product owners?
Marina Lazowicz
We started introducing data in our everyday work, very simple, simply first by looking at how much time. The first metric that's very easy to track and very easy to see anywhere and easy for the teams to understand and use is how much time is something or some piece of work, usually an issue ticket spent in a specific state.
Wasko
So like in progress or blocked or waiting to be tested, whatever or in.
Marina Lazowicz
Testing in any state, depending on what was most interesting. We were looking at how much you spent in a specific state. Now this is what I used with the teams to start to look at that data very simply. For example, again going back to Jira, it offers some cool features like insights where you can see what is stuck, how much time is spent. So very simple. You don't need any external tools. But using that days spent in a specific state. So we were starting the conversations around that specific number. Like why do we think an issue or ticket is staying along in if it's in progress? Is the developer working on it for days and days ahead, you know, and why is there. Is there a problem? Is it difficult for him? Does he need help or support? If. Or is the ticket waiting for someone to give some feedback? Does is maybe something missing, like some assets or some information that the product owner needs to provide or whatever. So we started conversations around that number specific number that was one small piece of data, like the number of days something is stuck in one place and that is probably some blocked item. This is one very simple thing looking at the data that I started to use with development teams. And from there we really could open up a lot of problems and A lot of issues that the team is facing. You know, it's like a Pandora box that you open when you start asking these questions. Why is this stuck? You know, because there can be a million reasons. And then you start dissecting reason by reason and start solving all of these, all of these questions. So that was one way of using the data that I started with the teams. Another is with product owners to do some planning. Use data for planning and not data only as okay, our velocity, average velocity this and then we can plan with the least number of story points. But I try to use some historical data, some data that we already have from our teams that's not just story points, but other like how long is our cycle time, how is our throughput, how many things we can deliver in how long period of time, and so on. So these are just basic metrics that really helped our teams be more fast, be more productive, help the product owners to, to plan a bit, a longer period of time. My product owner had a problem that he came to me with, how can I plan a quarter? How do I know how much we can do in one longer period of time? How do I estimate that with themes? And then I suggested that we look at our historical data to see, you know, previously how much the team delivered and use that information and use all of that data to see, to forecast how much the team can deliver in, in the future.
Wasko
So when you started introducing this, of course you found things that needed to be tackled. You were able to inform the planning process.
Host
But what else happened?
Wasko
Like how was this received? What were the questions you got about the data you were showing?
Marina Lazowicz
A lot of questions come from when you look at data, especially those like the image, how much something is stuck, like I mentioned. So we opened a lot of problems that the team was facing. Not just the team itself, but the organizational problems. Not getting some feedback that is coming from other teams, not getting some information, you know, that we're dependent dependencies on different teams that are maybe not were not really visible previously, you know, so opens a lot, a lot of questions and maybe some even dysfunctions. Again, going back to the story previously, when you see something is stuck in a long time, then we got into the situation of okay, why? Because the developer is working on two other tickets, you know, but of course.
Wasko
You start uncovering this so the problems are now understood. Or at least we know about some of the problems. Not necessarily understood, but we know about some of the problems. But doesn't that like. Cause I don't know about you, but I'VE heard this. Wait a minute. We had none of these problems before we introduced the whole idea of cycle time or the whole idea of time in a state. It's the idea that is bringing the problems. Didn't you get that kind of feedback?
Marina Lazowicz
I have to be honest. No, no, maybe, maybe. Because I really tried to keep it very simple on the developers, not to overwhelm them with all of these names and phrases and, and numbers. You know, try to keep it very, very simple. Introducing one by one. So like with developers with the teams, I try to talk only about this itemage or not even mention the name of that metric. Like let's talk about this ticket that is stuck for 12 days. You know, let's talk about this and this and this problem, not mention it, that it's a metric that I track or whatever some of these things are really trying to do in the background and have that informed, get myself informed so I can talk to them knowing all of these things, not necessarily involve them into discussing every metric together.
Wasko
You know, so kind of you chose one topic at a time and that's why it was easy for them to digest it. Because it can be overwhelming to start to look at, e.g. item age on a particular state and suddenly there are 10 problems. Like even that can be overwhelming.
Marina Lazowicz
Yeah, I agree. I agree Ken. I try to keep it simple and focus on one thing at a time. Not to, you know, break the folk, break the focus on too many problem solving at the same try to solve the one problem at a time.
Wasko
One thing that I, I don't know if that's what you did, but implicitly I understood was also this idea that you opened the space for them to talk about what was affecting them. You were not telling them, hey, this is affecting you. But you were rather asking, okay, so this item has been here for 12 days. Does anybody know why?
Marina Lazowicz
Yeah, exactly, exactly. With those questions coming from my side really opened, opened the space for them to find out what's going on and how they would solve it. Because for example, one thing I just thought of it that came out of this kind of discussion was, and it came directly from the development team was oh, maybe our tickets are too big, you know, do we have too big? That's brilliant, you know, that we are working on. So, and the merge requests and, or you know, they're becoming too large. And the people who are doing reviews.
Wasko
They used to call them CVS bombs.
Host
Back then when I programmed and out.
Marina Lazowicz
Of that they started discussion, okay, let's see how we can it didn't even come from me. You know, how can we split the tickets? How can we make them smaller? How can we find a good, a better size for our, for our tickets? So this is something that came up and it was really helpful. We had a separate meeting around that, made some actions there, made some team decisions, how we are going to do it, how we're studying, when's the right time and whatever. So this is something that came out of just this simple number, like, okay, let's look at our tickets and why they're.
Wasko
Yeah, because it opened the discussion and people could come up with their own findings. And I think that's exactly, that's a very important process to highlight.
Host
Thank you for sharing that story, Marina. Great story.
Marina Lazowicz
Thank you.
Host
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 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 startup 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, 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 now@globalagilesummit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May.
Wasko
I'll see you there.
Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: How to Introduce Data-driven Decision Making to Skeptical Agile Teams
Guest: Marina Lazovic
Release Date: March 26, 2025
Host: Wasko
In this insightful episode of the Scrum Master Toolbox Podcast, host Wasko engages in a deep conversation with Marina Lazovic, an experienced Agile Coach and Scrum Master. Marina shares her journey of integrating data-driven decision-making practices into Agile teams that were initially skeptical of such approaches. Her story offers practical strategies and valuable lessons for Scrum Masters and Agile Coaches aiming to enhance team performance through informed data utilization.
Marina begins by recounting her initial foray into data-driven decision making:
Marina Lazovic [01:38]: "The first time I started using data a lot to make informed decisions... I discovered that there's more, there's more data that we can use. More tangible data that's more helpful."
She emphasizes that while many teams begin with basic metrics like story points and velocity, there's a wealth of additional data available that can provide deeper insights into team performance and project health.
Marina outlines the foundational metrics she introduced to her teams:
Marina Lazovic [04:24]: "We started introducing data in our everyday work very simply... by looking at how much time a piece of work spent in a specific state."
She leveraged JIRA’s built-in features, such as Insights, to track metrics like the number of days an issue remains in a particular state (e.g., In Progress, Blocked, Testing). This approach provided a straightforward starting point for teams to visualize workflow bottlenecks without overwhelming them with complex data sets.
Acknowledging the potential resistance from teams, Marina shares her approach to mitigate skepticism:
Marina Lazovic [09:04]: "I tried to keep it very simple for the developers, not to overwhelm them with all these names and phrases and numbers... just talk about the ticket that is stuck."
By focusing on specific, relatable data points rather than abstract metrics, Marina facilitated meaningful conversations without causing information overload. This tactic helped teams see the immediate relevance of data to their daily tasks, fostering buy-in and reducing resistance.
The introduction of data-driven metrics revealed underlying issues that were previously unnoticed:
Marina Lazovic [10:05]: "It opened a lot of problems that the team was facing... dependencies on different teams that were not really visible previously."
For instance, tracking the time a ticket remained in a particular state led to discussions about oversized tickets and inefficient merge requests. These revelations prompted actionable changes, such as splitting large tickets into smaller, more manageable tasks, thereby improving overall workflow and productivity.
Marina highlights several strategies that facilitated the successful integration of data-driven practices:
Wasko [11:53]: "You were not telling them, hey, this is affecting you. But you were rather asking... Does anybody know why?"
This approach empowered teams to take ownership of their challenges and collaboratively develop solutions, enhancing their engagement and commitment to continuous improvement.
Marina reflects on the broader impacts of adopting data-driven decision making:
Marina Lazovic [12:32]: "With those questions coming from my side really opened the space for them to find out what's going on and how they would solve it."
Key takeaways from her experience include:
Marina Lazovic’s story underscores the transformative power of data-driven decision making within Agile teams. By introducing simple, relevant metrics and fostering an environment of open communication and ownership, she successfully navigated initial skepticism and uncovered valuable insights that propelled her teams forward. Her approach serves as a practical guide for Scrum Masters and Agile Coaches seeking to implement data-driven practices to enhance team performance and project outcomes.
This episode provides valuable insights into the practical steps and thoughtful strategies required to introduce data-driven decision making in Agile environments, especially when faced with initial resistance. Marina Lazovic’s experience is a testament to the positive impact that well-implemented data practices can have on team dynamics and project success.