Vasco Duarte (4:21)

Yeah, exactly. And it helps with those stories, right? This is what we try to do here on the podcast. Tell real life stories that can help us first feel ourselves inspired and then later on inspire others as well. And when we inspire others, of course we mostly work with teams and sometimes teams get in their own way and those teams that self destruct provide great insights and learning or lessons learned for us to then in the future use and avoid those same anti patterns from happening again. So tell us that story Matthias, the story of a team. Give us a little bit about the context and then walk us through the little steps or approaches or behaviors that over time grew and became a problem for the team.

Mateusz Kommander (5:11)

Well, I will navigate a little bit to our yesterday's discussion about individual individuals and interactions over actually processes and tools. So what is what I was able to observe? And I was, I'm observing that, that recently in one of the team I'm working with and I'm trying to support them to actually maybe break a little bit that process that rigid processes they are trying to organize themselves around. But I will today refer to my past experience into one of the teams which actually the team was very rigid on the processes they've implemented. We were working within an airline company and we needed to work on a tool that should support the daily operations, the planning and the scheduling of, of an airline. And it was due to the fact how rigid the airline industry is. We needed to be able to be sure that we are deploying on the right moment that we are deploying the items that are without big, let's say without big issues or without any issues. And the team to protect themselves, they've actually designed very rigid process in terms of who, when, what should approve how the deployment should look like, how long the testing should take, how long the development should take, et cetera, et cetera, et cetera. And unfortunately, the processes, the more the processes, if they failed, instead of thinking of, okay, can we be a little bit more sort of looking into these processes that maybe we should actually not be that strict in terms of the dates, for example, in terms of the scope that we are deploying, the team tried to answer with even more rigid rules, even more control over how they are working.

Vasco Duarte (7:26)

So adding more process to a process that wasn't working.

Mateusz Kommander (7:30)

Exactly. So spiraling into that process, thinking process, that the more control we will be able to give ourselves over our own work, the better it was.

Vasco Duarte (7:43)

Can you give an example like of. Of maybe a problem that they had and how they reacted to that by adding yet more control mechanisms.

Mateusz Kommander (7:54)

So the problem, the one of the examples were that when they missed a date of finished testing, day of assumed date of finished testing, and therefore we should start deploying to production, we missed that, I believe of over one day at that time. And it was such a huge problem for a team that the team first of all decided to create additional catch ups in terms of how the testing is going and additional points where we will be able to exactly track where, where the testing are exactly be able to confirm if we'll be able to finish by specific date instead of saying, okay, we missed that day, but we can easily deploy the next day, so or maybe next time, instead of looking for smaller scope to deploy, for testers to be tested throughout few days, maybe we should focus on discussing with testers how busy they are, how much time they can spend to testing. So we were lacking the discussion between different people with different skills. Instead of that, we are hitting dates with specific deployments.

Vasco Duarte (9:07)

So instead of adapting to that, like there was a delay one day late for the completion of the testing tasks. So instead of taking that as information, what they decided was to have more meetings, more follow ups, more information collected during the testing.

Mateusz Kommander (9:27)

Yes. And actually the reason behind that was one of the issues that I see that fortunately with the new Scrum Guide, we moved out from the Scrum Guide with the three questions, which was quite often misunderstood at the beginning because it was quite often presented. What have you done yesterday? What are you doing today? And what will you do tomorrow? But everyone forgot about the part after the comma to get closer to a sprint goal. I think that was around that in the old Scrum Guide. We moved that out and I saw that the daily instead of being Actually, the discussion what we can do today in general as a team, how we should align and how much time we have tomorrow to support each other. We were focusing on the items. I was doing that, I was doing this. So the team was trying to look busy on a daily instead of aligning what they should do. So this was one of the items that I've aimed to break sooner at the beginning and what we've started to fix that very simple. On a daily. I've asked to no longer give any updates about about the backlog. Okay. So we stopped discussing and presenting the backlog items during the daily and we focused rather on actions that may impact someone who is farther in the pipeline. So I was rather trying to navigate the questions, do you need any other developer to refine or sorry to review your code today? Or if the code, if I knew that the code was reviewed, I was navigating through the questions then do you plan to deploy or do you aim to deploy that? So how, with which QAs you should start aligning about? Should you should the QAs prepare one of the work on preparing one of the environments or preparing the test cases for the item. So rather trying to navigate with the actions that you need to happen for you today or tomorrow with the team instead of you telling me on which tasks you are working.

Vasco Duarte (11:39)

And that really switches the emphasis to the collaboration and to the adaptive decision making rather than adding more overhead, more bureaucracy to try to control something that is in the end impossible to control in that level of detail.

Mateusz Kommander (11:55)

Yes, of course, of course. To have this conversation, of course we needed to change a little bit the sort of process or understand that part of the process now is that we are not updating, for example, our backlogs on a daily basis, but we are updating it as things happen. So for example, if you are picking up an item for work, do the update already, not before the daily, so make your work visible as soon as possible. I think those are quite often basics within a teams that we are forgetting. And I do believe that sometimes when we are joining the daily and we are mentioning or speaking about what we are doing today, we're actually forgetting that maybe it's more important to say what do you expect from others for you to help you today instead of telling others what you are doing.

Vasco Duarte (12:49)

Yeah, that's a great question. What do you expect from others? Because that elicits conversations around collaboration and maybe I'm expecting something others are not willing to do because they are either busy or they have other priorities and that needs to come out as early as possible so that we can discuss it and adapt to it.

Mateusz Kommander (13:10)

Exactly. Exactly. So. And again, here we are still looking into. We are speaking already only about the first value from Agile Manifesto, the interactions and individuals. And this is the most important aspect or one of the most important aspects, to have that personal connection and to be connected with others.

Vasco Duarte (13:32)

Yeah, I really like that perspective because for me, the daily meeting has always been a catalyst for collaboration. And I have found, and I've said it several times here on the podcast, that the traditional default questions are actually not appropriate for it. And I think that the example and the story you just shared with us is a great example of how we can transform the daily to emphasize more the aspect of collaboration. So thank you for sharing that, Matthias.

Mateusz Kommander (14:01)

Thank you for having the opportunity to do it, Vasco. And thank you for being here today.

Vasco Duarte (14:10)

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes, share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is.