Read along you will

Shane: Welcome to the no nonsense podcast. I’m Shane Gibson. 

Murray: and I’m Murray Robinson 

Jurgen: And I am Jurgen Appelo

Murray: Hi, again thanks for coming on the podcast 

Jurgen: Thanks for the invite. 

Murray: For people who don’t know you can you tell us a bit about who you are and what your experience is 

Jurgen: Sure. So I’m from the Netherlands. Originally a software engineer. I have always had a wider interests than programming. I was never really the geek weather 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, a scrum and whatnot. Worked very well and. There I had to figure out what is my role as the manager in this organization, because crumb 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. Cause we were doing some things to make things work. So that’s why I wrote the book and the rest, as they say is history that launched my career in the agile community. 

Murray: You’ve been doing a lot of agile training through your own business since then and consulting 

Jurgen: I don’t do consulting because I’m a really, really bad coach and consultant. I’m a writer speaker. I licensed my course 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. 

Murray: You have a model called unfix for scaling agile organizations that’s looks really interesting So I want to talk to you about that. 

Jurgen: 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 or 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 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. 

Murray: 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 Unfixed.work because it’s going to be so much easier for you on this stand if you do that. 

Jurgen: So I use the metaphor of Lego. What you see is just one thing that you could make with the individual elements of the Lego box and other 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 safe. 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 and then they disband. That 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. 

Murray: So can you give us an example of a base then. 

Jurgen: Any group of people have between 10 to 150 people that together would feel they belong to each other. that could be in 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, 

Murray: And do you have that BICE organized around business market product facing? 

Jurgen: Yeah. So it is business oriented. It could be a product area if it is a very low product. If it’s a one big SAS platform, then the base would be maybe around campaigns or something like that. And that would already involve 150 people. But if it is games company with many different teams making tens, maybe hundreds of games then you need some other kind of clustering of who do we keep together? Well, maybe everyone who’s into mobile games. That’s around a 100, 150 people. Okay. Well, so then you could say that would be a base.

Murray: Alright So what are the other groups? 

Jurgen: So I took great inspiration from team topologies, manual pies, and Matthew skeleton did great work there. When I wrote management three dot 0 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, internal, but what Matthew and Manuel did was they defined that actually the four kinds of them. One is the end to end value stream team I call that the value stream crew as the same thing as the yellow one. I even use the same colors just to stay true to where I borrowed the ideas from. That’s the scrum team, the Canada 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 that coaches, that mentors maybe by helping them with product ownership whatever. It could be, even something technical that they helped them out with, like dev ops 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, unFix. 

And then 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 tongue. And in my opinion it is about the 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 highly rated designers out across so many scrum teams?

Well, you tell them you’re all your own little units, make yourself 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’re responsible for. But I think it is a bit more than that. There is just a talent that you need to have available across all of them. 

Murray: We usually want the specialist to be in the team full time. 

Jurgen: So that is indeed the suggestion that I hear particularly from the less community. I know from experience with other doesn’t work, I had two highly rated designers. If I told them you gone to sit part-time on seven different scrum teams, just move your chair around several times per week, they would have quit that job.

That’s not the way they want to work. And 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 our 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. 

Shane: 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. That’s a consulting capability and make sure that the other crews, I happy they’re getting the services they need, but they’re not focused on cross skilling or up-skilling or enablement. They’re focused on getting that job done because it’s a job that has a scarcity of resource. And if, the team’s upskill over time, then you probably need less of that capability crew. They should disappear if the organization covers the scarcity over time. But for a while that scarcity will exist. So it’s a consulting group 

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

Murray: 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 cause then we are going back to a functional structure again and there’s too many dependencies but I think if it’s specialist so part-time on different teams That makes sense 

Jurgen: 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 the discussion or is 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. 

Murray: Yeah. understand. And the value stream cruise, we went over very quickly but they are basically your long lasting cross-functional team that can build feature from beginning to end. 

Jurgen: Yeah. Yeah. That’s a scrum team, the Kennan team, the agile team in less, they called them the feature teams. The one thing like to disagree with is the idea of long-lasting. We can have a separate discussion there because I also incorporate the idea of dynamic reteaming 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 that. 

Murray: So do you want to talk through the other parts of the model we haven’t talked about yet 

