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, Hien.

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 got into other companies and I'm like, "Huh?

What are you doing here?

But I need to understand the business in order to help you." And this is exactly what Heen was telling.

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.

And for me, they were using Scrum.

So I was like, "Okay, you're using Scrum, right?

So you have the same understanding, but no." And for me, that was a problem that we got a lot of a telephone game from higher up, from analysts, as Geen said.

And from there, my journey took on to understanding more and trying to teach this collaborative modeling the way I did it for six years into other companies, which I still, to this day, I find companies that lack.

Every time I go in, go into a team and help them understand the business, Oh, and then they're like, Oh, you're like a business analyst.

I say, well, I do.

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.

So, uh, but I understand it when I do that.

In my first six years, it was like normal to talk to each other and was a good setting.

But having these isolated departments that, that clashed a lot.

And that took me into much more social.

So yes.

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, 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, 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?

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 so 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 so 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 the 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 ahead.

You were going to focus on refactoring here, here and here.

And then I went to talk to to hire 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, because this is very interesting, because I go to do our software departments, and they're going to focus on improving the old products.

And you go to the higher management, and they're like, no, no, our focus is really on 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 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 that 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, yeah, I think that's it.

Right, Hien?

You're missing the, to create a shared understanding.

Yeah, yeah.

That's the problem.

Which is the part that tries to tackle the miscommunication mostly.

So yeah, it was a very boring definition.

But as Kenny said, there are a couple of important things.

And the first thing is that we try to get rid of the silos.

We try to bring people into the same room or virtual room there.

And we try to get them to talk to one another instead of having these documents that's written by a business analyst and handed over and handed over and handed over.

So we try to sort of bring everyone there, including the business analyst, because they're 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, you tell me how you do your job, tell me which departments you have to communicate out there is who tell us everything.

And we're going to make that visual.

You're gonna write it down, because I don't know if you have ever been in a meeting, Richie, where things are just, they're just talking around and around and around.

Yes.

Very annoying.

So we tried 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 gonna let Kenny tell you how we do that, so I don't gobble up all the time.

- Yeah, so it's including all the stakeholders.

By the way, we say stakeholders, but that can also be the developers or engineers or testers or analysts in the team, right?

they're also stakeholders in a way.

So the way to describe collaborative modeling 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 does concern if you're in a cinema where which we write about is like a a a place got reserved right so it's relevant for the place got reserved so what are then you 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 like Archimede, which I used in the past, or other modeling tools, they're very constrictive, right?

They have these certain dialect that you need to use, and I can never know which the arrow is which is filled in or which is open.

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 Gumbeldor 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 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 used story mapping, which is also a great tool in the product management space.

You got example mapping in the testing, more testing space.

I say testing space, but I love to use it as an 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, Gin?

No, that's correct and 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 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 once we sort of understand what the domain really 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, and 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 operating the 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?

Are they worth putting in the software, or can we continue to do that manually?

Which engineers often react to very badly 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?

He would said business model canvas is mostly to understand the company and the goals and how they get there.

and like, okay, 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, you 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 microservice?

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, 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, and show that same person what other people bought.

The analysts were like, "Stupid idea.

We're not going to do it." What did he do?

He still implemented it, and 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 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'm doing.

They have a lot of business every day.

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 and this combo of us three working together on this was exactly about that point, right?

Sheen 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 oh I've been to this conference and I see 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 job as consultant came in, "Oh, we're going to do some event storming." So I just send invites like, "Oh, join me." And then 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." So what we usually try to do in that situation, 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, "Kenny, that's wrong." "Oh, okay.

Can you tell me?" So once you're wrong, people will come.

So 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 how are you asking these powerful questions.

Well let me show you.

So these are three heuristics that I use.

I'm not sure Heen if you have...

I always say like find some not really sponsored, but sponsors in a way, you 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.

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 like 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 really, 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.

Yeah, some 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.

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 80% of the time this will need 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.

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.

You're 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.

(laughs) 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.

But just make sure they're as informed as possible.

And this is what I hope to achieve in this.

And so everyone is then at the same page where you're actually having the session 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.

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, yeah.

So, uh, sorry to say this.

It depends on what the outcome is.

So we have, but I can give you a few examples.

So, uh, 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 the, 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 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 Magnorski, created this thing called, now I forget it.

Thank you, Hien.

Wow, I forgot that.

And what she did, and I've did this in the past, and that takes one hour, maybe two every three, four weeks.

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 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 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 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 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 take it in 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.

or do some example mapping.

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.

-Hope that helped.

Very great insight.

And I like 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.

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 as it was thought maybe.

Yeah.

Yeah.

Yes.

[LAUGHS] 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, he 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 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.

Bye.