The unFIX Model for Versatile Organizations

Small Talk with Jurgen Appelo (Transcript)

What follows is the transcription of the conversation we had with Jurgen Appelo about his unFIX Foundations Workshop for Versatile Organizations (3 March 2023).

The chat has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: First of all, how are you? What’s keeping you busy lately? How is it going?

Jurgen: I'm good. Very happy because the unFIX Model is getting a lot of traction. I look forward to being in Milan, also in Stockholm and Budapest and other places. We have a team with the unFIX company for three months, three months and a few days to be precise. We are now an official start-up and there are lots of ideas in the backlog. And people are very enthusiastic, including ourselves, of course.

Avanscoperta: Exciting times, congratulations on this first milestone - the three months of the company. I'm curious to know more about how you are applying unFIX to your own company. The last time we spoke, Alberto Brandolini was with us too, and I remember unFIX was in its very early stages.

So right now it's been about two years, if I'm not wrong, since the beginning of unFIX. As usual during our Small Talk events, let’s start with the basics.
So what is unFIX? What are we exactly talking about today?

Jurgen: Well, I call it a pattern library. Some people might call them a combination of practices for designing organizations.

It’s about teams, business units, and their specific visuals, specific colours, which all have a specific meaning.
I am inspired by various sources such as Dynamic Reteaming and Team Topologies and other books, as well as by great people who talked about this before me. I just use the good stuff and turn that into something that people can use to describe how their organization is supposed to work.
It's a work in progress. The model will keep extending with more patterns but we have a very good first version right now.

Avanscoperta: Today I read your blog post about unFIX not being the same as SAFe, where you basically say that you're not reinventing the wheel, it's just a matter of mixing stuff and doing something new.
Another important part, which is also the title of the workshop, is the so-called versatile organization. Now I remember the conversation on unFIX started around the crisis of COVID, when we needed to reinvent ourselves to survive the changes etc.
Would you tell us something more about what a versatile organization is, and how that applies now that the crisis is finished (fingers crossed)?

Jurgen: I use that term to indicate the kind of organization that is able to change its structure all the time, and that is not stuck in one form.
That's why I call it unFIX.

The model is based on not staying fixed in the same structure, with the same framework. I also say that the unFIX model is not a framework for that reason. It is a pattern library; because the word framework in itself implies a rigid structure. The idea of a framework implies that you have a frame that holds everything together. That is not the case with the unFIX model.

All the patterns within the unFIX model are optional. It's more like LEGO. You can put the blocks together in any way you want. There's not a single block mandatory in LEGO; you just grab the blocks from the basket and start building.

That's the kind of feeling that I want to give with unFIX. And actually, I want every organization to come up with their own design that is right in that very moment and that could be a different one in one year, for example.

Let’s get back to the LEGO example; anything a person makes with their LEGO blocks will be different from what another person will make.
So I would love to have thousands of pictures of what people created with the patterns of the unFIX model, putting them together in different ways and allowing their organizations to continuously reform, and restructure themselves, depending on what is needed in the environment.
And that's what I mean by versatile.

Avanscoperta: So unFIX is not a framework, you don't need all the bits and pieces available, everything depends on your specific context and on what you need to do and achieve in that given moment. We are talking about organizations that are able and want to change and adapt.
How about other types of organizations, let’s call them non-flexible or “fixed”? What kind of change is needed to embrace this kind of unFIX approach?

Jurgen: I'd like the model to be as applicable as possible for as many organizations as possible. And let's be honest, a lot of models and structures that we are familiar with are created for IT businesses.

Whether we talk about scaled agile framework or large-scale Scrum or Scrum at scale, they're all about IT. Even Team Topologies is very much IT-focused, and that's fine.

But other people also would like to know what is their place in an organization that needs to be dynamic. I’m talking about HR, marketing, finance, support, and so on. And there are many organizations that do not even have IT and have outsourced all their IT, but they still do a lot of valuable work, whether it's fire departments or hospitals or airlines.

I often try to look at other kinds of industries to be inspired by what should the pattern library look like, just to prevent the bias towards IT, because we can be inspired by things that are going on in other industries that do some things much better than we do in IT.

