Jurgen Appelo - The Unfix Model

Speaker A: The agile toolkit. Hi, I'm your host Bob Payne and I'm here with Jurgen Apollo, um, starting the, the podcast for the, the third time I believe. Um, and uh, hopefully we won't have any technical difficulties this time, but I'm really interested in um, talking about your unfixed model and some ideas that you have about organizational design and scaling and the patterns language that you've developed, uh, in that model.

Speaker B: Yeah, um, great to be here Bob. Indeed. Fingers crossed. Hope we have it. We nail it this time. Um, so, um, yeah, I've been uh, inspired by um, uh, Agile scaling frameworks, uh, which um, are um. Well uh, I have a love hate relationship. I always say with scaling frameworks they are full of good practices but at the same time I don't like the way those practices are packaged as things that we need to implement and that we need to roll out in an organization. Um, I am um, a fan of pattern Libra, uh, like team topologies, but also sociocracy and liberating structures and so on. They're collections of suggestions, options. Everything is optional in a pattern, uh, language and you have to build your own method or framework uh, from the available uh, options. And um, as I said, Team topologies was one of the sources that I was inspired by because they offer four patterns for team uh, types. But there's also Dynamic Re Teaming by Heidi Helfand and Network Scale and Agile, another book that offers some structural patterns, um, and more, um, that uh, together at some point came together in my head and nudged me to start doing something about uh, about organization design. Because I thought organization design organizational structure was underserved in the Agile community. The suggestions were rather naive and poor in my opinion, usually resulting in matrix structures. Um, and um, I think we're losing you again.

Speaker A: Um, I can actually hear you so I think we're okay.

Speaker B: Okay. All right. Because you're frozen on my end.

Speaker A: I'm so sorry. I'm going to go off video.

Speaker B: All right. Um, and um, from various sources of inspiration I have started making the unfixed model.

Speaker A: Great. Um, and I know that um, in talking about this in other contexts that I've heard you speak, um, you talk about this idea of a collection of Lego blocks. Um, uh, and that strikes me as a good analogy. My first thought when I saw the visuals for the framework was a bowl of Skittles. And I'm not sure that that candy necessarily translates uh, to your context, but um, it is a very colorful mapping.

Speaker B: Yeah, we um, would have M&M's on this side of the pond. Yeah, but very much the same thing indeed.

Speaker A: Yeah.

Speaker B: Um, and um, yeah the most important thing is that everything is optional. Though of course as in Lego, some blocks are more obvious than others. There are a few types of blocks that you basically use nearly all the time and some are quite specialized. Um, it's actually interesting to know that LEGO offers nearly uh, 4,000 different types of LEGO blocks.

Speaker A: Oh, I didn't realize it was quite that large.

Speaker B: Exactly. You're not the only one. Most people don't even know that it's that there are so many. And that is interestingly enough to create um, uh, more options to offer people more possibilities to deal with all kinds of things that they would like to build. You need a large box of options. Of course you do not use all those 4,000 blocks at the same time. That makes no sense. Actually. The fewer the better. That will be the art of making a nice uh, LEGO model to use as few pieces as possible, ah, out of those uh, wide variety and that, that satisfies the idea of what they call in systems thinking the law of requisite variety which some people say is the most important law for management. That is that a system needs to have a sufficient variety on the inside to deal with all the possible uh, changes that happen in the world outside. Because it needs to respond to uh, an ever changing environment. And the more options it has and um, the more variety the more uh, the longer it can survive in a changing environment. And that I think is sort of the reason why I offer the unfixed model to help people create network organizations that are able to survive in an ever changing environment. And that requires options and flexibility and versatility as I sometimes say.

Speaker A: Yeah, I'm later today giving um, a talk uh, on our webinar, um, at lightspeed and it is called Agile Evolution and the selfish meme. Um, and I sort of bring in this idea of um, creating variation um, uh and needing that variation to be able to find situationally appropriate or situationally optimal uh strategy. So I'm really big, big fan of that and always thought that any of the scaling models, um, any of even the team models, um, for the most part if just implemented, sort of, I don't know, implemented we can just leave it at that. Was uh, potentially a problem because you're not creating a situationally optimized um situation and in lean thinking uh, they never would have looked for that perfect end solution. It was always, you know, better was a, was a terrain that you um, you navigate uh, to try to find a uh, slightly Better solution and that um, so I think, I think you and I are fairly well aligned on that sort of philosophical um, foundation.

