Create fluidity and get the conflicts out! Conversation with Kenny Baas-Schwegler - part 1

Transcript

Kristof

What do you think is your role in creating coherence in organizations as an architect? How, how are you doing that exactly? Well, first of all, do you think that’s important? And then also like how are you approaching that? Or like, how is that connected to your job in organizations?

Kenny

Yeah, so my job is, well, going down several scopes in the organization and - I’m not sure where I heard it first - the social technical system and the levels of scope and Jacque, I can, I cannot pronounce his full name. The timing of…

Marc

Elliott Jacques.

Kenny

Elliott Jacques, yeah. Thank you! So, I know Ruth Malan talks a lot about him, and I know you do as well. And for me, I like to sit on team level and between team level. And I say specifically between, because I don’t like to use the word, the hierarchical work. On top of it, because I want to get that hierarchy out, but it’s a scoping thing, and I think that’s important. And I like that talk, the Ted talk about systems. You know, I see the teams working as parts in a system, and we need to make sure the parts fit together. And what I see and Marc talked about this, that autonomy is really individualizings things. Right? That I’ve had a team as a consultant that says, yeah, we are all in charge of our own backlog. Well, that’s great. And now they need to change something also on an organizational level, some responsibilities needs to be flipped, right. Instead of we need to solve this. If something happens, we need to solve it now. But if we going for like an event driven, then they need to solve it. So that also means that they need to flip the responsibility. We cannot do that because they own their own backlog. Okay. So you’re actually stuck with parts that don’t fit anymore. So you need to have someone helping with that facilitating that and helping with that solution, where do the responsibilities sit and that, that is the enterprise or domain architecture as you see in this levels of scope that Ruth Malan talks about. And I like to be in between that and keep facilitating that to keep it coherent with each other. So I think that’s important. And I see it with my current customer as well, where the same thing happens. Where PO talks about responsibilities, but are not totally, they don’t see what the impact is on the architecture if something is flipped and the architecture sees it in a, sometimes in a different way, on a more technical level. But I think that coherence is really important and especially setting boundaries, of course.

Kristof

And I think, so I’ve got this hypothesis that’s in the API landscape: there’s been two really big trends. Well, there’s a lot of trends, but two big trends that I wanna focus on. One, one is API first. And we talked a little bit about this with Jabe Bloom also that’s, my assumption is that organizations are trying to replicate Amazon where they’ve seen like, “oh, you just, you tick your small teams and you put APIs around them and then everybody just keeps creating APIs all over the place, and it’s gonna be fantastic. Are you gonna have a platform? Great.” And Jabe basically was saying, but that’s actually not a platform. Actually, AWS is not a platform. It’s a bunch of computing primitives, and they’re not really coherent because they’re, there’s just a bunch of stuff. And if you want to create a platform out of that, you have to fit the pieces together and configure them in specific ways. So there’s this one trend. And then the other trend, that specifically is happening in the API space is this Paved Road to Production, which is the thing to facilitate this API first, which is we’re gonna make infrastructure, make it really, really easy to make lots of APIs. And that’s great. And like, it’s great to reduce friction in these processes, but at the same time, it feels a little bit like, so at the second order effect from these two trends is gonna be just a bunch of API soup, that, that’s not really coherent. Is this something you’re seeing because you’re, you’re seeing this better than… Than me, I think, in organizations.

Kenny

