Aligning Teams and Architecture for Fast Flow with Paul Van Der Slot

Ever wondered how to transform overloaded agile teams into efficient, autonomous units? Get ready to uncover the secrets of fast workflow in our conversation with Paul Vanderslot from Rotterdam. As a seasoned software architect for an energy network operator, Paul faced the daunting challenge of a bottleneck team buried under a massive backlog. He shares his personal journey and the emotional toll that team dependencies created, revealing the magic formula for fostering empowered, product-minded teams that see developers as creative problem solvers and value creators.

Discover the transformative power of domain-driven design as Paul explains how aligning teams with specific business domains can lead to independent architecture and smoother collaboration. With practical examples and insights, Paul illustrates how recognizing domain shifts in language—like transitioning from "candidate" to "employee"—can significantly enhance team autonomy and efficiency. Learn how event-based integration and stable contracts between domains minimize frustrating dependencies and context switching, resulting in happier and more innovative developers. This episode is packed with invaluable strategies to supercharge your agile teams and revolutionize your development process.

Connect with Paul on LinkedIn:
https://www.linkedin.com/in/paul-van-der-slot-03545b37/

Read "Architecture Modernization" by Nick Tune:
https://manning.com/books/architecture-modernization

Read "Escaping the Build Trap" by Melissa Perri:
https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X

Chapters

• 0:06 Empowering Agile Teams for Fast Flow
• 8:29 Implementing Domain-Driven Design for Teams
• 18:30 Navigating Domain Transitions for Agile Success

Transcript

Mark: 0:06

Welcome to the Agile Within. I am your host, Mark Metze. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Well, welcome back everybody. This is Mark Metz with the Agile Within podcast. My guest today from Rotterdam, the Netherlands, is Paul van der Slot. Paul, welcome to the Agile Within.

Paul: 0:50

Thank you, Mark, it's very nice to be here.

Mark: 0:53

Oh, so great to have you. So before we get started, Paul, it's like a tradition here on the Agile Within. If I were coming to Rotterdam for a day, what's one thing that you would say that I couldn't miss doing?

Paul: 1:05

Well, Rotterdam for a day. What's one thing that you would say that I couldn't miss doing? Well, Rotterdam is one of the biggest harbors in Europe, so I think it would be nice to have a view or have a boat ride around the canal or the river that is flowing through Rotterdam. But if you're visiting the Netherlands, cycling around the town and visiting different highlights would be amazing as well.

Mark: 1:28

I have heard cycling is quite nice, so yes, so on our bucket list. My wife and I are going to get over to the Netherlands one day and we'll have to look you up if we're in the Rotterdam area, for sure.

Paul: 1:38

Yeah, you're definitely welcome. Let's do that Awesome.

Mark: 1:42

But before we get started, Paul, tell us a little bit about yourself. So you say you're a software architect. Introduce yourself for us.

Paul: 1:50

Yeah, sure, so I've been working in software for a little bit over a decade now. I started working as a software engineer with a big architecture mindset and now actually working as an architect for over two years. So I'm still quite hands-on and not the high ivory tower architect, but, yeah, with my feet in the mud, and I also have a passion for domain-driven design and collaborative modeling and techniques like that. So that's some of the things that I bring to the clients that I work for. I'm doing that independently, by the way. That I bring to the clients that I work for I'm doing that independently, by the way. So I'm an independent contractor.

Mark: 2:29

So the title for our episode today is Aligning Teams in Architecture for Fast Flow, and Paul is an architect for an energy network operator there in the Netherlands and he walked into a situation where they were building a new product and he observed some issues right away. So, paul, why don't you set the stage for us? When you came in, what kind of issues did you see and how did you approach them?

Paul: 2:55

So I joined there three years ago at Alliander, I joined the part of Klein Verbruik, which is translated into small consumption, klein Verbruik, which is translated into small consumption, and there we work towards a common goal with six teams, with the SAFE framework and after a few PI planning events, I started seeing some common themes, some struggles in some themes and also a lot of emotion while collaborating.

Paul: 3:21

What I noticed was that the oldest team actually has become a bottleneck, with a backlog that was way too big at some point, and all the other teams they were also dependent of the oldest team. That old team was already there for a while, quite ambitious, and they had way too much and, at the end, too complex software to maintain and that means that they didn't have enough focus. They had to do context switching a lot of the time and there were a lot of dependencies from the original team and the other teams that have joined To work that out. A lot of dependencies were there, a lot of meetings were needed and the problem for the other teams as well was that they weren't able to create value on their own. They always needed a bit of the original team to deliver value. Complication actually took a lot of emotion and problems with it to the planning event because one team was way too full with their backlog and the other teams couldn't deliver valuable stuff, and that happened over and over actually.

