#034 - Jurgen Appelo - designing an agile organisation

Foreign.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I am Jorfanopolo.

Hi Jurgen. Thanks for coming on the podcast.

Thanks for the invite.

For people who don't know you, can you tell us a bit about who you are and what your experience is? Sure.

So I'm from the Netherlands. Originally a software engineer. I have always had a wider interest than just programming. I was never really the geek or the nerd, as some others around me were. I was interested in management and marketing and even bookkeeping and finance. So obviously I ended up in management positions rather quickly. I had been a CIO at the company for seven years, introduced agile thinking there, Scrum and whatnot worked very well. And there I had to figure out what is my role as the manager in this organization because Scrum didn't really tell me. And the only thing I heard was let's get all the managers out everywhere because they're just in our way. I thought it was on the one hand true, on the other hand disrespectful, because we were doing some things to make things work. So that's why I wrote the book mentioned at all. And well, the rest, as they say, is history. That launched my career in the agile community.

You've been doing a lot of agile training through your own business since then in consulting.

I don't do consulting because I'm a really, really bad coaching consultant. I'm a writer, a speaker, I license my courseware materials. That's what I do. So I offer workshops every now and then, always with the aim of getting rid of them, having other people do them, just testing them, coming up with games and exercises and some other little businesses on the fly that I come up with every now and then.

You have a model called Unfix for scaling agile organizations that looks really interesting. So we want to talk to you about that.

Well, we've already figured out that we can have our teams be agile, deliver things end to end pretty fast. But that doesn't make the company as a whole more flexible, more versatile. It doesn't work if the rest of the organization sticks to its old habits in a hierarchical fashion. And let's be honest, putting 10,000 people in a very, very big room and say, hey, go be agile, form self organizing teams, that is not going to work. They need some guidance on how to structure themselves. That's why pictures of organizational designs are so popular, because they give people an idea of how they could form themselves in teams and groups and larger constructs. In order to get things to work. That's the problem that I am trying to solve. The managers and HR and others like to have some inspiration on how to redesign the way they do their work as an entire company, not just as an agile Scrum team.

Okay, let's talk through your unfixed model. So for the listeners, I really urge you to go and have a look at the picture of the unfixed model on unfix work because it's going to be so much easier for you to understand if you do that.

So I use them the metaphor of Lego. What you see is just one thing that you could make with the individual elements of the Lego box. Another metaphor you could use is the pattern language for organizational design. The most foundational one is the base, or as some people call it, the tribe. I have that concept from the Spotify model. I find it very important that there is a sense of belonging in the organization. This is a concept that is not addressed in most of the familiar agile scaling models. It is not in say it is not in less, it is not in some of the others. They focus on what is the product group. What is the group of people that together is making one product. And if that happens to be a very small product that could be made by one team, then great, you just need one scrum team and that's it then as far as safe and less are concerned. Okay, that's it done. So for me the base is the container where you have a sense of belonging and a sense of trust, where you can say, I trust everyone around here. So think of the analogy of airlines. They have crews managing the flights. At some point the crews go home, then they disband, their work is done and then they're back in the base. So that's base. Tribe is the same thing. You can use the word tribe if you want.

So can you give us an example of a base then?

Any group of people between 10 to 150 people that together would feel they belong to each other. That could be a business unit. It could be the entire company. If the company is 100 people, then the company is the base. There's this sweet spot of between 100 to 250 is a very rough rule of thumb. But around this order of magnitude is where people feel belonging and trust.

And you have that base organized around business market, product facing.

Yeah, so it is business oriented. Could be a product area. If it's a very large product, if it's one big SaaS platform, then the base would be maybe around campaigns or Something like that. And that would already involve 150 people. But if it is a games company with many different teams making tens, maybe hundreds of games, then you need some other kind of blustering of who do we keep together? Well, maybe everyone who's into mobile games. That's around 100, 150 people.

Okay.

Also then you could say that would be a base.

All right, so what are the other groups?

So I took great inspiration from Team Topologies. Manuel Pais and Matthew Skelton did great work there. But when I wrote Management Theoret O, I didn't get further than teams should be value units to others, either to customers or to other teams. And that is still true. You always need to have a customer, whether it's external or internal. But what Matthew and Manuel did was they defined that actually there are four kinds of them. One is the end to end value stream team. I call that the value stream crew. That's the same thing as the yellow one. I even use the same colors just to stay true to where I borrow the ideas from. That's the Scrum team, the canvab team. That's the most common one. But there is a reason for exceptions. An example is the coaches team, for example. They go across the scrum teams. I call that an example of a facilitation crew. They facilitate the other crews to get their work done by being their coaches, their mentors, maybe by helping them with product ownership or whatever. It could be even something technical that they helped them out with, like DevOps might operate in this way. So it's just the pattern of this crew that goes across the others is the purple one. And I call that the facilitation crew in, in onfix. And then the red circle is the capabilities crew. In Team Topologies, they called it the complicated subsystem team. Well, I mean the same thing. I just have a different word because I think complicated subsystem team is not something that easily rolls off the top. And in my opinion, it is about capability that you offer. You have a small group of people with a certain talent. It could be cybersecurity experts that are very expensive, hard to find. You only have two of them and they need to be available for seven different Scrum teams. It could be data mining expertise, it could be AI machine learning talent, it could be whatever. I had a case like that with two top rated designers and we had seven Scrum teams. How do you spread two, two highly rated designers out across so many Scrum teams? Well, you tell them you are Your own little unit, make yourselves available and let nobody else complain about you. That's your job.