Speaker B: Yeah, I think so too. Um, and uh, indeed staying with a systems thinking, uh, complexity thinking, uh, um, background we need to find the optimum in the fitness landscape and that requires us to change ourselves all the time. Uh, and uh, to well to prevent people from having to reinvent the wheel, uh, I would like to offer a set of patterns and that is what Christopher Alexander did long time ago in his book Pattern language in the 70s patterns for, for cities. He showed that every city basically has town squares and promenades and other well uh, known solution. Only every city has them in different combinations because they all have different environments. And that is, is a nice way of explaining what patterns are for.

Speaker A: Yeah, it's interesting. In the agile community we have um, uh design thinking that came out of this idea of a wicked problem also from urban design, uh, space. Uh, so yeah. So where do you um, what's a particular pattern that you feel has been really badly neglected in the agile space? It's like asking which one of your children is the favorite. I know but

Speaker B: um, well um, one of my favorites is uh, about the experience um, uh, of the user, the customer that goes beyond the product delivery that we usually focus on in the agile community. Um, and that's not my own insight. I have that from one of the books where they say that agile transformations have often resulted in islands of agility.

Speaker A: Sure.

Speaker B: Various uh, uh, uh, uh, products, uh and uh product areas that are optimized for their particular island. But customers are not interested in individual products, they're interested in an entire experience. So for example, um, when I, when I make a transaction, financial uh, transaction with, with my bank, I'm not interested in particularly the app or the website or whatever. The only thing that interests me is sending uh, my money to someone. And for that I use a variety of products that the bank offers me. Now I have experiences that are sometimes uh, quite horrific, uh using these various apps uh, from the bank because they do not offer a holistic experience. You can see that the different team creates the app and different team makes the website and so on. Uh, things are poorly integrated uh, individually the app is updated pretty often. Same for the website. But I have literally been stuck a uh year ago uh between the app and the website when uh, the app required me to authenticate myself and change my password on the website and the website required me to validate password with the app and they were sending me back and forth between the two. And that was a typical outcome of uh, Islands of Agility, um where I as a customer I'm interested in the entire experience and for that I offer the experience crew, um, um as I said inspired by uh one of the books Network Scale and Agile that I read where they say uh, some people should have a laser focus on the entire experience with all the touch points that a customer has with the business and that even includes finance that sends invoices, uh, uh, and the service desks and physical stores and so on because the customer has an experience across many different touch points that needs to be optimized and ah that and people in the experience crew could be data analysts, they could be service designers, user journey mappers, human interaction designers, whatever. They should inform the product owners and the teams of those various uh products uh, what are the things to solve uh, across their own boundaries.

Speaker A: Uh yeah, that's really powerful. Um and I've been unable to find this graphic uh but at some point my son was potentially looking at scad, which is um, a fairly um, you know the Savannah College of Arts uh and Design and it's fairly well known um program and they had, there's a, there's a very famous, I think she's Michelin, Michelin starred chef in um Savannah at the Gray. And they had a service map or an experience map uh that was the intersection of the people making a reservation, interacting with front of the house, back of the house. Uh, it also had uh, tendrils coming out for onboarding new associates into those. And it was just uh, it was a really wonderful graphic that I saw when I was there and I've been unable to find um a public ah display of that. So it may have been just something that they have shared um with the restaurant and at their ah, their site there. Um and I think you're absolutely right that that idea of customer experience um is certainly an important one. And uh, the work of folks like uh, Jeff Patton and Marty Kagan among many others in the Agile community have really emphasized that need for not just features, feature factories but um, uh understanding uh, that user interaction.