Mark: 4:24

If you're using Safe. I can imagine the dependency map that you had was quite messy with lots of yarn and lots of directions.

Paul: 4:31

Yeah, definitely. So, yeah, that was also one of the first signals where I thought, okay, this is not what it was supposed to look like.

Mark: 4:39

What was the main cause? So you said there was this one team that was the bottleneck. How did you start to unfold that, to start breaking that down so that everybody wasn't dependent upon this one team that was frequently overloaded?

Paul: 4:54

Yeah, so that's not something that you can do easily, I think, to be clear, what I ideally see as an ideal state would be that we had a lot of autonomous, independent teams which would be very empowered to do everything around product development, which was not the case at that point. So empowered teams, product mindset instead of projects, a lot of ownership and focus and I wasn't in the space at that time I started as a developer and later as an architect to change everything right away, but I started signaling the problems and stating that we could do things different, and one of the important things was that I proposed to make the team more the central part in this company, so that it wouldn't be the product manager who was the only one with a vision, and then product owners, who were more order takers and take the orders from the product manager and deliver it to the team, and that the developers would be code monkeys and just building features without knowing why. That's not what I wanted to, uh, be the situation. It wasn't completely like that. It's a little bit exaggerated, but what I would like is also something that Gerge Oros mentioned perfectly.

Paul: 6:13

He mentioned once that the Silicon Valley-like companies think of engineers more as value creators and creative problem solvers, while some traditional companies see them more as factory workers. Another great quote from Brandolini is that at the end, it's not the knowledge of the product manager or the domain expert that gets into production, but the knowledge of the team and the software engineers. So it's important that they understand what they are doing and why they are doing stuff, and then you can get in a lot of cool things where the teams actually discover. So that would be the ideal state to me. And yeah, how we get there was, yeah, quite some journey, because then you get towards the question if we have one big product with all these teams, how can we get to that state actually?

Mark: 7:00

So, paul, I've got a question for you. This is interesting. So you're an outsider coming in and you're coming from an engineering slash architecture background, so you're not necessarily coming with a lot of authority. How did you start introducing these ideas and getting people to open up, to thinking differently about how the teams were organized? Because I can imagine some of the resistance that you encountered during that.

Paul: 7:29

Yeah, there definitely was some resistance, but I think what was the most happening was that they were very happy that people had different ideas and, in this case, me, had an idea how to tackle these problems, because everyone was quite aware of that. It wasn't the ideal situation that we had right now. We were struggling and just hitting the wall and didn't know how to get out of that situation. So at one point I shared my view on these things and explained things like what Conway's Law means and how you can help your teams get more autonomous and more independent at some point, and how that would look like and how it would solve the problems that we had at this point. And that was all theoretical. But then the ball started rolling. We started talking about it and it became tangible at some point and more and more people became enthusiastic about it okay, so continue your story.

Mark: 8:29

You were going on to start talking about how you started tackling some of this yeah, yeah, so, um, so I was talking about independent teams with fast flow.

Paul: 8:40

So that would be the ideal state. And if, if you want that, you also need an independent architecture, loosely coupled architecture, because if the software solutions of the different teams are talking a lot with each other, you need a lot of collaboration while evolving those systems. If the systems are as independent as possible, the teams can work as independent as possible as possible. The teams can work as independent as possible. That's actually stated by Melvin Conway with Conway's Law, who says that the organization system design will be a copy of the organization's communication structure. That's actually on the basis of this idea.

Paul: 9:17

So we say now that we want to align the team with the architecture, and one way to do that quite well is to also align it with the loosely coupled business domains, so the different business domains that are independent of each other, the different problems we want to solve or the different opportunities we have. So some examples for domains could be marketing or sales or loyalty billing, fraud detection, things like that, and those things are quite independent. And if you put one team and you say you are now responsible of everything around fraud detection, then it can work quite independently and create an architecture that is independent of all the other business parts. So that was actually what I proposed there.

Mark: 10:03

And I imagine that helps tremendously with letting the team focus and go deep in your example, like with security, and make it really a first-class citizen to not be so overwhelmed with everything. But to really go deep and make sure that it's bulletproof.

Paul: 10:20

Yeah, so that's definitely the idea. So if you are focusing on one of those domains, you can really understand the ins and outs of everything of that domain, but you can also let go all the other noise around you. You don't have one big model where you need to focus on and you need to understand everything that is happening around you. You can really focus on this small part and then you can see that the team is already noticing improvements in that domain, because everything they are working on it, they are refining, they're talking with business people and their context and their knowledge grows and grows, which makes it possible to create even better products at the end.

