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

00:02:22.231 --> 00:02:23.495 I'm doing that independently, by the way. 00:02:23.495 --> 00:02:27.007 That I bring to the clients that I work for I'm doing that independently, by the way. 00:02:27.007 --> 00:02:28.445 So I'm an independent contractor. 00:02:29.240 --> 00:02:48.467 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. 00:02:48.467 --> 00:02:50.371 So, paul, why don't you set the stage for us? 00:02:50.371 --> 00:02:55.629 When you came in, what kind of issues did you see and how did you approach them? 00:02:55.890 --> 00:03:20.074 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. 00:03:21.000 --> 00:03:32.512 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. 00:03:32.512 --> 00:03:44.449 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. 00:03:44.449 --> 00:03:53.967 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. 00:03:53.967 --> 00:04:03.305 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. 00:04:03.305 --> 00:04:08.286 They always needed a bit of the original team to deliver value. 00:04:08.286 --> 00:04:23.427 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. 00:04:24.300 --> 00:04:25.144 If you're using Safe. 00:04:25.144 --> 00:04:31.471 I can imagine the dependency map that you had was quite messy with lots of yarn and lots of directions. 00:04:31.632 --> 00:04:32.394 Yeah, definitely. 00:04:32.394 --> 00:04:39.021 So, yeah, that was also one of the first signals where I thought, okay, this is not what it was supposed to look like. 00:04:39.382 --> 00:04:40.264 What was the main cause? 00:04:40.264 --> 00:04:43.613 So you said there was this one team that was the bottleneck. 00:04:43.613 --> 00:04:53.742 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? 00:04:54.343 --> 00:05:12.502 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. 00:05:12.502 --> 00:05:57.483 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. 00:05:57.483 --> 00:06:01.310 That's not what I wanted to, uh, be the situation. 00:06:01.310 --> 00:06:03.173 It wasn't completely like that. 00:06:03.173 --> 00:06:13.567 It's a little bit exaggerated, but what I would like is also something that Gerge Oros mentioned perfectly. 00:06:13.586 --> 00:06:22.033 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. 00:06:22.033 --> 00:06:34.665 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. 00:06:34.665 --> 00:06:43.088 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. 00:06:43.088 --> 00:06:46.589 So that would be the ideal state to me. 00:06:46.589 --> 00:06:59.788 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? 00:07:00.839 --> 00:07:02.084 So, paul, I've got a question for you. 00:07:02.084 --> 00:07:03.129 This is interesting. 00:07:03.129 --> 00:07:15.011 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. 00:07:15.011 --> 00:07:23.480 How did you start introducing these ideas and getting people to open up, to thinking differently about how the teams were organized? 00:07:23.480 --> 00:07:28.632 Because I can imagine some of the resistance that you encountered during that. 00:07:29.779 --> 00:07:46.769 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. 00:07:46.769 --> 00:07:49.475 It wasn't the ideal situation that we had right now. 00:07:49.475 --> 00:07:55.079 We were struggling and just hitting the wall and didn't know how to get out of that situation. 00:07:55.079 --> 00:08:15.125 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. 00:08:15.125 --> 00:08:17.209 And that was all theoretical. 00:08:17.209 --> 00:08:19.473 But then the ball started rolling. 00:08:19.473 --> 00:08:29.329 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. 00:08:29.370 --> 00:08:40.179 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. 00:08:40.340 --> 00:08:41.966 So that would be the ideal state. 00:08:41.966 --> 00:08:57.879 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. 00:08:57.879 --> 00:09:06.659 If the systems are as independent as possible, the teams can work as independent as possible as possible. 00:09:06.659 --> 00:09:07.722 The teams can work as independent as possible. 00:09:07.722 --> 00:09:14.062 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. 00:09:14.062 --> 00:09:17.509 That's actually on the basis of this idea. 00:09:17.950 --> 00:09:36.514 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. 00:09:36.514 --> 00:09:46.975 So some examples for domains could be marketing or sales or loyalty billing, fraud detection, things like that, and those things are quite independent. 00:09:46.975 --> 00:10:00.527 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. 00:10:00.527 --> 00:10:02.866 So that was actually what I proposed there. 00:10:03.659 --> 00:10:16.153 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. 00:10:16.153 --> 00:10:20.062 But to really go deep and make sure that it's bulletproof. 00:10:20.684 --> 00:10:23.028 Yeah, so that's definitely the idea. 00:10:23.028 --> 00:10:33.311 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. 00:10:33.311 --> 00:10:39.929 You don't have one big model where you need to focus on and you need to understand everything that is happening around you. 00:10:39.929 --> 00:11:00.725 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. 00:11:01.419 --> 00:11:11.453 So you identified this approach, where you wanted to have different domains and have teams assigned to a domain and have specialties. 00:11:11.453 --> 00:11:13.701 How did you go about implementing that? 00:11:13.701 --> 00:11:19.232 Was there a model that you used, or did you just tell us about how you, how you made that happen? 00:11:20.315 --> 00:11:21.176 Yeah, great question. 00:11:21.176 --> 00:11:23.397 There are a lot of ideas around that. 00:11:23.397 --> 00:11:33.945 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. 00:11:33.945 --> 00:11:41.870 There is also the belief that you have to have different models to be able to keep evolving in a complex environment. 00:11:41.870 --> 00:11:50.106 There are some ideas behind domain-driven design on how to find these boundaries and there are a lot of ideas behind this. 00:11:50.106 --> 00:11:53.496 You have in the team topologies area. 00:11:53.496 --> 00:11:56.143 There are a lot of ideas how to split up teams and domains. 00:11:56.143 --> 00:12:23.448 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. 00:12:23.448 --> 00:12:36.326 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. 00:12:36.326 --> 00:12:38.239 So this domain-driven design. 00:12:38.960 --> 00:12:45.125 Can you give us a summary or a high level, give us an elevator pitch for domain-driven design?