Speaker B: Yep, I agree and personally I have been more inspired by other communities such as the jobs to be done community where their primary focus is this experience, the job that the product has. They literally say that the, the customer uh, hires a product to get a job done, to get an experience uh, with famous examples such as uh, why do people buy a drill? Well that's not to create holes in the wall. Nobody is happy with holes in their Walls, uh, ultimately it's about hanging up paintings and uh, or photos, family photos or whatever because that's make, that's what makes us happy. So the experience is decorating our house, our homes, uh, that is, that creates the happiness molecules as I, as I say. So the job of the drill is to help us decorate our home. And then once you figure that out then you might come up with alternative ways to help people decorate their home that does not involve drilling holes in your wall, um, but other means of hanging up paintings and so on. So I, I know there is some attention to that uh, idea in the Agile community, but not as much as I would have liked because let's face it, we have a lot of product oriented terminology, product roadmap, product backlog, product manager, product owner and so on. But the word experience uh, is not used very often still. And in other communities they uh, uh, they have been, they're ahead of us.

Speaker A: Yeah. So um, uh there were a number of things that also jumped out at me about some of the patterns. Uh, that was um, to a certain extent intuitive but when you gave it a name it was very helpful. Um, uh, and that's you know the different types of bases. I think in, in um, Agile um, we often look at especially the scaling strategies, this idea of a fully integrated base where everyone is pulling towards the same end goal. Certainly um, you mentioned safe and less. Um, and, and and those two come to mind where we have, you know we're creating a team of teams that is aligned to a particular goal but that only applies to those sorts of uh, problems. Um, where have you seen? Um, I look at licepeed and because we're a consulting company we're probably somewhere between a strongly aligned and loosely aligned base. Um, but where have you seen what companies are great examples of or parts of an organization that are great examples like fully segregated, loosely or strongly aligned basis.

Speaker B: Yeah, so let's uh, uh, explain the idea for a moment. So the whole point of having a base is to have a micro enterprise, a small business unit that is ideally uh, self sufficient and autonomous and small enough for everyone to feel that there is a sense of belonging, that there's psychological safety and trust and respect, uh, and so on. In quite a few organizations this is lacking. Um, my own example and experience is 20 years ago when I was a consultant, uh, sent to a customer, uh, together with three other people from around the company of 4,000 people. I only met them at the client and then we formed a team and I like my team but the only People that I knew back at the consultancy company were my manager because he decided how much I got paid. And I knew the HR person because she paid me right. And I didn't know anyone else in the whole company. And um, Christmas celebration with 4000 people in a big event hall was one of the most, one of the saddest experiences I had in my life where everyone at the table had to be introduced to each other and, and tell each other what they were doing at that company of 4000 people. Um, there was no sense of belonging, what whatsoever. So I quit within a year.

Speaker A: Mhm.

Speaker B: And this is one pattern that I have picked up. Um, you should have a small group of people, whatever they're doing. But people need to have a home, a base. That's why I call it a base. Some people might call it a try, but. Mhm. I understand some people don't like that word because of cultural appropriation or whatnot. Uh, so I've defaulted to base as the term to use. And then there can be different flavors indeed as you said, uh, safe, uh, and less makes sort of the assumption that the various teams that work together on one product that naturally will have to work together as a team of teams, as you said, they form one larger unit. You indeed you can call that the base. But if you have uh, a couple of teams that do not work together on one product, there's still reason for them to feel a sense of belonging in a larger team of teams because um, uh, otherwise they might feel lost. And uh, so one example is indeed uh, the loosely, um, uh, loosely line base. Uh where, well that would be a consultancy company uh, where you have a couple of uh, uh, uh, teams perhaps working at different clients. But they need to know that there is a home to come back to that they know the other people on the other teams. Which is something that was lacking for me 20, 20 years ago.

Speaker A: Sure.

