Collaborative Software Design

Intro

Xin Yao: Welcome, viewers, listeners. Welcome to the "GOTO Book Club" , a new episode. Today, it is a great joy that I am joined by Evelyn Van Kelle, Gien Verschatse, and Kenny Baas-Schwegler, the three fantastic authors of this new book called "Collaborative Software Design: How to Facilitate Domain Modeling Decisions." I've just read the book, I couldn't get my arms down. So, it's a great pleasure that I've got to interview these three fantastic people.

So, just for people who might not know you already, can I ask each of you to use a couple of minutes just to introduce yourself? Where are you based? What's your background? And in particular, how did you journey into this field of collaborative modeling and design? Was it second nature for you just from the very beginning of your career, or did you make any kind of surprise discovery on the road that led you here? So, who would like to start?

Gien Verschatse: You can do it, Kenny.

Kenny Baas-Schwegler: Evelyn.

Gien Verschatse: Oh, yeah, Evelyn. She's the first on the cover of the book.

Evelyn Van Kelle: Yeah, well, that's in alphabetical order, right? But, okay, I'll start. It's fine.

Xin Yao: Yeah, totally democratic, yes.

Evelyn Van Kelle: That's not a problem. So, my name is Evelyn Van Kelle. I'm based in the Netherlands. Well, almost Belgium actually, so I'm in the middle of Gien and Kenny. And I mainly focus on behavioral change as a consultant and trainer, so I have a background in social sciences.

I did not necessarily expect to end up writing a book that's called "Collaborative Software Design." But here I am, and I'm actually enjoying it because I truly feel like after a few years here in this field, that there should be more social scientists in the tech world or the IT world because I think it really strengthens each other and it really helps create a socio-technical environment that we want to do.

When we do collaborative modeling, the tech part usually goes pretty well. Of course, you have challenges and things can go better, but what usually goes wrong is humans. And that's where I specialize in, so humans, and their social dynamics, and the relationships, and how everything works. So, collaborative modeling is a great environment to observe that and to work in because, well, humans and behavior and their dynamics are everywhere.

So, there's a lot that we can do there, and if you are able to facilitate and manage those well, then I think your outcome will be better as well. So, that's also what I really like in our book, that this balance is really there. Yeah, and that's what I focus on, not just in the book but also in my work.

Xin Yao: Indeed, it is a very socio-technical book. I guess, Gien, your name is next on the cover.

Gien Verschatse: Yes, it's next on the cover, so I'm next. Yep. Hi, I'm Gien Verschatse, for the viewers there. I'm from Belgium. I'm a software consultant currently working for Aardling, where I specialize in software strategy and design. But I started my career as a programmer.

When I started my job, I was very much surprised with how things were done. I kept thinking there has to be a better way, right? I was just handed a bunch of requirements, and I didn't really get the requirements. And the first project I ever worked on didn't go that well. So, there was something in my mind always saying, there has to be a better way.

And I recently started as a teacher, studying to become a teacher, which I didn't finish and went into computer science. But there we actually were told that if you're genuinely interested in your students, even if you taught something like informatics or Dutch, which were my subjects, then you'd get the respect of the students.

And so I did something similar in my second project. I just went to look on the floor. How are people actually doing their day-to-day job? And I felt that that worked a bit better to understand. And then eventually, the DDD Belgium meetup started getting popular, and I got introduced to Domain-Driven Design. And with Domain-Driven Design, I got introduced to collaborative modeling and all that kind of stuff. And I was like, yeah, my gut feeling was right. There is a better way to do it, and there's actually an entire community here who agrees with me. So, that's, sort of, how I started my adventure. And it ended up with the book.

Xin Yao: You ended up teaching in a different way than you expected.

Gien Verschatse: Yes. I'm glad that I went back to it. I'm glad I can do the training and the workshops, and I write some blogs, which is also teaching in a different form. And the fact I always thought that those three years were, kind of, wasted. But as it turns out, 15 years later, not that wasted. I can still tap into that knowledge once in a while.

Xin Yao: Nice. Nice. Okay. So, we have the one and only Kenny left.

Kenny Baas-Schwegler: I'm Kenny Baas-Schwegler. That name comes from my partner. So, I live just outside Amsterdam with my two cats, Lulu and Mr. Noodle, and with my partner. I need to say it should be that order at home, right? So, cats are important.