So that's what the capability team is for. You have a rare capability. It is an expensive capability. It might be something technical, like complicated subsystem that they are responsible for, but I think it's. It is a bit more than that. It is just a talent that you need to have across all of them.

We usually want the specialists to be in the team full time.

So that is indeed the suggestion that I hear, particularly from the less community. I know from experience that it doesn't work. I had two highly rated designers. If I told them, you going to sit part time on seven different scrum teams, just move your chair around several times per week, they would have quit their jobs. That's not the way they want to work. They wanted to be with each other, be their own little unit. And actually, from a business perspective, this was also the smartest decision because they actually grew and they became their own design unit. Ultimately, they even were pulled out of the base and they became their own company offering their own design services to clients. So I think it's perfectly normal to have such a small group of people work autonomously and offer their services to the other team.

So would you say the difference between the capability crew and the facilitation crew is. The facilitation crew behaves like coaches. They're there to improve the skills and capability of the other crews, whereas the capability crew is more like a bunch of consultants. It's a consulting capability. It makes sure that the other crews are happy, they're getting the services they need, but they're not focused on crop skilling or upskilling or enablement. They're focused on getting that job done, because that's a job that has a scarcity of resource. And if the teams upskill over time, then you probably need less of that capability crew. They should disappear if the organization covers scarcity over time. But for a while that scarcity will exist. So it's a consulting group.

Yeah, exactly. It's. It's a bit of a nuanced thing. It's. It's not as binary as the picture suggests. I can imagine a. A group of two or three people can interpret themselves as either facilitation crew or a capability group, depending on how they behave. That's totally fine with me. It's just that when your main thing that you do is coordinate, you collaborate across the teams, because it helps also these teams to work with each other, then what you do is Facilitation across those yellow value stream crews. If the thing that you do is offering your talent because it is rare, if that is the emphasis, then I call it a capability crew. But as I said, it's a nuanced discussion.

I would think that it makes sense if they're specialists and it doesn't make sense to put them full time into a team because the team doesn't need them full time. But I would worry a little bit if we took people who could be full time in teams and took them out and put them into a capability team, because then we're going back to a functional structure again and there's too many dependencies. But I think if it's specialists or part time on different teams, it makes sense to me.

Yeah, but I think you said it yourself, if they could be full time on each team, then it's not a rare talent anymore because then you have apparently enough people to put one on each team. The whole starting point of this discussion was that you don't have enough of them. You have only two or three and you have seven or 10 scrum teams or whatever. How do you deal with that? So this is the response to that situation. You don't have 10 cybersecurity experts for 10 teams and also indeed, they don't have enough to do.

Yeah, understand. And the value stream crews we went over very quickly, but they are basically your long lasting cross functional.

Team that can build a feature from beginning to end.

Yeah, yeah. That's the Scrum team, the Kanman team, the Agile team, unless they call them the feature teams. The one thing I like to disagree with is the idea of long lasting. We could have a separate discussion there because I also incorporate the idea of dynamic re teaming which is getting more popular these days. So those crews do not necessarily have to be long lasting. Like airline crews are not long lasting. They go back to the base and they form new crews and they go on another mission, but together as a larger collective, the base. They are responsible for the entire product or whatever it is that they are managing together.

So do you want to talk through the other parts of the model we haven't talked about yet?

