Scaling with Purpose, Managing Agile Team Growth While Avoiding Conway's Law Pitfalls | Mateusz Komander

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches

Episode Summary: Scaling with Purpose, Managing Agile Team Growth While Avoiding Conway's Law Pitfalls | Mateusz Komander

---

Introduction

In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages with Mateusz Komander, an experienced Scrum Master, to delve into the complexities of scaling Agile teams within an organization. The conversation centers around Mateusz's real-world experiences, the strategies he employed to manage team growth, and the challenges he faced, particularly concerning Conway's Law. This summary captures the essence of their discussion, highlighting key points, actionable insights, and valuable lessons for Agile practitioners aiming to scale their teams effectively.

---

Background: Mateusz Komander’s Journey with Agile Scaling

Mateusz begins by sharing his journey of implementing change within an organization eager to enhance an existing employee engagement application. Tasked with leading a rapidly growing team, Mateusz encountered the fundamental challenge of scaling beyond a typical Scrum team size without a predefined scaling framework in place.

“I was fortunate enough to be in an organization who are quite open into experimentation and into experimenting with any change and any approaches.”
— Mateusz Komander [02:47]

---

Scaling Approach: Introducing “Flights” for Agile Teams

To address the growing team size, Mateusz introduced a novel approach involving the creation of small, cross-functional sub-teams referred to as “flights.” Each flight comprised up to four members, including a QA specialist, a backend developer, and an Android/iOS developer. The objective was to enable these small flights to focus on specific aspects of the application, fostering agility and swift delivery.

“The intention was that each of the flights could focus on one aspect of the product, develop, finish it as soon as possible and jump to something else if needed.”
— Mateusz Komander [04:07]

This strategy allowed for focused development while maintaining flexibility. Additionally, there was an initial plan to occasionally merge flights temporarily to tackle larger product components before re-splitting, ensuring scalability and adaptability.

---

Challenges Encountered: Emergence of Silos

Despite the promising start, Mateusz observed a significant challenge as the team expanded. The flights began to develop silos, not vertically aligned with product areas but horizontally based on technical specialties. Backend developers gravitated towards backend tasks, and similar patterns emerged in other technical domains, undermining the cross-functional intent of the flights.

“The teams started naturally to somehow aim into splitting the work. Not really vertically, but rather horizontally.”
— Mateusz Komander [07:45]

This horizontal segregation led to reduced collaboration across different product facets, as teams became more focused on their specific technical layers rather than the overall product delivery. Mateusz acknowledges that this drift was partly due to differing speeds of development across technologies and a lack of long-term alignment.

---

Insights and Lessons Learned

Reflecting on the experience, Mateusz emphasizes the importance of understanding team dynamics and technological dependencies when scaling Agile teams. He highlights the need for:

1. Clear Long-Term Alignment: Ensuring that all teams are aligned with the overarching goals and direction of the project to prevent divergence into technical silos.

2. Flexibility in Scaling Approaches: Being prepared to adjust scaling strategies based on the evolving needs and behaviors of the teams.

3. Awareness of Conway’s Law: Recognizing that organizational structures can influence the design of systems, Mateusz underscores the necessity of structuring teams in a way that aligns with desired system architectures to avoid unintended silos.

“As Scrum masters, as agile coaches, as leaders in general, we need to be aware of those dynamics because otherwise we might not detect the silos early enough to be able to do something about them.”
— Vasco Duarte [10:08]

Furthermore, Mateusz suggests considering platform teams that support multiple product teams, allowing for vertical splits aligned with product functionalities rather than horizontal splits based on technical expertise.

---

Conclusion: Moving Forward with Enhanced Strategies

The episode concludes with Mateusz sharing his optimistic outlook despite the challenges faced. He acknowledges that while the initial scaling attempt had its drawbacks, it provided invaluable lessons that inform his current and future approaches to Agile team management. Mateusz’s experience serves as a testament to the importance of adaptability, continuous learning, and the nuanced application of Agile principles in scaling efforts.

“Definitely nice learning point and place to look more thoroughly in future scaling approaches.”
— Mateusz Kommander [10:41]