I actually started out studying electrotechnics, making embedded hardware but also writing the software for that. So, that was my study. So, with the hardware, you cannot really just think, oh, let's do this. No, you need to think about how things are going because once it turns into hardware, it's very hard to change.

So, getting that, getting into IT, I was also quite surprised, as Gien Verschatse said, right? I was like, okay, I was taught to model everything out and then go do stuff with it, and that was not the case in software. But I was very lucky. I got into an environment for six years that actually already practiced, sort of, Domain-Driven Design, already did microservices, DevOps. I got in. And within two months, I got a... It was asset management, so I got to study asset management, a two-day course to understand the business. I had my users just around the corner, so they actually sometimes went up to me and looked at my code. So, all this was very natural from the start, from the first six years where I learned programming but also eventually learned to be an architect, to be a tech lead.

Actually everything from the get-go, I was very privileged in that environment, which I still to this day go into because I'm an independent consultant now. With my training and my consultancy, I get environments that are not like that. So, the first time I went out, I was like, "But... but... but... Huh? Why?" Right? I was just used to just talking with my, well, users or other people, information analysts that were all part of my team, and model it out together.

So, well, early on, I got to experience Domain-Driven Design. I was a very early adopter of event storming. And from that point, when I started doing consultancy, just before I met my current partner, Vanessa, and she's a social scientist. So, she has a background in anthropology, so I went out. And I came from a team that worked very well. And then I went out doing consultancy, got into my first event storming, and it was horrific. I was like, "What is going on here?" Well, as Evelyn says, humans. So, when I got home, I told this to my wife. My wife says, "Well, did you know?" And then I started diving into anthropology and got into Deep Democracy, which came roughly out of anthropology as well. Social science and Deep Democracy is really about making better decisions. It's not an IT thing. It's really more how do we, as communities, make better decisions. So, thanks to her, I got to that path.

Eventually I met Evelyn through DDD Europe, met Gien through DDD Europe, and actually, yeah, we got together, got the same challenges from a different perspective, and then, yeah, we started writing the book about our experience from all different, well, areas, I might say. So, for me, collaboration is important, so I like pair programming, I like ensemble programming. So, yeah, I still like writing a book with other people, but it is challenging, I must say, but very, very much a learning experience for myself so…

Challenges of Writing a Book Collaboratively

Xin Yao: That's so fantastic. I mean, the three of you, it looks like you have really different points of departure. I mean, Gien and Kenny, you both work with DDD, but still you started with collaborative modeling in different ways. I'm so curious. I, sort of, talked with quite a few authors, especially in the DDD community, and people tend to tell me, "Oh, my God, it's so demanding to write a book. You can't imagine," right? So, that's one person, right? So, you're three. So, I can't help wondering... So, obviously, you decided to write a book together. That's a big decision. Did everything go as expected in this collaboration? And would you mind sharing some of the stories, maybe anecdotes that...? You know, just to use these things you mentioned in your book, did you have, kind of, conflicts? Did you discover each other's shadows? Did you...

...sort of, have to deal with some decisions that only have a majority vote? So, tell us a bit.

Kenny Baas-Schwegler:  I always tell this anecdote because, yeah, the book is about collaboration, "Collaborative Software Design." So, writing a book collaboratively is also natural, right, because you experience what you're writing.

So, I remember at one point, I got feedback from Gien actually. And I told Gien, "Whoa, that's some rough feedback, right?" And she was like, "Yeah, yeah. I was very scared that it was very low." I said, "But it's good. I like that because I know we have the same goal," right?

So, we talked that out and we said, "Well..." And we get into our own inner shadows because I was like, "Well, it hurt me in a way, but it's 100% true." I had this quote from James Acaster. He always says, "Never in my life have I been so upset by something that's 100% true." And that was all the time writing the book. But that's good because that is my inner shadow saying, "Okay, why does this actually hurt me?" But I know Gien has the same goal as me, so I know she does it in a good way. So, we talked that over.

And for me, that's one of the main things in this book that I remember vividly like, "Okay, that's what we write about in the book, and we actually experienced that while writing the book." And it got way better because of it actually. That's why I loved writing that book. The conflicts made it very good. Those make it better.