Jurgen: 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 architectural 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 web shop 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 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 that’s not customers. They should offer them an API and SLAs 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 3.0 that 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 compensation 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 team decisions of a, 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. that 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 scaled agile framework, these things are not allowed.

 Those are anti-patterns. I said the managers go on 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 ask collate 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, 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 a matrix is that you make the organization more centralized. Guess what? That’s, what they never wanted with matrix structures of course, but that is the outcome reportedly by users or people who want to matrix organizations and also as reported by organization design as theorist.

So I don’t want this, I say this, 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 of uncaught exceptions. 

Shane: 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? When you’ve got more than one chief, how do you manage that decision-making at the chief. 

Jurgen: I don’t define how a management team should do that 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. 

Murray: 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. A day could be dependent on other parts of the organization. I am I 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 

Jurgen: 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 atonomous 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. 

Murray: All Right. Well what’s this experience crew and acquisition crew 

Jurgen: Right. I have noted and with me many others before me that even if you have a number of agile teams, that tried 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 never 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, et cetera.

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 and item was missing and it 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 extra time. I believe. So it was logistics that dropped the ball, not product. It was another department that was also a department 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. 

Murray: Why wouldn’t we do the same thing for software architecture as well? 

Jurgen: 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 customer. It looks at the teams for them to collaborate. If you have a situation where you pushed 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 teams. 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 Crow by the way is exactly the same on the other end supplier facing everyone that you signed contracts with vendors, gig, economy, workers, freelancers, whatever they haven’t experienced with you, as a company.

And in my experience that can suck quite a few times as a supplier or vendor. To survive in a 21st century, you need to solve that part of your business as well. So now there is a joy for business partners to work. 

Murray: Alright you’ve got on your diagram rolls called captain and chair. What’s that about? 

Jurgen: 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 a very democratic and they wanted all to be involved. But as a side effect of that, it costs 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, or liaison, a LinkedIn. There are many words for the same pattern. When our country, the Netherlands represents themselves at the United States, 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 landing that plane safely. And to be a point of contact with the outside world, in certain cases, that’s the analogy for that. 

Murray: Somewhat. I like A team leader 

Jurgen: Whatever you want. It could be, the product owner having this role. It could be a team leader having this role. I have written a case study on pine drive in Tallinn Estonia, they have mission leads. So they have crews or missions that exists for three weeks to five months are 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. 

Shane: 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. The other person that has that role of ambassador. 

Jurgen: Right exactly. 

Shane: And then we got chair. 

Jurgen: 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 mall 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. Push that out, that there is no chapter lead in a chapter. And then basically there is no difference anymore between a chapter and the Guild, other than scale. The chapter is, is a place where you discuss your specific functional area as a developer or as a UX designer. For example, to coordinate UX stuff across the different teams, someone will have to moderate the discussions, maybe , a senior UX person or something will as 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. 

Shane: So what we often lose when we moved to the central way of working is cure of people. I call it pastoral care, but let’s say 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 fading watering, loving nurturing of the people live in the model? 

Jurgen: Well, looking back at what I’ve always suggested with measure through O detecting the need for this is responsibility for the managers. They need to understand that people have a desire to be helped with that 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 a 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 couple of people or it could be just one who is the mentor for everyone in the base and helps them with that personal development and finds learning paths and whatever talks about that 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, or they 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. 

Shane: 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 code on the trade off decisions on what’s the next priority? 

Jurgen: No. Another thing that I borrowed from another source is the four kinds of organizations that I have named the fully integrated base, the Lucia line base, the strong align base and the fully segregated base and a fully integrated the base is the one where everyone works on one part. The situation that safe and less are created for. You have multiple scrum teams. They all work on one thing. It was 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 products prioritization, et cetera. If you have a strongly aligned base that could be perhaps a SAS platform with microservices teams, they don’t operate in the cadence. Pipe drive is an example of that. They have teams, they deliver multiple times per day. They don’t need pen on each other, but they need one mission, one goal, to work towards. 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 a 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. Management is not involved other than invoicing and finding customer. They are more involved in sales and marketing then. And not at all in features prioritization for customers. This 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. Cause 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 team compete for eyeballs. And there is no prioritization going on on the management team level. It’s like, okay, let a thousand flowers bloom and made the best game when it’s up to you. It’s friendly competition. 

So you see the mole captures more different kinds of organizations other than just we have a big product that we need to cut up somehow in multiple teams. And depending on what kind of organization you have, it is quite a range between a large kill 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 the. You’ll have to figure it out for yourself. How much is the blue team involved in prioritization and strategy? Because those are very different situations that I just reviewed. 