00:12:45.125 --> 00:12:45.365 Paul. 00:12:45.995 --> 00:12:49.788 Yeah, sure, and to start up, it isn't that well understood. 00:12:49.788 --> 00:12:53.099 There are a lot of misconceptions about domain-driven design. 00:12:53.099 --> 00:12:58.741 So probably, if you hear this elevator pitch and you remember it, you know more than most people. 00:12:58.741 --> 00:13:09.743 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. 00:13:09.743 --> 00:13:11.807 So there's a focus on learning. 00:13:12.514 --> 00:13:24.376 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. 00:13:24.376 --> 00:13:27.341 And then you need to do that together with business people. 00:13:27.341 --> 00:13:36.674 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. 00:13:36.674 --> 00:13:41.226 So you need a shared language between business people and IT people. 00:13:41.226 --> 00:13:50.440 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. 00:13:50.900 --> 00:14:07.288 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. 00:14:07.434 --> 00:14:15.245 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. 00:14:15.245 --> 00:14:33.426 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. 00:14:33.426 --> 00:14:45.327 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. 00:14:45.327 --> 00:14:59.663 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. 00:14:59.663 --> 00:15:11.125 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. 00:15:11.125 --> 00:15:15.846 So maybe in the sales context you don't talk about employees but you talk about consultants. 00:15:16.355 --> 00:15:26.537 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. 00:15:26.537 --> 00:15:53.221 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. 00:15:53.221 --> 00:16:02.696 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. 00:16:03.557 --> 00:16:04.279 Yeah, definitely. 00:16:04.279 --> 00:16:11.318 And also another great quote is that actually software development is about learning and working. 00:16:11.318 --> 00:16:12.894 Software is like a side effect. 00:16:12.894 --> 00:16:30.654 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. 00:16:30.654 --> 00:16:36.087 It's a kind of odd way to think about software development and it's quite drastic. 00:16:37.297 --> 00:16:44.384 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. 00:16:45.034 --> 00:16:45.859 Paints a great picture. 00:16:45.859 --> 00:16:47.746 Pick us back up in your story. 00:16:47.746 --> 00:16:55.427 So you started seeing where domain-driven design could be a model that would help this organization with being able to focus. 00:16:55.427 --> 00:16:57.378 All right, so what did you do next? 00:16:58.120 --> 00:17:04.458 Yeah, so actually, before I joined, the company already started with doing a design sprint. 00:17:04.458 --> 00:17:10.584 So they had an off-site of five days where they did a design sprint and ended up with a prototype. 00:17:10.584 --> 00:17:30.865 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? 00:17:30.865 --> 00:17:46.307 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. 00:17:46.307 --> 00:17:52.788 So it was a design sprint, a visionary design sprint actually, that put a dot on the horizon. 00:17:52.788 --> 00:18:00.154 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.