Evelyn Van Kelle: I think that really our differences, because like you said, we are very different people, but I think our differences really made the book, right? I mean, we are different in personalities but also in terms of expertise and that really made the book. So, I always told my friends and my family when they were asking like, "How's it going? You never got into conflicts?" And I'm like, "Yeah, but we can fight very well together."

That's a very true thing, right? I mean, conflict is not necessarily a bad thing. And we can have really healthy, constructive conflicts together. And that really helped. And, yeah, in terms of shadows, mainly my own shadows, I ran into those. And my shadows have a lot to do with the ranking part because I see Kenny  and Gien as very knowledgeable, very, very... Well, they are experts in their field and I'm too, but I look at them and I think, "Well, they know way more than I do." And now I have to add to that as well.

I had to fight my own shadows a little bit. But I think because we also very...we know each other pretty well by this point. I mean, if you write a book together, you get to know each other. So, it also helped us in... We all observed what was going on, and we could talk about that. So, that made our conflicts very productive from my perspective.

Gien Verschatse: No, it was. It's like I think one of my shadows, or it's more of a demon at this point than it is a shadow, is that all my life I have been told that I am very rude. I never have the intention to be rude, but apparently, something about the way I express feedback or opinions when asked for it struck people as very, very rude.

And also, like when I was 25, I invested so much time in how to get better at communicating, how to stop being perceived as rude, and years I dedicated to that. And then so, for me, I often asked Kenny and Evelyn  as well, "Was it rude? Did I insult you? Like, is this rude?" And then Kenny Baas-Schwegler responded in the nicest way possible. And it was like I'm still using a lot of euphemisms and worried that I was too rude, but at the same time, it's like, do people here finally appreciate something about me that other people have been, sort of, bashing on for years in my life? And that was a really nice experience to have actually.

Recommended talk: Creating Local-First Collaboration Software with Automerge • Martin Kleppmann • GOTO 2023

Understanding Shadows and Their Role in Collaboration

Xin Yao: I was just thinking what makes the three of you sound very different from some of the contexts I tend to observe is that you are okay to stay with the discomfort of seeing others' shadows and even demons and to use your own word, to shine a light on these dark sides. You know, for people who don't have this language, right? So, I was just wondering how... Maybe you can explain what a shadow is. I'm just segueing into this topic directly. What is a shadow? Why is it important in collaborative modeling decisions in software?

Gien Verschatse: So, correct me if I say something incorrect. But yeah, we grew up in different environments. We have different experiences throughout life. And some of that becomes trauma, and you carry that around, right? And you get this perspective on the world, and it's all from your experience and less pleasant things from trauma.

And so, when you put people in a group, it's all there. But you don't see that, right? I mean, if someone is physically ill or has a broken leg, or they have something there, you can see that. But sort of the psychological trauma that people have, and the experience that you have, you can't see it. And that is why we, sort of, thought about it and came up with the metaphor that things live in the shadows because you can't observe them but they're there. They're very much there. Just as your shadow is there all the time, that trauma and that view on the world is also there in that room with all those people. And they're all very different.

And often when you ignore it, it becomes worse and worse. And so we say that shadows actually turn into demons, right? Because demons live in the shadows. And then there are very ugly things and you can't see them but they're still there, and that's, sort of, where those two metaphors come from, right? Things live in the shadows. And if they get back, they become demons because they're festering there and nothing is done about it.

Evelyn Van Kelle: Maybe to add, because also where the behavioral science comes in, because the shadows are there. We cannot see them, but they are influencing what we do. So, because of what we've learned and experienced in the past... We learn from consequences. So, if something we do is experiencing something bad, we won't probably do it again in the end.

So, if we have that enough, then for example, if you've always been told that you are not the smartest person in the room or you always felt like you're not the smartest person in the room, then that might be living in your shadows. And it might cause you to say, "Well, I will just stay quiet because everyone else was way more knowledgeable." So, the shadows are not visible, but they are heavily impacting all of these group dynamics, and that's a very, very important part of what's happening in a group. Well, you have to. You want to shine a light on them because you want to understand where everybody's coming from. And if you shine a light on them, and these demons or these shadows become more visible, then yeah, you can address them, and you can manage it, and you can facilitate it. So, it becomes, well, probably more effective .