Mark: 11:01

So you identified this approach, where you wanted to have different domains and have teams assigned to a domain and have specialties. How did you go about implementing that? Was there a model that you used, or did you just tell us about how you, how you made that happen?

Paul: 11:20

Yeah, great question. There are a lot of ideas around that. So I'm heavily influenced by domain-driven design and in domain-driven design there's a concept called the bounded context, which is really related to such a domain. There is also the belief that you have to have different models to be able to keep evolving in a complex environment. There are some ideas behind domain-driven design on how to find these boundaries and there are a lot of ideas behind this. You have in the team topologies area. There are a lot of ideas how to split up teams and domains. Domain-driven design, For the same, there's a great method which is called event storming, which can help you with identifying these boundaries between domains, and there are also amazing frameworks, like, also from the team topologies area, independent service heuristics, which is a method to objectively identify or challenge the domains that you see. So you have some candidates and then you can objectively, by asking some questions, challenge the domains that you have seen and see if they are really as independent and as great as you thought they would be. So this domain-driven design.

Mark: 12:38

Can you give us a summary or a high level, give us an elevator pitch for domain-driven design? Paul.

Paul: 12:45

Yeah, sure, and to start up, it isn't that well understood. There are a lot of misconceptions about domain-driven design. So probably, if you hear this elevator pitch and you remember it, you know more than most people. But it's originated from the book of Eric Evans, which is already over 20 years old, and it's actually an approach to software development with a few characteristics. So there's a focus on learning.

Paul: 13:12

So the belief of domain-driven design is that it's very important to understand the problem that you are solving and that understanding that problem is really the bottleneck in creating high value software. And then you need to do that together with business people. And the second thing is that language is very important, so they use language to get a common ground and a common understanding in solving those problems. So you need a shared language between business people and IT people. And another one is that at the end, you need multiple models to not evolve in a big ball of mud or some unmaintainable system.

Paul: 13:50

An example that can maybe let it be a little bit more tangible is, for instance, if you have a company like an IT consultancy and you talk about the entity employee, that can mean a lot of different things in different contexts.

Paul: 14:07

So in the finance context you're talking probably about a bank account and a name and an address, because people need to get paid and get their salary. But if you talk in the sales context, you probably think about the consultants that you are letting hired by other companies, who work on some project, have a certain rate or a certain seniority, and if you think about that, the employee does exist. For instance, the CEO employee does exist in a finance context because he or she needs to get paid, but in the sales context you probably are not letting your CEO work as a consultant. So if you have one big model of employees, then you already start to notice that it's quite hard to understand what is relevant for an employee and that model can get quite messy. It's probably way better to split that model up for the different context and create a model that is ideal for that situation and you can also adjust naming for that situation. So maybe in the sales context you don't talk about employees but you talk about consultants.

Mark: 15:16

The very first thing that you mentioned was being very clear on the problem that needed to be solved, and I've been reading a book called Escaping the Build Trap by Melissa Perry. She talks in there about product people being very intentional about describing the problem that really they need to solve for the customer and getting away from a feature factory where you're just releasing feature after feature after feature and then, before you know it, you have all this bloat and only 20% of the features that you're releasing are actually used, because that's what you're focusing on releasing, not actually solving a problem. So, yeah, I really resonate with that which you said being very clear about trying to delineate what is the problem that you're trying to solve.

Paul: 16:03

Yeah, definitely. And also another great quote is that actually software development is about learning and working. Software is like a side effect. The hardest part is really understanding the problem and learning about the problem and then, while learning, you probably deploy something to production, get feedback again, learn, and then, by the way, your understanding grows of what you are trying to solve and what value you are delivering. It's a kind of odd way to think about software development and it's quite drastic.

Paul: 16:37

But yeah it's a way that it's a quote from Alberto Brandolini again, but yeah, really like that way of looking at it.

Mark: 16:45

Paints a great picture. Pick us back up in your story. So you started seeing where domain-driven design could be a model that would help this organization with being able to focus. All right, so what did you do next?

Paul: 16:58

Yeah, so actually, before I joined, the company already started with doing a design sprint. So they had an off-site of five days where they did a design sprint and ended up with a prototype. What I did was I took that prototype with a lot of people who were at the design sprint and we started thinking about how would this prototype work, what would be the global information flow and what kind of domains or pieces of software solutions do we need to create this prototype? I was doing that with a lot of different people with product owners, other architects, lead developers and at the end, we had quite a good common understanding on what we needed to build to be able to deliver this in six or seven years. So it was a design sprint, a visionary design sprint actually, that put a dot on the horizon. This is where we want to be in six years, because we needed to do a lot of things very different because of the energy transition.