00:18:00.536 --> 00:18:11.459 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. 00:18:11.878 --> 00:18:30.065 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. 00:18:30.065 --> 00:18:39.448 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. 00:18:39.448 --> 00:18:46.090 That's a clear transition of where somebody is, at the first point, not yet hired and later is hired. 00:18:46.090 --> 00:18:50.731 So a change of language is probably an indication that you are in a different domain. 00:18:50.731 --> 00:18:55.874 If the purpose of what you are doing at some point really changes, that's also a shift in domain. 00:18:55.874 --> 00:19:02.276 Or when the user group that you're serving is changing. 00:19:02.276 --> 00:19:15.250 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. 00:19:15.250 --> 00:19:18.805 All those things were indicators that we were in a different domain. 00:19:19.555 --> 00:19:22.442 When you say the language had to change, what do you mean? 00:19:22.442 --> 00:19:23.526 The language had to change? 00:19:23.756 --> 00:19:26.505 Well, the language doesn't need to change. 00:19:26.505 --> 00:19:30.866 When language changed, it can be an indication that you are in a new domain. 00:19:30.866 --> 00:19:43.707 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. 00:19:43.707 --> 00:19:52.886 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. 00:19:52.886 --> 00:19:59.208 That might be an indication that we are talking about different domains serving different people. 00:19:59.208 --> 00:20:02.344 Another great example was what I was just talking about. 00:20:02.344 --> 00:20:06.125 First we were talking about employees and now we are talking about consultants. 00:20:06.125 --> 00:20:09.563 It's the same person, but the language suddenly changed. 00:20:10.345 --> 00:20:10.807 I get it. 00:20:10.807 --> 00:20:19.845 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. 00:20:19.845 --> 00:20:30.829 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. 00:20:30.829 --> 00:20:33.563 I need to start really paying close attention. 00:20:34.285 --> 00:20:49.962 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. 00:20:49.962 --> 00:20:53.484 That's actually the benefit of these domains. 00:20:53.484 --> 00:21:00.586 Then you can get independent teams because you have independent domains and you have, at one point, less dependencies and fast flow. 00:21:01.835 --> 00:21:04.642 And then what about the working between teams? 00:21:04.642 --> 00:21:06.955 Then how does that work to make sure that? 00:21:06.955 --> 00:21:13.159 So you've got these boundaries, but how do you make sure that these boundaries are all working successfully together? 00:21:14.020 --> 00:21:14.201 Yeah. 00:21:14.201 --> 00:21:19.297 So of course I'm talking about autonomy and getting less dependencies. 00:21:19.297 --> 00:21:24.051 But totally autonomous and totally no dependencies, that's not possible. 00:21:24.051 --> 00:21:28.082 Then you don't get working software, so you have to have some integrations. 00:21:28.082 --> 00:21:34.786 It could be event-based, it could be via APIs, so you can think about how you want to integrate. 00:21:34.786 --> 00:22:00.205 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. 00:22:00.205 --> 00:22:08.780 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. 00:22:08.840 --> 00:22:23.364 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. 00:22:23.845 --> 00:22:24.885 Yeah, great, okay. 00:22:24.885 --> 00:22:43.247 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. 00:22:43.247 --> 00:22:57.099 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. 00:22:58.021 --> 00:22:59.022 Nice explanation, Paul. 00:22:59.022 --> 00:22:59.923 Yeah, thanks. 00:22:59.923 --> 00:23:07.098 Okay, so now we've got a domain-driven design where each team is assigned to a domain.