Sure. The platform team is the last one that I borrowed from from team topologies. At some point, the amount of stuff that we are responsible for as agile teams gets too large. There's a lot of architecture, the infrastructure in there. We push that out into a separate team and we call them the platform team. I have gone through exactly that transformation a long time ago where we had Multiple webshop teams making a collaborative webshop architecture together that became a platform, it became a platform team, that even became a platform company. And that company became bigger and than the original project oriented company that it grew out of because platforms scale much better than projects. So the platform team should basically see the agile teams as their customers. They should offer them an API and SLA and what you would expect from any kind of platform service that you use out there. As an engineer, governance is the management team. This is my attempt at defining where management goes. As I always said in management 300, even as the same color, by the way, blue as the management 3.0 color. That's the only place where the management goes, where composition, hiring, firing, that kind of stuff is determined. And also what the constraints are around self organization. Do we do dynamic reteaming in our base? Yes or no? Those are management teams. Decisions of how do we structure ourselves within the base so that great things can emerge from self organization. So the managers go there and they should stay out of everything else. And I say that specifically because with other models they do not tell where the managers go. They often intentionally say, well, we're not touching any management relationships. No line management function is addressed here. And that means as a side effect, you might end up with a matrix organization where you have managers anywhere in the picture hidden. They could be on the same scrum team because you're not changing the management reporting lines. And those are anti patterns. To have managers on your scrum teams or to have a product manager who is the functional manager of a product owner, for example, which is typically what you could end up with when you do the scale framework. These things are not allowed. Those are anti patterns. I say the managers go in the blue box. That's where you manage from and stay out of everywhere else. And that is also because from organization design theory I learned that a side effect of the matrix organization is that many more issues get escalated up the hierarchy because middle managers are unable to solve problems for their scrum teams because the people on those scrum teams have different managers, they escalate things up. Those managers don't even know each other, they don't work with each other. So they escalate up and before you know it, things end up at the CEO's desk. I had exactly this problem reported to me two weeks ago by someone in a workshop. He said, my CEO is this is solving the most ridiculous simple issues of scrum teams because everything gets escalated up to him through different paths, sideways. Because the middle managers cannot Solve anything. It's a matrix. And so the interesting unintended side effect of matrix is that you make the organization more centralized. Guess what? That's what we never wanted with matrix structures, of course, but that is the outcome. Reportedly users or people who are in matrix organizations and also as reported by organization design theorists. So I don't want this. I say there's the governance crew that's just one layer up from any crew. That's where you find all the managers. They work on one team. They should be able to solve the problem with each other. There's no further escalation up of uncaught exceptions.

So just on that, the governance team, the management team, there's more than one of them. So how do you create demarcation of decisions where you got more than one chief? How do you manage the decision making at the chief table?

I don't define how a management team should do their decision making. I think they are adults, that's why they are managers in the blue team. If I am required to help them to solve problems with each other, then something else is wrong. However they get their work done in that blue team, that's up to them.

I would think that there are going to be times when the base is not able to solve all of the problems that they have. They could be dependent on other parts of the organization. They may actually need to escalate things higher up. So I'm assuming that in that case the governance crew can go to another level if they have to for things outside the program.

Yeah. So how does this scale up further? That is another thing that we could discuss in a moment. How does it work beyond one base? But indeed I assume that the base is as autonomous as possible, that they can make nearly all decisions by themselves, but there will be dependencies on other bases. If it is a larger organization for sure. But then it is not a problem of a crew anymore. It is a problem of the base that it is not able to solve by itself, which makes it a problem of a different nature.

All right, well what's this Experience crew and acquisition crew.

Right. I have noted, and with me many others before me, that even if you have a number of agile teams that try to optimize their own part of a product, you could still have a customer experience. That sucks. Either because the agile teams do not collaborate with each other well enough, which means that you have wonderfully optimized individual product areas, or maybe like a fantastic website and a fantastic app. But whoa. The person who tries to navigate between the two, that doesn't really work well. What we have done in the agile community is we have changed functional silos for horizontal silos. There was many reports of that. On top of that, many agile models look only at the products. It's product roadmap, product backlog, product owners, product management, etc. But what about the other parts of the experience? I removed an app from my phone which was a shopping app. The app was fine, it was great, nothing wrong with it. But when delivered my groceries, an item was missing and that happened three times. And it made me so angry that I had to go to the supermarket after all to get the missing item. And I said, why bother shopping through the app then? Because this is just costing me extra time. I deleted the app. So it was logistics that dropped the ball, not product. It was another department that was also the partner with a touch point towards the customer as part of the customer experience. Sometimes it's finance that drops the ball, sometimes marketing, sometimes it's customer service. The customer experience as a whole is more than just using the features. And there's many examples of these. I have the great bank that I use. The website is great, the mobile app is great. Between them, it sucks. If you want to go from one to the other, that is simply not optimized. So the experience crew has that responsibility. What is the customer journey and what are the pain points that we have to solve? Because things fall between the cracks of those agile teams.

Why wouldn't we do the same thing for software architecture as well?

Depends on how you have solved software architecture. If the architecture is in the agile teams, then you do that through a facilitation crew. So if those 5, 6, 7 scrum teams are responsible together for one shared architecture, then I would suggest probably you want a facilitation crew that facilitates those different crews working together collaboratively on one architecture. But it is an inward facing crew. It does not look at customers, it looks at the teams for them to collaborate. If you have a situation where you push it out to a platform team, then this is the mission. That is what they do. They optimize that architecture, that infrastructure for the other team. So you have solved it in a different way with another pattern from the pattern library. So yeah, you're right, that is just as important. I identified the problem on the customer facing side. The acquisition crew, by the way, is exactly the same on the other end, supplier facing everyone that you sign contracts with, vendors, gig economy workers, freelancers, whatever, they have an experience with you as a company. And in my experience that can Suck quite a few times as a supplier or vendor. To survive in the 21st century, you need to solve that part of your business as well, so that it is a joy for business partners to work with.