Murray: 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 you’ll functions now a chapter and you’re now 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 yet 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. People management and capability management is now done within the tribe which is similar to your base. I’m consulting with a client at the moment where I’m encouraging them to do as much capability management as I 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? 

Jurgen: 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, 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. 

Murray: Yeah You don’t see a longer term role for a capability manager whose sitting outside the base then. 

Jurgen: Depends on , what that definition is of the capability manager. If that person hires and fires people with a certain capability and the size on their conversation. That should go into the management team over the base. Cause 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 hire 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 as an established rate that you cannot negotiate, then good luck with your business agility. That’s never going to work. 

Shane: So You talked about dynamic reteaming. There is a theory that teams take a while to form once a year to give her, and then I had a week together , theres 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. As they hop on the plane, they go and do the tour of duty. That’s important to them. They come back to the base, they reform. So how does that work? What’s the benefit of doing that over the cost of having to reform those teams? 

Jurgen: 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 a countered. Red gate 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 newer technologies, and work on that 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, philosophy drops a bit, but they say customers don’t really know this and the benefit of people feeling that they can decide for themselves, whether they want to move is greater than the drawback of that temporary hit in velocity. Another example is a pipe drive, they have mission teams. Some missions take a couple of weeks. Others take a couple of months again engineers volunteer to sign up to our mission. One of them volunteers to be the leader, the mission lead, I call him the 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 at home. Taking care of technical debt, small issues, whatever. And then they insist that everyone rotates all the time. If you’ve been on a mission one to three 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 more or less 20, 25 people. So there’s relatively small basis where the entire base takes care of the sense of belonging, the code infrastructure, et cetera, is just within the 25 people they reform in different temporary units.

Murray: 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 Cause 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 it 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 and not to spend all their time trying to work out what the hell is going on.

Jurgen: 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 typologies that call this cognitive load and they say, there is a certain area, a certain amount of coach, or the amount of knowledge that you are responsible for as a team. And 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 pipe drive, they found that the optimum for them is about 20 to 25 people. They found that where this number of people, 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. These work with the same coach stack, they work with the same code base. 

So this argument doesn’t hold up the pipe drive case. And I have to stress there that this was the reason 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 we tell them as managers, I’m sorry, you have to stay on your own team. It’s long live 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 reteaming well, instead of just forcing people to work on one long live 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 them when I feel that I would like to learn something new.

 So we optimize for the employee experience, and we take a little bit of a hits sometimes in terms of drop philosophy, 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. 

Murray: 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 it altogether so they can learn. If the really big problem is people getting bored Then more moving around Probably a good idea. 

Jurgen: Exactly. So, is context dependent. Figure it out. I just say you need to consider the benefits versus the drawbacks of reteaming 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 fast respond time to organizational or environmental changes. Pipe drive are super fast at responding to environmental change like COVID happening to them. That was easy for them cause, they were already talented in terms of reteaming no problem. That’s a benefit you have in terms of business agility. 

Murray: So a lot of organizations are outsourcing their software development to another company India or China how does that fit in with this model 

Jurgen: Interesting question. Well for now I have only defined what is the base level. So I thought that wasn’t 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 software development because the unfixed small is not just for software. It just described stuff happening in an organization while you create value, whatever kind of product or service that you are making. There’s a split somewhere and there’s a vendor and there’s a customer and they both can apply on fixed 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 processes 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 and manufacturing company. I’ve been there 10 years ago. I spoke with the CEO of Mr. Jang. He wrote the forward actually of the Chinese translation of Management three row. 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 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 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 basis. For example, that just offer platform services to the other basis. My hypothesis is that what you see within one bay, 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 basis. We have basis that help with your customer experience. We have basis that focus on architecture infrastructure. They do platform work. Those are platform basis. And we have base with special talents. They do data mining. They offer that capability to the others. Those are the capability basis. I see exactly the same patterns appearing, but then in a network way where they find each other and have temporary Clustering. That’s what happens at higher that they have temporary clustering of basis to make computers, fridges, vacuum cleaners, and all those things, because those products are too large to make as one migrant price. They make them , as clusters of basis and they find each other. 

Shane: Yeah, as you’re talking there, I could see that one of the reasons the network is working is because even though each of the bases are delivering a different thing to a different internal or external customer, their role 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 a, an external organisation thats 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 and the hive is fundamentally working the same way, then there’s that shared language , their shared understanding of what it takes to get something to done.