So I want the model to be broad, not deep. If you want to go deep, then you need to have another framework like extreme programming. We're not going to cover XP practices in this context, so why bother?

What is missing is something more holistic, something that any organization can use. That being said, we do have some more radical models such as Holocracy and Sociocracy. They are also great sources of inspiration for me. They are on the other side of the spectrum. They are too radical, too extreme.
Most organizations wouldn't even consider beginning with Holocracy or Sociocracy to use those as a sort of flag on the horizon to go in one particular direction.

I want a type of library that organizations can use now and that offers step-by-step changes towards becoming networked organizations instead of hierarchical structures. In this case, people can be reteaming and changing teams as often as needed instead of being assigned to long-lived, steady teams.

So the unFIX model is a bit in between. It is not as extreme as some others out there but it also tries to stay away from being only IT-dominated.

Avanscoperta: I’m always curious to know where the idea for a particular approach or something comes from.
Was there a moment when unFIX actually started to take shape? Nothing is born from scratch, as we know, but maybe there was a moment when this actually took a shape in your head.

Jurgen: I remember pretty well when I was thinking that it was so sad that we are still stuck with the Scaled Agile Framework in the world of IT and agile as being "the largest and most popular" framework in the world.

I only hear people complaining about it, but it sells, apparently. And that to me is a rather sad state of affairs. And then the alternatives do not get much traction, to be honest. And I thought: "I'd like to offer my own alternative, that is, as I said, not IT-focused, but covering the organization as a whole".

And I was able to do that finally, after years, because things were coming together in my head. As I said, I read a couple of books that gave me inspiration and I started seeing the pieces of the puzzle and the fog was clearing in my mind.
Years ago, when I was still working on Management 3.0, I didn't get further than “every team needs to be a value unit”. And I still believe that - every team has to offer some value, either to a customer or to another team.

But I didn't know how to proceed beyond that, how to turn that into a structure that looks like a network. And I needed some more inspiration and ideas simmering in the back of my head for several years, apparently, until I was finally able to start drawing pictures with the ideas I had collected and accumulated.
And of course, I knew from the start I had to show pictures, that is obvious. Once you start showing pictures, then people see themselves in a certain place that resonates. Only when you show things visually, then you're able to get resonance with the audience, I noticed.

So from the very beginning, I made sure that I could create visuals that looked fun, because that is important to me. No boring stuff. We have enough greys and blacks in other models. I want a colourful model with smileys and cool terms that people have fun working with. Well, I think I achieved that because I get good feedback on that.

Avanscoperta: We have a question from the audience.
Could you please share some thoughts on why “captains” are needed? Is there any reason why they are not “stewards”?

Jurgen: Well, the first sentence is already not correct because nothing is needed in unFIX. There's not a single pattern that is mandatory. As I said earlier - if you do not like captains, you won't have captains.

I started out with three roles: Captains on Teams as an option, Chairs on Forums as an option, and Chiefs on the Governance Crew as an option. We are now discussing with my team to add more of these roles inspired by other models out there, from SAFe to Scrum to Holocracy, Sociocracy, and so on. Some of them are very similar solutions to the same problem.

We did a bit of inventory and research over the last couple of weeks, so within a month or so, we were probably going to offer the next version of what we see as potential roles.
And I don't understand what Stewards would be according to the question above, but we will offer some other ideas for what kind of roles people can recognize.

One thing that has always bothered me a bit about Scrum, for example, is that it offers roles such as the Product Owner and the Scrum Master, and then the rest are just “team members”.
That makes it feel that the rest are “the defaults”, and two people are special, with a specific name and specific responsibilities. And that in itself sort of puts them aside it elevates them to another level.
And you see this also happening in organizations - the rest of the team is just “team members” but we have these two special people that we treat differently.

I don't like that, to be honest. I want every person on the team to be special. Whether they are a creator making something or they are a performer whose activities are the value, whether they are a specialist or an advisor or whatever. We have to find 12 to 15 different potential roles.

And the Product Owner would be like a director of a movie, for example. I like that word better than product owner, actually. The director of a piece of value has the vision of what the value is supposed to offer as an experience to the consumers.
And the same applies to a director's mind if we talk about a movie. What is the experience that people should have when they watch the movie?
The producer is a very different kind of person. The producer ensures that the bottlenecks are all cleared and that things are available for the team. I sense a similarity to the Scrum Master here, such as removing impediments. So what they call a movie producer would be very similar to a Scrum Master in Scrum.

