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