Overcoming Code Ownership Silos in Agile Teams | Ville Reijonen

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches

Episode: Overcoming Code Ownership Silos in Agile Teams | Ville Reijonen

Release Date: January 21, 2025
Host: Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner
Guest: Ville Reijonen

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Vasco Duarte welcomes back Ville Reijonen to discuss a critical challenge faced by many Agile teams: code ownership silos. Ville shares his experiences and insights on how to dismantle these silos to foster a more collaborative and efficient development environment.

Book Recommendations: Broadening Management Perspectives

Vasco begins the conversation by asking Ville about the books that have inspired him in his role as a Scrum Master. Ville highlights the importance of understanding the broader management and business perspectives in Agile practices.

Ville Reijonen recommends the "Essential Collection" by Peter Drucker, emphasizing its value in grasping the big picture of business management. He states:

"The purpose of business is to create a customer and keep it."
[05:08]

He elaborates that Drucker's philosophies help Scrum Masters and Product Owners appreciate the relationship between customers and markets, which is essential for effective Agile practice.

Vasco Duarte echoes the sentiment, encouraging listeners to explore Drucker's extensive bibliography for deeper management insights.

Understanding Code Ownership Silos

The core of the episode delves into code ownership silos—a situation where individual team members or sub-teams exclusively own specific parts of the codebase, leading to bottlenecks and reduced collaboration.

Vasco Duarte frames the discussion by asking Ville to share a story about how these silos develop within a team:

"Tell us that story first. We'll dive into the takeaways later."
[05:55]

Ville Reijonen explains that code ownership silos often stem from existing system conditions where ownership is fragmented either at the individual or team level. This fragmentation leads to a lack of cross-functional collaboration, as team members become hesitant to interact with or modify parts of the code they do not own.

Strategies to Overcome Code Ownership Silos

Ville outlines several strategies to break down these silos and build a more cohesive and trusting team environment:

1. Implement Comprehensive Testing

   • Ville Reijonen emphasizes the importance of integrating tests into the development process:

     "Add whatever is created with tests. Start layering tests on top of the system so you have more certainty that it doesn't break."
     [08:21]

   • Vasco Duarte clarifies that establishing a robust testing framework, whether manual initially or automated later, helps build trust among team members by ensuring that changes do not inadvertently disrupt the system.

2. Peer Code Reviews

   • Ville suggests that the original owners of a code segment should review any changes made by others:

     "The person who has been owning the part of the system earlier is the reviewer for every change that comes in."
     [09:30]

   • This approach not only maintains code quality but also facilitates knowledge sharing and mutual trust within the team.

3. Adopt Shared Code Ownership

   • Moving towards a shared code ownership model allows any team member to modify any part of the codebase, provided changes are reviewed and approved. Ville likens this to the internal open-source model:

     "Anyone can change any part of the code, but before it gets accepted, somebody will go through the change and validate that."
     [10:22]

   • Vasco Duarte adds that this model reduces bottlenecks and increases the team’s agility by eliminating single points of failure:

     "Segregated code ownership also creates slowness... Shared code ownership model... yields faster throughput of user stories and features."
     [12:21]

4. Educate Management on Long-Term Benefits

   • Ville points out the need to align management’s expectations with these practices:

     "Create understanding in the management that this is a necessary step to do."
     [10:45]

   • While implementing these strategies may initially slow down the process, they ultimately lead to a more resilient and efficient system.

5. Encourage Pair and Ensemble Programming

   • Ville advocates for pair programming and its variant, ensemble programming (also known as mob programming), as effective methods for teamwork and knowledge sharing:

     "Pair programming is a powerful method to actually learn and to feel safe... Ensemble programming creates understanding on the system for multiple people and feel safe about the changes."
     [15:18]
     [15:52]

   • These practices help team members build trust and collaboratively solve problems, further breaking down silos.

References to Agile Literature

Throughout the discussion, both Vasco and Ville reference key Agile literature that supports their strategies:

• "Team Topologies": A book that explores different team structures and their impact on software delivery performance.
• "Agile Software Development by Patterns": A resource that reviews various team setups and patterns related to the Scrum Master role, providing actionable frameworks for Agile practitioners.

Vasco Duarte underscores the importance of these resources for Scrum Masters to implement deliberate and effective team designs:

"These patterns are more or less self-descriptive and contained. You can go and implement that rather than try to develop small changes over time."
[13:07]

Conclusion

The episode concludes with Ville and Vasco reinforcing the importance of shared ownership and collaborative practices in Agile teams. By implementing comprehensive testing, peer reviews, shared ownership, and collaborative programming practices, teams can overcome code ownership silos, reduce bottlenecks, and enhance overall productivity.

Vasco Duarte wraps up by encouraging listeners to explore the recommended resources and apply these strategies to transform their Agile practices:

"Remember that sharing is caring."
[16:20]

---

Key Takeaways