So we've been thinking about what could the roles be on a team and not only have a role for the product on Scrum Master or the director and the producer, but also for the others because the actors do very important stuff in the movie. Actually, they are the best-paid sometimes, so why not call them the performers? That's their job, they are the performers.

There are a lot of other patterns that we'd like to offer in the model, and all of that should be optional. Fine if you don't want to use any of the LEGO blocks. Just leave them in the box if they have no value to you. The whole point is to explain what we're doing and figure out what the future could look like for our organization.

Avanscoperta: Another question from the audience.
Can you share some feedback outcomes and exhausts from people organizations that unFIX successfully?

Jurgen: The first version of the unFIX model was published one year and four months ago, and it was a beta version to test the waters, and I got good feedback. Then I published the website on January 1, 2022. So that's a year and one month ago. That's not long.

So I do not have yet examples of organizations that found the unFIX model, started experimenting with it, reported back to us, and allowed us to create a case study out of it, it would take a bit more time.

We do have case studies of organizations that have already worked like this, which I simply described with the unFIX model, with the patterns that we now have - Pipedrive, Coolblue, and several others on the unFIX website, they were already doing things in an unFIX manner. They were using the same patterns, basically just using different terminology. That was in itself already very useful.

Right now the first results are coming in and the first case study was published last week, and it’s about Worldline, which is one of the largest payment providers payment gateways in the world. They have been working on their own on structuring their teams in an agile way. They discovered the unFIX model a year ago, started experimenting and are now the first actually to offer feedback to us. For example, we now know about their actions when it came to reteaming. For them particularly, it was the reteaming that they were interested in.

I want the model to offer a solution also to companies that do not want to be stuck and fixed in the mindset of “one person, one team dedicated full time on one thing” because that is old-fashioned thinking in my opinion. It just doesn't allow people to participate in different contexts.
This is life now, and we need to enable that so that they do this safely and responsibly without saying things that are simply unworkable, such as having one person stay in one team full time and long live, that's not going to work.
Wo Worldline is the first example. Others are in the pipeline, but we'll have to wait a bit longer.

Avanscoperta: How often have you seen or would you recommend this reteaming to happen?

Jurgen: It can be anywhere from once per year to several times daily. Whatever you want.

Let’s take the example of Redgate software. They published this several years ago. They have an annual ritual of reteaming where people choose to work on another team. So this is all voluntary and, on average, about one-third of people choose to work somewhere else. They do see that velocity dips a little bit for two weeks, but no customer notices this, and people love the opportunity of being able to work somewhere else, which is good for personal development and so on.
So the net benefit is high compared to the small drawback of a little bit of a hit on velocity for two weeks in one year, which is nothing.

On the other extreme, we have companies such as Tesla that does reteaming every 3 hours. Check out the videos by Joe Justice, who has worked there and is a famous person in the agile community.
Tesla has people swarming in the factory every 3 hours towards tasks that need to be done. So that means that every 3 hours, people work with a different sub-team. Basically, the whole factory of 150 people or so is “the team”, and they form sub-teams with the cadence every 3 hours to solve a problem with things like paint or fixing a problem with the steering wheel, and so on.

Joe explains that the rate of learning goes through the roof. Just imagine - within a few weeks, you have worked with everyone in the whole company. So it's mind-blowing. It takes a toll on people, not everyone can do this, but overall it works for Tesla.

And then there are other options in between. There's a case study of Pipedrive on the unFIX website. They have temporary mission teams for new large features, something like minimal marketable features that they create mission teams around, and those last for a couple of weeks to a couple of months. And then they have a reteaming process going on, where people who have been on a mission team for a while go back to the maintenance team, and people who have been on a maintenance team for too long, then go to on a mission team.
So there's a continuous rotation between maintenance versus new product development. In this way, the whole tribe is responsible for the entire code base. And every person needs to do both maintenance and new product development. This allows them to focus on one thing for a couple of months or a couple of weeks.