Vasco Duarte wraps up the discussion by reinforcing the significance of understanding and addressing team dynamics to foster effective collaboration and product delivery in scaled Agile environments.

---

Key Takeaways

• Understand Team Dynamics: Recognize and proactively address the natural tendencies of teams to form silos based on technical expertise.

• Align Scaling with Product Goals: Ensure that scaling strategies support the overall product objectives and maintain cross-functional collaboration.

• Adapt and Iterate: Be prepared to modify scaling approaches based on real-time feedback and evolving team behaviors.

• Leverage Platform Teams: Consider implementing platform teams to support multiple product teams, facilitating better alignment and reducing silos.

---

This episode offers a deep dive into the practical challenges of scaling Agile teams and provides valuable strategies and insights for Scrum Masters and Agile Coaches aiming to navigate similar landscapes. Mateusz Komander’s experiences highlight the delicate balance between team structure and collaboration, emphasizing the need for thoughtful, adaptable approaches to Agile scaling.

---

Notable Quotes

• “The intention was that each of the flights could focus on one aspect of the product, develop, finish it as soon as possible and jump to something else if needed.”
  — Mateusz Komander [04:07]

• “The teams started naturally to somehow aim into splitting the work. Not really vertically, but rather horizontally.”
  — Mateusz Komander [07:45]

• “As Scrum masters, as agile coaches, as leaders in general, we need to be aware of those dynamics because otherwise we might not detect the silos early enough to be able to do something about them.”
  — Vasco Duarte [10:08]

---

Stay Connected

For more actionable advice, tips, and inspiring stories from Scrum Masters and Agile Coaches worldwide, subscribe to the Scrum Master Toolbox Podcast. Stay tuned for upcoming episodes and insights to elevate your Agile practice.

Transcript