Kenny Baas-Schwegler: And taking that a bit to software design and architecture, it's also very relevant where I had a very good experience for six years building software, event-driven architecture, and everything. So, I knew this worked for me. And here I have a bad experience with. So, if you do something like... Well, we were working with 140 microservices. It worked but I had some very bad experiences with it, so that changed me.

So, in my shadow... Well, it's in the shadow of a new group. They don't know this. They don't know my experience. So, I would always subconsciously try to get people to work first on a monolith instead of microservices because I know how hard it is to maintain and upgrade microservices. And that's what the shadow means, right? If I don't add that wisdom to the group, my behavior would always be to try to, sort of, nudge people towards building a monolith. But that only comes from my experience. And that really, to be honest, especially architecture, it's not based on facts. It's based on one person's experience, not mine. There are other people that have the same experience, but there are people that have experience in microservices. And if we don't talk about both of our shadows, about our experience, then it gets all messy when we try to do decision-making, right? If we don't talk about our previous experience, that will turn into a problem actually. And that's a little bit towards software design, right? That's important. Well, decision-making will be, well, messy, let's say.

Xin Yao:, I totally see that also in my own experience. We are in a complex world. All these decisions are really... Not one person is able to make them based on individual knowledge, right? If we want to get everybody's big, best potential and all the knowledge out and people are holding back because of their shadows, or people are really upset because the demons came out, then those decisions would not be as good as we would like them to be. And therefore, the time we invested in collaboration will not be worthwhile.

One thing, in relation, I would like to explore, the concept of collaboration itself. I mean, if you look at today's agile world, everybody is almost...everybody's doing agile, kind of agile development, and nobody would argue against collaboration. But then people tend to have different interpretations, maybe mental models about what collaboration is. Some people might say, "Okay, we have all these rituals. We do sprint planning. We do backlog refinement. We discussed these stories in Epics. Are we not just collaborating?"

And I've heard developers say, "Are you saying that we are supposed to go into the problem space and this strategy space and talk about business decisions? Is that even my role? Why do I need to bother, right?" So, all these kinds of different perceptions about collaboration make me think, what is real collaboration for you? Could you let me know what we should observe in a working session where real collaboration is happening?

Evelyn Van Kelle: I think you were spot on when you said everyone has different interpretations, right? Like collaboration, just all of the other values and principles from the Agile Manifesto, they are all very big container concepts that have a lot of room for interpretation and misinterpretation thereby. So, the most important thing is that, in the context that you're in, you all should have the same interpretation or definition of collaboration. So, for me, there's not one definition, but it depends on the context that I'm in.

And then we have to be very explicit about it, also in terms of what it means in terms of behavior, right? Like you said, are we supposed to do this and this? Well, if you don't know, then apparently you missed something there. So, for context, there's a different definition for me.

In the context of us three writing a book together, collaboration for me meant that we... Well, we had this whole Miro board where we did some collaborative modeling actually on the book, but we recreated structures on every chapter, and we created frames for dialogues of the characters in the book. And for me, the collaboration I feel like we should be on the same page about all of the email templates basically that we have on this board, and then we can go start writing, and then we have some agreements on how to give each other feedback.

In that context, it had a very different definition than when I'm facilitating an event storming workshop, for example, because then you have a different definition that you need there for collaboration. So, yeah, I'm not sure about Gien and Kenny, but I don't have one definition. It really depends on the context. And in that context, everybody needs to be on the same page of what it means, and it can mean different things in that sense.

Kenny Baas-Schwegler: If I can add in the context of our book, if we call "Collaborative Software Design," what we really mean with that is that a team building software, right, that can preferably exist not only by developers but business analysts, testers, whatever you need in order to fulfill a business goal or fulfill a problem and let that team collaboratively design the software together with the stakeholders that know the most.

So, as an example, what we see nowadays is that a software team has a PO, and what I usually see, especially in companies that are not used to building tech, is that PO is usually just creating user stories that the product manager gives that PO.

Now, the problem is the handover here. So, the developers, A, don't know really about the true problem space. As an example, let's say someone comes in and they say, well, I want you to... Well, this example is a bit in the book. I want you to build a reservation system and make it so that reservations cannot have one seat in between, right? So, then that would be the user story, and then a software, and then they get the requirements. And then they think that's the problem space. But actually, a PM already thought about how I can solve the problem of people willing to go to our cinema, willing to have good seats in our cinema without them leaving gaps in between. So, we need to sell the most seats in a cinema, but we also want people to have good seats.