All right, you've got on your diagram roles called captain and chair. What's that about?

Yeah, so I have personal experience with a self organizing team that was so self organizing that they wanted to be with every meeting with any outside stakeholder because it was very democratic and they wanted all to be involved. But as a side effect of that, it cost them a lot of time just to schedule a meeting with an outsider because they had to figure out who was available when. And I said as one of those outside stakeholders, this doesn't work. I would like to speak with someone tomorrow. I don't want to wait two weeks for you all to check your calendars. This is not agile, this way of responding. And the very common pattern for this is to have a proxy, a representative, a liaison, a linked pin. There are many words for the same pattern. When our country, the Netherlands, represents themselves at the United States, we. We do not send half the country, we send an ambassador. That's the more logical thing to do. You send one person, that person represents us and we trust that person to do a good job. In the airline industry, that's the role of the pilot. The pilot has communication with the tower and does the relaying of all the messages to the rest of the crew. That does not make the pilot the boss of everyone else on the plane. He does not decide the salaries for the stewards and stewardesses. No, that person is the pilot or the captain for that mission, in charge to taking off and landing that plane safely and to be a point of contact with the outside world in certain cases, that's the analogy for the captain.

So are they like a team leader then?

Whatever you want. It could be a product owner having this role, it could be a team leader having this role. I have written a case study on pipedrive in Tallinn, Estonia. They have mission leads, so they have crews or missions that exist for three weeks to five months, somewhere in between, until they're done developing a new feature set. And then one of the technical people, a technical person is the mission lead for that mission. So that person is the captain. It is not a product manager. One of the engineers leads the mission until a safe landing. So it's context dependent, but someone has to be the proxy for a time.

So that person's fronting the team. When one person needs to front, it's not the manager so that person's not in charge of telling everybody else what to do. They're not accountable on their own for delivery. They're the person that has that role of ambassador.

Right, exactly.

And then we got chair.

Yeah. So the chair is the moderator of the forum. The forum is the same as the chapter or the guild in Spotify language. Notice that the Spotify model is basically a matrix organization, because the chapters in the Spotify model have chapter leads and they are managers in the original thinking behind that model. This has already proven not to work very well according to many reports. So I push that out that there is no chapter lead in a chapter and then basically there's no difference anymore between a chapter and a guild other than scale. The chapter is a place where you discuss your specifical functional area as a developer or as a UX designer, for example, to coordinate UX stuff across different teams. Someone will have to moderate the discussions, maybe a senior UX person or something who has been voted as the one to be the moderator and to make sure that everyone gets together every now and then to do these development of guidelines and learning materials and stuff like that.

So what we often lose when we move to this Agile way of working is care of people. I call it pastoral care, but it's that understanding if somebody needs somebody to talk to or they need somebody that's going to help them progress their career, where they want to go and what they want to do. Outside of the value stream of the crew and within the Spotify approach, it seemed like the chapter lead was that pastoral care leader. So in the unfixed model, where does that live? Where does the feeding, watering, loving and nurturing of the people live in the model?

Well, looking back at what I have always Suggested with Management 3.0, detecting the need for this is responsibility for the managers. They need to understand that people have a desire to be helped with their personal development and other concerns that they have as employees. It doesn't mean that they have to do this work as the managers. They can delegate it. They can delegate that to mentors, they can delegate that to a people development crew. And those would then be examples of either a facilitation crew or a platform crew. If you have a couple of people, or may, it could be just one who is the mentor for.

Everyone in the base and helps them with their personal development and finds learning paths and whatever talks about their private issues that they maybe don't want to talk about with the managers who decide on their career progression and composition. That will be a platform service. Or a facilitation thing. Either of the two, in my opinion. So you're just reusing the patterns that we already discussed, only for a different area of concern, which is mentoring and personal development. That's up to management, that's up to the blue team. They need to decide which of these patterns that we have as just a couple of them that we can repeat, using them for different instances, different things we need to solve. And one of them is people development support.

So just before we deep dive in some of those things, prioritization of work to be done, is that sitting in the blue team, is that a governance call on the trade off decisions on what the next priority is?