So there are lots of options, actually. And that's the whole point of the unFIX model. I'd like to show the options and not tell people: “you should be in a cadence of eight to twelve weeks with a PI planning at the start and then iterations of every one to two weeks”. That is a huge dependency you're creating between the processes of all those teams. And we're talking about SAFe in this case, of course. Well, it could work for some organizations, but I would prefer to break it all apart and offer the different options as a menu and then let people choose.
And if they want to choose reteaming, it’s an option, it’s not a must. If they want to do it, there are ways to do this safely and responsibly, and then there should be a menu that helps people to figure out what fits their context.

Avanscoperta: What is the smallest company you've seen unFIX applied to, or what would you recommend as a minimum number of people, if any, to start experimenting with it?

Jurgen: We’re six in my team, and it works. We're a startup, we are supposed to do everything, and we do everything as a team of six. But still, we found it makes sense to divide up the huge backlog that consists of many different tasks, from finance to infrastructure to development to content creation… it goes all over the place.

Then we have to define the different value streams. Content creation is a value stream, offering memberships to partners and trainers is another value stream. And then create a few platform areas, such as legal and finance, which is a platform service to the rest of the organization, similarly to infrastructure.

So we created a picture for ourselves. Even if we're just six people, we can define the different value streams and the different platform areas and we simply do reteaming between them. Every area has a subset of two, three, sometimes four people, who say, “I'd like to work on that.”
So we have two people or three who do the content, basically. The other four are not very interested. Then have two people working on finance, but it's just a different combination out of those six people.

We've used the unFIX model to divide up the backlog, and now have different backlogs for different things.
And it also makes it easier to create meetings because we're remote, and a meeting with two people is easier to set up than a meeting with six people all the time for everything happening. Twice per week we have a full team meeting, on Monday and Thursday, for an hour to discuss stuff that applies to everyone. But in between, we have these fast meetings for specific areas, whether it is memberships or for content or any of the other areas of our backlog.

We use the unFIX model to describe it, and it works for us. So here is an example where it works for a start-up and we have a blog post where it works for an enterprise of thousands of people.
You decide where you want to begin.

Avanscoperta: Let's read this questions from the audience.
When an organization is evolving from startup, it passes through different stages of cultural development. Should the unFIX approach take this into consideration and be implemented accordingly?

Jurgen: Yes, I think so. Actually, I have taken the Ten Stages Model of the Life Cycle Stages that I already offered as part of the Shiftup workshop four years ago. I incorporated that into the unFIX model because I think it is a very crucial concept that explains that a business model or a value stream goes through these life cycle stages and in the beginning, the practices will be different from later on.

First, you focus on doing the right thing, and then you try to do that thing right, or you change from exploration to execution gradually. That means that culture changes, that maybe the people that are involved in that value stream have to change over time because some, like me, are very good in the exploratory stages, and others are very good at execution. You shouldn't hire me for execution. I'm not so good at that. I lose interest when something is already working and it just needs to work better. I'm a creative person; I want to invent something new.

So different people, the culture of the changes, the ten lifecycle stages, the conclusions that you want to draw from this - all of this is part of the pattern library of the unFIX model.
Each one of you can see what this all means depending on your particular context, but at least we have a starting point for the discussion.

Avanscoperta: Thanks Jurgen. Another question from the audience.
​Is it actually even possible to compare unFIX with SAFe? In my opinion SAFe focuses on processes and roles, and does not tell anything about the structure (patterns) that are employed.

Jurgen: Great question. I am working on that right now, actually. I started with a few structural patterns because I think that it was not done well enough in other agile scaling frameworks, including SAFe.

SAFe does not explain where we can find HR or marketing and so on, though it is the most elaborate of the frameworks out there. So it has made a start.
Indeed, SAFe tells you much more about processes, whereas the unFIX model has no process information at this point, but I think we will get there at some point as well.

So right now, I'm in the process (pun not intended) of figuring out what else we need to offer for someone to unFIX SAFe. I think SAFe is a toolbox of some really good ideas, but as a framework it fails because it is rigid. It mandates that an organization is stuck in a cadence of eight to twelve weeks with PI planning and IP, and so on.

And I think that's simply not good. I want to give people options. I want to unFIX stuff, break it apart, and offer different options as a menu. But right now, we are not on par yet with what people would need to unFIX SAFe.