So, someone, a product designer usually, or a UX designer, already thought of a solution to the actual problem, and that solution comes into a PO and then the developers get totally lost in what's the real problem. And then they're not building the correct solution most of the time. So, for us, collaboration means putting developers with the product managers, or the UX designers, user researchers, and let them design the product and the software together. So, in the context of "Collaborative Software Design," as in our book, that's what we mean with collaboration, and we do that through collaborative modeling actually.

Recommended talk: How Architecture & Culture Go Hand in Hand • Eoin Woods & Charles Humble • GOTO 2024

The Challenge of Brownfield Complexity and the Role of Collaborative Modeling

Xin Yao: Right. And that, sort of, ties directly into this concept in Domain-Driven Design called ubiquitous language, isn't it?

Kenny Baas-Schwegler: For me, that was very, very normal when I started working, that someone came up to me and said, "Hey, I need you to change this." And for me, it was normal. Oh, I know exactly this. The moment I stepped outside that, people were using the term that when I talked to the business, they didn't use. And I'm like, "Huh?"

Xin Yao: Right. I think there's this one-liner in your book, somewhere you wrote, "Driving design by understanding the business." And that is so true because eventually, like Brandolini said, what's going to the production is the understanding of the developers. And what do we want that understanding to be a narrow understanding of a user story, somebody else wrote, or the real empathy and compassion for the user's pains or needs? What kind of ambition levels? So, I guess that depends on how collaborative we are. And coming back, again, to the quality of those decisions and how good we are at harmonizing each other's knowledge and shadows and all these sorts of things, right? So, that's so true for me.

You mentioned, Kenny, this... I think you called it BigScreen, this example, this running example in the book. And for me, this is, kind of, even a complexity times three, multiplied in a way, because it's, kind of, a brownfield complexity. You have a legacy system, which most companies do. And if they don't do it now, they will. In a couple of years, they will have legacy systems, and that's about modernizing them, keeping them in sync with the business needs and the user needs. Could you unpack a little bit what makes the brownfield complexity tackling more challenging than greenfield development and how could collaborative modeling and design help in this context?

Gien Verschatse: So, with greenfield, it's this idea that there is nothing there, right? There's no software. And so we call it the brownfield when there is software there. And there's, sort of, this thing that most of the time it is a less than optimal software that is there. And so I think one of the most challenging things is that brownfield has an active solution, okay? And so it's very hard once you have seen a solution to something, it's very hard to let go of that, right? Because your mind is now very, sort of, used to what you see in your code and how you see your software system and how you divided it originally.

And even though you know that it has severe flaws and it's not optimal, just to stop thinking in that solution that you already worked on is very difficult. And I think that is one of the most challenging things when you want to do a redesign. We want to, sort of, look at the ideal situation and no longer think about what is already there. Subconsciously, you're always thinking about what is already there.

And so that's also why in Domain-Driven Design, you have this thing of problem space, which we say like, okay, you have your solutions and that's great. But also, we want to understand the original problem again because that software system is a solution to a problem, and you need to verify if, well, that problem is still the same because that solution was created 10 years ago. And, well, technology evolves all the time, businesses change, markets change. So, what could be an ideal architecture right now just isn't the same as 10 years ago. So, we want to go back to that original problem.

And I think collaborative modeling really allows us to do that, because you can take a bunch of domain experts and other stakeholders and you put them in the same room. And then, as a facilitator, you're sort of like... We go back to how your business processes work. We go back to how it all functions. And we ask questions when we run into, okay, but this is a solution. We dig deeper and we try to find out, "Okay, but what's behind that? What kind of problem do you have from a domain perspective that actually was solved this way?"

And so I think the visual... I think, for me, visuals are a very important thing in collaboration. I don't think you have collaborative modeling if there is nothing visual there. It makes it very easy to show how everything is working. And then to dig deeper into details and go back to, okay, but originally, what were you actually trying to do here? Because I want to know the problem. I don't want to know the solution.

Recommended talk: Organization: A Tool for Software Architects • Eberhard Wolff • GOTO 2021