No. Another thing that I borrowed from another source is the four kinds of organizations that I have named. The fully integrated base, the Lucio line base, the strongly aligned base, and the fully segregated base. And a fully integrated base is the one where everyone works on one product. The situation that safe and less are created for. You have multiple Scrum teams, they all work on one thing. It is probably released in the cadence. And then I can imagine that management, the blue team is more involved in what is actually happening here in terms of product prioritization, etc. If you have a strongly aligned base, that could be perhaps a SaaS platform with microservices teams, they don't operate in the cadence. Pipedrive is an example of that. They have teams, they deliver multiple times per day. They don't depend on each other, but they need one mission, one goal to work to. Then management. The blue team is probably still a bit involved, but already more is delegated in terms of priorities to those yellow teams. It changes when you switch to loosely aligned base because then those different yellow scrum team, they work for different customers. It could be an outsourcing company, for example, a hundred people and you have 10 scrum teams. And they all work for different customers. They are hired per Sprint or whatever. Many of it is not involved other than invoicing and finding customers. They're more involved in sales and marketing then and not at all in features. Prioritization for customers is not their job. And then the last one is the fully segregated base is where the base could be an incubator, maybe a games company, where all those teams could even be each other's competitors because they could be competing for the same customers. I was at Rovio in Helsinki, the makers of Angry Birds, and they make many small games and game players can only play one game at a time. So those agile teams compete for eyeballs and There is no prioritization going on at the management team level. It's like, okay, let a thousand flowers bloom and may the best game win. It's up to you. It's friendly competition. So you see, the model captures more different kinds of organizations other than just we have a big product that we need to cut up, some in multiple teams. And depending on what kind of organization you have, it is quite a range between a large scale scrum product oriented product versus an incubator with 20 different startups in one unit that creates a sense of belonging for them as a home for those startups. And there's different options in between. So depending on those, you'll have to figure out for yourself how much is the blue team involved in prioritization and strategy, because those are very different situations that we just reviewed.

I mean, this all makes a lot of sense to me. I've used this sort of model both for a digital agency, which would be your loosely coupled model, and for a tightly coupled product team that just needed a lot of people working on different parts. So that makes sense to me. One thing I wanted to ask you about was the chapters. I continue to use chapters. And the reason is that nearly all the organizations I consult with have a functional structure. And if I say to them, your function's now a chapter and you're now a capability manager, you're no longer telling people what to do in detail, but you're managing the capability and doing the pastoral care and recruitment and all that sort of stuff that makes them much more comfortable than a model where we say there's no functions anymore, you don't have a job. Plus those people are actually very useful, very good at that sort of thing. So maybe it's a transitional model to what you're talking about. We had Jason Yip, who's a senior Agile coach at Spotify, and he said that Spotify has now moved from chapters to the model you're talking about. And people management and capability management is now done within the tribe, which is similar to your base. I'm consulting with the client at the moment where I'm encouraging them to do as much capability management as they can within the leadership team for the program. But there's still an important role for the functional managers outside the base to build the capability for the base to then use. Does that sound reasonable?

Yeah, absolutely. It sounds perfectly reasonable. The chapter does solve an issue in the sense of being an intermediate step for functional departments towards a full self organization. It is a forum, we get together, someone moderates it and then we talk about our function or a technical expertise. Or it could also be a geographical area, the North America Forum or something like that. But the functional forum is a special case because this could be the successor of the functional department, indeed, as you said. And that gives functional managers a way out they can see. Okay, so for a time being, I could perhaps be that chair of the functional forum. I might lose a couple of rights that I had for the time being, but they promise me that I will move into the blue team, the management team at some point and then I will be a manager still and someone else will take over from me as the chair of the functional forum and we will undress that role even more. So that it is indeed only ceremonial, basically in terms of hey, let's meet and talk, because that's basically what the chair does. And then the functional manager should have found a new home as part of the management team and work as a team member instead of a protector of his or her functional domain.

Yeah. So you don't see a longer term role for a capability manager who's sitting outside the base then?

Depends on what that definition is of the capability manager. If that person hires and fires people with a certain capability and decides on their composition, that should go into the management team of the base. Because you do not have an independent business unit that is self supporting if you leave that out. And this is heavily inspired by companies such as Haier, the huge Chinese company, one of the most successful companies in the world, where they have 4,000 micro enterprises. And every manager of a micro enterprise decides on who is working within that micro enterprise. Why did they get paid almost full autonomy? Because you cannot be fully autonomous and move fast as a business. If you are forced to purchase services from within the company at an established rate that you cannot negotiate, then good luck with your business agility. That's never gone.

So.

You talked about dynamic reteaming. There is a theory that teams take a while to form. Once they're together and they know how to work together, there's some magic that happens. And as soon as you remove or add a member, we lose some of that magic. But you've said you're a strong proponent of dynamic reteaming. The way you described it is they hop on the plane, they go and do the tour of duty that's important to them. They come back to their base, they reform. So how does that work? What's the benefit of doing that over the cost of having to reform those teams?