So that is my next challenge for the next few weeks and months. I will ensure we get there as soon as possible because you're not the only one interested in solving the problems caused by that approach.

Avanscoperta: Next question from the audience.
What was one thing you learned from creating this that you hope everyone takes away?

Jurgen: Thank you for the question. I think that's a very important one.
For me, it is about the experience, and I cannot repeat it often enough. I'm glad you asked this question, because ultimately, it's the experience that counts, not the product, not the activities.

It is all about the experience of the customers, the users and the employees.

And in that sense, some frameworks out there completely fail because people complain about how bad the experience of using the framework is for them. And they told me that they feel they're stuck in a way of working that feels like a feature factory. I found sentences on the SAFe website that say, “we produce features and measure how fast we can output features”. Indeed, that turns you into a culture of what you could call a feature factory.

That is not relevant. Customers are not interested in features. They are interested in their experience and the experience that they have with you as an organization. And I try to focus on that.

This is one of the reasons why I try to make the unFIX model itself colourful with smileys and stuff, because I want it to be a better experience playing with this model than with some of the other very boring-looking models out there.
I think about this. I intentionally chose colours that make people feel like they're playing with LEGO, because the feeling needs to be playful, not something that managers are mandating that we should use.

Another example regards the number of unFIX workshops on offer. I will not be the only one doing workshops. There are others already offering the unFIX foundation workshops, and intentionally my team and I have said, “you can do an unlimited number of workshops with just one license. There's no fee per workshop”. Because if I do that, when there is a fee for every workshop that someone gives, then there is an incentive to make the model as complicated as possible so that people need more training.

This, as you see in the scaled agile framework, is so complicated that people need a lot of training just to understand what everything means. This is by design because this is their business model to make it as complicated as possible so that people need more training because that's how they earn their money.

So I said to myself, “I don't want to end up like that. The best way to do that and make sure that I do not earn money with more training”. In this way, that is not going to be the incentive. So I opted for allowing people to do unlimited workshops with one new license, and we will ensure that our team members get paid in another way.

And all of this is part of the experience too. It is the experience of how the model is perceived, and how people use it. It needs to be about playing. It needs to be about case studies and not about sitting in classrooms and then getting certificates.

Avanscoperta: And talking about classrooms, Jurgen will be in Milan in April 2023 with The unFIX Foundations Workshop.
So after all these years of trying to make it work online, how will the in-person workshop be like? From our past experience together, I remember a lot of playing, a lot of cards, and colours of course.
So what can we expect from your workshop?

Jurgen: There will be a lot of games and exercises. I will bring a whole suitcase of colourful cards, people love working with cards, as it turns out. I learned it during my Management 3.0 classes - games such as the delegation poker and the other physical exercises work very well. So I thought, “when I do a new workshop, I want a lot of cards on the table and just have people play, have discussions, and come up with a couple of exercises and games to play”. It will be a very interactive workshop.

Avanscoperta: What type of people would actually benefit from the unFIX workshop?

Jurgen: It is most beneficial for people who are influencers in the organization when it comes to the organizational structure and the ways of working. Any random team member might find it an interesting workshop, but they might be disappointed thinking, “okay, well, this is all cool, but I have no voice in the organization, I cannot change anything”, so it might be frustrating.

You would probably be better served with a role as an HR person, a middle manager, a product owner, or a consultant. This can be beneficial also to business consultants who are influential and can actually convince managers to make the necessary changes within the organization.

So the change makers, as I sometimes call them, are those who will benefit the most.

Avanscoperta: Thanks a lot to Jurgen. It's been really cool and interesting to get a sneak peek into what we will experience at your workshop.
Last question. Will this become a book as well?

Jurgen: There will definitely be a book. But I am writing a novel right now, and I promise to write only book one book at a time. So first I want to finish this one, then work on unFIX book, which will also allow the unFIX model to evolve a bit more before I start writing about it.

Cover photo credits: Jurgen Appelo and unFIX Team.

Check out the full interview on YouTube or on Spotify.

Learn with Jurgen Appelo

Jurgen is the trainer of The unFIX Foundations Workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Subscribe to our Newsletter 📩 (available in Italian and English) and be the first to know when we schedule a new workshop or we publish a new workshop.