Yeah. So, I have a background in software engineering, actually, electro engineering, where you already had sort of like microservices right together. So when I got into the software space, I’m like, “why isn’t this, so why is this so unstructured?” Because, well, there’s a lot of social interaction too. And that, that doesn’t happen on the sprint board. But as a, what I usually see in the software engineering space, and I teach a lot of Domain-Driven Design where we mostly discuss about domain models and their responsibilities towards, well, you have several names there, the original names, the problem space, right? What problems do our, well stakeholders, domain expert customers, users have, and let’s create bounded context around them, and then see how you integrate these models together. And form APIs on top of them specifically designed towards the interaction with the other models. So it really depends how you create your API depending on the social interaction between it. These are the strategic patterns in DDD. So for instance, a big, huge anti-pattern people call it anti-pattern, which is not the conformance pattern, which is say, well, I have an upstream domain model that I need to use in order to fulfill my responsibility, but I cannot say anything to them. Right? There’s no interaction possible, but I still need them. So that, then you conform and then you say, “okay, let’s not translate anything, let’s use their model as is,” which is a well-known pattern, but it can be an anti-pattern if it’s not designed correctly. But if you design correctly, it’s a cheap pattern. You just need to stay linked. And then there’s the customer supplier pattern. And these have influence on the way you design your API. Because, depending on that interaction with the other teams, I’m trying to be more constrictive in my APIs or a bit more open in my APIs, or a bit more standardized in my API. So it really depends on these contexts. And if you, what I see happening is usually people, when they go move to microservices, they tend to split on nouns or on services, or you get a user service, or you get an account service that, that might still be useful, but you also get an application service. But these don’t really say anything to me. What is their outcome, or what is their promise to me? What are they serving? Right. They’re just nouns. So within the DDD space, we say, okay, but what is, what is it they trying to solve for me? And this is what I usually see the companies I consult is that they don’t think in responsibilities or in outcomes. And Rebecca Wirfs-Brock talked a lot about responsibility-driven development in the past before DDD and I think that’s the switch. We keep talking about services as if they’re systems. So for an engineer that might be, “oh, this is a nice deployable surface,” while for a business, a surface can mean, “okay, what is the surface you’re delivering?” And that ambiguity between the two collides usually, because there’s no shared language, hence what DDD solves. So I try to avoid the word surface and try to more work to what is this thing solving, for instance, I’m solving that I’m allocating seats. So, okay. I’m getting more meaning to my surface, right? And that’s for us is for the DDD spaces, a bounded context for that, you can create an application boundary. So a deployable unit, and here, hence a system, right. System in the is also an ambiguous word. So I try to work on that. Try to split the deployment boundary that we keep. Stop talking in deployment boundaries, because that usually happens in an organization, right? We say, “can you please update surface X with blah, blah, blah.” And that relates to an actual deployment, but rather using contextual boundaries, which are the bounded context, “can you please in a seat allocator at this business rule.” And then we, as software engineers will decide how we’re gonna implement that. And I think that’s what usually I see from that perspective is it’s going wrong, right? So we don’t necessarily have that shared sense of responsibilities anymore. So what is this actually solving? I hope that makes sense. And from there build the API.

Kristof

It makes sense. But I think you’re actually already working with people that got their stuff together, because I’ve seen, I’ve heard teams where basically they, they’re like, we’re a big bank, we’ve got lots of divisions, lots of teams. They’re all doing their own IT stuff. They’re now all doing APIs and we’ve got lots of APIs, like hundreds.

Kenny

I’m working with these as well. Yeah, yeah, yeah. I’m working with these as well. Yeah. Yeah, definitely. And the thing is that they usually also have these big, well, they call it monoliths, but they’re usually big pile of muds. And I’ve been working with a larger company where I give the DDD training there. And I started with one team really small because I don’t like to come in and sell this whole thing. Okay. Let’s just start small with two days and let’s ref- let’s go through a scenario in your, in your case. And let’s see where these contextual boundaries should be. And then they figure out that they have several contextual boundaries and several different APIs before moving. They already have APIs, like SOAP or REST APIs, of course, maybe even GraphQL APIs, and then I try to help them with that case, creating first, the responsibility boundaries, and then they can decide what kind of API they need for that. I get the same thing from engineer because something you trigger, they already have a bunch of APIs. And then at some point they say, “well, we need, we need to know one vision of the user,” and then I’m already in distress. And I’m saying, “no, no, no, but what’s the context of that user. And why would you need it for whom? Bring some more clarity.” And that, that’s what you said at the start, right. It’s creating that coherence, but more coherence on responsibilities. And from there create APIs instead of create APIs on what you already have. And what you’re saying, they’re creating thousands of APIs under current design, and that same creating microservices on your current big ball of mud. The only way you can split it is what you already know. And usually the engineers don’t know anything about the business. So how would they split? On nouns. Because they think those are real objects. So then they get the account service and the transaction surface. And it’s like, okay, but now they’re just creating a distributed big ball of mud.

Kristof

Yeah.

Kenny

And they don’t fit together, but they will make them fit in the end. And then you get more spaghetti between the distribution and then they make it even more complex and chaotic. And that’s yeah. That’s what I usually see.

Kristof