Yeah, so this is a hot topic nowadays. Heidi Helfand wrote a book on it. Dynamic reteaming. I see examples popping up. Let me describe the example that I have encountered a Redgate software do dynamic reteaming once per year. They make it an annual event where people can choose voluntarily to work on another team. And their statistics say about one third of the people decide to work somewhere else because they like playing with new technologies and work on their personal development. That's a personal thing to choose and do. That the impact is not so big that it hurts teams for longer than two weeks or so. So yes, velocity drops a bit, but they say customers don't really notice. And the benefit of people feeling that they can decide for themselves where they want to move is greater than the drawback of that temporarily hit in velocity. Another example is a pipedrive. They have mission teams. Some missions take a couple of weeks, others take a couple of months. Again, engineers volunteer to sign up to a mission. One of them volunteers to be the leader, the mission lead captain for that journey. And then when they're done, they return home to what they call the launch pad, which is basically the maintenance team. That is the team that stays home taking care of technical debt, small issues, whatever. And then they insist that everyone rotates all the time. So if you've been On a mission 1, 2, 3 times, you'll have to go to the launch pad and work on maintenance for a couple of months. If you've been on maintenance for too long, you have to go on a mission. So there's a continuous rotation of engineers between maintenance and missions. And that happens within tribes that are more or less 20, 25 people. So there's relatively small bases where the entire base takes care of the sense of belonging. The code, infrastructure, etc. Is just within that 25 people. They reform in different temporary units.

Yeah, I think there's a big problem with that approach when there's a lot of learning required for the team that you're going to work in. So for example, there are many teams where there are specialized tools, specialized software that they're developing, specialized problem set where it can take 12 months to really learn it. And people just aren't effective for the first couple of months because they need deep knowledge. And if you move people around from one team to another, if the two teams are working on a similar area might be okay. But even then there's going to be quite a ramp up period. But if they're not particularly similar, then I think that could be very ineffective. I have seen a lot of engineering companies where there is A big ramp up. And so we want to keep people together so that they can be much more effective and not just spend all their time trying to work out what the hell is going on.

I understand. I just think that argument is too easily used in the Agile community as if the whole contexts are like that, which is absolutely not the case in team topologies. They call this cognitive load. And they say there is a certain area, a certain amount of code, certain amount of knowledge that you are responsible for as a team. You don't want to swap knowledge in and out of your head all the time because that is a waste. I completely agree with that. But that is why at Pipedrive they found that the optimum for them is about 20 to 25 people. They found that with this number of people, the amount of stuff that they are responsible for together is not too much to swap things in and out of memory. So it doesn't matter where they work within those 25 days. Work with the same code stack, they work with the same code base. So this argument doesn't hold up in the pipedrive kit. And I have to stress there that this was the reason that pipedrive did their original implementation of reteaming. Because the CTO said to me we were struggling with people quitting their jobs. The jobs were not interesting enough for them. They continuously want to develop themselves. Those engineers, they wanted to work on something new every now and then. And if we tell them as managers, sorry, you have to stay on your own team, it's long lived team because otherwise we destroy velocity. They're going to quit their jobs. They were doing that now where is your velocity when people quit their jobs all the time? I mean that should be obvious that this is not what you want. So it's better to take the hit and figure out how to do dynamic retaining well instead of just forcing people to work on one long lived team or as the less website even says, forever quote unquote on the same team. I don't want on a team that is works together forever quote unquote. I want to develop myself and use new technology stacks every now and then. I want to volunteer for that and I feel that I would like to something new. So we optimize for the employee experience and we take a little bit of a hit sometimes in terms of dropped velocity, maybe for a couple of weeks or we have to synchronize technology across the company somehow so that it is easier for people to move around.

I think it depends on the context, it depends on the problem. You're trying to solve. Because if learning is a really big problem in your organization, then you want to keep people together so they can learn. If the really big problem is people getting bored, then more moving around. Probably a good idea.

Exactly. So it's context dependent. Figure it out. I just say you need to consider the benefits versus the drawbacks of re team because there are benefits and drawbacks involved and you need to weigh them against each other and not just disregard or dismiss reteaming out of hand because you haven't even considered what the potential is there. You have a faster response time to organizational or environmental changes. Pipedrive are super fast at responding to environmental change like Covid happening to them. That was easy for them because they were already talented in terms of reteaming, no problem. That's a benefit you have in terms of business agility.

So a lot of organizations are outsourcing their software development to another company in India or China. How does that fit in with this model?