Mark: 18:00

So, when you come up with this, you come out of this design spree and you've got this big picture vision that you've got for the next five or six years that you want to go off to.

Paul: 18:11

So then, how did you start tackling the problem because now we had a clear view on what we wanted to create as an architecture, what would be boundaries of different domains and some heuristics you can use. There is, for instance, when the language changed, so at one point we are talking about a candidate and then another point for an employee. That's a clear transition of where somebody is, at the first point, not yet hired and later is hired. So a change of language is probably an indication that you are in a different domain. If the purpose of what you are doing at some point really changes, that's also a shift in domain. Or when the user group that you're serving is changing. For instance, we were creating software for our internal employees, but also software for contractors, that we were actually doing the work outside and doing the digging and placing all the electrical cables and the gas pipes. All those things were indicators that we were in a different domain.

Mark: 19:19

When you say the language had to change, what do you mean? The language had to change?

Paul: 19:23

Well, the language doesn't need to change. When language changed, it can be an indication that you are in a new domain. So an example of where the language changed is when we are first having someone who requests something at our site and at a later point we are talking about someone who owns the building. Probably, if we are looking at a requester point of view, you have some software and then we are suddenly talking about things that happen to the owner of the building. That might be an indication that we are talking about different domains serving different people. Another great example was what I was just talking about. First we were talking about employees and now we are talking about consultants. It's the same person, but the language suddenly changed.

Mark: 20:10

I get it. So what you recognize is when the language changes, that's a signal that we probably are switching domains, or we might be switching domains. Yeah, and where that's important is, if the domains are switching and you have teams assigned to domains, then you have another team that needs to start listening in to say, oh, this is important to me. I need to start really paying close attention.

Paul: 20:34

Yeah, so the interesting thing is that you are designing the domain boundaries so that you say, okay, if on one domain one team has the responsibility and another domain, another team has a responsibility, they can work quite independently. That's actually the benefit of these domains. Then you can get independent teams because you have independent domains and you have, at one point, less dependencies and fast flow.

Mark: 21:01

And then what about the working between teams? Then how does that work to make sure that? So you've got these boundaries, but how do you make sure that these boundaries are all working successfully together?

Paul: 21:14

Yeah. So of course I'm talking about autonomy and getting less dependencies. But totally autonomous and totally no dependencies, that's not possible. Then you don't get working software, so you have to have some integrations. It could be event-based, it could be via APIs, so you can think about how you want to integrate. But it would be great if that would be via contracts, for instance, that you don't need extensive collaboration every time when something happens on the boundaries, that actually, for instance, some event has happened at the end of your process, then you can say, for instance, when the payment is received, that shipping starts shipping something to a customer. Then I just do it event-based and say payment received, and then the shipping context and the shipping domain knows okay, now it's my turn.

Mark: 22:08

I have package uh the stuff and send it to, uh, to the customer and for our listeners out there who may not be coming from a technical background, share with us what you mean by contract, because I'm a former developer and I have a sense for what you mean.

Paul: 22:23

Yeah, great, okay. So what I mean is that we are quite explicit on the interaction between one domain and another domain, so that it is described what is the interaction and what kind of information is transmitted from one side to the other. And that is always stable, so both parties can see the contract as stable and that it wouldn't change, and that makes it possible for both parties to work independently on their side of the contract.

Mark: 22:58

Nice explanation, Paul. Yeah, thanks. Okay, so now we've got a domain-driven design where each team is assigned to a domain. They're more or less mostly autonomous. They're able to break down some of the dependencies. Talk to us about some of the successes that you started seeing achieved through this domain-driven design approach.

Paul: 23:23

Yeah, sure. So what we did see at the end was that we had obviously way less dependencies between teams. We did see that the flow of changes was way higher. Every team has quite a clear purpose at the end, and that also made sure that learning and innovation was way better at the team level, because they had all those focus and really can dig deep in a certain problem and can really learn about the environment they are working in, which also led to team happiness. They really were able to achieve some goals and create value to the customer independently, which made the teams happy as well. So those were some of the things we saw at the end.

Mark: 24:04

Yeah, that can be understated.

Mark: 24:07