Understanding and Managing Technical Debt through Collaborative Decision-Making

Xin Yao: I guess that sort of ties back to Evelyn's original point that everybody is on the same page. Maybe as the legacy software evolved, everybody was getting more and more not on the same page. And now you need them to be on the same page before you can say, what's the change? What should we change? And that's exactly what you're describing, right? And I think this is, by reading a book, I got a newer understanding or maybe an even more sophisticated understanding of what technical debt is because originally, I thought it was just the sloppy decision that became debt. And you basically tied that into, kind of, an architecture decision-related debt. Could you share with the viewers and the listeners what your definition is about technical debt?

Gien Verschatse: Yes. No, so to sidetrack a bit, I have this hobby of decision-making theory, which got out of hand. Now it's in the book. And so I have been looking for good definitions of decisions because I think, in general, people are not very good at making decisions. That was my impression. It's a very hard sell because everyone thinks they're amazing at making decisions. And in, sort of, the context of economics, so how they teach decision-making in economics at Stanford University, I bought the textbooks. They're very expensive, but I bought them because I was fascinated. And there they said that a decision is a process, and there's no point in time where before and after. And that's how most people see decisions. It's just a process, and you have a starting thing, which is analyzing and generating options and then getting information and looking at the preferences and all that kind of thing. And when have you made a decision? When there is a cost in being wrong.

And they say that's the moment you can say we really made a decision. There's a cost in being wrong. And then the question is with technical debt as well, if we go forward, at any point in time, you can change the decision if you're willing to pay the cost. If you pay the cost of being wrong, you can change any decision that you want. So, if you pay the debt, you can change. And I've used this with customers a few times already, and there's going to be a cost along the way. we pick this option about all these things, you'll have a cost there and you will have to pay it. Either we pay it right now or we pay it in a year, but you will pay that and be aware that it is.

And I find that it resonates with people a lot better if you say that, "Hey, we'll just pay a cost and we'll be able to change our decision," because, yeah, this technical debt is so vague and it's a debt but it never gets paid off most of the time. While if you want to change a decision, I mean, people change their minds all the time. And it's like there's a cost but please change your mind. I don't really care. I'll pay for it.

Xin Yao: Yeah. And then a collaborative process that is leading to better decisions and with Deep Democracy and being aware of ranking and all these, they will sort of... Well, I guess we still make debt in some way, but it's probably less indebted with less interest to pay in the long run because we're the problems we're solving and we have this shared understanding, right?

Gien Verschatse: There's less uncertainty. So, we try to get rid of the uncertainty in making a decision. And the less uncertainty there is, the more chance it is that you pick the right alternative of all the things that you had. And so there's a higher chance you'll never have to pay the cost because you chose a good option out of all the options that were there.

Kenny Baas-Schwegler: To add to that debt, what I usually see is that, if one person makes a decision, that doesn't deal with the side effects of the debt, which is usually a PO or a manager saying, "We're going to go left." And then the developers get called at night because it's a crappy decision, right? So, what you're mentioning with Deep Democracy, we're trying to democratize that decision-making so that it's not only a PO that makes the decision, but the whole team or the whole group you're doing collaborative modeling with because that's the goal of modeling, trying to, A, make exact... Who can make the decisions and who's allowed to make the decision. And B, how can we add people to do that or how can we add people or bring people into that decision.

So, we're not saying every decision should be democratic. There's things like a consent-based chapter in the book about decision-making. But the thing is you want to get people along with that, and you want to know, okay, if we're going to this alternative and we have this trade-off, how can we actually neutralize that trade-off?

To make it explicit, we once made the decision to go trunk-based. There were two people not willing to go along, and we asked them, what does it take for you to go along? And then they said, well, we don't know how we could do this in the frontend. We need feature flagging for this, but we don't know how to do this. So, if we first can figure that out, I'm all for it.

So, then we added that to the decision, and then you remove some of the resistance to that decision. And it becomes more a sustainable decision because everyone now goes along with the decision. The team was even battling with each other when this needs to be prioritized higher now on the backlog. Great, right? It created a whole team together towards the same goal instead of the PO deciding what the priority is and the developers just being an IT factory. No, it was a whole decision together with the PO.