[Pasco 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 Gojkoacic, 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.

[Vasco]

Hello everybody. Welcome to our Wednesday, the Leading Change episode this week with Mateusz Kommander. Hey, Mateusz, welcome back.

[Mateusz Kommander]

Hello, Vasco. Happy Wednesday or meet of the Week. Happy seeing you again.

[Vasco]

It's only Wednesday, Captain. It's only Wednesday, which means we got three excellent episodes with Mateus coming up. So stay tuned. And today we're going to talk about change, of course. So, Matthias, share with us that process of change that you were involved with and you know, how it went from beginning to end. And then highlight for us the tools, the tips, the tricks, the techniques you learned back then that you still apply today.

[Mateusz Kommander]

Hey. Yes. So today my history about change I think will be actually very, very funny one. Maybe not funny one, but very, hopefully very inspiring. So for me, the change I was for us, we need to remember as Scrum masters that for us to be able to provide or to implement any change with any organization, we need to have the support and quite often not only the support from the team or the product ownership, but quite often from the manager perspective, if we do not have that, it's hard to provide that change. I was fortunate enough to be in an organization who are quite open into experimentation and into experimenting with any change and any approaches. And my story actually began when the organization decided to provide improvement into one of their already existing app. So they aimed to further develop an application that will be supporting employees throughout the say their engagement with the company since the onboarding process, throughout their work till the offboarding process, including all of the aspects how the employees are supporting the the company. So we've started with a plan with a goal and with some small POC around that. And I was actually asked to, because I was already leading one of the teams in that organization, I was asked to support that second team as well. And at the beginning we've started very small, but the team grew quite fast, quite a lot with multiple skills that were needed for our development. And I've met or I was placed in a very quickly in a position when the team was too big to be a typical scrum team. So the organization didn't implement any scaling approach per se within any of their products, within any of their developments so far most of their teams were small enough to be able to work within rather one product team, product oriented team. So this was quite new for them. Fortunately for me in my past I was working in a quite big company and within scaled program approach from the biotech industry and I was able to bring that experience into my new project, my new product. And together with the program manager who was very supportive, her main goal was Mati. I just want to have the products to be delivered. How you do it is really up to you. And so we started introducing a little bit split based on very small and agile teams that can work on separate aspects of the application. We called those small, let's say individual groups of about flights. We're aiming to not have more than four people in one of the flight. So we are aiming to have the one qa, one backend developer potentially that can also leave that part of the team and Android and iOS developer. So the aim was that because we have so many different areas of the application to be developed, we didn't want it to have one team to be focused on that or for example to be the whole team of almost 20 people joining one call and listening about different aspects of the organization of the of the application. The intention was that each of the flights could Focus on one aspect of the product, develop, finish it as soon as possible and jump to something else if needed. We were aiming to maybe join, fully join the two of the small flights to work on one of the bigger products for some period of time, but then as soon as possible split them again. So the experiments started, the experiment started quite promising. We were able to to very fast develop first improvements within this team. Unfortunately at some point we were a little bit lost into silosing with that split. So the teams started naturally to somehow aim into splitting the work. Not really vertically, but rather horizontally. So I've started.

[Vasco]

You mean according to each flight, right?

[Mateusz Kommander]

Yes. So the flights actually started to focus the people instead of focusing on delivering specific product areas, they've started to backend. Developers started to be focusing solely on backend development. Yeah, and I saw that the some.

[Vasco]

Also the flights were around skill sets. Not necessarily.

[Mateusz Kommander]

No, the flights were around part of the product. But even though the flights were organized as they were, the teams decided also the people within those teams started to align separately on horizontal level.

[Vasco]

So even within the flight you started to have these different silos.

[Mateusz Kommander]

Yes, exactly. Or cross flights. The team started to collaborate more, cross backend, for example development instead of delivering specific items. This was. And unfortunately.

[Vasco]

This is interesting, this was an interesting observation. Do you have any insights as to why even though the different sub teams were collaborating, they were mostly collaborating around their year article or sorry, their architectural layers.

[Mateusz Kommander]

I think this is something that I may need to pay more attention because based on different technology, the speed of development was different and I think maybe a little bit lack of alignment of where we are heading, like long term or how the teams could maybe shift faster if needed, brought us or put us into that position that teams stopped collaborating a little bit. Unfortunately for me, I'm speaking unfortunately here, was that in that moment, it was the moment when I was jumping into or I've got an offer from different company to join them. So I've handed over that to different Scrum master and I know that he was trying to collaborate or to work for a little bit with that approach. But at the end I believe they've split it into two teams. When one team was focused only on the front end development with Android and iOS and second team was focused only on the backend development.

[Vasco]

That sounds familiar.

[Mateusz Kommander]

Yes, I think maybe that was the best approach or most suited approach for them. Maybe my me introducing the way, how I've introduced that was a little bit too wishful thinking at the moment when I brought that into the team not really understanding the differences in the different skill sets or the different technology needed. Definitely nice learning point and place to look more thoroughly in future scaling approaches.

[Vasco]

I think for me, one of the things that is really important for us to acknowledge as leaders, grandmasters, agile coaches, team leads, development leads, department leads, whatever that leadership position may be, one thing to recognize is that there are certain dynamics within groups that are very hard to stop and very hard to eliminate. And perhaps we don't even want to eliminate them. But of course the reverse is that they have a clear impact on how we look at our work and how we organize our work. And for example, there's a strong identity around technical frameworks, like backend frameworks versus front end frameworks, around platforms iOS, Android, Linux, whatever, Kubernetes, Docker, whatever that may be. And those identities will immediately affect how people choose to group and collaborate. And as Scrum masters, as agile coaches, as leaders in general, we need to be aware of those dynamics because otherwise we might not detect the silos early enough to be able to do something about them.

[Mateusz Kommander]

Yes, exactly. And silos or I think the team, if we are looking on different team dynamics, sometimes maybe the organization needs to look a little bit differently and maybe we need to actually have a platform team that's supporting different other product teams that are delivering part of the product and because sometimes maybe it's. It might not be possible to have always the vertical split. So we need always to look a little bit, have a little bit wider view into the context of organization or context of, of technology used and how it's utilized.

[Vasco]

Absolutely. That's definitely another aspect that was a great story, a lot to reflect on, I'm sure, and think about how to organize our scaling efforts. So thank you for sharing that, Mateusz.

[Mateusz Kommander]

Thank you. Thank you Vasco, and hopefully see you tomorrow.

[Pasco 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 caring.