• Shared Code Ownership: Transitioning from segregated ownership to a shared model can significantly reduce bottlenecks and increase team agility.
• Comprehensive Testing: Implementing robust testing strategies builds trust and ensures system stability.
• Peer Reviews: Engaging original code owners in the review process fosters collaboration and knowledge sharing.
• Collaborative Programming: Practices like pair and ensemble programming enhance team cohesion and collective code ownership.
• Educational Alignment: Ensuring that management understands the long-term benefits of these practices is crucial for successful implementation.

Notable Quotes

• Ville Reijonen:

  "The purpose of business is to create a customer and keep it."
  [05:08]

  "Add whatever is created with tests. Start layering tests on top of the system so you have more certainty that it doesn't break."
  [08:21]

  "Anyone can change any part of the code, but before it gets accepted, somebody will go through the change and validate that."
  [10:22]

• Vasco Duarte:

  "These patterns are more or less self-descriptive and contained. You can go and implement that rather than try to develop small changes over time."
  [13:07]

---

For more insights and actionable advice, subscribe to the Scrum Master Toolbox Podcast and stay updated with weekly episodes featuring Agile experts from around the globe.

Transcript

[Vasco Duarte]

Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th, 20th of 2025 in Tallinn, Estonia. We're gonna have a transformative experience. We're putting together an event that is all about real life agile. It's not theory or buzzwords. It's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now we're bringing together the best stories in Agile. From product leaders to engineering wizards to business, these will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now we're in our super early bird phase and that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three, we'll dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now. Right now that that's out of the way, onto the episode. Hello everybody. Welcome to our team Tuesday. This week we have with us Ville Rayonen. Hey Ville. Welcome back.

[Ville Rayonen]

Thank you. Thank you, Vasco.

[Vasco Duarte]

So, Ville. And by the way, it feels good to know how to pronounce somebody's name. I mean, it doesn't often happen here on the podc. That's great. To have Fin here because that name I can pronounce. All right, Wille, we'll talk about teams in a second because it is Team Tuesday here on the podcast. But first let's dive into the book that most inspired you in your role as a Scrum Master.

[Ville Rayonen]

It's not necessarily the book influence, but I would recommend in this phase I would say Peter F. Trucker Essential Collection would be something I would read and then why probably tells it why it is so so a while back as a student at university I had this course called Management of Innovation and it was a business case course. There was a lot of different kind of innovation dilemmas and business situations and London's course and they had this other book from Petrifracker called Innovation and Entrepreneurship on the post and you could call Tracker as some kind of management philosophist. So so probably his most cited definition is this the purpose of business is to create a customer and keep it. Well, that's not verbatim but quite close to that one. And, and that sentence has already quite a lot in that one. So create a customer and keep the customer. So that's you have to have your antennas on the market and see what's happening and listen to customers to keep it. You can, you can dwell on this sentence quite a long time already. So Deming was working a lot of in Japan also and so I wouldn't necessarily say this innovation entrepreneurship book would be something you would read, but the collection would be better because he has published quite a few books and I think there's a lot of people, product owners from Master which are not so aware of this side of the business and management. I think it would be beneficial to think about the big picture and especially this relationship with the customers and markets.

[Vasco Duarte]

Yeah. And it's essential to think about the big picture, as you said. So great recommendations. Essential Collection by Peter Drucker and I'm sure that if you're interested in any management topic, you will find something from Peter Drucker on that topic. So check out his bibliography as well. Right Ville so now we dive into the team story. Now we want to work or learn about a team that kind of started developing a set of patterns. I bet you like that. Or behaviors that eventually over time took a life of their own and caused big problems for the team. So tell us that story first. We'll dive into the takeaways later. But how did that, you know that set of behaviors or patterns develop over time? Tell us that story.

[Ville Rayonen]

So one kind of destructive pattern necessary doesn't its existing condition often already in the system, which is kind of ownership of a part of the system. As this pattern, it repeats on multiple layers. It can be a person who owns a part of a system, or it can be a team which owns a part of the system. And then you talk about component teams, which is kind of common topic usually. But this individual level, the same pattern also occurs. And it can be so that each person in a team owns a part of a system. And often you are not allowed to touch some other part of the system. And it's not going to be ever a team. It's a group of people working somewhat together. You might put a label on top of it and it's a team, and you might do planning together, but nobody else is interested what other people are doing because they have their own part of the system. So it's total.

[Vasco Duarte]

Was that the case for this particular team that you were working with? Was it that each individual owned a part of the code and nobody else was allowed to touch that.

[Ville Rayonen]

That kind of system? I have seen and that there's often a lot of fear accompanied with that setup. People are afraid first to kind of show what they have inside their own box. It's all black box kind of, and they afraid if somebody else touches that thing, what will happen with it? So it requires a lot of work to kind of the people to create the trust to open up and show the stuff and start to kind of be willing to accept other people's code, other people's ideas.

[Vasco Duarte]

Right. So the pattern is clear. Let's dive into those strategies that we could use to start building that trust. Because you said it requires a lot of work to build the trust between the team members. And that makes a lot of sense. But how do we start doing that? Like, in your experience, what has worked and what have you tried in order to try to build trust within a team that is, as you said, owning completely different parts of the code and maybe even afraid that others will come and destroy their part of the code.

[Ville Rayonen]