Okay. I think, then, that’s the first confirmation of my hypothesis.

Marc

You were talking about moving from, called the deployment boundaries to contextual boundaries. Boundaries and organizations are usually a reflection of Conway’s Law as in the reflect communication structure or the hierarchy or budgeting, depending on how far back you wanna trace it. But, so, I assume this is not easy to do so moving the boundaries in a sustainable way. So you say you’re going in with the team, you’re working two days, you work through a scenario, start to sort of make them aware of the difference. That sounds a little bit like I’m going in as an agile coach and I start show them how the workflows and make them aware of different ways of looking at flow and optimize it. But, so, my common experience is even you go and you work with a team for six months, once you leave, if you just train a team here and there, six months later, everything is gone again. So how do you make these boundary changes sustainable?

Kenny

Yeah, it is not only two days training for some, for some, it works for some it doesn’t. I had this one company where it worked because I really focused on the bounded context pattern. So instead of the deployment boundaries, think of “what, what is the purpose?” Of course, that’s the start of their whole journey, but if they are already creating boundaries based on language, with a domain model for a specific use in mind, and Eric Evans gives a very well introduction to the Mercator map. That, that’s a model for a specific purpose. So I try to train them on that, but I also try to get the business involved straight away if that’s possible so that they, or at least the PO–we always mention this–so at least the PO also thinks in that and the PO sees the, um, how do you call it? The benefit of doing this. So then you have the whole team there. So I trained the whole team. It’s not a tactical or technical course, it’s really the whole team. And that’s why you have the PO there as well, that can help drive it. Right? If I get, for some reason, a lot of PO have the rank to drive this as well. So as long as I can also get the PO on board, I already have a bonus point if they see the value in it. And a lot of POs I’ve trained so far are like, “oh, finally I have a shared language. And I can go to my stakeholders and give them in functional language, an option that my developers now also understand.” But that two days I only focus mostly on that bounded context. And, and from there, they either pick it up because it already changes in their mind. Right. Okay. Oh, we need, don’t stop talking in this or there’s ambiguity. So I put a high focus on ambiguity in language, and you see the change slowly coming in. And what I do then after the training, we always do some lean coffee afterwards, or I keep in touch and see, how’s it going. Yes, one out of 10 cannot pick up because they in so high cognitive loads that they cannot do that. And then we always apply or always say, okay, let’s, I will go join them for a while. So I have like three days a fixed customer, and I help them step by step being the benevolent dictator architect in that team and help them, and then slowly move towards architecture without software architects. So I’m not sure who, who there’s this, nice, see, I’m horrible in names, but there’s this nice progression of you have four types of architects. So benevolent, architect in the team, architecture by the team and their inmates running the asylum. So, I try to then get inside, be the benevolent architect, and then move them towards that right side and then help them. So that’s also an option. And I try to really focus on mentoring, someone who can take that up. That is my sole purpose by being there. And hopefully that change because I put the design in the team, so I let them design it. They reap the benefit in six to nine months, and hopefully they continue, but, you know, afterwards, you never know because it’s a small team and it’s a part of a larger system again, which is the organization. And if there’s a fractal pattern of not talking to the business, which we also see, yeah. Then, within, within a year, they might be back because they’re, yeah. And then I cannot do anything on that level. Then we really need to also train the organization with them and helped the organization change thinking in these contextual boundaries. Yeah. So either a team is successful because they’re allowed to do so, they have autonomy inside the company, then it’s okay if they’re not. So what you’re saying, the bigger banks, then it’s harder definitely or harder maybe sometime. And we tell that upfront.

Kristof

And, well, we dropped straight in. So like there’s, some of the more introductory questions. That maybe, would be interesting to cover. So one thing that we’ve been asking our guests on, well, you’re one of our first guests, so it’s still fairly, fairly fresh, but one pattern that I start seeing evolving is, well, one question we started asking everybody is how, what’s your experience with complexity. And how do you talk about complexity? Do you talk about complexity with your customers or is that something that’s like, eh, you know, better stay away from the dark side? Or, how is your experience with that?

Kenny