Speaker B: Um, an example of uh, um, fully segregated base that would be um, um, or maybe an R D unit or an incubator inside a larger enterprise where you have a number of teams working on separate ideas that could even be competing with each other. Where multiple teams are trying to solve the same problem and uh, made the best win. It would be sort of a friendly competition. Uh, it's very similar to a games company or the mobile games. For example, I often mention um, Rovio, the makers of Angry Birds in Helsinki. I was there a number of years ago and they make lots of small games. It's just 3, 4, 5 people on average uh, enough for, for one, for one of those games. So multiple games, uh, teams would together form one base. Uh because um, there should be a sense of belonging in a larger group and they are competing because they compete for eyeballs. Uh, a person can only play one game at a time. Um, but management doesn't care which game is uh, winning as long as they have some winners. Um, so uh, it's a friendly competition. Mhm. So those are different kinds of bases. Indeed. I offer four in Unfix language. Uh, um, but the primary reason for having a base is to have that sense of belonging. And there you see also the cutoff point for what some people might refer to as traditional agile. Mhm. Because in 2001 when they got together the 17 gentlemen, they defined the values and principles. Uh, they didn't imagine enterprises of 10,000 people or larger. They were focusing on small, relatively small, a uh, small number of people, uh, working on the software products and uh, and of course individuals and interactions over process and tools. Works well until you have a hundred people or so. Um, if you have 4,000 people you're going to need a little bit more. Yeah people for people to feel psychologically safe and so on. In fact I, I cannot feel psychologically safe among 4,000 people. It doesn't scale this uh, this, this value. Uh, so you need a smaller unit to sort of contain traditional Agile. You could say within one base. Everything that uh, traditional agile says that applies to one base. But if you go to multiple bases and I prefer to scale out uh horizontally, not scaling up, then you need other ways for those bases to work together in a self organized manner. Uh, and that involves other kinds of practices.

Speaker A: Yeah, and that's, that's where I think the work with Holacracy or Sociocracy um, really took uh, that, that idea of a network of nodes and ran with it for example.

Speaker B: Yes. Although um, both uh, Holacracy and Sociocracy, one is a framework and the other is a pattern language in my opinion they do not make the distinction between um, circles at the small level versus circles at a larger level. Uh where at the small level you can do without lots of rules and policies and, and roles and so on because it's all self organized within a base. Um, you can leave a lot of things undefined. Yeah, um, at the larger scale, the larger scale the more you have to define things and, and set the rules. That's why we have government countries because anarchy has proven not to work. Uh, and you cannot just scale uh, self organization as described in the agile manifesto to 100,000 people at the cutoff point beyond the base level, you need different kinds of practices.

Speaker A: Hm.

Speaker B: That serve the same values and principles and that might involve contracting and defined procedures and whatnot.

Speaker A: Mm. Um, what, what is your guidance, uh, for the size of most of your crews? If you're looking at bases being in the, the hundreds or, or you know, low, low thousand, um, size.

Speaker B: So um, in my book Measure Theater O, I once said uh, five plus or minus two. Um, that was 13 years ago. Um, based on the research back then.

Speaker A: Uh, it is funny when I talk about um, the selfish meme. I think that was one of the memes that denied us um, early on, uh, the variation that we probably needed to understand.

Speaker B: Right.

Speaker A: Yeah.

Speaker B: So yeah, five has always for a long time been um, the Optimum 4.6. As Richard Hackman suggested in his uh, work on team size. Um, I think teams uh, have become a bit smaller on average, uh is my hunch. I have no evidence to back this up, but I think because of free mode working and digital technologies that we, or to uh, the smaller end of the scale. So 3, 4, 5 people is maybe more obvious than 5, 6, 7. Of course smaller and larger sizes are still possible too, but if you're asking me about the averages then I think the average has gone down a bit. And uh, that's the crew size. That's, that's the team size indeed that we're talking about the base. That would be, well, anything below Dunbar's number 150.

Speaker A: Okay.

Speaker B: I sometimes say keep it two digits, maybe up to 100. Um, to stay safe. Um, larger is possible, but at some point it's going to break. Um, I can imagine people feeling a sense of belonging among 200 people. Um, not 2,000. I don't know where it ends.

Speaker A: Sure.

Speaker B: To how far you can stretch it.

Speaker A: Yeah. Well, um, what, what are your, um. Because you've started um, pulling in organizational design. Certainly Lyspeed is not one of the organizations that's larger than that number. But most of the clients that we have um, are much larger than Dunbar's uh, number. Um, have you thought about extending the pattern library to look at base interaction and then whatever that. To use the circle analogy, whatever that circle looks like at that level.