Interesting question. Well, for now I have only defined what is the base level. So I thought that was the most important thing to address. How do you organize yourself within a unit of roughly up to 150 people? That entire unit could be an outsourcing company in India and they have clients in the west that they work for. And so that's why you apply this model. You can also apply the same model to the clients in the west that just don't do sovereign development. Because the unfixed model is not just for software. It just describes stuff happening in an organization where you create value, whatever kind of product or service that you are making, there's a split somewhere there's a vendor and there's a customer and they both can apply unfix to their own context. I think Agile has solved the problem for small companies. There is this built in assumption in the Agile Manifesto. Individuals and interactions over process and tools. That's great, but that works when you trust everyone. And guess what? The human brain is not equipped to trust 300,000 people. And there are companies that large. So you need to figure out okay, how do we do this then with 300,000 people? Then at some point we'll have to introduce processes and tools and defined ways of working with each other across the base. One of my big inspirations is hire the Chinese manufacturing company. I've been there 10 years ago. I spoke with CEO Mr. Zhang. He wrote the forward actually of the Chinese translation of Manchu 3.0. And at the time they were already switching to their model of an ecosystem of thousands of independent Units. It's a network, a genuine network of micro enterprises. They have multiple HR units, they have many marketing units, they have many manufacturing units, and they all somehow find each other in that ecosystem and do contracting with each other, smart contracting. Because beyond 150 people, you cannot just trust everyone. So you'll have to sign contracts with other parties, even within the larger company called higher. And this scales like crazy. They are one of the most innovatively managed companies in the world and continuously outperforming everyone else in the market. And that's because they are a true genuine network organization. They have 4,000 bases and they have no middle management. There's only one layer of managers, basically between the CEO and the basis. And they have lots of platform bases, for example, that just offer platform services to the other bases. My hypothesis is that what you see within one base, those patterns of how to work with each other, you replicate them in a fractal way to the higher level. So you could say we have some bases that help with facilitation across other bases. We have bases that help with the customer experience. We have bases that focus on architecture and infrastructure. They do platform work. Those are platform bases. We have bases with special talents. They do data mining. They offer that capability to the others. Those are the capability bases. I see exactly the same patterns appearing, but then in a networked way where they find each other and have temporary clustering. That's what happens at Haier, that they have temporary clustering of bases to make computers, fridges, vacuum cleaners and all those things because those products are too large to make as one micro enterprise. They make them as clusters of bases and they find each other.

Yeah, as you're talking there, I could see that one of the reasons their network is working is because even though each of the bases are delivering a different thing to a different internal or external customer, they're all internally working using the same pattern. So when you work with another base, you intrinsically understand the driver and motivation and how that base works versus working with an external organization that's based on a hierarchy. Because you just wouldn't understand how the decision making criteria is done. You wouldn't get the fact that things take so long, so you wouldn't build it into the way you work. But if everybody in the network in the hive is fundamentally working the same way, then there's that shared language, that shared understanding of what it takes to get something to done.

Have you read Maverick by Ricardo Simbler?

I think I read his other book, the Seven Day Weekend. Maverick was still on My list. I never got to read that one.

So he talks about how he turned his father's company into something almost exactly like Hive back in the 80s, I think, or 90s, during a time of economic collapse in Brazil. He set up all of these small business units. They all had to have their own revenue and costs and profit, and they had to survive partly by selling things to each other, but also by just going off independently into the market. Some of them died and some of them thrived, but overall they grew a lot.

Exactly. Yeah. Because you turn the hierarchy in a network, and a network scales horizontally and not vertically. It makes perfect sense from a complex systems perspective. And indeed they say exactly the same at higher. Each of those micro enterprises is allowed to go outside. You should not feel forced to purchase servers internally in the organization that is non competitive. If you find an outside provider, you should have the right to go with them. And that also applies to hr, that applies to marketing, that applies to recruitment and whatever. So it's liberating the managers of the bases, they are responsible for survival of their unit. So they have to make sure that whatever services they purchase elsewhere in the company are competitive. Otherwise they can just go to the market and get those services there.

I think that would be incredibly liberating and I'd love to work that way because I've worked in so many big organizations where you have to use some really crappy internal service that's super expensive. And why do I have to use them? Why can't I go and work with these other people who I know are great and who cost the same or less than you do and can do it in one month instead of your 12 months.

Exactly. And that's because someone up there thought it would be more efficient.

Yeah, greater utilization.

Exactly. Well, we already know that communism doesn't work. The Soviet Union proved that this kind of management of the market will fail. So Haier has proven this concept. Ricardo Semler has done this. Others have done this. I just define the patterns. Unfix is a pattern library. That is, I think, the best description is not even a framework. Some people automatically refer to everything as a framework. But frameworks such as safe and less, they're one picture. This is how I shall organize their company. With some modifications, perhaps inside. But even if you just use one element of unfix, well, that's just your starting point. You now have your yellow value string crew. Good. Yay for that. What's your next step? It's a Lego box. You just pick the Lego pieces one by one. And you figure out how you want to build something with this. But it comes with built in constraints. I like that. Also, Lego, you cannot just put every piece together. They only go together in certain ways. And I think that's the way to do it. With patterns.

Yeah, we love patterns and pattern libraries. So let's summarize.