Sometimes, when you're talking at a management level, maybe even executive management level, you hear lowering dependencies and you immediately say, oh well, that means we get to move faster, we're not waiting as much, and that's true and that is very important. But I don't want to short sell the side of it from the developers, because I feel like they can be much more happy and productive and they're just not frustrated in their job that they take two steps Now wait, okay, now somebody did work for me, now I can resume my work. And many times when that happens you get into the trap of well, I'm waiting for this team to get back to me, so I'm going to start something else, right, and then you get part through that. And then the other team comes like okay, here you go, your part's ready. Now your context, switching back and forth, back and forth, and that thrashing being a former developer, that thrashing is very draining and by the end of the day you're just, you're just exhausted, and so your creativity, your productivity, all that I can see, would just soar.

Paul: 25:10

Yeah, definitely, and you literally saw that at the teams. So the team that had a lot of frustration during when I just joined at the PI plannings. You really saw some frustration in there and were started thinking is this really what those people are? These aren't nice people. And then, one and a half year later, when things improved and they had less responsibilities and they had more focus and they could deliver stuff, you started noticing that this was an amazing group of people that could deliver the greatest stuff. So context is everything here, and that was definitely one of the themes where I did see the biggest change.

Mark: 25:49

Yeah. So when you have lots of dependencies like that, that does promote a code monkey mentality, right, your job is just to code, that's all you do, and you punch the clock fingers to the keyboard. You're coding.

Paul: 26:03

you're're not thinking, you're just cranking out code yeah, definitely, it's hard to get ownership and really understand the why. If, for instance, seven teams are together responsible for delivering a feature, then it's really hard to get the overview of what all those seven teams are doing and what the value of all that together is. That's way harder than when you do it alone or with another team. Uh, so definitely that, uh, it makes it way easier, but it's not like, um, that magically happens, for instance. So it was quite a journey to get there at the end easy to say, harder to execute.

Paul: 26:39

On right yeah, so definitely. So. What I did see was we had, at some point, an agreement on the ideal state and what those domains would be, and everybody was talking in domains and really have a buy-in on the direction we were going. We were looking at the purpose of those domains and if it aligns with the purpose that the team has that the team has. So we were going great.

Paul: 27:06

But then we came to the moment that we really need to execute all of this and we noticed that the ideal state was different from the current state and then, bit by bit, we had to make some changes. Obviously, we started with the original team the one who had the most weight on their shoulders and the most responsibilities and their shoulders and the most responsibilities and started eliminating some of their responsibilities and giving it to another team. And, bit by bit, yeah, there were some easy decisions where a team was already quite aligned with a domain, but there were also some domains where four different teams were working in and then we really had to put some effort into transferring software from one team to another to get the situation where we could get started with in this way, and so it took some effort and some time and some money to get to the situation at some point.

Mark: 28:03

Yeah so if our listeners are intrigued and they're thinking this sounds like a similar problem that Paul walked into that we're having, what would you suggest for them to get started? What is your advice? Is there like one book, one article? What would you suggest for them to get started?

Paul: 28:24

So, if they're used to domain-driven design or are intrigued, right now there is something like the domain-driven design starter modeling process. It's on github, it's open source and it's for people new to domain-driven design describing how you could do this process globally with all kind of different methods and all kind of help and methods around that. So that would be a great start. There's also a great book about architecture modernization by Nick Choon which is also touching upon all these themes and, yeah, for me it was also great help. I was doing this and this book was in pre-order at some point and I was really reading all the chapters together when they became available and was noticing that I was kind of doing that, but it made it way more easy for me to clearly explain why we were doing things and all the reasoning behind it. And, yeah, it's not that big of a coincidence that you mentioned escaping the build trap, because there are also a lot of product management influences in all those different ideas.

Mark: 29:40

So we'll put some links to those resources in the show notes. If our listeners want to get in touch with you, Paul, what's the best way for them to do that?

Paul: 29:48

Yeah, I'm mostly active on LinkedIn, so you feel free to contact me on LinkedIn or connect with me and ask your questions. And yeah, I'm always happy to chat about these stuff. So, yeah, feel free to reach out.

Mark: 30:03

Great. We will put that in the show notes as well. People to get in touch with you. Paul, this has been an absolutely fantastic session. I really appreciate your time. Very impressive with what you've been able to achieve.

Paul: 30:16

Yeah, thanks a lot. Yeah, it was a great journey and it wasn't something that we did overnight. It really took more than a year to get to that state and a little bit more upfront to get everyone enthusiastic about it. But now in hindsight, I'm so happy that we did it this way and we really see that people are loving this approach right now.

Mark: 30:38

So yeah, thanks, great Thank you, and thanks to our listeners. We're going to put a wrap on things. This has been another episode of the Agile Within. We'll see you next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, Mark Metze.