Welcome to Software Testing Unleashed, the podcast for testers, developers and software makers who live quality as an attitude. Get fresh ideas and sharp insights to grow your mindset, to learn new methods and to drive real change in how we build software. Better software and better teams for a better world. Hi, I'm Richie, software quality coach, keynote speaker and author. My guests today are Gien Verschatse and Kenny Baas-Schwegler.
Gien is a software engineer and consultant with a strong background in domain modeling and software architecture. She's experienced in both object-oriented and functional programming and applies that mix in various industries, including biotech. Gene is also a domain-driven design practitioner and international speaker, known for building bridges between users, domain experts, and engineers.
Kenny is an independent software consultant and trainer, and he focuses on software architecture and technical leadership. He combines domain-driven design with team topologies to help teams build collaborative and resilience systems. Kenny supports organizations in managing complexity, resolving conflicts, and aligning software with real business goals. He's also a regular speaker at international conferences and an active contributor to the software community.
And in this episode, we talk about collaborative software design and why aligning people is just as important as aligning code in our projects. Why do we deliver often software features we don't really understand based on some assumptions no one ever challenges? What if your biggest software problem is actually a conversation that never took place instead of bugs? And how can we design software that reflects real business needs, not just what's on a diagram and in a document?
We will explore how developers, testers, architects, business experts can collaborate using simple and visual modeling techniques. It's a very interesting topic and I'm really happy that the two are part of this show today. And now enjoy the episode. Hello Gien, hello Kenny. Nice to have you on the show. Thank you for having us, Richard. Yeah, thank you for having us. Yes, great that you are here. It's a little bit a remote recording for the OOP conference.
Unfortunately, I cannot be on site at the OOP this year because I go skiing. So maybe it's a good part for me. Nevertheless, I want to have these topics, the interesting topics from the conference in my podcast and I saw through the abstracts and saw your workshop, your tutorial about collaborative software design and then I get big eyes and so, okay, this part we have to talk about in the podcast.
Yes, and as I read your abstract, it's mentioned such problems within communication with stakeholders in a software project, which is so the baseline where you start with your collaboration techniques and so on. But let's focus first on the problem. What's the problem in talking with each other, with the stakeholders? I would say, and Kenny can tell his experience with problems.
I think when I started out as a software developer, way back when, one of the problems you have is that you actually don't really talk to your stakeholders. So you don't talk to the users or the people with the knowledge on which you're creating the software, either people that you're helping basically.
You know, it used to happen for me was that someone most often called a business analyst or something goes to talk to all the peoples, writes down their assumptions of what the software is supposed to do and then hand that over to the software development department. And then we interpreted their assumptions and wrote that into code and pushed that into production. And then the feedback was like, well, this is not doing what we actually needed to do.
But thank you anyway. And so that was for me, I think, the biggest problem. And I went looking for ways to sort of, you know, make that handoff a bit smaller. And that's sort of how I ran into collaborative modeling. So that's how it happened for me. I don't know about you, Kenneth. Well, I started, I was very lucky, like, when I started my career, I was in a company and
I didn't know anything. I came from embedded electronics, which was like, you need to model out everything you did already collaborative modeling with a, with a software system before you actually make the, the hardware, because you know, once it's hard, it's, you cannot, well, you can change it, but not that easy. So when I came into software, I was very lucky to come into a small team.
And like within a month, I got like this course in asset management, understanding what, what, what my users were actually doing. So we have a saying in Dutch, I'm not sure I cannot translate it with the pop label in Dakota, which means from the start, I got it correctly, in my opinion. And you know, I started collaborating and eventually Scrum got introduced and which helped us at that point. And after six years of working that I knew a lot about asset management.
I was a principal architect there within that team, within a department which grew to like two teams. And we already did like microservices, architecture, DevOps from day one I was publishing. So, but the thing is, the reason I could publish it to production because I understood the business so I knew exactly when I was allowed to publish things or promote things to production.
Right. So for me, it was natural to do this. And then I got into consultancy and then I I got into other companies and I'm like, huh, what are you doing here? But, but, but I need to understand the business in order to help you. And, and, and this is what exactly what Gien was, uh, telling. And within my first six years, I got to experience how domain driven design actually worked for me. And then I got into other companies where engineers didn't know anything about the domain.
And I saw that resembled in the code. Uh, and for me, uh, they were using Scrum. So I was like, okay, you're using Scrum, right? So you, you have the same understanding, but no. Um, and, and for me, that was a problem that we got a lot of. A telephone game from higher up from analysts, as he said.
And from there, my journey took on to understanding more and trying to teach this, uh, collaborative modeling the way I did it for six years into other companies, which I still, to this day, I find companies that lack, uh, every Every time I go in, go into a team and help them understand the business, and then they're like, "Oh, you're like a business analyst." I say, "Well, I do that, but I'm not." But okay, for me, it's normal.
And I felt it a bit weird that it's still not a normal thing to practice these days. But I understand it. When I do that, in my first six years, it was normal to talk to each other and was a good setting. having these isolated departments, that clashed a lot. And that took me into much more social silos. Yeah, that's one view I always see.
When I got to my clients, which are mainly very big companies, and when I get into the software development team, and I see they're working at the code and implementing user stories and tasks from the board, but they don't often know why they are doing this and what's behind it. They are just implementing what they have on the board and don't understand the big picture or the business in case or don't even think about ops or security or something. There's a very isolated field there.
And I think when we see Agile-- - Yeah, there's a nice quote from Alberto that says, They're working on tasks, you say, right? They're taking a task and they put it to production and they don't know. And that don't know, that assumption, that gets to production, not necessarily what's in the story. And that's the real problem here is that they take tickets but they don't know why they're doing the ticket.
And without that why, they will just bring something to production that's an assumption of their understanding of the ticket. And that's the core. And sorry to interrupt you there, but that popped into my mind with your question, what's the real problem? For me, what you just said with the story on the board and they're just implemented it, they're taking a lot of assumptions, I can 100% assure you, and that gets to production.
- I think there is a nice parallel view before we come to your solution or your view on the solution, is when I look at the testing department where I grew up, so as a tester, There is the big case that we deal with a lot of assumptions there.
The assumptions from the developer and the business analyst who tries to translate something from the business into technique and the architecture and the tester has a lot of assumptions and needs to define what is the real thing meant that can be tested against. So for a tester and for quality people, it's even more important to have a good understanding of what should the software do. Yeah, I think it even goes a bit further than that.
I remember going to a company and we were talking about software strategies, how does your year look like, where are you going to focus everything on? And they were like, oh yeah, we're going to focus on getting rid of technical debt. You were going to focus on refactoring here, here and here. And then I went to talk to higher management. I was like, hey, lovely company. So what are your company goals? What's the business strategy here?
And they were like, yeah, well, for the next two years, we really want to focus on our new products. And I was like, hmm, because this is very interesting, because I go to their software departments and they're going to focus on improving the old products. you go to the higher management and they're like, no, no, our focus is really on getting those two or three new products, getting those out there in the next few years.
So even on higher levels, there's discrepancies and there's no alignment and there's some sort of missing communication or miscommunication, which are two different things. And so often if you go to IT departments, they don't know how the company functions, They don't know the strategy. They don't understand what they short-term and long-term are hoping to achieve, really.
And so all of that makes for software and software development and how it functions less than optimal for the company that they're actually doing it. And so there's context missing there often as well. So it's on all levels. I feel that somehow people think you can just create software without understanding anything else. I don't know how that happens. But it's there. Yeah, that's true. So and you get the way to make it more better in our software project. So what is your start with?
What is your idea to do to make better understanding of the software and what is needed for the business? Yeah, so I mentioned collaborative modeling already, which is a very generic term. And I don't know, do you know the definition by heart, Kenny? It's a complex leading decision making process that well, and that it's a visual process. I know the, not by heart, but it's a visual process and you do it with your decision makers or stakeholders. So there's a few main terms in there.
It's a conflict laden. So it's usually you do it for complex decision making processes. So not for easy stuff. I mean, uh, yeah, I think that's it. Right. You're missing the, to create a shared understanding. Yeah. Yeah. Which is the part that tries to tackle the miscommunication, mostly. So yeah, it was a very boring definition. But yes, as Kenny said, there are a couple of important things. And the first thing is that we tried to get rid of the silos.
We tried to bring people into the same room or virtual room there. And we tried to get them to talk to one another. instead of having these documents that's written by a business analyst and then handed over and handed over and handed over.
So we try to sort of bring everyone there, including the business analyst, because they're good at their jobs, they know how to ask good questions to the business and you want that in that room there very much, together with the software developers, the architects, business analysts, anything involved. We're going to all put you in that same room, and we're going to talk about what is actually happening. What is important to you? What are the processes? What are the workflows?
Tell me how you do your job. Tell me which departments you have to communicate out there. Tell us everything. And we're going to make that visual. You're going to write it down, because I don't know if you have ever been in a meeting, Richie, things are just, they're just talking around and around and around. Yes, very annoying. So we try to make it visual because then you focus the conversation on what's actually
there, what's in front of you. So we try to visualize as much as possible. And we do that in a very simple way. I'm going to let Kenny tell you how we do that, so I don't gobble up all the time. Yeah. Yeah. So it's, it's including all the, all the stakeholders, by the way, we say stakeholders, but that can also be, uh, the, uh, developers or engineers or testers or analysts in the team, right? They're also stakeholders in a way.
So the way the, the way to describe collaborative modeling or, or the tools you use, it's that it should be easy to use a well common one in a domain driven design is event storming or domain storytelling. These are two of the most common used and they're both very simple. Event Storming in itself is an orange sticky and it's a domain event. So something that's relevant for your stakeholders. So it doesn't concern any databases or, but it does concern if you're in a
cinema, which we write about, it's like a place got reserved, right? So it's relevant for the can go further into that right okay when when is it not possible to reserve a place right and then you come into these constraints so you're adding all these things very natural instead of if you look at tools like uml which are still great or or like archimede which i used in the past or other modeling tools they're very constrictive right they have these certain dialect that you
I don't from the heart know what that means. And you don't want that. If we're talking about knowledge crunching, as we call it, right? Understanding business, we want information and knowledge to flow freely so that everyone can actually, and the metaphor is what like Gumbeldore does with his brain, right? Try to get everything out of the brain and into that pool. The pool is the modeling space, right?
And you want to make the best effort that everyone could do that freely without being blocked. And that's the challenge, right? The first challenge is the tool. So we try to create simple. So we try to use simple tools. And there's, these are the domain driven design tools, but there was already use story mapping, which is also a great tool in the product management space. You've got example mapping in the testing,
more testing space. I say testing space, but I love to use it as a engineer as well. I
think it's not confined to just one role like business model canvas. Usually product management take the business model canvas, but I had a friend of mine who used it with the engineering team and like he said with management and then compared them and there was so much new things popping up that the management didn't know that there was this API that they can use as a new value stream right so but the business model canvas is also relatively easy if you know your business of course.
So it needs to be simple it needs to be very easy to work with it and I think well did I miss anything. No that's that's that's correct and any for any visual tool can become a modeling tool as Kenny said, it's just about, you know, making sure you don't have to do a lecture for two hours to make them understand how it works before you start using it. Most of it is post-its or something as simple as that, or drawing some figures. So yeah, that's the visual tool that we use. And as I said, we do
that to create that shared understanding, be the Dumbledore. And is all about, then we can start and how everything is connected, because that's the most important thing there as well. Everything is connected in the real world. But in software, you have to, you know, chop this up for different reasons. We have the ability tags, like maintainability and flexibility and scalability and all that kind of stuff is we need to take things into consideration
consideration when you're creating a software system. And once we understand, well, that department has this sort of flow, but other departments sort of tap into that, or they have to do it a bit different, and their constraints are a bit different. Do they have different business rules? What are the exceptions here? How often do these exceptions actually happen? Or they're worth putting in the software or can we continue to do that manually? Which engineers often react to very
badly when I say that. But it's like, if this is happening once a year, why would I put that complexity in my software system? Let's just keep that manual. It's that's still okay to do, even in 2025. Is it worth putting in a software system? How is this going to evolve over time? As I said, business model canvas is mostly to understand the company and the goals and how they get there and how do they see that change and will the software system be able to do that with them.
So then you have to try to find good boundaries that actually allow you to do that. But the fact is that you have a better view of how things are connected. And so if I have to say, okay, we'll make a cut there, it will make this a microservice, we'll create a boundary here. I understand that I'm making an artificial cut, but the process in reality actually continues. So I will have communication between microservices there, 'cause there's no other way if I make that cut.
And then I can also can start asking, okay, but what if I make it slightly different? How would that change the communication in the microservice, between the microsurface. So that's the point where we start to do the design of it. So first we try to understand as much as possible and then we see, okay, what are now good boundaries? Where are we going to cut? And how does that influence the communication that needs to happen between all these boundaries that we're setting up?
Because we still need the business to have a flow that's actually as close as possible to what they actually do on a day-to-day basis there. - Or to add, it might change the flow, but since you have all the relevant stakeholders, as you can imagine, in classic IT, they come with requirements, here's my process, and then an analyst comes with the process and just build it in. The thing is, we as engineers and testers and whatever, We know, oh, but this can be a lot way smarter, right?
If we use this technology with this, we can optimize this process. And usually that dual learning, that's what we call it, right? It's both sides. That doesn't happen in a classic company that's top down because requirements are dumped on the team and they should implement it. But the team, and there's this very good example from an engineer at Amazon that at one point said, You know, I see what people bought in the data and I also see what they also bought.
So maybe after someone bought that product, I can show that same person what other people bought. The analysts were like, stupid idea. We're not going to do it. What, what did he do? He still implemented it. And it's now a function in every, it's now an upselling function in everything. So that you can see, right. That's the power of collaborative software design. You design it together and you need to design it together because each impact each other.
When we come together to make this visual modeling with all the stakeholders, how do I get the people in there? Because there are some engineers who say, I don't care what business say, I want to to just to code my code and the business guys say, I don't want to get in contact with the IT staff because they don't understand really what I what I'm doing. They have a lot of business every day. How what are your arguments to put them together in a room? I have a lot.
I mostly just do it at gunpoint. So this is exactly why we wrote this book. So a first part of this book is about the need for collaborative modeling, but there's tons of books like event storming, domain storytelling, user story mapping that goes into these specific tools and collaborative modeling. Our book specifically also goes into these social challenges. And today, Aveline, the third author, isn't here. She also has a huge background in social science.
these combo of us three working together on this was exactly about that point. Right? Heen and me know a lot more about software engineering and architecture and we combined that knowledge into this book to answer these questions because people love event storming usually. They say, "I've been to this conference and I've done some event storming and I want to do this. And this was me coming from that six years environment, right. Where it was natural to do.
And then coming into my first, uh, job, uh, as consultant came in, oh, we're going to do some event storming. So I got, I just, I just. Right. Send invites like, ah, join me. And then like 20, like five people didn't show up, started out event storming and it was a total mess. It was a total disaster. came home almost crying, like, what is this? I thought I had it. Like, seriously, I have a wife that also has a background in social science. And I'm like, what happened here? And she says, well,
here's some theory and some books and some knowledge. And that put me on the path also on the social science part. So to get people in a room, you first want to create a shared
need for it. So what if it depends on the it depends on what they're dealing with. So if if there's not a lot of collaboration going on going in and putting them into room might not be the smartest thing because people will see it as a self-fulfilling prophecy right they say oh I haven't learned anything at the end well then so what we usually try to do in that situation we We try to do interviews with people and try to understand what are the problems they're
facing and move them towards, "Oh, but maybe it's smart to do X," right? And then move them into a collaborative modeling session. That's option one, having interviews. Option two might be what we call in the book, guerrilla modeling, meaning I've been in a company that did the same. I was actually there to help the testers and they did acceptance testing over the entire landscape, but nobody had a clear picture of what the landscape looks like.
And every time I talked to a different team, they didn't want to come into one meeting. So back then before Corona, I just went in the middle of the coffee corner, rolled out my paper roll and just started modeling their landscape. And then people passed by and they saw it and, "Oh, but Kenny, that's wrong." Oh, okay, can you tell me? So once you're wrong, people will come. So that's a different, that's two different tips. A third one is doing it secretly. So you're doing it for yourself.
Start off with doing it for yourself. You get a better understanding. You will ask more powerful questions. And then eventually people will wonder, hmm, how are you asking these powerful questions? Well, let me show you. So these are three heuristics that I use. I'm not sure if you have.
- I always say like find some, not really sponsors, but sponsors in a way, find some people who are experiencing the same problems that you are, whether you're a software developer, or a tester, or anything else. There's a pain there, right? You feel something like, I just don't understand what they want, and I create software and I have to change it all the time. And I really would like to stop. Yeah, I would like to sort of get it a bit better at the first try.
And there are other software developers experiencing that. And there are people on the business side who are genuinely frustrated that we ask for something and it's not what we want. So try to find those people who are open to trying out new things, create a small group and say, look, I want to try something. I want to see if it works. I just don't want to do this with 10 or 15 people when I haven't practiced yet. Would you help me with it?
And even just to having with those two or three people and start modeling together and experimenting with how you could do that, they will notice that, hey, this is actually really great. Thank you for inviting us. and they will start advocating it. And that way, when someone from the business says, you know, I tried this out and it actually really works, people from the business will be less reluctant to try it out as well. If you do it with a tester, you will have the same experience.
So once people experience it in general, they're very happy about it. It's just that they're reluctant to do that. So yeah. Yes, very, very specific tips. That's great for the people out there, I think. And when we have such a collaborative session, what is more the outcome? Is it the visual thing we have at the end of the session? Or do you think it's more important just to communicate with the other guys there? I would say it's the shared understanding, the knowledge sharing that has happened.
So the outcome is that you have a lot of post-its on the wall. But one of our mottos is that you should throw them away. It's about getting to that shared understanding about being better informed on how things work, understanding the business rules better, understanding, you know, 80% of the time this will need to happen and then 15% of the time
we actually will have to do that in a situation. So it's the knowledge you gain from it. But we do say that we have a template in the book on how you can prep your first session, because you do need to communicate this very well to other people. You want to sit down and think, okay, what do I want to achieve? What are my goals? Which process or which part of my software system do I no longer understand? So I want to create a group of people and I want to see from a business
perspective, how is this supposed to work exactly? So that's a goal you can set up. So make sure that you're well prepared and that you have a clear goal in mind and that you inform everyone of hey, this is what we're going to try to do. People like to be prepared. Walking into a meeting and having no idea what's going to happen. I don't know about you, but that kind of freaks me out.
So give them the idea, tell them everything, right? This is what's going to happen, this is what we're going to do, this is what you need to bring your brain most of the time. Yeah, but just make sure they're in as informed as possible. And this is what I hope to achieve in with this. And so everyone is then at the same page where you're actually having the session and and why you're in that room. And that helps a lot.
- When I look at the organization of such a collaboration session, there are two questions which come to my mind. It's the first, how long is typically such a session? How long can we be productive on such a topic? And what is a good frame to repeat such a session? Or is it a one-time show And then we are all in our business again. - Yeah, so sorry to say this, it depends on what the outcome is. So we have, but I can give you a few examples.
So there's one session that's called big picture event storming. The outcome is there massive learning, understanding the bigger picture of your company. So what's this company doing? Where are the software systems? And that's massive learning, breaking the silos, knowing what's the most evident thing to work on now, right? Because we can vote at the end. And especially as a consultant, I use this.
If someone brings me in for a project and I do a big picture event storming, and they say, well, you know, on the right side is the problem. And then they hired me for the left side. I'm not doing the left side because it's not like the most prominent thing that everyone wants to work on. So that's a big picture event storming, it takes a day. From that day, I could also distill and decompose further.
So I can extend that for a couple of days, but this is what we call a design start, or there's many words for these workshops. However, you can also make it small. So a good friend of ours, Andrea McNorski, created this thing called, um, who now I forget it. I thank you. Heen. Wow. I forgot that. And what's he did. And I've did this in the past and that takes one hour, maybe two every three, four weeks.
Um, you get everyone from the team into the room and you ask them, okay, what does the architecture look like? Can you visualize it for me? And you can do that with C4 modeling, for instance, if, if the people are known this first time I did it, it was just stickies and boxes. And that took one and a half, two hours. So it was half hour, everyone for themselves. And then we tried to merge all these things and we, and we literally merged their view of how the architecture looks.
One and a half to two hours. Now, if you take things like example mapping, even, typically from an example mapping point of view, you take something from the backlog and you want to do that for 20 minutes, because if it's not clear within 20 minutes what the acceptance criteria are, you need to discover more. So after 20 minutes of doing that, okay, what's clear, what's not clear, what needs to be discovered?
So again, it can be like a couple of days in a row, or it can be just every so often that in a retrospective, sorry, refinement, I don't do Scrum anymore that much. So I'm kind of confused for a reason, because I think this would be a lot better if you collaborate more often, coming back to the previous question, I might not need documentation, I can go straight away code that out. And I've seen teams do this, right?
They collaborate and then they code, come back for feedback, collaborate some more code, and they don't require all these scrum things anymore. Retrospective yes, but they didn't do refinements. So that's why I'm a bit confused with the terms, but you could do that if you're still doing this.
I wouldn't go from scrum all to what I just say, just taking steps, take your refinement and try to do some example mapping to see, Hey, does this fit, invite a stakeholder that put it on the backlog, do some example mapping. The example mapping is the easiest one of them all in my opinion, because all you need to ask is, can you give me a specific example? And that takes 20 minutes. Try it out. 20 minutes last. See where that gets you. Great. I hope that helped. Very, very great insight.
And I liked the thought about doing the collaboration on one side and then going directly and building the stuff and then going back to collaborating because a lot of steps we will build between are always transfers from knowledge to another ticket, to another ticket, to another view and so on. And there's a lot of things we can lose between these two steps. So it's a very, very pragmatic way to do it and to work in agile like I understand it was thought maybe.
Yeah. Yes. So you say as was thought, we're also domain-driven design practitioners. There was already Agile when Eric Evans wrote the book, but he was very clear. He wants to have a continuous conversation with stakeholders. And now I feel like the conversations are in a refinement or in a demo, right? But he wants, and that's how I used to do it for six years. I could just walk to my domain experts or stakeholders to have that continuous conversation, that feedback loop.
And in my opinion, yes, that is the essence of agile because you constantly want to inspect and adapt, collaborate something, try to design something, implement it, see what it does, come back with that feedback and have that continuous conversation together with your stakeholders. So yeah, for me, that's more agile than Scrum that I see nowadays. Yeah, Kenny, thank you very much for all this insights into the collaboration of how we can design software.
I think there was there were a lot of very specific parts we can take in our daily business and to start with this topics. So thank you very much that you have been here on the show in the podcast. And up from now when we record, the OOP is still in the future, but maybe when we play the episode, it will be in the past. So I wish you all the best for the OOP and a very great tutorial and workshop there and a lot of nice collaboration with the other guys. Thank you. Thank you. Thank you.
Bye. Bye. Bye. Bye. Bye. Bye. Bye.