Recommended talk: Domain Storytelling • Stefan Hofer, Henning Schwentner & Avraham Poupko • GOTO 2022

Moments of Fulfillment in Facilitation

Xin Yao: That's so true. And I guess we touched upon a lot of these... I guess, in collaboration, you have this six-step process. There are some techniques that are more tangible, but then there are these softer, intangible aspects, as we talked about with ranking. Kenny, the situation you're mentioning, like somebody with a higher rank with decision power, and then how do we harmonize that, and the bias and conflicts and all this like Everlyn and Gien talked about? I guess we need, kind of, a facilitation, and the three of you have done a lot of facilitation.

So, toward the end, we're more than halfway through, I would not like to go before I've asked you this question. In your experiences as facilitators, when do you feel most alive? What kind of breakthroughs or moments when you're facilitating a workshop or working session that make you feel, yes, I got this and I really made a difference and I feel great? Can each of you share something?

Kenny Baas-Schwegler: Before we share, I want to make one thing explicit about the facilitator role, right? That can be everyone in the team. So, everyone in the team can facilitate. Even though I'm not an official facilitator and I'm part of a team, the book explains how you can even facilitate for yourself. So, it doesn't necessarily... If you hear this, oh, do I need to become a facilitator? No. If you're a developer in a team, or you're a tester in the team, or whatever role, or a business analyst, you can become that facilitator.

Xin Yao: Thank you for pointing out my cognitive bias. So, they lead that notion that there needs to be a central person in the room. You can be that. But back to the question...

Kenny Baas-Schwegler: Shall I start?

Xin Yao: When do you feel most alive? Yes.

Kenny Baas-Schwegler: Well, I feel most alive when a session ends and they're not dependent on me anymore, because mostly during a session, you constantly have the feeling people are looking at you, what to do next maybe because you're put into that rank of facilitator. So, it's also a bit of... What's the English word? Melongelic?

Gien Verschatse: Melancholic?

Kenny Baas-Schwegler: Melancholic feeling. I've been in that situation where I facilitated as a... I was in an architect role enabling a team. And that team, after three months, finally had a breakthrough. They got their model to fit just right. And then a few weeks later, the person came to me and said, "Kenny, this is amazing. We just implemented it. I had a new change and normally this would last six weeks, and now I'm done in six hours." And I'm like, "Oh, this is great," right? They were not dependent on me anymore. They could go along by themselves.

But it's also a little bit sad because I wanted to be part of that experience of developing. So, if I can get that, right, because my whole goal of doing this is actually to make it better for the person I actually want to be, which is the developer in a team, that lives in a team where I started my career, right, which is a team that facilitated themselves and each other towards that goal. If I can create that team, I'm very happy, but I'm also a bit sad because I wanted to be really part of that team and developing but yeah...

Xin Yao: I can feel you. So, first, you make yourself useful, then you make yourself redundant.

Kenny Baas-Schwegler: Yes.

Xin Yao: Okay. So, let's go to Evelyn.

Evelyn Van Kelle: So, I agree with what Kenny says, because it's always a nice feeling when you become redundant. But in another aspect, I feel very alive when I start to see and observe all these behavioral patterns, right? So, when I see humans at their best like I see everything happening and I see conflicts arise, and polarities, and ranking, and bias. And then I start to observe them, and that makes me feel very good, although that might not sound very nice, but it makes me feel really good because I get a sense of what's going on in the shadows and what could improve the session in that sense. And then when I'm really feeling alive is when the group itself starts to observe what's happening, and they start to become more aware of their own behavior and of the shadows that are living in the group, and they start addressing it. Then I don't have to do it, but I'm standing there, and then someone observes something and shares that with the group in a very objective way. And then I'm like, "Yay."

Xin Yao: Right. So, what I hear you say is, kind of, like you feel really alive when you see the divergence process, bringing up the shadows' divergences. And then you know that in that moment, there is a higher potential for us converging at a higher quality because we feel safe and we have talked about these things. That's so true. I almost got goosebumps when you said it. Gien, what makes you alive when you facilitate?

Gien Verschatse: It's a tough question for me because facilitation does not come natural to me at all, so it's a difficult question. But I think that after the end of a session, if there are people in the room there and they're walking away with a new understanding, a better understanding of their domain, of the software system, or why it's so difficult to implement features, right, if you can show them the value of collaborative modeling, if you have a group of 15 people and, honestly, one walks away that was like, "Jesus, this is very handy. We have to do this more," I feel like I succeeded here, right?