Speaker B: Yeah. So my inspiration is uh, uh, higher. The Chinese company that visited uh, 12 years ago while they had just gone through that huge transformation of turning into a network of 3000 self organizing micro enterprises as they call them, of uh, on average between 10 to 20 people, though some are Larger and some are just uh a handful, um but they work together, they collaborate horizontally. And uh, what you can see in how Haier operates these days and there are several books on that company written already, um, you see the same patterns repeating themselves. So if you can uh imagine um a ah new fridge or a vacuum cleaner being launched on the market. One team of 20 people cannot do that by themselves. They need multiple teams, uh ah as the, the makers of the machines. They need factories, they need marketing, uh and whatever. So multiple units in the, multiple micro enterprises in the network get together and they do contracting, they do smart contracting. It is all automated, um but there is no management uh direction necessary uh to to get that organized. They, they decide on these things themselves. If they can get friends in the network to team up launching a new vacuum cleaner or, or a washing machine or whatever, then they can do that. And uh, what you can see is that some form uh teams of micro enterprises, you could say that would be a value stream CL instead of a value uh sharing crew. Um some of those micro enterprises offer platform services to the rest of the network. For example Internet of Things. All those devices at higher, all those machines, uh, they want them to be Internet of Things capable, uh absolutely the most advanced company in the world and the number one IoT company in the world it is often said. And uh, that was one of the constraints of the CEO a number of years ago that everything had to be iot. So of course there are some micro enterprises that specialize in offering those services to the other uh, to the others in the network. So those are platform uh units uh uh like the platform teams and the platform crews within onebase inspired by team topologies. You have platform micro enterprises in the network offering their services internally. Then you even have uh micro enterprises that specialize in the user experience. The only thing they do is watch data, uh detect uh user needs and sell that information to the other units uh so that they can act uh on it. That is what within a base an experienced crew would do at the larger scale that would be uh, experience oriented, uh, basis or micro enterprises. So you see the same patterns repeat themselves. You have some doing platform stuff, some doing value stream stuff, some doing outward facing experience stuff, some work with partners, open um, innovation networks, universities, even competitors and so on. Some micro enterprises are specialized in that, in opening up uh the boundaries to collaborate with others outside of the network and make that talent available to the network. So uh, the same patterns repeat. And that's why I love the idea that it is basically self similar at scale it's almost fractal you could say.

Speaker A: Right.

Speaker B: The pattern within the base, you see them repeating, it's not exactly the same, but it is self similar as we say, um, at the, at the network level. Now higher is unique I would say in that respect. Um, I mean there are 80,000 people or something these days. 4,000 micro enterprises. Um, that is astounding. Um, I don't know any other companies organized like that, but for me they are uh, the example to uh, to follow because they only have two layers of management basically. And that's it. While other companies of that size, they have at least 10 management layers in between.

Speaker A: Yeah, um, I very much like the idea, um, of uh, self repeating, uh, patterns. Uh, I mean when you get down to it, all of the scaling methods for the most part that are prescriptive really look at. If a team needs to plan together, then a team of team needs to plan together. If a team needs to manage internal dependencies and impediments, then a team of teams uh, needs to do that. And, and, and you know, I think it is valuable for. I always emphasize this in all of my classes or, or consulting, you know, that, that um, you know there's nothing particularly sacrosanct about these ideas. They just um, have worked for some people and maybe, maybe appropriate for, for your situation as well. Um, yeah. Uh, and sometimes those are completely antithetical to finding uh, an optimal solution. Um, so I, I always use the term best fit practice rather than best practice. I've always hated that term, uh, for, for a while.

Speaker B: Sounds sound good to me as well.

Speaker A: Yeah. So I um, know that I have been um, excited about uh, unfix. What, what sort of traction are you getting in the marketplace of ideas? I, I noticed that you ended up in Jim Highsmith's most recent book. Um, uh, and just curious, um, you know what the, what the interest and uptake has been for, for you guys. I know that you rebranded your company, um, with that, that branding. So what's the future look like, Jurgen?

