Vasco Duarte (5:08)

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 (5:55)

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 (6:56)

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 (7:06)

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 (7:52)

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 (8:21)

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 (9:06)

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 (9:30)

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 (9:59)

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 (10:22)

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 (11:08)

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 (11:46)

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 (12:21)

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 (13:07)

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 (13:32)

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 (15:18)

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 (15:52)

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 (15:59)

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 (16:11)

All right.

Ville Rayonen (16:12)

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

Vasco Duarte (16:20)

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 (16:27)

Thank you.

Vasco Duarte (16:32)

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.