Oh, yeah, that’s a tough one. So I, in my training, I try to give a blunt introduction to Cynefin and talk a bit about complexity to show them, to really quickly help them. Okay. What do you think the problem is and how to approach it? So to say, okay, if you, if you’re in here, we need to do more collaborative modeling. So from the DDD space, we do a lot of collaborative modeling, but I try not to give too much wording to things like I’m coming in and doing Domain-Driven Design. Then you take one session and then you say, oh, this doesn’t work. This Domain-Driven Design, right. Similar to like continuous delivery. Doesn’t work, DevOps doesn’t work here. So I try not to talk too much, but try to help them, experience by doing collaborative modeling. So we do a lot of event storming. And with event storming, you can actually let them experience the complexity. One of my favorite ones, if I, if I can get them on that is picture event storming. That’s how we call it. So, we take like, 15 domain experts, so that can be product owners or business analysts, or actually the, the users, the internal users of the system, into the room of a total business line, get the top engineers and architecture in a room. So you, you’re roughly with 20 to 30 people and we’re gonna event storm their entire landscape. Right. But from a functional point of view. So from a value stream point of view, and that’s really chaotic, it takes a day. And from there they can witness and experience the complexity that’s going on there. And from there, I can help them and guide them into creating some more structure, but also telling them it continuously involves, right? It’s not static. Right now you’re doing it, right now you’re forming your teams like this, but maybe at some point you get a new product, you need to change your team setup. And my current customer, you see it, that they’re having a lot of complexity because something is working that they start up with one year ago, new product. And now all of a sudden, the entire business starts getting on there, think, “oh, this is a new thing we started, needed to work on.” So yeah, the engineers are really frustrated with going left, going right, going left, going right. Okay. New priority here, new priority there. And also the product only, you see switching there. And what I try to help them with is constantly creating structure out of that chaos and having the sort of whirlpool in it. And I do that with mostly either event storming, use story mapping, example mapping, and bringing all these collaborative tools in to create that coherence. And then you always get the, “but what about documentation,” question. Right? “Can we document?” And I said, yes, if something, at some point get fixed, I would love to document it. But at this, at this team, I’m trying to experiment with one big Miro board, they are hybrids. So sometimes I go in a physical meeting, but sometimes we’re in a hybrid meeting. So I create one Miro board where I do all these things and then keep structuring it once we need it. Right? Once we feel we need to structure it, we structure it and then reuse things. And Miro really helps there because it also has versioning things. And that’s how I try to create coherence of the knowledge by constantly collaborating in a modeling session. That’s how I try to not explain complexity, but let them deal with the incoherence of the language at least so that they… And they now start correcting me actually last time I used the word and then the PO came, “Kenny, that’s not, that’s not the word we have been using now. Right. We agreed on it.” “Oh, thank you.” And then I was like, ah, first check box. They started to correct me on the language they’re using in that collaboration.

Kristof

So for you, it is about, so you show complexity through, the lack of coherence and the experience of when things fall apart. Is that, that’s a good characterization?

Kenny

Yeah. And through that collaborative modeling, so I’ll let them basically experience them through a collaborative modeling. And these are really simple events, really simple tool. The only problem is to get them on board with it. That, because it’s a big investment, a full day. But then I showed them the complexity, yes. Through visualization and through letting them in experience the incoherence, because at that point they say, “oh, I didn’t notice. Oh, but you’re using a different words.” But, and then from there create these boundaries and–Jabe Bloom said that, right–dancing with boundaries and negotiating all the time that’s happening in that collaborative modeling session. And try to create architectural decisions out of that. Okay. So we decided that let’s create a structure more in the mindset. So share, shared mind. I tried to document it, but for some reason, if it’s too complex, I’m always running behind there. So I remember one time we finally, after three sessions, got to a really, really simple flow and there was someone who was a bit against it. So we got that person in and “ah, new insight”. Great. Finally, we had it, then I documented in an activity diagram and then one week later I returned and they’re like, “yeah, it’s changed again.” And I’m like, oh no. But at least I did diagramming as code, so I can, I can updated it. So I’m still, yeah. Finding a way to get that out right. To get “okay, should I document it?” And is it helpful or not, but on one way hand, I think so. But on the other hand it changes so fast and… Hope I make sense there.

Kristof

No, it makes a lot of sense. It’s, it’s really fascinating to hear the different answers. Like Jabe Bloom talked about the, having, having something on the tip of your tongue that as like a personal experience of complexity. But in the, it’s interesting that for you, it’s a, it’s a group experience and it’s actually something that’s part of your consulting. So I really, really fascinated and excited to hear what other guests are gonna say because, yeah…