Speaker B: Well, gosh, um, uh, the future. Well, I can only uh, talk uh, uh, about what we're doing now. Sure. And only hope about what could be possible in the future. Indeed. Uh, Jim Highsmith included a page or three in his book on, On Fix. I'm very, very proud of that. Um, there has been quite a bit of pushback on certain agile scaling frameworks, uh, among the signatories of the Agile Manifesto. And I think for good reason, uh, good reasons. Um, and I'm very happy that uh, at least, uh, the idea of a pattern language is embraced by one of the 17. At least maybe more could, could follow. Um, the traction. Yeah, we have case studies coming up. I mean I started a year and a half ago, so it takes time for people to find this and start experimenting and exploring. And we uh, are now getting the first results of people reporting back that they made some changes and that they were very happy with what they have done. And then it takes some effort to convince them to create a case study with us. Uh, and then writing that takes a couple of weeks and sometimes months because of all the permissions that you sometimes need, um, and the interviews that you need to do. But uh, yeah, the case studies are becoming available on our blog, so we are quite proud of that. And uh, my workshops, uh, have, uh, have uh, in some cases been selling out. Not a single one has been canceled. So that is a good sign as well. That is, um, I do, uh, I do myself one per, per month. But we also work with partners who organize their own workshops. And next is what I'm working on, the next version of the on fixed model that ah, I hope will be finished by the end of August, uh, to at least have some answers to all the questions that uh, agile scaling frameworks have answers to, but then in the form of a pattern language instead of a framework. So I say that we are on par with what else is out there and people can draw their own methods and frameworks with the available patterns that they have. A much larger LEGO box. You could say to start building stuff and then the next thing to do would be, well, first of all, new, new version of the workshops, of course, but also I want to start, uh, showing pictures of what you could do, um, following the examples of, or the metaphor of lego. Um, people do not receive a big box of 4,000 pieces of lego. Uh, they receive um, examples of what you can make like um, a hospital or a truck or a dragon or whatever. That's what you get, uh, with a little manual on how to make it. And then, uh, people learn, uh, or kids in some cases learn that, that this is how LEGO works. And then it might be a fire truck for one day, but next day they've turned it into something else. That's how it works with lego. Right? That's, that's the fun part.

Speaker A: They've, they've turned some of those blocks into barefoot landmines for parents. Undoubtedly.

Speaker B: Exactly. Yeah. And um, so I would love to follow that example and offer people, uh, um, starter kits, you could say um, with the, with the patterns of the, of the pattern language. Like okay, this is a starting point and this is a starting point but don't treat it as a framework. You're not stuck with it. You're supposed to take it apart and add other stuff and turn it into your own thing because that's when the fun uh begins of organization design. Um, people understand that with Lego. So as long as we follow that analogy then I hope they will also get it and not as with frameworks that they get stuck with a certain implementation and that people are certified with uh, the correct implementation of the framework. Uh, that's, that's not the way I want to go.

Speaker A: Yep, um, in many ways it's very similar to some of the Disciplined Agile work that Scott Ambler and others, uh, did that, that has since been sort of kited over to the pmi. But I saw that as maybe less a little bit of patterns. Also some toolkits. Um, but you know the goal was not to implement any one of them. They were examples of ways of using those ideas together to, to create something that, that would work for you.

Speaker B: Yeah, uh, indeed. Um, I uh, I had a glance at Disciplined Agile. There's also other stuff out there, uh, Eva Jacobson for example and his essence, uh model. Um, so fortunately I'm not the only one who using uh, patterns rather than frameworks. Um, so there's ah, uh, opportunities for collaboration, uh, and friendly competition. All of that is great. Um, but I sincerely hope that the industry as a whole moves away from framework implementation towards more Lego, uh, modeling with patterns.

Speaker A: Yep. Um, and the other thing that I've found um, many agilists are very dogmatic about is this idea and ideal of a um, steady team. How, what, what, what is. I sort of roughly know some of the thoughts that you have on that but where did, where do they get that potentially wrong?

Speaker B: Well, um, uh, I agree there is quite a bit of bias.

Speaker A: Yeah. And maybe I should back it up because it's not wrong in many situations. But where are um, the spaces where that may not be optimal?

Speaker B: Well um, we can see in other industries that the steady team uh, does not work. You know there are no steady teams, uh, at fire departments, in hospitals and news crews, whatever.