Yeah, let's do it. So this really resonated with me and I can't decide, is that because you're so eloquent at the way you describe it or because it has a lot of patterns out of Spotify? And I've found that works best with the teams I've worked with so far. So people like pictures. I have had the unfixed model picture on half my screen the whole time you've talked. And I think if I didn't have that picture then I wouldn't understand what you were talking about as much. So if you're listening to the podcast, stop walking, Stop driving, pull over or wait till you get home and get the picture up. Otherwise you'll get half the story. I like the idea of base or tribes. I always have. We've had other guests that talk about sense of belonging as being important. The tribe is a group who have the same vision, mission, understanding of where they're going. And they should be 100 to 200 people. Dunbar's number. So don't have 500 or a thousand people in a room trying to plan out 90 days. It's ridiculous. I like the Value Stream crew. We could call it a squad, a pod, a team, whatever that they could be serving an external customer or they could be serving other people within another base or within their base. We often forget that. And there's a whole religious argument about our internal customers, actually customers. And it's like, well, you're serving somebody, as long as you know who it is and what they want, then we're all good, in my view. I really love capability crew. I love that you've got a pattern, that when we have scarce specialist resources, there is a way we can deal with that. So I love that idea that they're consultants, they are experts that deliver what they deliver. That's all they do. They good at it, they love it. They probably don't want to do anything else. And so I think that's, that's a nice pattern. I like the attempt at dealing with the manager dilemma. I hate the word governance, so I'd probably change that to leadership crew maybe, but I'm not there yet on that one. I'm not sure I understand how that would work. So I'd have to work with organizations that are using this and see what happens to get a better understanding about that. I like the idea of experience crew looking at the customer journey, having that holistic view across everything. And then I'd be really intrigued about how they feedback when the logistics company left your yoga behind three times. How do they help them understand that that's killed the app? I love the re teaming. One of the downsides of scrum and sprinting, it's a marathon. The teams get stuck in a grind. It's a relentless grind. So I can see that idea of reteaming, breaking that grind up. And I really like the idea that it's context sensitive. That's not a methodology that says every 90 days change the team. It depends on your organization and your cadence. But the one thing that got me was when you said it's borrowed patterns, it's a Lego box. That's what for me agile is about, is picking up patterns that work for you and being clear that that's what we're doing, that we haven't invented a new methodology, we've just leveraged other great work people have done and helping customers apply it where it makes sense. So the fact that you referenced every book you read every pattern that you said has value and then articulate it in a way that I could understand, that's pretty damn cool. So thank you. Murray.

Yeah, I really like your unfix model again. I been doing versions of this for a few years now based on reading about the Spotify tribes and guilds and chapters and I have also experienced some of the issues and gaps in that sort of models. I really like the way you've put it all together. It makes a lot of sense to me and it's very clear. I think people find that very helpful. I do think that chapters are a good thing to do for a while with functional managers. But I do see the value of having capability management move into the bases. I really like the idea of making these bases all financially independent of each other. So an organization has a series of business units that trade with each other. That would just cut out so much bloat and bullshit in big organizations. If you had a 50,000 person organization made up of 200 bases, that organization would be so much more effective. We've talked before about management tax. 30% of most organizations are managers, which is such a big cost and feels to be like this would have a lower percentage of managers in it because people are. It's just organized better. So that people are doing more useful things but management is still there and important.

Exactly. So at Haier they basically fired 10,000 mill managers. Can you imagine that? They had to find a different. Either they became an entrepreneur as a leader of a micro enterprise and end up there as a management team member or they had to find some other job elsewhere and they helped them with that. But they said no more middle management that turn into platform infrastructure. And one more thing that I'd like to add because you said fully independent. They're not fully independent at higher in the sense that they are dependent on the success of their market facing micro enterprise. So it is clause in their contracts if they contract with each other and every unit that they contract with will share in the success of the market facing unit that is selling the ultimate product. So it percolates back into the network. It is a shared win or loss that they have with each other and they, they have this. Otherwise they said it became too competitive, this network. They had to turn it into more of a collaborative network that way. And they solved that by creating this dependency of profits across the micro enterprises that cluster together to get product into the market. I think that's really well done. And if you have this in your contract, you can fire the managers.

I'd love to explore this internal market idea further. Because big organizations operate currently like Stalinist regimes with central planning and three year and five year plans, let alone the three month PI increments.

We know that doesn't work.

Exactly. So that's a top of my backlog right now. I'm working on that. I'm doing more research, more reading. But what happens at the next level above the base? Yeah, I think after the summer I have a better picture of.

All right, where can people find you?

UNFIX.org that's it. So very simple, easy URL UNFIX. Work there, you find the website, there's a community. Please join the conversations that we have. There's stuff happening this year. There's an event in Berlin already in September. Looking forward to that. So yeah, I'm happy to evolve this with the members of the community.

All right, fantastic. Thanks Jurgen. Thanks for coming on.

Thanks, Murray.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile, contact murrayevolve.co. that's evolve with a zero. Thanks for listening.

It.