Hi everyone, my name is Patrick Aku, and for today's episode, we covered collaborative modeling, we go over, why we model in the first place, what problems it solves and how you can even apply it yourself, which today's guest, I had Marco hi myself, on, who's a trainer speaker, and even organizes the Kandinsky conference about DDT. I'll put the links to a socials, as well as the conference in the description below.
And with that being said, enjoy the episode, So I've heard I know you through Kenny and can you get those kind of the same thing? It's getting so much more popular right domain driven design as well as event storming, but a lot of organizations just need help with it because they've probably read somewhere somehow about it. Think it's a good idea for reasons. I have no clue where to start. So, when exactly do you come in, is it when they've read something?
Or when you publish something, well, that varies a lot from customer to customer and from company to company. So so my journey started is very different over the years. It started somewhere around 2010. Yeah, and back in the day I was learning about it from Eric Evans and Greg young and some other people in London from the conference about DVD. And in the very first, let's say two or three years, I've been applying it basically to my own
company where I was a team lead. So we were building a Health Care system and putting domain-driven design to practice and I realized that it's really hard to learn everything through experimentation and and on Our own. So going to a lot of conferences, sharing with the community, starting the DD community in Germany to get other people interested in this topic, which I find highly not only interesting, but highly productive.
Yeah, it was to me, it was like the solution of the problem that agile couldn't solve and that test-driven couldn't solve. And that all the architectural patterns is couldn't solve because what was missing was modeling. Having a conversation between domain, experts and stakeholders and programmers and and get all the people. The right people into the room to finally have the conversation. Not only once, but continuously
and applying this as a culture. So, in the beginning, the first few years of my activity, it was like a slow, push gradual push towards like, hey, let's build a community of practitioners. Let's get people interested in this in these things, and, and let's get them experimenting. And then, exchanging ideas and then more and more companies said, hey, I've heard you talk. I've seen this article. I've I've been in one of your
workshops. Can you do this in our Company please and you help us with the problem. And, yeah, this is it's mostly when people feel they have a need, there is there is a gap, right? They feel over didn't really modeled properly and now we want to I would say between 2014 and 2018 or so. That's like roughly until one or two years before the pandemic. There was, there was the main drive for people to approach.
They saw a talk that was kind of like an impulse and they realized, oh, that's missing here. We really need to collaborate better and more and we're not lacking the will to Do it, but we're lacking the methods of. How do you approach that, right? How do you get the right people in the room? Especially because, in many cases, culture is I wouldn't say broken but it's it got to a certain way where it's really hard to build the trust between
programmers and non-programmers. Yeah or the technical folks and the non-technical ones. So getting people to communicate again to trust again. So the developers to actually be interested in the domain because they know their impact and their ideas matter and the The domain experts and stakeholders to really trust the developers to have their interest at heart and not just wanting to build a cool new framework or something to rebuild that trust takes takes effort.
And one of those methods that were using the event storming which is a one of my favorite collaborative modeling methods. It, it has it basically built in. It's a trust-building mechanism if you like because it's so simple to learn, you don't have any power when you know the method but the other person doesn't Dried or don't.
So you bring the right people together and the conversation usually starts with a with a bit of guidance into a very natural flow over a very short period of time and yeah, that became more and more and more thing that was really successful. And then, while started Consulting full-time at some
point and then the pandemic hit. And now, everything really changed because now people realized we don't need to have a consultant here in the building where we don't need to get them in. So, When you can do that remote, there is a lot of drawbacks to remote collaborative modeling and we can talk about that at length.
We've been experimenting like hell in the last two years when I can imagine but there's that there's trade-offs there, strong Traders there, but some things actually even work better in remote, but it's now, it became even in a world where the pandemic goes down, people can meet again, right? It becomes a trade-off. Now, to make a decision, like,
shall we meet in person yet? All, shall we do a remote workshop and neither format is best in every situation that Pros and cons, but one of the major pros of a remote Workshop is, you can remote Workshop from anywhere. Yeah, you can get a consultant or trainer or facilitator from all around the world. So you can really pick those that that fit your culture, the best that really understand your kind of problem or that have experience with with your kind
of needs. And you can do it for short amount of time. So that's something. We've been doing a lot in the last last year or so, not having these three or five day modeling sessions because you need all the experts to come in. Into a building and then really lock their time, right? But you can do it in a relaxed formats, a half a day, and then day or two of of rework and then another half day, so we can really adjust to the needs of
the customers. Yeah. And yeah, that's that's what I've been doing the last two years. Yeah. And it's a still, it's a Continuum of change. So, there is never a stable like, this is how my work goes. Its, it depends on what customers need. Yeah. So sorry for babbling on. Feel free to stop me at any time. Yeah, don't worry about it. I I like that. It's giving you kind of this flexibility now as well as with the the remote working nowadays. Probably ever the same but I can
imagine what I've heard. And also while talking to Kenny and Evelyn Vogel as well, is that you need the same people in the same room, right? But if you're doing this remote, it's going to be a virtual room. And people going to get distracted. It's not the same sitting physically and looking each other in the eye and even
modeling. Because you can't really I mean you have virtual rooms probably something like mirror or whatever they can use that you can use to just draw out a mind map or whatever but it's different isn't it? I think it's getting harder and harder to get those people enthusiastic and to get them to collaborate in that way as well. Absolutely. I'm totally with you there. So there's, there's, those are the strongest drawbacks.
I figure. The one is getting people really excited about a workshop because if it's just the next meeting, right? You click teams or Zoom, you close it and open up. The next meeting is like, okay, let's get a coffee and what are we doing now today? Yeah, yeah. It's it's not if you get people into a collaborative modeling session in person is usually, they fly over or the take a train ride or what, at least
it's movement, right? You go there and this is locked time, and It feels like a different thing changing scenery, seeing all the people, especially having humans. In your vicinity, a group of those gives you a certain feeling of the audience and in Zoom, or meet. It's just like you have a bunch of faces half of them, have their cameras turned off, and it's really hard to get a company culture where people feel excited about sitting in front of a camera. So, yeah, that's, that's the
thing that's really dragging. Which is why we need a lot of exercises for that. And there was something by Terry free the workshop, by Terry, for that. Took a while ago called training from the back of the room. And that totally blew my mind, in that regard, it's about brain friendly learning like the most, most information about how humans actually learn how the brain really learns. Yeah, came from studies from the last 10, 12 years or so.
So Humanity has made a lot of progress in understanding how learning works and to really effectively learn something. You need short bursts of connecting with the topic, right? Connecting the, the audience to the topic. And Then getting a short like 5 10, maybe, 15 minutes, introduction to an idea and then you need to practice face and then after that a reflection where you teach back or where you were, you somehow transfer the knowledge and the practiced ideas into some other format by
writing it down or whatever. And that's the the rough gist of it. But that meant from the before times, when we had like half day or full day, sessions of a single activity, with 30 people in a room, we now try to boil it down. To Shorter bursts to say, we can do half a day workshop. Problem, but it will be three or four sessions that are concise. And each of them has an actual time portion related to, let's get people, motivated and
connected figuring out. How are we solving your problem here? Right? If your invite the people mandatory attention isn't required, right? It just because you're part of the team, you don't have to be there if you can't learn from it or contribute to it. Yeah. So really getting people motivated by by having a problem that is now solved for them or getting solved for. Them or where they can help others to get a problem solved. Right? That's what we want.
We want the people to be there because I want to be there and then having short bursts makes it energy management wise so that people stay motivated. But even with the best of methods, it's a totally different Beast remote than in person. And you can't get this group feeling of. Yeah, we're getting there, that just just doesn't happen. Even if everybody's clapping, you just hear this. Drowned out noise of Zoom clapping. It doesn't work.
So yeah, that drawbacks Yeah. I mean we keep learning and improving and probably making it better. Hopefully in the end. What I've seen good. Yeah I've seen I've seen positive approaches with it. Things you couldn't do in the before times and that is. You have 20 people solving a business problem or trying to synchronize a mental model of what are we actually trying to solve here, right? Understanding the problem space first and then you realize, oh suit.
Now that we are getting to this area. We need Tony's information here, right? Or let's call Tanya quickly and all of a sudden you can send a messenger. Say hey do you have time between now and 4:00? Yeah, please join the zoom link. We have a few questions and then you put some speech bubbles on the mirror board with questions for Tanya. And then once she joins you just ask like, hey, what's this about? How does this work? What should we do when this fails right?
You're the expert here. So what will you say? And then having an actual conversation, not just some text drop or somebody gives you answers but going into okay. Why does it matter? What are the Alternatives? And A dynamic, quick modeling introduction from someone, and then they can leave again. Those things became possible. And that's immense, that's really great. And the other thing is when you remote, you can, you can quickly say hey let's copy the whole model right?
You have a mirror model. Yeah you can select 500 sticky notes, make a duplication and reshape it and say wouldn't this look better? And all of a sudden it's way easier to work with a malleable model. It's not haptic anymore. You're losing this this sense of space. Case, right? It's not that on the left side of the wall. If I go over there, I know we're talking about this part of the
model. Yeah. But it's all scroll and zoom but it's easier to change the model again and and that gives well it's an unfair Advantage but that gives a technical people more more ease of use and more motivation. Yeah. Which is also the danger because the people that aren't used to work with computers that much or that don't like mural that much those now get a disadvantage right, which they wouldn't have in physical space but It's totally totally different,
totally different problems. You have to tackle when you do a remote Workshop there. Yeah, I can imagine, so, but I mean, I love those benefits, right? The flexibility of just flying someone in remotely, it's as simple as just dialing them in and being like, hey, we have these questions. We already wrote them down so we can give you your attention. Basically, right now, when you join, and we can basically cross off a bunch of questions that we've had what I'm missing though.
And I don't know if you agree with this is I think I learned most also, when there's kind of a social aspect for listening to this audio book on happiness and they call it vitamin es. I don't know if it's an actual psychologically or how do you say that? It's studied as much but those social aspects contribute to personal happiness. I think if you're happier, you also enjoy those memories more and maybe even you learn more or your retention rate is better
that way. But it's different when it's remote, right? Because Very much focused on. Okay, we're here with a certain goal. We want to be efficient and therefore we are effective, but you're missing that social aspect. You can't just go out of the room and be like, hey, guys, ten-minute break grab a coffee, talk to each other, see how it's going? And then we'll get back to this again. Yeah, absolutely. So I've tried a few things like breakout rooms for social
get-togethers, right? So at the start, if people are introducing themselves, nobody wants to listen to 50 people saying. My name is that my role is right, that's boring. NG especially in Zoom when you can't even look at them really. But so making small breakout groups, having people to connect with, just a few people sharing. Some fun facts asking questions like hey, how would you describe your job to your, to your grandparents, right?
That I'm not nerdy. What what's your what do you do every day and try that or that helps a bit but it's not the same and especially at the end of the workshop. That's usually when most of the actual truth come out which I find really interesting lots of customers, I've had in the past, you do Modeling for the whole day. Like the business people out there and then the technical people and some stakeholders and it feels like, okay, we got
there. We really understood everything and then then the workshop ends and you going to for drinks or dinner with some of the people from the workshop. Yeah. And then you hear like oh yeah so now I can tell that right now that the boss isn't here anymore. Then you get get oh my God you see stories and that happens so often that you realized oh yeah we have been modeling something, everybody was under the impression. Like this is going really well.
Yeah, but if psychological safety does not exist, I mean, nowadays I have a feeling for that, right? You get experience with more and more psychological and safety and, and you get it. You feel the tension in the room, everybody's very official and then, you know, something's up so, but, yeah, it's really hard to break through that when the safety, isn't there, as an external facilitator. You can't just say, hey, everybody now feel safe and talk to each other. It doesn't work.
Exactly. That's something that's cultural change that needs time. And deliberate effort from the company. So, But that's what the the in-person meetings after the workshop were really good for ya. So, I've started to bake this into the actual Workshop format in Virtual and remand in person
at the end of the workshop. There's always a cool down face saying, hey, we take half of it, half an hour, not for feedback, not for reflection, just for, let's grab your best Pals from the workshop and and discuss stuff, right? And if you have anything you'd like to share with me, please do. So, here are some sticky notes. You can also just put a bunch of ideas on there and do whatever you You want basically it's just like a cool down time.
Yeah he is. Well depends on cultural like he's beer or coffee or whatever and the same thing goes for for many remote workshops when it's not just a four-hour session but it's a multi-day session or so then every time you do a workshop take 15 to 20 minutes at the end and say okay cool down throw people into breakouts and let them just hang out chitchat. It's not the same but it helps a
little bit. Yeah. Yeah. What I find is the most important aspect for successful collaborative, Ling is psychological safety, right? Yeah, that's that's your feel that when people really don't mind. When they say, oh yeah, sure. We hang out anyway, that's perfect. And then, you know, the modeling is going really well. Exactly, you feel everybody is stiff and they have ranks and some people have a suit and some
don't. And, and they look at it as a different and talk to each other different than it's like, something's all as much as you want. Yeah, you're going to get a different version of the truth. Write something that's going to more superficial, but not the actual truth. So then what you're R doing isn't really as effective as it can be, which is a shame right. It's very simple and very nuanced and that way.
Yeah. But it's part of getting everyone in the same room hierarchy is a part of that and people always have that in the back of their mind, right? That person is either my boss or their boss and if I say something I might mess up or it's going to come back down and that is very inherent in the culture of a company, which is very hard to break down to get everyone to open up to each other. I guess and I wouldn't say I would say don't be discouraged by what we just uncovered,
right? It's not that if you don't have the psychological safety that modeling isn't for you. Yeah, it's a systemic approach. You can always make things better from wherever you are. You can always use collaboration modeling to get a bit better. And as I said before, right events roaming, for example, has psychological safety Improvement, built-in not as an idea, but that's what happens when you do it, because you see, we're not fighting.
Against your idea. I'm taking your idea of putting it on the wall and then I'm asking critical questions and I'll show you my idea and we start standing shoulder-to-shoulder against the model and just talking about trade-offs. And of course, this doesn't go in like one session. Everybody loves each other that doesn't work, but it makes trusting easier because all of a sudden you see. Oh yeah.
Well now we uncover some truth that we were maybe afraid or just just organizationally impossible to talk about before and now some things uncover it's also hard, sometimes people really don't like Like seeing the truth and then they fight it, right? But at least you get transparency and you can always make it a bit better than before. Yeah, and this is this this is a long game. So changing you're changing your company to a psychological safe. One trust me.
I've been 14 years in the same company and we've managed to get a psychological safety team and and good connection to other teams. We didn't even manage to get the whole company to psychological safety and enjoying collaboration and in the end but still We made an impact and then really made things better over time. So yeah, that's that's what you can do.
Always optimize a bit from where you are to get better and don't get discouraged by, people wanting to work different because they also have needs, right? They work the way they do because they value hierarchy and the benefits that brings. You know, it's not, it's not all bad to work in a strict role and in strict hierarchy, it's not what I prefer but it has benefits.
So it's always a trade-off and respecting, everyone's cultural decisions and And then making things transferring to come to a common goal. I think that's the most important thing. Yeah, I completely agree with that. It's going to take a few years because this change is it's not going to happen overnight, right? It's a change that has on a multitude of levels within an organization and that affects
lots of people. And if those people don't agree, either they move with the flow or they move against the flow and usually moving against, it means they have to leave at some point which means you are looking at a multitude of years. Before an organization can make a cultural. Shift like that. If we, if we step back and and ask the question, why are we modeling in the first place? Because modeling is more of a what, right? It's a method to solve certain problems.
I think it's because we kind of lack the understanding or there's a mismatch in understanding how either organization works. So that chain of event works or what each other is actually doing or helping to speak the same language. Why do we model in the first place? Well, that's that's that's a very philosophical question. So, Bear with me. I'm going to take a look, take you to your through your childhood. Now there is there's the official modeling that we do nowadays in software
development, right? And the official ideas or the the main ideas are you model to synchronize understanding? So you have an idea in your head I have an idea on my hat and we can't share ideas. I cannot give you my brain content. I can only use words to describe things and you might misunderstand those words. You most likely not, you will guaranteed misunderstand in some sense. Because a perfect transference of internal worlds doesn't happen.
So we use a lot of symbols like Words gestures, drawing sticky notes. Any method we can find to synchronize and through active feedback. I'm doing something. You're showing me what you understand. I show you what I think that you think that you understand. So on right, we do that for a while until we realize. Yep. We now talk about enough of the same thing that we can productively move on from here and well reason number one is to synchronize. Understanding like do we share
the same problem? And the other is to come up with Solutions. Say hey I can do we could do this, right? And you say that's a good idea. We could also do that. Right? What are the trade-offs? Is there a polarity here? What are we optimizing for? What are we optimizing against with this solution? And is there some hybrid middle ground, right? So problem, space, understanding and solution, space Discovery and design. Those are the main reasons. From a architect modeler DD
point of view. But I think it goes way way way beyond that, because I think modeling is inherent in human nature since the moment you're born. That's what your brain is doing all the time, it's modeling. And this is where it gets philosophical a bit. So I'm trying to keep this short, but, you know, you don't see reality. That's, that's one of The Facts of Life. You don't see the real world because you see real seeing is a model, your brain builds in your
head. It's a virtual world where your brain renders, a 3D image from photons, hitting your eyeballs. It's interpretation of light, waves of the electromagnetic spectrum and generating 3D World, which is an image of reality, but it's not reality in your head, right? So yeah, and what you do, as a child, your brain, basically just fires and your arms wiggle and your eyes, just see something. And it makes no sense to you.
And then over time, these feedback loops generate patterns and you realize, oh, this is my arm, right? I'm not in that word sense, but the awareness of what what shapes respond to which images to which touch and All of that is modeling. And then you start, you keep on modeling, you make sense of Reality by having an idea of. Hey, what if we play, father mother child, right?
You model reality. I What You observe, you transfer it into a game and then you play situations and that gives you feedback again for the real world and it sounds like an official thing that children learn to do. But the of course you don't have to learn that. Yeah, it's just what your brain, does you have ideas hypotheses. It's basically the small scientist in your brain. You have hypotheses about reality, you do things with it. Experimental ways in modeling in prototyping.
And then it put us back to reality and right. Everybody had tried to move a coin with their mind, or to fly and didn't work. And it sounds stupid, like, because why our children doing that. And we don't do that as grown-ups, but we do, we don't do it with coins and telepathy telekinesis because we learned that doesn't work, that was one experiment, right? We do with other things with things that are way more complex because you grow and grow over time in more complexity and
everything that you've learned. Earned becomes reality for you and and truth that is hard to change harder to change but that's what your brain does. It's only modeling the whole time and when you want to build a soft piece of software or when you solve a business problem, you keep on doing the same thing, right? We are modeling anyway even if we don't do collaborative modeling exercises.
Yeah and that's that's the hard pill to swallow for many people like you have been modeling because somebody gave you a document, right? They were modeling by writing down what they think you need to hear to solve their problem. And now you take this piece of paper, you read it and you build software because you take this model from paper into code through your head. But we realized that non collaborative modeling has really, really slow feedback
loops. So if you give me 200 Page documentation and I write code and then you test it, which is already something that every company does, right? But then you test it and then we back. This is a week-long feedback loop if it's, if it's fast, right? So, it would be better to be within days. As or maybe hours and the best feedback loop would be zero standing in front of each other talking together about the model and having the fastest feedback loop possible until we both agree.
Like Yep, this is what we want. Great. Exactly. She's thinking, because you started off with kind of the language, right at the. I have a certain idea and I'm trying to convey that to you but our brains work differently. Also, how we've modeled the work or how we understand. The problem is completely different. So there's an inherent miscommunication in how we communicate.
Okay, right? Whether it's Linguistics whether it's I'm typing a piece of software in your interpreting, it where I write a certain document, right? I get people sending emails and people reading it and be like, man, they're mad at me and I'm like, well, how did you get that? Like, I don't understand it, but there's people interpreting Things based on how they grew up, how they see the world or how either they were raised or
is inherently in there. I don't know exactly what it is, but there is always inherent miscommunication then So then the collaborative modeling. Hopefully allows you to focus on that miscommunication and make it more or absolve it more. Yeah, and that's the part where, where the different methods become valuable, right? I mean collaborative modeling is the easiest thing in the world. It's basically means you put people together and then they talk exactly what then come all
then. Come all the hardships, right? Some people as you say misunderstand each other and you misunderstand, many things. It starts with a Language. Right. I'm saying words and you have a different meaning. For those words in your head, if I say shipment, you say crate. We might mean the same thing, but because we work in different areas, right? We now have different words for it.
So, there's two ways of misunderstanding using different words for the same concept or having the same word for different concepts slightly or fully. So that's the linguistic part, which is tackled by domain-driven Design and the ubiquitous language and having a collaborative modeling method that uses Visualization to show. Oh, this is a context. He let's draw a boundary. Let's draw a bubble around it and show in this area. This word means this specific thing.
When we go over the boundary into this area, this is where the language changes. It seems so trivial to make that visually distinct, but the moment you do it. Oftentimes, you see so many people's eyes light up like, oh wow. And then they'll realize whether we're misunderstanding each other so much, but it doesn't stop there, right? It's also the things you don't
say. I don't say a lot of things because they are Suit and they are super obvious to anyone working in my field, but you have no clue this topic even exist and you can't because we never talked about it. And and that's all official communication about a topic and then you have emotional communication, right? The way you say things to people power and nonverbal communication, that gets strongly misunderstood.
Yeah, one of my favorite examples, like I was at my own conference in Berlin, the Kandinsky. And there was there was a person, I think from Ian origin and I was talking about Aggregates and he was like shaking his head the whole time. I'm like, yes. And I kept on arguing more and more and and at some point somebody's talking said, hey that's that's that's just acknowledgement I'm like oh wow, okay, cultural sensitivity,
right? So all of a sudden you realize even the things you thought were Universal aren't Universal and and those surprises can come in any company. So you don't know how people mean things that you misunderstand. So the emotional part is like that's a minefield. In in companies that don't have psychological safety, already baked in fully. So and even then, it's hard work, right? You always need to keep psychological safety up.
Its work to keep it going because you need to work on the trust that you have with other people around you. Yeah, it sounds like such a fluid thing because I mean people are different. Right? Cultures are different organizations are different. So there's no kind of cookie cutter mold that you can apply, right? We have these methods and we have these tools and they're applicable in. In some situations or we've grouped them.
Therefore we think these are applicable in a lot of situations because we have the history to back that up, right? But that's no guarantee for the future. So if a company gets you in and they're like, okay, we have these kinds of problems. We think these are the best tools, they might be completely misunderstanding. Either the tools will the problems of. There's a lot of things that can go wrong with in that. How do you when you come in? First of all, figure out figure
out what they actually need. And then actually help them attain that. Yeah. So the thing is I don't know if I ever really understand what companies really need. That's then, still your interpretation, right? So that's like there's there is a philosophical Gap that I can never break, right? I can't ever have the guarantee, but, but I mean, that's not the point of the question philosophy again.
But the thing is, heuristics is what we do using heuristic approaches, not not metrics and not default method that you always. Always use what. I don't go to a company and say, let's do events roaming just because I know how to do it and then we'll get this kind of result and then we'll take it and do a context mapping and what not, it's like first you talk to them and figure out what
are your pain ports right there? I mean there's a scoping called usually people explain what they want and I always try to listen into the emotional side of things, see where people get excited or get angry, when they describe a problem, large parts of the problem are just like and this is his and that it it and there's it, it sounds very boring but they describe stuff and then you see them. Getting emotional at some topics. Like, okay. That's let's dive deeper into those.
Yeah, so going with emotional cues to get some hold. And then usually, even the easiest coping colors, already modeling session secret one, right? We're not calling it that but writing stuff down asking critical questions. Doing all the heuristics. We know from modeling to figure out the real intent behind that behind that request. But again it's just it's just an inkling. You get, you get an idea of what they want and you get a mandate for what they Want you to do for
them. Yeah, and very often it's like people want you to teach them test-driven development so the developers produce better quality. If you understand the why? Hi. This is Simon sinek. The idea going with that. Always start with understanding the why, if you understand why they get you, why they want this thing to be taught. Then you can modify during the workshop to approach that code better. Exactly. They don't need test-driven development. You realize, well the quality is good.
People think tdd makes you better in quality but your quality is okay. What's not, okay? Is that you're not building what the customer needs. So, there's a conversation missing. Sometimes a conversation is happening, but the quality is crappy, because of the Legacy. And the old system is not really maintainable, but it has to be maintained due to cost. So, let's figure out a strategy to get out of the Legacy. Right. Right. That's build. Smaller. Anti-corruption layers and extract.
New parts of the domain to be able to move fast again. So, The that was a long-winded, political answer, the short answer is heuristics. Instead of, instead of default methods is the goal, so what happened when you say was pure Aesthetics? Yeah, it's a hard thing. A heuristic is a, is a rule of thumb that you can use to get answers fast. So if your ristic is not a scientific method to say, hey, this is an approach that is
proven to work, right? A heuristic is any kind of rule that you can put for any kind of situation that helps you to get fast. Answers due to a certain Behavior. Let me try with an example when I feel that people are talking to each other and they both not but I feel that they don't understand. Then I visualized by that's my heuristic the visualization
heuristic, okay? When I have a feeling you misunderstand each other let's draw what we mean on sticky notes and put it into a timeline and now we really see. Are we talking about the same thing? It doesn't mean I'm always getting the right answer. Sometimes the message is just a waste of time but it's a heuristic that more often than not. Not gives me a good answer. Yeah.
Technically heuristics. If you have something like, you have multiple services or bounded contexts that are talking to each other, you can, of course, query the data, you can go with an API and doing this or that or you can publish an event, that is semantic, right? So doing that gives you a better understanding more decoupled systems. So that's a heuristic approach to say, if your system feels too tight and coupled, going for
events. Semantical events is a good heuristic to get you out of that rut. It's not the The way it's not the best way or anything. It's a heuristic that you can use and it always comes. I mean, that's another heuristic that it always comes with the idea of small controlled experiments, which is if you're sticking of itself. So whenever I do a heuristic, I'm not just applying it and then run away and hope it worked. It's you do something.
You figure out what's the impact, what are the pros and cons? What do we see here? And mighty, as well as broader nice rustic ones, it was the anti heuristic or something on the counter here. Istic like forever. Heuristic you apply? Figure out the counter heuristic that would do the opposite. That is also helpful, right? And and try that figure out if that gives you different results.
So thinking about the Opposites is something that I really do a lot when I went to try to help something or someone the moment, I apply heuristic. I know I'm guessing what is a gambling game? Yeah. And you're not. It's a gambling that makes you learn in the long run but in a short term it might be a cost that that is high, right? So you have to do a modeling in 20 people, that's a heuristic approach. I think that would help what if it doesn't.
Well before you do it, you can think about the counter here State. Like, what would happen if we do it the other way. Another way that is opposite to that and then you have a trade-off that you can really think about and, and figure out, and it doesn't have to be you alone, right? You can make this a collaborative decision. You know. How, shall we? How shall we approach this? I think this is the best approach. So, let's go with that or this. These are the trade-offs.
Let's make a decision here, so that's what your risks are. And there's a nice website by Kenny bus and and myself and a few others. The DD heuristics.com where we gather all the heuristics. From domain-driven design modeling collaboration and it's an open invitation to anyone to put more heuristics in there, right? It's it's a starting point to say. If you've never worked with your istakes, don't wait for the next method to solve all your problems, right?
Yeah. Test-driven development, didn't solve all our problems, functional programming or object oriented programming didn't solve all our problems. And agile didn't. So it's not the method that solves your problems. It's heuristically approaches in a third mindset that solves your problems that has the highest chance to do that. So gather your own heuristics to really build up a tool, set your own tool belt that you can pick from And that's the important part, right?
All these things we can give from external, are good. Impulses, good starting points and due to a lot of experience. If we have modeled over 100 different domains, I can see some meta patterns other people don't see that stick in one company for years, but those people have an insight into their own business that I can never have. Right? So they have a different world.
They need their own heuristics. If you build your own tool set from that, figure out what works in your context, what doesn't that's your best chance of really improving over time? And getting a published problem solved. Interesting. I think everyone has their own heuristics, right? It's maybe even a gut feeling or but you really externalizing, if this happens then I usually do this or I think this is then the best option.
But we also have these options or we have these counter options and we can weigh them out and it's for decision-making, I guess. Yeah. Do you like most of the heuristics you use that you come up with them on your own? Or did you take them from from oh no gone now. No, no, this is. This is this is I call it the system most collaborative effort I've ever been part of. It's really cool that is.
Yeah, absolutely. So without the community of domain-driven design practitioners and software professionals and now even psychologists and other fields, this wouldn't have been possible. I mean, it's like, I don't know if I have any heuristic that was completely my own. I have my own local heuristics, right? For my companies or my team's I'm experimenting. And that's kind of like the gist that I'm going with the whole time. Try to adapt methods and then I try to adapt them for the
problem that I see at hand. So event storming is great context, mapping is great, other methods worldly mapping for situational awareness, right? Those are all tools for a specific purpose but then you approach an actual company problem. And you're like, okay let's just mix and match, right? It's not about doing the tool, right? Yeah. It's about figuring out what do you need right now? And from all the tools. I know. Let's just let's just Frankenstein together.
Some new method that helps you right now and sometimes if people need to hear the name they want to have an event storming. Cool, I call it that but if I know that a context boundary would help now than I draw one and just still call it event storming because management pays for that. That's fine. But this that's my Frankenstein heuristic basically, I'm always putting together a method from from all the rest but I'm not the only one in the world who ever did that.
But the whole point is the DD Community is meeting multiple times a year at various conferences. And, and there's open spaces and User groups in every bigger city and this continuous learning Loop that has been going on for years. Now, culminating in the virtual DD Community, right? At virtual d.com, where we have like interview sessions, and modeling sessions, and and participation sessions of the whole Community.
Every few weeks, this learning effort made all these things transparent and there's like to drop a few names their right a big thank you goes out to Nicktoons who is building a together with it with some other practitioners building a repository called deed. DD crew on GitHub. So it's github.com / DD crew where you find a lot of very concise and very clear written. Explanations of. Hey, this is how you can approach context, mapping abounded context canvas and aggregate design.
So all these things that are hard to do when you start, it's all written out virtual Didi has all these interview sessions and The Learning Journey for beginners and so on and so like it's a big Community effort so no one should come up with our own turistic Saint their own and keep them for themselves. This only works as a community. Yeah. And what I feel very strongly is we don't compete in methods of modeling, we don't compete in being good modelers.
We compete in shift planning, we compete in car Automation, in whatever your domain is that you work in, right? That's where people compete, but the craftsmanship of building good software and other crafts person shape of building would software and for that matter, building good systems, because it's not software. It's humans. Added pieces, right? And manual pieces. Whatever you design to solve problems. How to solve problems. Something, we don't compete in
that. Something we need to collaborate in as a, not only as a company or as a community, but as a whole planet because I mean, people might have noticed but the world is kind of screwed a little bit in multiple areas and we're not going to solve it by keeping our Trade Secrets and trying to become more rich as individual. We're solving them by collaborating and sharing methods of how to solve problems better. So, yeah, your little, your Moral compass on top.
I mean, I completely agree with you on that right. That's why I love being part of this community. And I think it's also very unique within this community. There's so many ways of conveying and sharing knowledge right we have blog posts podcasts videos on YouTube just plain text or even conferences getting together as a meet-up stuff like that. It's all with the main goal of knowledge sharing, right. How do you solve this? How have you? L've this.
What can we learn from that? Should we also try that? What are the edge cases, whether the trade-offs, right? Sharing, whatever you've done. So, someone else either is going to learn from that. It's going to make the same mistakes, realizing they can, or they going to avoid that and
choose other options right? To do what we do and be better because of it. Yeah and I would even go one step further, I mean, totally agree with you there but I would even extend the sharing into collaboration on then. So sharing ideas is great. And That's that is what conferences have been for for many years, right?
Yeah, but we realized in the last few years, that at Kandinsky our conference in Berlin, it's a conference about domain-driven design Centric and everything that makes business software better at some point. We realize the talks are and what people really come for. I mean, it's interesting to get an inspiration, right? But you can't, you can't really teach someone a topic in an hour of a talk. Yeah. But collaborating on things really doing a Hands-On two three, four hours of getting
into. To a topic with the experts, add the experimenters and ideally, even with contradicting or opinions, having two experts at saw the differently. Let's have a Hands-On session and really share stuff and then work on this, not just by transferring knowledge by, but by engaging into each other's ideas and getting better at
practicing. So that's what what I think is really important to build a community of shared practitioners that work together and improve together and not just share ideas, which is already. Start. But that's just to just the starting point of getting a real traction on the road. Yeah, yeah I think I mean you see that more and more in software development as well right? Co-creating, collaborating doing things together, sharing each other's mental model or externalizing it or doing it
together. I think it's more fun for me personally. And I think it's more effective down the road as well, which is great. If I move back to the heuristics, have you ever read something that you're like, that's never going to work then. Applied it in a It actually did work or have you applied things and then it just failed horribly. I have to think about I've done it the other way around, I thought. Hey, this is definitely going to work and that it didn't that was Graham for us.
So I thought we thought that we would solve our problems by doing. Hey, we're not communicating properly. Let's, let's put this framework into place and then with an agile mindset, we're going to go to the Future. Yeah. And then it was a long struggle. It always felt like, oh, we're getting, there were getting better. We're getting measurable. All right, the pace is going up and whatnot. Velocity is improving cool.
But after a year or two realizing we didn't really move anywhere from here because company culture is still broken. That's the thing not working. That's where modeling at some point came in. But I don't think that I ever read something where I was like, oh, this is never gonna work now. I've never had that because I never think things never gonna work. I always try to figure out in which context is as helpful. So that's the different mindset, right?
So yeah, I was just wondering why I never thought that anything would work. I often think things don't work in this context, but I'm open to experimentation. So what I try to do is this is the whole opposite tourist approach. Again, a few years back, this was an idea by Greg young, which I really liked. He said, like, okay, do something. And if you do something and works in a certain way, and I know I lost my train of thought, sorry?
Yeah, forget about it. So what I do is I experiment with things Even with the with the when I think this cannot work right? Try something and figure out what it gives you and what it doesn't give you before we shun the idea of so that added basic mindset makes that I've never taken idea is like hey this can never work. I really like that approach and I agree with that mindset as well, right? Sometimes I hear people say, oh, this sucks or this sucks or I've I have bad experiences with in
this. It doesn't mean it's wrong, it just wasn't the right time, right, place, right context. Stephen because it was right for a certain context or certain domain, or certain situation. So having that kind of open mindset and being like I'd I mean, you can have right or wrong, it's not that black and white which is also why it's getting why it is interesting, right? It's not easy. If it was black and white we would have solved all our issues but it isn't.
Yeah. Which means there's always going to be trade-offs and situations. Absolutely. So I think the hard part is we're solving complex problems. That's where all this whole discussion, what this whole discussion is about. Of course there are bad Solutions and things that don't work and you know, they don't work in simple problems. That's that's an important distinction to make. If somebody says Hey I want to clean up the wall and I'm going to do it with mud.
Yeah, that doesn't work. I know that for a fact because I modeled this I've seen it. I know how physics work. This is definitely not true. This is not going to work but we're not solving those problems anymore. Right? And software, we're not solving like hey I want to store a fight, on a hard drive, how to do that. That problem is solved you Can read up and you can solve it. We're solving complex systemic problems where things are interacting and you don't know
what happens if you do this. You don't know how the market change the future changes, you might not even know all the trade-offs of the underlying ecosystem and infrastructure and so on. So in this ever-shifting area of Technology people ideas and needs, you're trying to build something that is stable enough to generate value and not only financial, but actual provide a betterment of your company or Humanity or whatever your goal is.
Yeah, and that, that needs constant attendance and, and attention and and shifting of the solution itself, right? So in that area, there are no simple truth. There is no right or wrong. It's always a complex situation that you need to model and understand trade-offs. This is why there are no bad Solutions. If somebody says, let's do this. Like, if you feel that's really important, let's figure out why, right?
What's your need? And then then map that what what why do we want the other thing like why do five people say no the opposite? But you say very strongly this direction and can we experiment, can we do something to actually learn? That would be wise and great to do. That's not always possible.
So, sometimes we shun of an idea, even though it would be great to learn from it, because, well, if you have a time constraint, right next, Wednesday needs to be delivered, we can't do much experimentation on two opposite Solutions, so let's go with, I don't know, majority or risk risk avoidance or whatever you are optimizing for. But that's again, as a heuristic and it doesn't mean that the other solution was bad. Is that you had to optimize
against it for reasons? Yeah, I think, I mean, that's what gives me energy, right. It's some rules that are laid out sometimes. You can challenge those rules, but that's kind of the context you work within, and making it happen being effective within that and making stuff happen together with other people. If it was just me by myself doing some things, I wouldn't get as excited because we're always dealing with people in this aspect and doing things
together. Getting that result together makes it just a great journey along the The way as well. And that is that is precisely where I think the the effort of collaborative modeling comes into play. Because in the beginning you have these constraints right? Somebody setting constraints whoever that is in a start-up it's the market or so in a strong company. It's a hierarchy. You have rules that can't be bent or that are not meant to be bent right now.
And those are enabling constraints first, right? This is like, hey, this is your framework within this. You can work creatively, do your best, right? And if you're very young or let's not not age, but if you are Experience in your field. Having strong constraints, helps you to to get a clear focus and to practice and to get your hands on on stuff. But then you realize, oh, there's a trade-off that you can make decisions. So you need to relax constraints.
So enabling constraints at any level of maturity become become constraining constraints at some point. So it becomes just just fixating you on the wrong path. And that is where well in many companies, people just leave the company go other places or they try to go to a different department, right try to Avoid the problem by leaving or that.
It's as is very long, and painful, process of making things aware and then higher-ups are feeling challenged, but that's not the point and so on and so forth. So this is where collaborative modeling methods. For me we're a really helpful tool as a gorilla and tactic saying I see the constraints given to me. I work within those until I reach a limit where say systemically, my work here is not the best help I can do for
the company. I see we have a problem that goes beyond my ability to code faster or produce Higher, unless back rates, I mean by a few bucks, but this is more about, can we solve the right problem? Do we have the right feedback loops and so on? So let's work on that. And and if you feel nobody empowers you to do that, you can always Empower Yourself by just making things transparent. Right. Take a few sticky notes, go out into the hallway. Where the business people?
See you and start modeling. Someone will ask you what you're doing, right? That's that's I mean this is a heuristic with a lot of drawbacks and risks and not for every company but as an idea using Different collaboration methods, guerilla-style just involving one person that is that is kind of benevolent towards you and asking them for help and get them excited about what you're doing because you're trying to solve their problem, not trying to get them to help you solve yours. Exactly.
And you using this step-by-step helps you soften the, the walls write the constraints go away after a while and then you can start to build your own constraints, figure out what do we need to do? How do we need to frame ourselves and help others that are learning now to be able to Best work. So it's those rings are helpful
to with. Yeah it's those kind of small ripples that eventually will turn into waves but you just need to make sure you you Ripple here and there with the right people on the right time and places or even a wrong Ripple here and there because you're going to learn from those. But eventually you will create those big waves that will create
the change. You intended, one of the final questions I had was I saw on Twitter or LinkedIn, I don't know exactly where but it said, Mark Hyman Self king of sticky, Aries or master of sticky. Some kind of sticky Master kind of thing. And also, when I jumped in the car, I mean, I see the stick is behind you, what's up with the master stickies thing? Yeah. So that is, that's the same thing that Elon Musk is doing, when he calls himself king of technology or something.
Right. It's just, I despise titles. I don't like that. People call you, like never made any kind of title that gives you a hierarchical power which is symbolic violence in that sense. Like this is the chief consultancy whatever or CTO or those titles have meaning in some companies. And they are important to, to clarify roles. But I feel so strongly about collaborative modeling and roles specifically organizational, hierarchy worlds, don't really matter.
In that sense, when you come together to solve a problem, you want to bring the people that have questions about the model or that can give answers about the model you want to have the people that are affected by the outcome of the model. Whoever that is doesn't really matter, right? Those people should be there. So yeah.
That in my last company, people tried to give me titles and then said, you was a team lead now, and like, great, now I'm like, this is my role now, I get a different one. I never changed what I, what I did because of the title was never around, but I always try to help systemically figuring out. What's our bottleneck is it learning is a process, is it? Coding ability is a, what's our
bottleneck? Let's solve that bottleneck first and then move on to the next one, always increasing situational awareness together and at some point people slap titles on you and once Became fully self employed as a consultant. Like, I'm the chief of sticky notes, and I'm the master of Storytelling, like, whatever. Like I just put stuff in there that eases people to see, hey, take it with a little smile and a grain of salt, right?
We can solve all the problems you want, but if you're looking for someone, whose title enables him to help you and the wrong person for your company, because I don't like the culture and I want to be called in because I am mr. X Y there to the DD expert or whatever you need help. I'm able to help. Help. Let's have a call and then we can actually move mountains. If you get me in to teach your programmers. To be better programmers. But you don't want to do the
work tomorrow with them. Then please don't call me that. What I do. Exactly. That's why t.i. sticky notes. And well these sticky notes Here is basically my just my cash that I need for. When I go even storming, just grab a bag of those and yeah, makes total sense. I love it, man. Let's let's run it off there. Is there anything you still wanna want to share? I'm yes, I would like to invite everybody to come to Berlin in October till the Kandinsky
conference that's under www. Kandinsky.com with 3D and it's a conference about the art of business software and collaborative modeling. Domain driven design and coding with a lots of hands-on experience and practice. So I would love to see you there or at the virtual DD community and I'm super happy to engage with anyone on Twitter, so hit me up at home myself, if you want to engage, In discussion. I'm always open to talk to anyone about anything. Awesome, thank you very much for.
Having me, put the links to social zon, the description below. Marco High, myself is probably everywhere, right? LinkedIn, Twitter, All That Jazz but you'll see it there and that's it. Thanks for joining us. Let us know in the comments. What you thought about this episode? We'll see you in the next one. Thanks for listening everyone. If you like the episode, I want to support the show. Don't forget to leave a rating better yet. Share the episode with a friend. Let us know in the comment
section below. What you want to hear. I will make it happen. Cheers.