Speaker A: Um, airline, airline and so on. Wife was a pilot for many years and you know often she'd be with completely new crew people she'd never flown with.

Speaker B: Yeah. And uh, the environment dictates what is the best uh teaming option. And for sure there are plenty of benefits of having a steady Team the same people working together for a long time. But it is sub optimization because ultimately it is about the experience for customers. Uh, not the team boundary is not the most important thing. Um, and um, I often use um, uh, the quote of um, uh, Martin Fowler who said a long time ago, if it hurts, do it more often.

Speaker A: Right, yeah.

Speaker B: And he referred to a software release as, you know Bob, when we shipped CDs in the 90s, that was incredibly painful.

Speaker A: Mhm.

Speaker B: Uh, so we learned how to do that more often, releasing software and remove all the pain that was involved. And for 15 years I've been part of the Agile community and coaches and consultants have said don't change your team boundaries because you will hurt Velocity and you will hurt throughput. Well if it hurts, why don't we do it more often? Uh, that is not a good argument not to change your teams. That is just dealing with the symptoms. Um, so we have to learn, I think how to do re teaming better. And Heidi Helfand wrote an entire book on the topic because in some cases it makes sense to form new teams. How often? That depends. At Redgate Software, uh, they wrote blog posts uh, about them retaining. Every once per year, um, people voluntarily picked new teams to work for and about one third changed to other teams. And I would call that dynamic teams because the teams themselves remained but people moved in and out between the teams. So the boundaries were permeable as we say in systems thinking. But other uh, examples are fluid Scrum teams. Um, William, Jan Aegeling, uh, another Dutch guy, uh, wrote about um, SCRUM in a, uh, with a team of teams, a team of around 50 people where every sprint they formed a different team depending on the sprint goals that they had. And then um, people picked the sprint goal that they wanted to work on. So the same larger team, you could say the Same base of 50 people with small mission teams per sprint. That is a fine solution. It worked for them.

Speaker A: Yeah.

Speaker B: We have Tesla as the last example. They are extreme. Joe justice does keynotes on the topic. He worked there for a year and he says uh, the teams last for three hours there. So that is re, uh teaming uh, to the max you could say every three hours they pick a new combination of people in the factory to work with and they all self select which jobs they want to contribute to. So different options, different environments, different ways of doing teaming. The steady team has its benefits, but it is not the only one.

Speaker A: Right, yeah, um, we did some work uh, probably eight years ago, maybe even a little longer with a um, big data Organization that was working to help people, um, and help power companies, um, reduce in, you know, household usage. So there um, had some products that would uh, were typically purchased by uh, power companies. Um, and they uh, did dynamic reteaming. Um, well, it was not fully fluid. It was every quarter they would uh, they would completely re team and kind of blow the teams, um, uh, up. And uh, you know, Motley fool for quite a long time has had this um, idea of you just everybody's desk is on wheels and you literally just unplug and there's network drops in the physical plant on power and you just pick up sticks and, and move whenever it makes sense, um, to do that and, and Valve and, and companies like that.

Speaker B: Yep.

Speaker A: Great. So, um, where can people find out, uh, more about your work and, and, and hear you and, and learn from you? What's, what's, what's that look like?

Speaker B: Now the most obvious place togo is unfix.com, uh, I don't think I even need to spell it. Pretty simple. Um, fortunately the domain name was available uh, a year and a half ago. Um, so that's where you can find uh, the model, the patterns that we're working on. New uh, ones are still in development as I said, or a new release before the end of. The end of the summer. And um, there's a community, uh, there's lots, uh, of cards, playing cards available for download in PDF for all the patterns. I wanted every pattern to come with a card so that people can create games and exercises with them, um, digital and, and physical. That is very much appreciated, I noticed. And uh, yeah, shoot me a message in the community and I'm uh, happy to chat.

Speaker A: Excellent. Well, I want to respect the time box. Um, I know we had scheduled um, this to 11, so I want to be mindful of that and I really appreciate having you on Jurgen. Um, I'm looking forward to seeing that next iteration uh, of unfixed.

Speaker B: Thanks for the invite, Bob. Pleasure.

Speaker A: Yeah, thank you very much.