Because that is part of what facilitation is. It's also to show them how good it is when you did it. Even for people that it's not natural... For me, standing in a group with a lot of people, it's not something that comes easy, but I do it because I know it gives me better solutions. And so when someone walks away with that same idea, that, okay, it takes effort but it is worth I, I kind of feel like I've done a good job.

Xin Yao: That's so true, right? So, you contributed not dismissing ideas when people are not really having a real understanding but just being polite or something.

Resources for Collaborative Modeling & Decision-Making

Xin Yao: So, we are almost at a wrap. So, I think we need to do a little bit of a final round, just to say what kind of... If you need to mention one to two resources besides your fantastic book, obviously, which I really recommend everybody go and check out. Yeah, I just need to say that I consider myself a very experienced facilitator and doing collaborative modeling, but I took away so many new things from this book. So, definitely worth a check, folks.

But before we close, I would like to invite each of you to recommend one to three resources, podcasts, books, or videos that have inspired you or something. Just very quick so our viewers and listeners can have some more stuff to check out on this topic of collaborative modeling and decision-making.

Evelyn Van Kelle: There's so much to choose from.

Kenny Baas-Schwegler: My favorite podcast I listen to is something called "Choiceology" by Katy Milkman. And that is just an amazing podcast because they give you a real-life story from around the world. Then they explain what happened, and then a social scientist explains what kind of biases during that decision-making they faced. And then they explained, "This is what happened."

So, one of the stories is about a guy who went to the million-dollar thing, right? And he ended up with two suitcases, one $2 million and one 0.01 cent and he got, like, $800,000 bid so he could take $800,000. And then he chose to open his suitcase, and it was 1 cent. So, what happened there? That's what they explained. And the podcasts are amazing. So, if you want to learn more about the biases that we have during decision-making, "Choiceology" by Katy Milkman, it's a really good thing.

Then for a book that really changed my setting is Jitske Kramer on "Jam Cultures," which goes into the deep democracy part but also the ranking part and mostly how we can form this cohesion. It's not an IT book, but I learned a lot from that and from "The Corporate Tribe" book with Danielle Braun. A lot of the content that's in our book, we got bits and pieces from those two books as well, which goes into deep democracy as well. And then the best book ever is "Sitting in the Fire" by Arnold Mindell, which goes into big group conflict solving. So, he's been to places in Ireland in very polarized groups. It's a great read. It changed my whole mindset.

Evelyn Van Kelle: I think our list is really similar. I think we all have similar resources. But to add to what Kenny already said, "Thinking, Fast and Slow" should be on that list as well. Also, if you're interested in the whole cognitive bias part, then it's a very nice book on how your brain works, and how decision-making works, and how valuable these biases are. Even though very often they have this negative connotation, they are very valuable things. And it's a book full of examples. So, I would add that to your reading list as well.

Xin Yao: Definitely. That's a great book. Gien, do you want to add something to the list?

Gien Verschatse: Yes. Something about making better decisions perhaps. I think the book that sort of kickstarted it all for me was "The Creative Thinker's Toolkit." They're very simple techniques to already have a better understanding of the options or about the decision that you're making. So, I highly recommend that one. And I think Barry O'Reilly is doing sort of a tour through Europe talking about the philosophy of software. And I think having a better understanding of why we design software, and why we use boxes and arrows, and where it all comes from is very interesting to dig deeper into as well.

Xin Yao: Thank you to all of you. And we'll make sure to include all these recommendations in the show notes. We are at the end of the road. Thank you so much for joining me for this really, really enjoyable chat. I took so much away from our conversations. And I know Evelyn, Gien, and Kenny, they are all three very active in the community. So, check them out on LinkedIn, on social media, and join in, in making this field of collaborative modeling and design even better. No matter if you're doing software design or something else, making a difference. And humans at their best, to quote Evelyn Van Kelle, we can do it with the help of this book. And let's practice together. Thank you so much, and see you next time.

Evelyn Van Kelle: Thank you.

Gien Verschatse: Thank you very much.

Kenny Baas-Schwegler: Thank you.