00:23:07.098 --> 00:23:10.194 They're more or less mostly autonomous. 00:23:10.194 --> 00:23:14.477 They're able to break down some of the dependencies. 00:23:14.477 --> 00:23:22.201 Talk to us about some of the successes that you started seeing achieved through this domain-driven design approach. 00:23:23.104 --> 00:23:23.525 Yeah, sure. 00:23:23.525 --> 00:23:29.570 So what we did see at the end was that we had obviously way less dependencies between teams. 00:23:29.570 --> 00:23:33.358 We did see that the flow of changes was way higher. 00:23:33.358 --> 00:23:53.951 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. 00:23:53.951 --> 00:24:01.612 They really were able to achieve some goals and create value to the customer independently, which made the teams happy as well. 00:24:01.612 --> 00:24:04.814 So those were some of the things we saw at the end. 00:24:04.953 --> 00:24:07.068 Yeah, that can be understated. 00:24:07.148 --> 00:24:21.347 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. 00:24:21.347 --> 00:24:38.337 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. 00:24:38.337 --> 00:24:49.455 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. 00:24:49.455 --> 00:24:53.111 And then the other team comes like okay, here you go, your part's ready. 00:24:53.111 --> 00:25:09.672 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. 00:25:10.353 --> 00:25:13.606 Yeah, definitely, and you literally saw that at the teams. 00:25:13.606 --> 00:25:19.046 So the team that had a lot of frustration during when I just joined at the PI plannings. 00:25:19.046 --> 00:25:26.278 You really saw some frustration in there and were started thinking is this really what those people are? 00:25:26.278 --> 00:25:27.748 These aren't nice people. 00:25:27.748 --> 00:25:43.012 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. 00:25:43.012 --> 00:25:49.654 So context is everything here, and that was definitely one of the themes where I did see the biggest change. 00:25:49.935 --> 00:25:50.096 Yeah. 00:25:50.096 --> 00:26:03.107 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. 00:26:03.107 --> 00:26:03.648 You're coding. 00:26:03.669 --> 00:26:10.026 you're're not thinking, you're just cranking out code yeah, definitely, it's hard to get ownership and really understand the why. 00:26:10.026 --> 00:26:22.890 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. 00:26:22.890 --> 00:26:26.145 That's way harder than when you do it alone or with another team. 00:26:26.145 --> 00:26:33.726 Uh, so definitely that, uh, it makes it way easier, but it's not like, um, that magically happens, for instance. 00:26:33.726 --> 00:26:39.698 So it was quite a journey to get there at the end easy to say, harder to execute. 00:26:39.818 --> 00:26:42.067 On right yeah, so definitely. 00:26:42.067 --> 00:26:42.287 So. 00:26:42.287 --> 00:26:56.777 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. 00:26:56.777 --> 00:27:02.121 We were looking at the purpose of those domains and if it aligns with the purpose that the team has that the team has. 00:27:02.121 --> 00:27:04.182 So we were going great. 00:27:06.345 --> 00:27:17.191 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. 00:27:17.191 --> 00:27:30.451 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. 00:27:30.451 --> 00:28:02.367 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. 00:28:03.069 --> 00:28:17.337 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? 00:28:17.337 --> 00:28:18.159 What is your advice? 00:28:18.159 --> 00:28:21.375 Is there like one book, one article? 00:28:21.375 --> 00:28:23.573 What would you suggest for them to get started? 00:28:24.205 --> 00:28:34.146 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. 00:28:34.146 --> 00:28:50.980 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. 00:28:50.980 --> 00:28:53.032 So that would be a great start. 00:28:53.032 --> 00:29:04.528 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. 00:29:04.528 --> 00:29:25.631 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. 00:29:25.631 --> 00:29:38.598 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. 00:29:40.445 --> 00:29:44.457 So we'll put some links to those resources in the show notes. 00:29:44.457 --> 00:29:48.236 If our listeners want to get in touch with you, Paul, what's the best way for them to do that? 00:29:48.625 --> 00:29:57.077 Yeah, I'm mostly active on LinkedIn, so you feel free to contact me on LinkedIn or connect with me and ask your questions. 00:29:57.077 --> 00:30:00.694 And yeah, I'm always happy to chat about these stuff. 00:30:00.694 --> 00:30:02.711 So, yeah, feel free to reach out. 00:30:03.614 --> 00:30:03.875 Great. 00:30:03.875 --> 00:30:05.952 We will put that in the show notes as well. 00:30:05.952 --> 00:30:07.410 People to get in touch with you. 00:30:07.410 --> 00:30:10.604 Paul, this has been an absolutely fantastic session. 00:30:10.604 --> 00:30:11.946 I really appreciate your time. 00:30:11.946 --> 00:30:15.654 Very impressive with what you've been able to achieve. 00:30:16.416 --> 00:30:17.178 Yeah, thanks a lot. 00:30:17.178 --> 00:30:21.695 Yeah, it was a great journey and it wasn't something that we did overnight. 00:30:21.695 --> 00:30:29.314 It really took more than a year to get to that state and a little bit more upfront to get everyone enthusiastic about it. 00:30:29.314 --> 00:30:37.671 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. 00:30:38.045 --> 00:30:43.131 So yeah, thanks, great Thank you, and thanks to our listeners. 00:30:43.131 --> 00:30:45.372 We're going to put a wrap on things. 00:30:45.372 --> 00:30:47.651 This has been another episode of the Agile Within. 00:30:47.651 --> 00:30:49.175 We'll see you next time. 00:30:49.175 --> 00:30:57.798 Thanks for joining us for another episode of the Agile Within. 00:30:57.798 --> 00:31:02.431 If you haven't already, please join our LinkedIn page to stay in touch. 00:31:02.431 --> 00:31:11.688 Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. 00:31:11.688 --> 00:31:14.115 This has been your host, Mark Metze.