Murray: Have you read Maverick by Ricardo Semler 

Jurgen: I think I read this other book the seven day weekend. Maverick was still on my list, but I never got to read that one

Murray: So, he talks about how he turned his father’s company into something almost Exactly like hive back in the eighties or nineties 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 only 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. 

Jurgen: Exactly Yeah. Cause you turn the hierarchy and a network and the network scales horizontally and vertically, it makes perfect sense from a complex systems perspective. And indeed they say exactly the same at high. Each of those micro enterprise is allowed to go outside. You should not feel forced to purchase servers internally in the organization. That is not competitive. If you find an outside provider, you should have the rights to go with them. And that also applies to HR that applies to marketing, then applies to recruitment and whatever.

So it’s liberating. The managers of the basis. They are responsible for survival of the 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. 

Murray: 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 the same Why can’t I go and work with these other people who I know are great and who costs the same or less than you do and can do it in one month instead of 12 months 

Jurgen: Exactly. And that’s because someone up there thought it would be more efficient. 

Murray: Yeah. Great utilization. 

Jurgen: Exactly. Well we already know that communism doesn’t work. The Soviet union proved , that this kind of management of the market fail. So higher has proven this concept. The Ricardo seminar has done this. Others have done this. I just define the patterns. Unfixed as a pattern library. That is, I think the best description. Is not even a framework. Some people automatic referral to everything has a framework, but frameworks such as safe and less there one picture. This is how thy shall organize , their company with some modifications perhaps inside. But even if you just use one element of unfixed, well, that’s just your starting point. You now have your yellow value stream 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 . 

Murray: Yeah we love patterns and pattern libraries. So let’s summarize? 

Shane: 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 modal 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’re talking about as much. So if you’re listening to the podcasts, start walking, stop driving by the or wait to get home and get the picture up of always you’ll get half the story. I liked the idea of base or tribes I always have.

 We’ve had other gifts that talk about sense of belonging as been 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 in 90 days. That’s ridiculous. 

I liked the value string crew. We could call it a squad, a Potter team, whatever that they could be serving an external customer, or they could be used serving other people, women, 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 the moral 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 there are consultants. They are experts that deliver what they deliver. That’s, all they do. And they got it. They love it. They probably don’t want to do anything else. And so I think that’s, that’s a nice span. 

I liked 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 bit of understanding about that. 

I like the idea of experienced 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 lift your yogurt behind three times, how do they help them understand that that’s killed the app?

I love the reteaming. 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 liked the idea that it’s context sensitive. There’s not a, methodology that sees every 90 days change the team. It depends on your organization and your cadence. 

But the one thing that got me was when, you see it as borrowed patterns, it’s a Lego box. That’s what for me edge all is about, is picking up pens 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 it and helping customers apply it where it makes sense. So the fact that you away, for instance, every book you read, every pattern that you see it has value and then articulate it in a way that I could understand. That’s pretty damn cool. So thank you. Marie. 

Murray: Yeah I really like your unfixed model Jurgen. 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 model. I really liked the way you’ve put it all together Makes a lot of sense to me and it’s very clear. I think people will find that very helpful. I do think that chapters are a good thing to do for awhile with functional managers but I do see the value of having capability management moving to the basis. 

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 basis 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 it feels to me like this would have a lower percentage of managers in it because people are just organized better so that people are doing more useful things but the management is still there and important. 

Jurgen: Exactly. So at higher, they basically fired 10,000 middle managers. Can you imagine that? They had to find a different job. Either they became an entrepreneur as a leader of a micro enterprise and ended up there as a monument 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 turned into platform infrastructure. And, one more thing that I’d like to add, cause 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 microenterprise. 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 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 solve that by creating this dependency, of profits across the micro enterprises that cluster together to get a product into the markets. I think that’s really well done. And if you have this in your contract, you can fire the managers. 

Murray: 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 

Jurgen: exactly. So that’s the top of my backlog right now. I’m working on that. I’m going 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. 

Murray: All right. Where can people find you 

Jurgen: Unfixed.work. That’s it. So very simple, easy URL, unfixed.work there you find the website, there’s a community. Please join the conversations that we have. There are 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. 

Murray: All right Fantastic Thanks Jurgen. Thanks for coming on 

Jurgen: Thanks Margaret.

Exit: That was the no nonsense at y’all podcast from Marie Robinson and Shane Gibson. If you’d like help with agile contact marie@evolve.co that’s evolve with zero. Thanks for listening.