Kenny

See what I can learn from there. Yeah. I’m a really collaborative person try to get them experience in a group. Especially in the, IT, there’s a, usually a more focused polarity towards the “I”. You see it in the whole branching scene and so much against pairing and ensemble mob program. Right? There’s a lot of resistance I see in the community because there’s so much focus on ‘I would just want to sit and code.’ So that’s why I try to focus on collaboration while I do know that’s the other side of the polarity, right. So, you do need to manage when to do what. So that’s also, the problem, but I like to align through these collaborative sessions. Like I love mob ensemble programming. Tomorrow I’m gonna do a refactoring again with four people. I love to create coherence on these smaller ones, but also on the bigger groups.

Marc

That also ties into how Dave Snowden talks about complexity and knowledge management, where he says, ‘In order to cope with complexity, you need–what he calls–multiple scanning,’ which essentially groups of people looking at the same problem with diverse perspectives and diverse experiences that they bring to it. And then you find better solutions. Then you find better attempts to get out of your problems, et cetera.

Kenny

Yeah. And that’s also coming from the deep democracy scene where they also say, ‘Right, get these different insights out because just getting a group of people together doesn’t necessarily work as well with ranking and biases.’ And, but you get better solutions because you get all the–what Woody Zuill says about mob programming, right. ‘All the great minds sitting behind one keyboard, solving the problem.’ I fully agree with that, especially in complex… If it’s a complicated problem, like stable, okay. Let’s just do an analysis, figure it out and implement it. Right. It’s just a stable process. Fine. But where I’m now everything changes continuously. The business changes continuously, the user changes continuously. So yeah, you need to get people together more often, fully agree that.

Marc

You were just talking there about deep democracy. What is deep democracy?

Kenny

So deep democracy was, may created by Arnold Mindell. I think in the eighties or nineties, he’s trying to combine psychology with group sociology and quantum Physica. And some people might, some people might see it as pseudo-science, which it might be, but there’s a lot of good points where you make. And I really like the core of it is what they call role theory. So role theory, there’s several versions of it in the literature. And he calls it ‘a role is everything that you have inside you.’ So it can be an emotion, but it can also be a mother or father role or an architect role. But we all have these and what usually happens in group discussions is that they’re getting fixated on a person. So that person needs to make a decision. And what they’re trying to do in deep democracy is make these roles fluid, right? If someone is like always, always the person that’s going against the crowd, right. The person that’s always against, then that person get labeled and they start ignoring that person. Right. But there’s more to that person. And that’s what role theory. And that’s what deep democracy try to do is true conversation. Try to spread that role and create fluidity in the role. So that not only that person is the nagging person, but also the person that has a lot of ideas. Right. And what usually happens. And I have this example from a training to give a concrete example where, because it’s a training, I sometimes don’t finish the exercises. I sometimes do training on their domain. And that has a danger, because you can get into too much complexity, that you cannot finish the exercise. Right. But at least they did it on their own, and hopefully… So after three times we didn’t finish one. And that guy was like, “yeah, sorry to speak out. But can’t, we just finish it for once?” He was really that harsh. And then you see people like, “it’s this guy again,” so. Everyone probably knows the situation. So what happens then is we usually start ignoring that person. Like, we need to continue, but because you feel everyone’s like, and then I just ask the question. Okay. So what I hear you say is that you want to finish it. What’s the need underneath there? Yeah. Because I like to learn more about this thing. And then I ask the question to the group “who else more in the group has this feeling of this?” And then suddenly people, I start raising my hands to create a visual aid. Like people can speak up and then three others start to do it slightly. And all of a sudden, so first the role fluidity, there’s no role fluidity. That person is like, ‘oh, this person again.’ And then all of a sudden it starts spreading around like, okay, multiple people have this. Okay. So what do we do now? So I said, okay, multiple people have this. And then it starts to solve itself because the group is like, “oh yeah, I can speak up now”. Right. It’s safe to also have this feeling in the group. And that’s the core of deep democracy: is trying to create that fluidity, trying to get the conflicts out. So the unspoken words out, they call it fishes, and spread that spread that need around of the conflict. So that decisions are being made more easy because now we understand each other’s needs, instead of talking about the solution, right. “I want to finish this” is a solution, but what’s the problem. What’s the need? And that’s what deep democracy goes in about. And it’s a really nice facilitation method to help deal with conflicts in groups and help them make better decisions.