When we talk about software, typical thing with this kind of issue is also that there's no tests or lack of testing or minimal testing. So the system might actually break because you don't see it. So the one person is really expert or for that part of the system. So the first layer would be kind of always add whatever is created, is created with tests. So you start layering tests on top of the system so you have more certainty that it doesn't break and it's less likely to break. So that's kind of one way of creating the system which you can believe in in some higher level.

[Vasco Duarte]

Okay, so what you're saying is we need to create a set of tests, maybe even at first manual perhaps like just to design them, then automate them. We need to create a set of tests that builds trust in those who own the code, that others can come in, change things and the code will not break itself, right? Yes.

[Ville Rayonen]

Other other part is kind of like that this person who has been owning the part of the system earlier is the reviewer for every change that comes in. So there's kind of learning possibility and learning feedback loop created in that kind of so peer reviewing of all the contributions. So that's other way of creating that kind of trust.

[Vasco Duarte]

That would be similar to what in Linux they call the maintainers, right? Like anyone can change any part of the code, but before it gets accepted, somebody will go through the change and will validate that. Yes, the change does follow whatever rules we have. And it seems to work according to what has been declared that it would work like, and so on and so forth.

[Ville Rayonen]

So what is usually typical, you have additional force in this system often that the management is wishing that there's still features coming out and adding test and peer reviewing code will slow you down. So what you have to create is also understanding in the management that this is necessary step to do. You will probably slow down and it will take some time before it will speed up, but it will speed up after doing this one and you will have actually system which has less risks because if that one person is hit by the bus, the classic bus factor, then you will be totally screwed. But this will reduce the risk.

[Vasco Duarte]

Yeah, and what we are talking about here is moving from what is segregated or separated code ownership into a shared code ownership. And some people would even call this the internal open source model, right? Where you still have clear owners, you still have review and kind of a vetting process for all changes. But anyone in the organization can suggest a change, do a pull request, for example, and then that gets reviewed and approved and then it gets into the final code, right?

[Ville Rayonen]

Yes. And next step, maybe further on the way would be shared ownership, but maybe it happens, maybe it doesn't. But already when people can change the other part of the system, it has much higher impact on the. You don't need to wait for somebody else, you can do it yourself. If you need something, do it yourself. And you can. The delays and wait times are diminished in that way. So actually the progress might be much faster already in that Sense.

[Vasco Duarte]

Yeah. One would say that the segregated code ownership also creates slowness. Right. Because you're inherently designing the system around explicit and deliberate bottlenecks. Right? Because one person can only do one thing at one time and then if they have to do everything, then there are queues that form so they become bottlenecks. One would argue that a shared code ownership model, initially for example through code reviews and then later on through automated testing CD&CI or CI and CD would quite quickly yield faster throughput of user stories and features. Is that your experience or am I seeing this wrong?

[Ville Rayonen]

That I've seen also it's the bottlenecks. Single person or single team behind the bottleneck is often which is delaying the whole implementation of whole system, whatever is going to be implemented. So when the bottleneck is somewhere else than in single component, then you usually go faster already.

[Vasco Duarte]

Yeah, absolutely. One thing that I think we should refer to here is a book that I'm sure you've read and many of our listeners read, but I'll mention it again. Team Topologies that tries to tackle these different setups. There's also a great book by. I forget the name now, but I'll put it in the show notes. It's an agile software development by Patterns I believe is the book where the authors review a bunch of not just team setup, but team setup being one and other patterns related to the Scrum master role and so on that allow us to kind of act deliberately on a system. Right. Like to look at the system not just as a collection of individuals, which it ultimately is, but but also from a slightly higher perspective or slightly higher abstraction level using the concept of patterns which you like so much and create designs for. In this case we were talking about shared code ownership. So patterns for shared code ownership are in those books that we can then use and think about complete implementation solutions. Right. Like these patterns are more or less kind of self descriptive and contained. So you can go and implement that rather than try to develop small changes over time that eventually lead to one of those patterns. So I guess it's kind of a superpower to have to know about those patterns. So I would definitely recommend Team topologies and agile software development patterns. How about you Willi, do you have another book that you think people should know about?

[Ville Rayonen]

I think this, this also one, one thing in this case is like how, how the people can learn from other people. I think pair programming is some very powerful method to actually learn and to be feel safe. Of course that's a skill which you have to learn or you can necessarily don't. That's a. You can have three people doing it or you have a whole team doing it together. It's the same thing. There, there is. There is the. What is called ensemble programming.

[Vasco Duarte]

Ensemble programming? Yeah. Which is the new name. It's called mob programming for those of us who heard about it early on.

[Ville Rayonen]

Yes. So that's the way kind of create understanding on the system for multiple people and feel safe. Same time about the changes.

[Vasco Duarte]

All right.

[Ville Rayonen]

Might be something additional done with the testing and reviewing. Or it can replace the reuse.

[Vasco Duarte]

Absolutely. We'll put the link to all of those resources in the show notes, so do check them out. Ville, thank you very much for sharing that story with us.

[Ville Rayonen]

Thank you.

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