Vasco (4:31)

Yeah, I can relate to that. And especially the frustration of not being able to do the things that you thought and perhaps were even told. I don't know about you, but definitely I was told that project management would help with. I remember, I distinctly remember that frustration of looking at the Gantt charts and realizing that this is just fluff, this will never work. And I was a project manager, trained project manager. So of course I found my own approaches. I. I started to appreciate the value of kickoff meetings. And that's certainly something that is very useful and we should all learn from. But I also realized how Gantt charts were totally useless. Totally useless. And how it was. How important it was to get the whole team together and have it together, own the delivery. Right. Which is something that Scrum has from the beginning. It's part of Scrum. But of course, that was my story. I don't know what story you have to share with us, Svane, but of course, today is Fail Monday here on the podcast. So we want a juicy story, a story of a difficult moment you had as a Scrum Master, as you were learning, perhaps, or even later, because we continue to learn throughout our career. So tell us that story, Svane. We'll dive into the takeaways later, but tell us that story first.

Tsvonimir Durcevich (5:47)

Yeah, I have to say I learned a lot, which means that I really did. I did some mistakes and that I learned a lot from my failures. And I think it's important, as you said, to learn from them and also to share them so that we can learn from each other in the community. Yeah, there is one particular story I want to share and it had a big impact also on the way how I am working as a screen Scrum Master and Agile coach later. And, well, I was working as an external Scrum master with the software development team, developing a new product in the organization. And my role was to support them in adopting agile practices and improving their way of working. We explicitly signed, we are using Scrum. And it was really a good start. So early on, everything seemed to be going well. We had a good communication with stakeholders and customers. We also, I think that we had established really a good relationship with the rest of the organization. And the team was really, I would not say well, I would say, yeah, they were happy, they were doing something new. They knew that they were also a kind of, you know, doing something new in the organization. So it was not a small organization, but they had a certain visibility like, oh, look, they're doing something new. They are also. They were really putting a lot of, a lot of focus on technical excellence. So it was really a good start. And then a bit deeper into development, we discovered a hidden complexity in one of the epics.

Vasco (7:54)

Okay, so this is a great turning point for the story. So everything was going well and over time you started to realize that maybe some things were not going as well as you thought. So before we dive into the complexity of the epics, what were some of the signs that you started to see that something was perhaps amiss?

Tsvonimir Durcevich (8:14)

Yeah, this is a good question, Masco. So one of the things that I noticed is first that the people were not kind of 100% dedicated to the team. They also had their kind of daily duties and it started to take more of their time. And this is where I got a bit concerned that they will not have enough time to devote to working in the team, with the team, and especially in areas where you have kind of complex development, where your development is kind of interacting with a lot of other systems in the organization. So there are some kind of dependencies. And it's not so easy to really look through this complexity and identify where should we focus as next. So this is kind of thing that gave me kind of feeling something is going on. I started to having conversations with management, but it was, I will explain later, when basically a lot of things escalated and when stakeholders got frustrated because of missing some important milestones, then things get a bit of, you know, I would not say very, very ugly, but it was really difficult because in the organization a lot of people started, well, because of the visibility, they started pointing fingers.

Vasco (10:07)

Yeah, absolutely. So you started to see that, okay, so there's something that is not going so well. You decided, okay, I need to talk to management about what is going on? What were the topics that you were bringing up first?

Tsvonimir Durcevich (10:21)

I said that I'm noticing that people have less time to devote to the. In this case, it was time for refinements, which was very important in exactly this discovery of complexity that could be hidden in some of the epics or in the backlog. And, and yeah, I got answers that it is part of the work, that there are some, you know, there are some things now also getting more important in these daily duties, which I also understand because, well, we are, you know, the reality is a bit different than if we just look at what could be in the theory or just to set up the theoretical. Theoretical setup. But yeah, so this was one of the very important statements. And the backlog was starting to grow. Backlog was starting, growing as they usually do, right? Exactly, exactly. And this is where we had kind of difficult conversations. And I noticed that people are really afraid of deleting strings things. And it was, well, it was one of my first, I would say, small failures in the projects. I couldn't, I couldn't persuade them to, to get backlog smaller. It was just growing. And, and although I explained how difficult it will be to get to still remain in a control that they have oversight of what is in the backlog and they didn't listen to me, this.

Vasco (12:17)

Is a very common story. I bet many of our listeners have faced this exact same story. So let's address Luke, our faithful Scrum master out there trying to fight the evil forces of backlog overwhelm, which are always coming whether we like it or not. Right. So, Tvane, if you had the opportunity to go back and relive that story, what would you have done differently?

Tsvonimir Durcevich (12:41)

Yeah, this is, this is a good, this is a good question. My, my biggest learning out of this story was to, to devote more time at the beginning of the project or engagement, doing something that we call kind of contracting or setting up agreements with the organization, the stakeholders, the sponsor and the stakeholders in the organization. How will I work with the team and the organization? And setting up things like the communication channels, which I discovered later that they were not open, so it was not transparent for the rest of the organization, what is really going on in the project or what is the state of the backlog and so on. And these things then backfired later. So, yeah, one of the biggest things that I learned is to really invest not only in setting up agreements, but also spending more time with the team and the organization to learn the context, to learn their context. How do they do things how do they communicate in the organization? This is what I'm trying to do now.

Vasco (14:01)

Absolutely. This is a great example of something we can learn from project management, which emphasizes a lot through of course, decades of experience. Actually by now, probably centuries, about a century or so when project management was first formalize this, this concept of the, the stakeholders, right. Like the people who can influence the project. And also the communication strategy, like all project managers will learn that communication is one of the key aspects that project managers need to look into and establish very early on, just like you said. And this is something that Scrum masters can learn very much from project management as well. It's, it's a great insight and a great lesson. Thank you for sharing that Swane.

Tsvonimir Durcevich (14:43)

You're welcome.

Unknown (14:48)

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.

Vasco (15:16)

We don't feel that energy anymore.

Unknown (15:18)

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 groups, 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, whose challenging approach 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.

Vasco (17:57)

Literally.

Unknown (17:58)

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 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. I'll see you there.

Tsvonimir Durcevich (19:27)

SA.