Kristof

This connects with NVC, I think. Right? Because like the needs and the solutions. So I’ve been learning about nonviolent communication. It’s the same, the same language that they use, like, what’s your needs, that’s underlying your solution that you’re suggesting.

Kenny

Yeah. Yeah. The only thing that deep democracy does do is that at some point, right, you’re talking about needs and create fluidity, but then it can start to polarize. So it can form two groups at some point. So you have really two options that goes against each other. And what deep democracy then says is now we need to get everything out on the table. So first of all, you need a psychological safe environment to do this, of course, but you go deeper. So now you say, okay, let’s stretch out these polarities. Let’s say everything. Right. But also be mean to each other. It’s fine. So then it’s not nonviolent, but it’s a violent way in a, so just say everything, everything needs to be put on the table. And then from there you go back and say, okay, now that you heard everything, what does that do to you as a person? And what are you gonna do different? So that’s a bit difference in deep democracy, right? You try to, you try to solve it with a nonviolent part, but at, at some point, if there’s no decision being made, that means, okay, we haven’t set everything that has to be set. So let’s see if we can stretch the conflict up. And then. Yeah. So throw out all arrows, they call it. So throw everything you got in this safe environment, right. We call it a safe environment. So that means there’s a few rules that you need to… It’s not personal. Right? But also we finish this exercise. It’s not that in the middle, you can move away. No, we’re finishing this.

Kristof

I haven’t done one of these, but I’ve heard Laura talk about appreciative inquiry. That sounds a little bit like this, although yeah, probably it’s less… Wait, the other thing this is sparking for me is Dutch culture. This is you’re so much more open than, than we are here in Flanders. I would say.

Kenny

You think, but we are rational, open, not emotional open. And going deep takes and more emotional approach. So I think, yes, we are in the Dutch culture is really direct and rational open, but I don’t think it’s really, if I look at myself as well, it’s not really, you, you’re not direct about your fears. Right. So, for instance, I was in a session of my own with my team last Monday, and something happened and I said, well, and I feel myself talking about the rational, right? Yeah. The process wasn’t, I think the process get needs to be better. We like talking about how the process gets better. Right. Then all of a sudden, what am I doing? Actually, I’m pretty sad that this happened. So then I vocalize that I’m sad. but that’s uncomfortable in the Dutch culture. So.

Kristof

Okay. Well still, still learning. I, well, massively appreciate the collaboration, because it’s different and always good stuff comes out.

Kenny

Yeah. Yeah. And that’s what I love. And what they say, a conflict, same as failure is an opportunity to learn.

Kristof

And for me, a conflict is already, we disagree on really rational opinions, right? Like, like for me, conflict is already, I like this beer, you like that beer. Okay. Now we’re in a conflict. Right? Conflict of opinions. So that’s for me is already a conflict, but the harshness of conflicts, you need different approaches. And that’s what deep democracy also says. Right. Adjust your approach according to the culture, you don’t, there’s a structure in it, but please change it to the culture you’re in.

Kristof

Yeah. Interesting. I’ll look it up.

Kenny

Yeah. And, well you have the Arnold Mindell part. So his book “Sitting in the fire” is really nice because he talks more about process work, how to do it in large groups. And then you have the Lewis method. Mirna Lewis. And she picked that up and created a structured approach to it. So Arnold Mindell’s style is really chaotic, and Arnold Mindell’s style is also more about putting up the heat for instance. So if you’re in a group, he always brings two facilitators to take both sides of the process. And he gets out what they call ghost roles. So if a manager isn’t there, okay, I’m gonna put that on the table. While, Mirna Lewis is more a neutral facilitator saying, I’m from everyone here. So there’s two different approaches to this site to facilitation, both work really well because the ghost role’s also really nice. Right? You can put up the roles that aren’t there, but give them a speech to give more insights, but then you as a facilitator show color. So it can also mean, oh, I feel unsafe now with you as a facilitator. So that’s trade off. It’s like architecture, trade offs.

Kristof

Interesting. Very interesting.