When Process Becomes a Prison, Breaking Free from Over-Rigid Agile Team Practices | Mateusz Komander

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode Title: When Process Becomes a Prison, Breaking Free from Over-Rigid Agile Team Practices
Host: Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner
Guest: Mateusz Komander
Release Date: February 11, 2025

---

Introduction

In this compelling episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a profound conversation with Mateusz Komander, a seasoned Scrum Master. Titled "When Process Becomes a Prison, Breaking Free from Over-Rigid Agile Team Practices", the episode delves deep into the challenges teams face when Agile methodologies become overly rigid, stifling creativity and collaboration.

Guest Background

Mateusz Komander brings a wealth of experience as a Scrum Master working with diverse teams across various industries. His insights stem from firsthand experiences where rigid Agile practices led to diminishing team morale and effectiveness. Mateusz is passionate about fostering environments where Agile principles thrive without becoming restrictive frameworks.

Key Discussions

1. The Onset of Agile Fatigue

The episode kicks off with Vasco introducing the concept of Agile fatigue, a term Mateusz has frequently encountered among Agile practitioners. Agile fatigue arises when teams feel burdened by incessant checklists and rigid processes, detracting from the core objectives of agility and adaptability.

Mateusz Komander [02:31]: "Managing for Happiness is actually a great book...no matter where we are within our career, we are quite often forgetting about the basics...support teams to create a better environment for their daily work."

2. Case Study: Over-Rigid Processes in an Airline Company

Mateusz shares an illustrative case from his tenure at an airline company, where the necessity for precision led the team to implement excessively strict processes. The project involved developing a tool to support daily operations, planning, and scheduling—critical functions in the highly regulated airline industry.

• Issue Identification:
  The team faced significant delays when testing milestones were missed, particularly in deployment schedules. Instead of addressing the root causes of these delays, the team's response was to introduce even more rigid controls.

Mateusz Komander [07: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."

• Ineffective Response:
  Missing a testing completion date by just one day was escalated into a major issue, prompting the team to add more catch-up meetings and stringent approval processes. This approach only exacerbated the problem, leading to increased Agile fatigue.

3. Shifting Focus from Processes to Collaboration

Recognizing the detrimental effects of excessive process adherence, Mateusz embarked on transforming the team's daily standups. The traditional format, centered around individual task updates, was replaced with a focus on collaboration and support.

• Old Approach:
  Daily meetings revolved around questions like "What have you done yesterday?" and "What are you doing today?", leading to a superficial display of busyness rather than meaningful progress.

• New Approach:
  Mateusz restructured the standups to emphasize collective goals and mutual assistance. Questions shifted to:

  • "Do you need any other developer to review your code today?"
  • "Should the QAs prepare any environments or test cases for the upcoming items?"

Mateusz Komander [09:07]: "So instead of adapting to that, like there was a delay one day late for the completion of the testing tasks...we are hitting dates with specific deployments."

4. Reinforcing Agile Values

The transformation underscored the first value of the Agile Manifesto: Individuals and interactions over processes and tools. By fostering open communication and collaborative problem-solving, the team moved away from rigid schedules and towards a more adaptable workflow.

Mateusz Komander [13:10]: "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."

Notable Quotes

• Mateusz Komander [02:31]: "Managing for Happiness is actually a great book...we are quite often forgetting about the basics...support teams to create a better environment for their daily work."

• Mateusz Komander [07: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."

• Mateusz Komander [09:07]: "So instead of adapting to that, like there was a delay one day late for the completion of the testing tasks...we are hitting dates with specific deployments."

• Mateusz Komander [13:10]: "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."

Insights & Lessons Learned

1. Avoid Over-Processing:
   Introducing more processes to solve problems often leads to increased rigidity and decreased team morale. Instead, focus on understanding and addressing the root causes of issues.

2. Emphasize Collaboration:
   Transform daily standups into sessions that promote collaboration and mutual support rather than mere status updates. This shift fosters a more cohesive and adaptable team dynamic.

3. Align with Agile Values:
   Always anchor team practices to the Agile Manifesto's values. Prioritizing individuals and interactions ensures that processes serve the team’s needs rather than constrain them.

4. Adaptive Decision Making:
   Encourage teams to make decisions based on current challenges and collaboration needs rather than adhering strictly to predefined processes. This adaptability enhances responsiveness and efficiency.

5. Visibility and Transparency:
   Maintain up-to-date backlogs and ensure that work progresses are visible in real-time. This transparency facilitates better coordination and reduces the need for excessive control mechanisms.

Conclusion

In this episode, Mateusz Komander provides invaluable insights into how overly rigid Agile practices can become counterproductive, leading to Agile fatigue and diminished team performance. By sharing his experience and the strategies he employed to foster a more collaborative and adaptable environment, Mateusz underscores the importance of staying true to Agile’s foundational values. Hosts and listeners alike are reminded that the essence of Agile lies not in the strict adherence to processes but in nurturing effective interactions and empowering teams to thrive.

---

If you found this episode insightful, consider rating it on Stitcher or iTunes, and share it with fellow Scrum Masters to help them navigate similar challenges in their Agile journeys.

Transcript

[Vasco Duarte]

Hi there, Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojko Adsic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The early birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now, it will only be available until early March, so grab it now. And now onto the episode. Hello everybody. Welcome to our team Tuesday. This week we have with us Mateusz Kommander. Hey, Mateusz, welcome back.

[Mateusz Kommander]

Hello Vasco. Welcome back. Nice seeing you again on this team Tuesday.

[Vasco Duarte]

Absolutely. And we are diving into the team's topic in a second. But first, Matteo, share with us what's the book that most influenced you in your career as a Scrum Master?

[Mateusz Kommander]

To be honest, that's a very interesting, very interesting question. So first, when I read this question as a preparation for the podcast, I thought the answer is quite easy and obvious because there's so many great books. But actually, because there is so many great books, it's so hard to choose the one. And for fair amount of time I was actually struggling. Which one should I recommend? Would it be either Managing for Happiness from Jurgen or maybe Daniel Goldman's Emotional Intelligence? Because both of those aspects are very important in Scrum Masters work. But my recommendation to Both seasoned scrum masters and beginner scrum masters at this moment would be really Managing for a Happiness from Jurgen. And my recommendation is actually based on the fact that no matter where we are within our career, we are quite often forgetting about the basics, the fact that we are there to support teams to create better environment for their daily work. Quite often we are focusing on tools, on metrics, on many different things, but not really. And then forgetting actually why we are there. And Managing for Happiness is actually great book. Not only with the practical tools from Management 3.0, but also examples, real life examples from Jurgen's life where we can see how he were able to apply and from where the ideas come from. This is very inspirational and also it may support a selling point for a team. Why specific practice could be. Practice could be. Could be introduced to the team.

[Vasco Duarte]

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]

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]

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

[Mateusz Kommander]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Vasco Duarte]

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.