What is a DAO? The organizational platform that makes borderless collaboration possible

DAO: Decentralized Organizing

What is the counterexample of a DAO? Take the “Innovation Center” of an international bank that I visited. The projects that were run there were mainly the toys of managers who were stuck in their career ladder. Despite the impressive space with moss on the walls, life-size tablets and exercise bikes, there was not the (mental) space to work unhindered on the future. Barely anything got off the ground, partly because the old organization still determined the rules. An organizational platform that makes it possible to transcend the boundaries within and between organizations is the DAO. The DAO forms a truly free space for cooperation and innovation and is making international strides. Welcome to the world of the Decentralized Autonomous Organization! I’ll take you through what a DAO is and how it is a medium for boundless collaboration on the issues of today and tomorrow.

From tech world to organizational world

The DAO originated in the tech world, where the idea of ​​decentralization has been an important topic for some time. While large tech giants mainly want to store their information centrally and maintain central control, there are disadvantages to that model. After all, if you want to be able to collaborate with others in the world in an open-minded way, it will hinder you if you are dependent on someone else’s platform. Now that there is a technology (for example in the form of blockchain) that makes it possible to achieve results together without being dependent on one central organization, forms of cooperation can also start to evolve. The DAO is the result of that. DAOs exist in various shapes and sizes, and are currently used, for example, for publishing investigative journalism, collaborating on life-prolonging medical therapies and developing (digital) citizenship in Estonia. The state of Wyoming has even made explicit room for DAOs in its legislation on corporate entities, with the result that a new city is being developed there: CityDAO. Time to clarify what the three letters of DAO mean in practice.

The three elements of a DAO

1. Decentralized: decentralization comes down to spreading ownership, input and further development of the organization across a broad and diverse group. This group often forms a community, in which existing ‘traditional’ organizations sometimes also participate. Furthermore, decentralization means that the resources and facilities to enable collaboration are widely distributed. So a DAO rarely has a shiny head office. At the same time, you have different degrees of decentralization: some DAOs are 100% decentralized and owned by a large community, others start with a small core and then decentralize step by step.
2. Autonomous: this is about the space that participants of a DAO have. The minimum set of rules that a DAO has, is about governance: how do we make decisions together about the further development of the organization. Examples of important rules involve membership requirements for the DAO, and how the voting rights work. Furthermore, everyone within a DAO can make proposals and take the initiative based on their own drive and involvement. This creates a ‘free space’ that makes it possible to do what is necessary together. And what is needed then arises from the intention of the DAO: the (evolving) mission that may or may not attract participants.
3. Organization: the organizational form of the DAO is closer to the idea of ​​a network structure than you will see in classic organizations. Anyone who wants to contribute to tackling an issue has the opportunity to do so and does not have to consult a manager. Whether your contribution is valuable is also determined by the participants of the DAO (your peers). In some cases, a ‘token economy’ has been set up for this in which all rewards are transparent. With the virtual tokens you earn (which can amount to serious amounts), you determine the value of individual and joint activities. In addition, you can use the budgets of a DAO for charitable causes, investments or the distribution of shares in the DAO itself.

The advantages of a DAO at a glance

What is the use of this new form of organizing? A free, autonomous space sounds nice, but what can you achieve with it? From my experience I see that a DAO enables you to:

• Work with a diverse group or community towards a common goal, without the barriers in and between organizations
• Let each participant contribute to the purpose of the DAO based on their own insights, and be valued for it by the others
• Manage the evolving organization; being able to create a purpose that is set up and maintained by the participants themselves
• Form a network structure that in addition to, or instead of existing hierarchies, develops new business models, creates social impact and facilitates transformations

It gets interesting when you compare these benefits to today’s organizations. For this I reference the thoughts of John Kotter in his book XLR8, in which he talks about the dual organization. In addition to the organization that does ‘the daily work’, you build a space within the same organization that makes horizontal collaboration on innovations possible across the hierarchy. The problem with this model, however, is that working across an existing hierarchy often gets stuck. You end up in what I call “matrix confusion” where horizontal and vertical hierarchies collide. Due to its autonomous form and technological support, the DAO makes it possible to still make the dual organization work. On the condition that it is outside the existing organization (and its systems) and the DAO regularly incorporates participation from customers and other organizations. There are major innovation opportunities in the latter area, for example through cooperation between the business community, government and educational institutions. These borderless collaborations require fewer governing committees, letters of intent, administrative memoranda and coordination meetings: the DAO offers a platform to get started instead of lengthy up-front negotiations.

Applications of a DAO in today’s space

There are plenty of opportunities for realizing DAOs. They already exist, the question is how to tailor them to your context. For inspiration, here are a few missions and collaborations that DAOs enable:

• The Innovation DAO: there have been many attempts by organizations to get innovations off the ground faster and better, from Google’s famous 20% innovation time, to the many innovation centers and incubators. A great opportunity is to transfer (part of) the innovation portfolio of an organization to a DAO. Employees and possibly partners can participate in this DAO. The ‘parent organization’ makes a budget (part of the salary sum, plus a material budget) and the time available in a contract with the DAO. Within the DAO, it is then up to the participants to innovate independently of the parent organization. Participants who are active and make valuable contributions receive tokens that they can use for further development of the DAO, for reward or for building share ownership.
• The Social Impact DAO: more and more organizations want to contribute to solving social issues. For example, around sustainability, housing or education. The problem often starts with the number of organizational units of, for example, municipalities, provinces, national governments, volunteer organizations, companies and interest groups that have to work together in the long term to achieve social impact. Forming a DAO that brings these parties (and others who can or want to join) together helps. The party you belong to fades into the background and the task at hand really takes center stage. You work together uninhibitedly on what is needed, whereby the benefits flow back to society and the organizations involved are less involved in showing their own relevance.
• The Startup DAO: Within and outside of organizations, new ideas emerge that usually are best accommodated in a new company. This is how new private companies, new labels and joint ventures are created. However, it can be a smart move not to place certain ideas in a centralized, but in a decentralized organization. Maybe the idea is not yet mature or rich enough, or it cannot be taken further by a small group of entrepreneurs or administrators in a useful way. Instead, it is better to activate a broader community. Or maybe decentralization is beneficial because you want faster global reach, with low barriers to entry and attractive rewards for (knowledge) partners who prove themselves in the startup.

In addition to these examples, you can work with DAOs on spatial development, new forms of education, energy cooperatives, fintech and much more. The challenge is to set up the form, governance and technology that suits the DAO. This way you get a decentralized organization and collaboration form that fits the mission.

The ‘well-known’ Coop versus the ‘new’ DAO

“Isn’t a DAO just another word for cooperative or coop?” people often asked me. The similarities are certainly there: a like minded community works together with the intent to harness the power of that community. And a cooperative structure generally does not have a strongly dictating central board. However, there are also differences. An important one is the (agreed upon) freedom and diversity of partners and contributors to participate in a DAO. An artist and painter will not easily join an energy cooperative as a full member; but with a DAO you are able to do that. Furthermore, a DAO has a transparent internal economy of contributions and rewards, which is technically supported. This light, playful form of working with market forces, is often absent in cooperatives. In addition to being cooperative, a DAO is also strongly meritocratic: not your position, but your added value is what counts.

The DAO Ladder

The formation of a DAO generally goes through several stages of development. Sometimes they all happen at once. The DAO ladder provides a great overview of the steps that a DAO goes through before it is fully decentralized and autonomous.

This is a modified form of the original model from the tech world, by William Mougayar

The main ingredient of the DAO can be found in the first step: the ability to participate for those who are motivated to do so. Subsequently, this participation leads to a form of cooperation that develops over time. The DAO economy that arises in parallel makes it possible to value contributions; whether this is social and/or financial value. Afterwards we arrive at the exciting process of decentralization: the ability to participate and co-decide (including about their own governance) of everyone who participates. It is up to the participant and her/his contributions to decide whether or not they will actually take part in the decision-making process. Finally, the autonomy of the DAO participants arises to jointly manage the issue, the initiative or the innovation they are working on.

The future of the DAO

In a world where boundaries within and between organizations are more restrictive than liberating, it is time to create new spaces in which collaboration is accelerated. With DAOs you free human potential and the energy of everyone who wants to contribute to innovation. The DAO offers a ‘home’ in which merits prevail over interests when working on (major) issues. For many organizations it may still sound abstract, and the additional technology takes some getting used to. At the same time, any organization can take the initiative to set up a DAO on a small scale. For example, to stimulate internal innovation, parallel to the standing organization. Or to tackle a complex issue with partners and work on it in a new way. In this phase it is up to the pioneers to spread the DAOs beyond the tech world. And in that you have Organize Agile on your side. I am proud to share that in addition to the DAOs we set up for others, Organize Agile also has its own DAO and we would like to share our experiences with you.

The Obeya Host helps attendees cultivate better meeting habits that transform insight to action with inclusive and sustainable decisions. Being skilled at this requires dedicated time, energy and attention, as well as using the room to your advantage.

Surfing is probably one of the most frustrating sports in the world to learn. There is a great number of skills required to get you properly out of the beginner phase, a phase that for most people takes years. This has much to do with the nature of surfing, but it is especially inherent to the terrain – that is the sea. Apart from strength and stamina there are mechanical skills to be learnt but the biggest challenge in surfing is to better understand the environment you are operating in and how to use it effectively. The surf is a complex environment in which you not only have to deal with the dynamics of the ocean itself but also with other surfers (one surfer to a wave), etiquette, unspoken rules and practices, other watercraft, and managing your own expectations and fears.

In other words, you need to know a lot, and be able to do even more, before you are even remotely competent at surfing. So how to learn these things? Well, by surfing. This is a problem, as it gives you only so much time to actively learn. It is not uncommon for beginner surfers to only ride a wave for mere seconds (if at all), in a surfing session that might be a few hours long.

What can the process of learning to surf teach us?

These difficulties bear a striking resemblance to learning to operate in a complex environment as an organization. It’s all pretty overwhelming. Half the time you might not even see or understand what’s going on. There are definitely dangers and competitors out there and mistakes can have real consequences. You are probably using the wrong tools and everybody is recommending different things. Clearly learning rapidly is absolutely critical, but you are not sure how to even get started and the learning process itself is harsh. Wouldn’t it be nice if you could learn how to operate in a safer environment? As it turns out, you can. It’s called skateboarding.

While that might seem strange at first glance – most people like their bones where they are – there are some key differences between surfing and skateboarding that make skateboarding much easier to learn. I have experienced these lessons carry over into surfing, but also into the way we work. 

How to change oceans into skateparks?

So how can we change the ocean into a skatepark? How can we change an organization, and maybe its context to make a complex environment into a more predictable place of learning? Answer: we need to create pockets of learning in our organizations; safe spaces in which you feel challenged yet confident enough to learn new behaviors and skills. Not just in a physical or facility way, but also psychologically. Just like any good skate park not only consists of a bunch of halfpipes, rails and ramps. It’s a vivid, socially safe environment due to its users. I believe good skateparks and great learning spaces in organizations are characterized by five elements:

1. Short feedback loops
2. Risk by choice
3. Learn at your own pace
4. Repeatability and variation
5. Culture of learning and striving

I will explore these elements one by one. And asked Marleen Groeneveld, Agile Coach at Takeda Netherlands, how Takeda uses safe spaces to aid their transition into a more agile organization.

Marleen: “I like this analogy. I often feel like Takeda’s halfpipe, or rather its custodian. Colleagues come knocking to practice and improve their agile skills. I provide them with the facilities. I make room for them, often literally, and I provide tools to visualize their work. But I also offer coaching and mental support in learning how to fall. For example, if a retrospective doesn’t work out, I help the scrum master to investigate what it takes to get more out of it.

Importantly, I am also a gatekeeper and safety officer. Are the teams here for sincere reasons to try agile ways of working? Are product owners and team members fully committed? Just like in a real skate park, you don’t hang out here for just a cool image. Are they actively working on creating the safe situation required for experimentation and developing their deliverables based on feedback? Ultimately this is their own responsibility. I can help in creating a safe environment, but I can’t make them wear their helmets.”

1. Short feedback loops

The body remembers and learns. Skateboarding provides you with extremely direct feedback. Get it wrong, and you are likely to find yourself on the ground. Falling hurts, but this is a good thing. Because the feedback loop is so short you can learn what works and what doesn’t, at a highly accelerated pace. Now compare this to surfing, get it wrong and you will usually find yourself in the water next to your board. It might actually hurt less in the short run, but that also lengthens your feedback loop. In learning organizations it’s the same.

Marleen: ‘Increasingly we’re finding that teams are spontaneously willing to try new concepts or proposals in very highly focused sessions we call pressure cookers. These are aimed at building and testing products in very short cycles. Typically such a pressure cooker will consist of four sprints in two days, with direct feedback from real stakeholders after every sprint. These sessions are excellent for kickstarting a larger project and help make the decision whether something is viable in a very short timeframe.”

2. Risk by choice

Skateparks are safe spaces. No, really! Granted, you might fall, and it might even seriously hurt, but you won’t get yourself into any trouble if you do not consciously assume the risk of being in that position. You are able  to manage the level of risk you are willing to take, by choosing where to skate and which sections of the park you will ignore (for now). This allows you to build confidence and push yourself where you might feel uncomfortable but the risks you are assuming are acceptable.

Marleen: “It’s about consciously considering between trying not to take risks or trying to do something totally different. For example, one of our first pilot, or ‘skateboard’ projects we decided to work on, was a project that had been struggling for quite some time with a very traditional workflow. This basically meant that although this was a real project there was very little risk of taking a big fall. Even if it failed totally we wouldn’t have been any worse off. Working on this project allowed us to add value for our customers and the organization while at the same time practicing a new way of working at a very low real risk. The project was a success, and this gave us the confidence to start using this new way of working in ever more areas.”

3. Learn at your own pace

This element of risk by choice has another important benefit that deserves to be mentioned separately: a skate park allows you to learn at your own pace. In the surf, or in the complex ecosystem of your organization, the required pace of learning may be forced upon you  by rapidly changing situations (adapt or die!). Adapting to these constant waves of change is a true art. Agility is key. But having a basic understanding of functional (meta)patterns and effective behaviors in such an environment makes you much more resilient. A skatepark allows you to learn these movement patterns and behaviors at your own pace. Sharp twists or slow curves, steep walls or more undulating terrain; you choose when and how often you want to practice a particular obstacle, whereas the outside world or the ocean makes the choice for you.

4. Repeatability and variation

Skating allows for lots of repetition, whereas surfing does not. But interestingly many of the fundamental movements are the same. Meaning that while skating in a skatepark or bowl, you can try a maneuver however many times you want until you get it right, and crucially, then repeat it until it becomes second nature, and you no longer have to consciously think about it. This newly ingrained pattern of behavior will then also serve you well in the water. This frees up space in your mind, which leaves you more time to adapt to specific conditions and pick your right lines, rather than having to focus on changing your habits while you are in this constantly evolving environment.

The same situation that allows repeatability also allows for variation. Because the environment is unchanging we can try new approaches to the same situation to see if they yield better results. Trying new approaches is relatively risk free, as the opportunity (to surf a wave) will not pass you by. You can reset and try again, over and over again.

Marleen: “Practicing requires discipline and focus. That applies in sports, it applies in learning to organize in an agile way. On the one hand it is nice to be able to learn in your own way. On the other hand it can really help to rely on someone who pushes and challenges you to go just that bit quicker, further, or take a different approach.

For example, we had an urgent project that was absolutely ideal to tackle using Scrum. It was completely obvious, yet somehow we were unable to align everyone’s calendar. There were endless discussions about time commitments and the estimated number of sprints required to deliver the product. Until Michiel remarked: why are we talking about continuity during next months? What if we simply cleared everyone’s schedule for just one, full week? Quite frankly we were astounded that we hadn’t been able to come up with that ourselves. We were too ingrained even in our new, normal way of thinking. In such times it can really help to have an outside pair of eyes.”

5. Culture of learning and striving

None of the things above would be possible without a culture that supports this, and quite frankly skateboarding is one of the healthiest cultures I have ever encountered.

There is something different about skateboarding compared to other board sports. While there are certainly better and worse skateboarders out there, the skateboarding community appears to be quite happy to include people from all levels. As it turns out, being good at skateboarding is not what necessarily makes you a skateboarder. Rather it is the striving. The willingness to try a new trick. Possibly take a big fall and then try again. In skateboarding taking a fall gets you respect. Spectators admire your efforts, practitioners have even more respect. After all, they have been through it themselves and know the true price of learning and bear the scars with pride.

This is exactly the kind of culture that allows you, and organizations, to embrace complexity.

Marleen: “I have noticed our culture is changing. Learning, falling down and getting back up again is becoming much more commonplace. I often overhear colleagues that say ‘this bit of work is too large, let’s cut it up into smaller pieces and experiment’. Or they admit that they have been blindly proceeding based on their own assumptions: ‘I thought I knew what our customer wants but now that I’ve directly involved them, I’m experiencing otherwise’. We are clearly getting better at taking these -mental- hurdles every day. And that’s cool!”

 

Ingrain new muscle memory and patterns of behavior

In skateboarding falling gets you credits. Striving is cool. But for many organizations not falling is the norm. They believe that they are held accountable for this by the market, as an organization and individually. Strange, because that very same environment, the market, the business landscape itself is as complex, changeable and unpredictable as an ocean. Learning in a skate park allows you to learn new patterns and ingrain them so they become second nature. So much so that they become second nature, you no longer have to consciously think about them and you can focus on the important things. What is the wave doing? What does my business landscape look like and what is the move I should be making?

This article is not intended as any kind of definitive statement of facts. Rather this article is intended to help me gather my thoughts, explore the idea, invite feedback, and find those willing to explore this with me.

The trouble with strong institutions

It may help the reader to know a bit about my personal background. I read International Relations in university. One of the subjects that would sometimes come up in discussions on state and nation building (setting up a healthy system of government in for instance a fledgeling democracy) was the issue of strong institutions. Institutions that are able to resist pressure from actors such as a President. The idea of course is that this protects not just the institution, but the system (and democracy) itself. A strong independent judiciary is a clear example of such an institution.

Clearly I now work in a very different field. Sometimes, however, I find that some ideas from my education and chosen profession intersect in unexpected ways: During the most recent election day in the United States a couple of my friends were having a discussion on the US institutions of government, in particular the Federal Bureau of Investigation (FBI). One was arguing that the institutions had not survived the Trump era, another friend argued that they had. Without going into that specific issue it did trigger some questions for me.

What if institutions are broken, but we simply can’t tell? At first sight they may still be there – clearly the FBI still exists – but are they still functioning as they should? Have they ceased to function properly long ago but are we simply unable to see it from the outside? If so, might it not have been better for some of these institutions to break completely, rather than to have them remain as a mere shell of what they once were? What are the costs associated with such a shell-like organization? What is it like to work in such an organization?

The dead beetle problem

It seems to me that such organizations closely resemble a dead beetle. Meaning it’s actually quite hard to tell whether it’s still alive without resorting to poking it. In a wider system this is a problem. We are expecting the organization (or part thereof) to perform its function in the wider ecosystem. Visually it is still there, it is holding the space, but because it is no longer performing its function the entire ecosystem may now be under threat.

A key question of course is, is this actually a problem, apart from for the individual organization? Won’t the organization simply be replaced by a new one? While that is certainly true in many cases, many organizations also simply refuse to die. They keep stumbling on despite serious internal problems. Usually, it is the employees that bear the brunt of this. They are stretched to their breaking point while trying to make up for the system’s wider failings. When they do eventually succumb or leave they are simply replaced as parts in a machine. ‘They couldn’t cut it.’ ‘This is not for everyone.’ Those that do still survive in the organization may even take a perverse sense of pride from this. Crucially, the organization does not solve the rot at its core. Consider also the business costs associated with this. Keeping an organization upright that is fundamentally unwell requires significant constant investments that could have been better spent elsewhere. Over time the costs of addressing only the symptoms often far exceed the costs of solving the root problems.

The need for built-in strategic weak points

Surely there must be a better way. A way for organizations to remain healthy, deliver value and be a great place to work. The solution, in my mind, is not to design a stronger beetle. In fact a stronger beetle would be worse. It would hold out longer, only to eventually collapse even more catastrophically. I feel the solution is the opposite. An organization that is built to not rot from the inside out, but rather one that breaks down early and, crucially, highly visibly in pre-designed failure points. An organization that is in fact designed to be weaker, designed to break.

When designing for weakness I don’t mean designing the entire system to break. That would be rather catastrophic. Instead we can design small pieces of a system to break, in order to prevent a total system failure. For a clear example of this consider a circuit breaker in your house or car. It is purposefully designed to break, to prevent something really expensive or truly crucial from breaking.

There are some important lessons here. A circuit breaker is a very small part of a system that crucially stops the entire system in its tracks when broken. Meaning understanding the cause of what broke the system and fixing it has suddenly become the number one priority for the entire system. Moreover circuit breakers fail early on in the process,and signal very clearly that they’ve done so. Finally circuit breakers are pre-designed points of failure that prevent critical systems from being destroyed.

Integrating circuit breakers into ecosystems

Organizations, however, are not machines, rather they act as highly complex ecosystems. So taking the lessons from circuit breakers, how can we apply these to organizations? How can we design parts of our organizational ecosystem to fail cheaply, early and force our organization to deal with the underlying issue immediately?

When discussing the issue with my colleague Carmen we agreed that the right solution needs to be both technological and cultural. We can engineer systems, or use information radiators such as Obeya to signal issues early but only when the organization and its people choose to act on these signals as soon as they appear, will we be able to stave off the dead beetle problem.

Organizations need to put a much higher value on solving the issues underlying even the smallest of warning signals at the earliest opportunity. Keeping the organization healthy should be the top priority of anyone in the organization at all times. Making this viable requires investing in the ability to detect signals at an early stage and in empowering people in the organization to act upon them. Fundamentally, it also requires a new kind of leadership. The best guardians of the ecosystem will be the ones with the greatest sensitivity to these signals, coupled with the will and power to act upon them.

Fighting the dead beetle problem together

Dead beetle organizations are all around us, although they can be hard to identify from the outside. (This is why Carmen insists on calling it the Schrödingers beetle paradox.) Redesigning them with critical failure points in order to help address fundamental issues is even more challenging, and always requires a tailor-made solution.

I’m curious, what forms of dead beetle problem do you see around you? And what opportunities do you see to build circuit breakers into your ecosystem?

Powerful patterns

Many organizations have started out on a journey of agile transformation. They adopt agile frameworks to help them deliver greater customer value continuously and may be starting to see the first benefits, but what is it that makes agile frameworks work?

Agile works because of patterns. It helps you to start eating apples instead of crisps. In other words, we replace an unhealthy pattern with a new one. Do the new pattern for long enough and it becomes the new normal. You have created a new habit. Do this on a large enough scale and you will eventually change an organization’s culture.

How does this work in practice? Let’s take a look at the most famous and most widely used agile framework: Scrum. It consists of a number of healthy patterns that, if done right, can put you on the path to a virtuous cycle of growth and relentless improvement. Scrum is so powerful because it has a strong focus on changing structures from the outset, team structures, and also behavioral structures. These structures are a combination – and codification – of a set of healthy patterns.

For a simple example, let’s consider the daily scrum. Teams can make the best decisions if they have all the information they need. The standup creates a pattern of information sharing and transparency that facilitates making better decisions and plans. These team level information sharing patterns combine to create a larger organizational pattern. A culture is created in which sharing information is the norm, allowing the whole organization to become smarter and to make better decisions.

Agile transformation works because it helps you to replace unhealthy patterns in your organization with healthy ones. This in turn will help your organization improve its performance while making it a great place to work. Sustain the pattern of replacing unhealthy patterns with healthy ones and you will find yourself in a virtuous cycle.

Clearly there is power in such a meta pattern. But if these patterns are so powerful, then why is agile transformation (creating this virtuous cycle) so hard? The problem lies not in learning the new, but rather in unlearning the old patterns.

Developing new habits

Anyone that has ever made a new year’s resolution knows how hard it is to create a new healthy habit. An old habit isn’t just replaced by a new habit: it often takes a long continuous streak of doing the right thing to create a new habit. Unfortunately, it takes only one instance of breaking out of the new pattern for you to have to start all over again (e.g. quitting smoking).

Therefore, building a new pattern requires conscious effort. Conversely, sticking to your old pattern requires no effort at all. It’s akin to a reflex. Organizations, like people, have reflexes. Patterns that have become ingrained in the organization. I often like to illustrate this point and the effect on organizations going through agile transformations by showing the video below. It famously shows Destin Sandlin as he attempts to master cycling on a bike that has its steering inverted.

This video is interesting as it shows the process of adopting behavior that is contrary to what the brain is used to. It takes Destin significant effort to unlearn what he has learned about riding a bike, and adopt a new way. It shows his progress from him not being able to ride the bike at all, to being able to consciously ride the bike, to finally unconsciously being able to ride it.

Agile transformation is a lot like this. When first starting out on this path many things feel alien or even wrong – all your reflexes are the wrong way around. Then you start to make progress and see results, but your transformation is still in a fragile state. You are consciously agile, but in stressful situations you or your organization might resort to old behavior. Considerable willpower and awareness of your own behavior and patterns will see you through, or help you get back on the horse should you fall off.

Continue to learn consciously, and you can reach a level where the new pattern becomes the new normal. You have adopted a new habit. At this point you are able to unconsciously follow the new pattern. It has become sustainable. In the case of a large scale agile transformation this may take years. But this is not the end state. Truly agile organizations are never done learning: you have to stay nimble. Even in a sustainable agile situation, an organization must strive to keep learning and improving consciously, while being unconsciously competent.

Agile transformation requires learning and adopting new patterns and unlearning old ones. Crucially it requires sticking to these new habits even in times of stress to make the transformation sustainable.

Organizational plasticity

How long it takes to sustainably adopt a new (agile) pattern depends greatly on the current state of an organization. There is another story of note in that video. It also shows Destin’s son going through the same learning process at a much quicker pace than Destin did. In Destin’s words ‘A child has more neural plasticity than an adult’.

Compare this to organizational learning. The older the organization, the stronger the reflexes and the more complex the preexisting patterns are likely to be. Younger organizations often find it easier to adopt new ideas and habits than older ones. The organizational debt, in the form of organizational patterns, has simply not piled up as much. Or in other words: there is less the organization has to unlearn. Younger organizations have more organizational plasticity. Of course, start-ups have it easiest. As they are a blank canvas of sorts there is very little for them to unlearn. (apart from sometimes years of business school).

The process of agile transformation can be a painful one to older organizations as unlearning existing patterns often takes the form of structural transformation in areas such an organization’s operating model and reward structure. But I believe the benefit of adopting agile patterns does not only instill healthy habits in an organization, it also has the potential to permanently rejuvenate an organization. An organization that has become truly agile has added consciously learning to its DNA, greatly enhancing its ability to adopt new patterns in the future. In effect it is able to maintain a higher level of organizational plasticity.

Conclusion

In agile transformations the difficulty lies not just in learning new behavior and patterns. Rather it is in unlearning old habits and consciously replacing them with new, healthy ones. Like adopting a healthier lifestyle, it is worth the effort and it will eventually become easier. Getting to the stage where you do not revert to unhealthy habits when under stress, takes serious willpower.

The ultimate goal is to get into a meta pattern of consciously building healthy patterns and replacing unhealthy ones. Agile can help you become a permanently healthier organization by rejuvenating your organization’s ability to learn.

Perhaps the added value of a job framework is that it remains upright even in times of stress or reorganization. Therefore I prefer to speak of a job framework suited to an agile organization. A framework that is transparent, simple, easy to adapt and tailored to the wishes of the employees of the organization.

Let’s get this out of the way first: The trend of having one generic function for everyone is not necessarily Agile. Conversely, having employees craft their own job descriptions is also undesirable, as this results in plethora of different job descriptions. The first option sounds simple, while the second appears to attribute ownership. However, how will you be able to find the person you need when you are looking for specific knowledge or expertise?

In other words, there is no single ideal solution and there never will be. Rather, what is required is a job structure that is suited to an agile organization. Because every agile organization will at some stage of its agile development run into limits imposed by her (old) robust framework. When that time comes it is vital to put people first rather than allowing yourself to be led by the existing (outdated) HR-system. The goal must be to develop a job framework that is future proof and can accommodate new functions and competitive remuneration.

Prerequisites for an agile job framework

How can you build a job framework suitable to an agile organization? Below I will provide 5 tips based on my own experiences as well as conversations with other HR professionals. Before I do so, however, I will explore some prerequisites that should be in place before you start on your new framework.

Prerequisite 1: Start by determining what the value of the job framework is for your organization

Don’t go looking for the perfect model. First of all it doesn’t exist. Secondly, it is preferable to listen to the wishes of your employees, rather than to stick rigidly to a model. Thus you need to ensure that the conversations about renewing your framework are the right ones.

Get yourself off to a good start by asking the most important question: What would make a job framework valuable to your organization?

Common answers to this question are:

• If it helps to offer structure and clarity
• If it can serve as the basis for remuneration
• If managers can use it to communicate with an entire job group in a simple way
• If it helps to create transparency
• If it can help to distinguish between people
• If it can serve as a starting point for development and career growth paths

This list clearly shows the Achilles heel of the job framework. It needs to be all things to all people. On top of this everyone values these things in different ways. My advice is collectively determine what your organization values most in a job framework. Don’t worry this doesn’t necessarily require days spent off site. Keep it small and light by asking this one simple question: What makes a job framework valuable to you?

Prerequisite 2: Co-determine the starting point for the conversation with employees and the works council

By creating a joint starting point you determine what is important to your organization now and in the future. Examples of such starting points include:

• Transparency
• Future Proof
• Co-created with all colleagues

Getting started with an agile job framework

The tips below will help you develop a job framework that is suitable for an organization that is living the agile values and principles. If your organizations is in this position it will be easier to develop an agile job framework than if your organization has not yet fully embraced Agile.

Tip 1: Use your organization’s vision and core values to develop a starting point

It is important that the job framework is tailored to your organization, i.e. your core values. What does that mean exactly? Let’s assume for a minute transparency is a core value of your organization. Your job framework should then also reflect this core value in all things, including remuneration. This core value should not only apply to the framework itself, but also to the framework development process. In this case it would mean including and informing employees in every step of the framework’s development, having regular review sessions, and using employee feedback to improve both the framework and development process.

A job framework that is basically good, but unsuitable to the organization, is the wrong framework. Start with your core values, and derive the framework from there.

Tip 2: Check your starting point against the agile values and principles

There are a number of values to take into consideration when developing a job description framework. For example, the new framework should enhance agility. If customers demand new services, you should be able to deliver quickly. If delivering this new service requires creating new job functions by wading through a procedural swamp, you are setting yourself up to be unnecessarily slow (and quite possibly lose to the competition). The same applies to job functions that are no longer required. These should be easy to remove, otherwise they will only cause unnecessary clutter (waste). An agile organization needs an agile workforce. Don’t get me wrong; this doesn’t mean firing people, instead it should be easy to switch employees to new (types of) work. If your organization’s job framework and the agile values are not in line, you may first need to ensure your organization has adopted the agile mindset.

Individuals and interactions over processes and tools is another critical Agile value. At its core, Agile is about people. What do your people need to feel good at work? What helps them to do their best work every day? A rigid job framework, that offers no space for individual wishes and personal growth, constrains your people in their development. Employees are often hesitant to pick up cross-departmental work when job descriptions have been worked out in great detail. In such a situation, working in a cross-functional team is commonly seen as extra work. Work that is added to their pre-existing work. While the pre-existing work is work the employee is judged on in his/her performance review (because that is what is in their job description). To stimulate working in an agile way it is therefore critical to slim down and simplify the existing framework and into roles. These roles can be agreed upon and regularly reviewed at the team level. Regular re-evaluation of these roles ensures they still add value for the team. Simplifying the job framework creates space for personal development.

Tip 3: Keep it simple

Keep job descriptions simple and concise. A single sheet of paper should do. If your organization has built a monster job framework, it is time to radically simplify.

Formulating three simple starting points is preferable to a long list. Then, make sure everyone understands the significance and consequences of these points. Having a session to discuss concrete cases, and see how these principles would apply in practice, can work wonders. For each case discuss how your starting principles would define how to act.

Strive for a simple job framework, including simple job descriptions. This requires constant upkeep. Writing simple job descriptions, only to never change them won’t do. Regularly refactor your job framework.

Tip 4: Optimize your job framework for change

Agile job frameworks come in different shapes and sizes. Every organization has different needs, so there are no uniform, ideal solutions. To help you on your way I offer some examples of how other organizations are addressing these challenges.

A form of job framework I often use, is to reduce the number of job functions to 5-20 generic ones, which can be expanded upon using roles. The advantages of this are that you create overview by simplifying and introduce additional flexibility using the roles. You can do this along two axes: expertise (Communications, IT, etc.), or skills (Business Partner, Specialist, Manager, etc.). In both cases an employee will belong to a basic group and can use roles to expand their profile. A remuneration bandwidth can be attached to the job function to provide a clear remuneration structure.

Baarda uses a different model for remuneration and development. The basis for this model lies not in job functions but in the problem solving abilities and added value of employees. Styr, a specialist agency in the field of remuneration, has developed a comparable but slightly simpler model and distinguishes six types of added value. The advantage of both these models is that they focus on growth and value creation. This provides clear boundaries for salary growth and the corresponding conversation. At the same time it shows you the gaps in your organization, meaning you can address these to ensure long-term organizational survival. Be sure to always properly reward your specialist, often they are the ones that most directly add value for the customer!

Depending on your needs the models above can serve you well. Is your priority to create clarity about employee responsibilities, or employee growth and the corresponding remuneration? Naturally, combinations are possible, as long as you ensure you are not creating a new job framework monster.

Tip 5: Small steps, deliver value incrementally

Finally, make sure you make changes to the job framework in an agile way. You can do so by being transparent about the process and by delivering value incrementally. This may sound simple, but for HR this is often a radical change in its way of working. It means involving stakeholders such as the works council from the earliest stage, rather than offering a massive proposal for their approval. It means constantly updating your colleagues about your (lack of) progress to ensure transparency. Please believe me when I say a simple intranet message won’t do. Get out there, and talk to people face to face!

Talking half a year to deliver anything of value is unacceptable. Rather, you can start by testing the new framework in certain job groups or by immediately addressing salaries you know (from benchmarking) to be noncompetitive.

Conclusion

Let’s go back to the beginning: What is an agile job framework? There is no single answer, and there never will be. What is clear, is that there is a need to transform old robust job frameworks into new resilient frameworks suited to agile organizations. The goal is to support cross-functional and cross-departmental ways of working and allow space for new job descriptions and competitive salaries. In order to create such a new framework two prerequisites need to be in place:

1. Start by determining what the value of the job framework is for your organization
2. Co-determine the starting point for the conversation with employees and the works council

Your organization’s vision and values are key starting points when designing a new agile job framework. The new framework needs to enhance organizational agility and prioritize people over systems. The new framework itself needs to be flexible and adaptable. This is important in order to maximize opportunities for personal development and cross-departmental cooperation.

Finally, we discussed some options for providing boundaries and structure. I gave three examples that can help structure your new framework:

1. 5-20 generic job functions combined with roles
2. The ‘Baarda model’
3. The ‘Styr model’

All three share a focus on sustainability:

• Space for adding, removing, or altering job functions
• Space for employees to develop and to take on new roles
• Clarity on boundaries and growth paths, and on how you can add the most value in the organization

Ultimately the most important question remains: What would make a job framework valuable to your organization?

When explaining Kanban, I have used the Kanban Pizza game, as described here, many times. Although I like the game a lot, I dislike the fact that it’s very wasteful of materials being used. You need a lot of post-its and markers to make your pizza’s. At the end of the rounds it adds up to a lot of waste, because you can’t recycle the materials that are used.

There must be a better way! That’s why I started searching for other Kanban simulation games. Then I remembered a Kanban Lego game I experienced during a Scrum Round Table meetup. There is a slideshare of the original game, where you can even download the materials you need to print out. Although I think this game also does a good job at simulating the different principles of Kanban, I think the tester’s role they introduce is quite complicated for just a ‘simple’ game. Then I thought, why not try and combine the Pizza game with this game and that’s how the Lego Animal Farm Kanban Game was born!

Below I will share the description of the game. If you are familiar with the Pizza Kanban game, you will recognize a lot of elements of it, seeing as the set-up and goal are the same.   

The goal of the game

The goal of the game is to create as many complete animals as possible within each round.

From a training perspective these are the main goals for the participants: Experience an existing process, which can seem quite chaotic and see how a Kanban system can give it more structure and flow Practice in visualizing the existing workflow and optimizing it through WIP limits and other improvements Experience inspect and adapt

How to set-up

The complete materials list is stated down below. Teams should have at least 4 team members for building the animals. There is a fifth role for keeping track of the number of finished animals and dismantling the animals. If you do not have enough participants however, you can consider combining the ‘Leg builder’ with the ‘Quality Assurance’ team member.

Each team (you can have multiple teams which will add some competition to the game) will have their own set of Lego blocks, a transport and scoring sheet and a ‘supply box’, which you as a facilitator will set-up at the start with masking tape. Any Lego blocks in the ‘supply box’ are safe from being marked as waste. However, don’t explain this to them until after the first round. Also, don’t make the ‘supply box’ too big. It should be big enough for all the loose Lego pieces to fit in, but small enough so that the participants should not be able to assemble the animals inside the taped square. 

The slide deck has the workshop with all the steps, including pictures of the four types of animals the teams should be making.

Round 1

There is no backlog in the first round, so you just let the teams create animals at will. Soon they will realize they do not have enough materials to build all types of animals, so they will have to make choices of what animals to build. 

During the first round, you do not show them the complete points system yet, which means they are not aware that they will be penalized for wasting material.

At the end of round 1 (after 5-7 minutes) you tell everyone to stop building and leave all the pieces on the table as they are. This is the time to show them the actual points system, where each finished animal is equal to 10 points. They will have to subtract points for all the animals not done, in other words, wasted materials. You subtract -10 points for each animal not done yet. -4 points for a wasted head or body and -1 point for every leg on the table. Everything that is within the ‘supply’ box does not count as waste. Everything outside of the ‘supply’ box needs to be subtracted from the total.  

Intermezzo

In between round 1 and round 2 you can explain the principles of Kanban. After you are done explaining, give the teams 5 minutes to visualize their workflow on the table by using the masking tape and post-its for marking the WIP limits. 

Round 2 and Round 3

In round 2 and round 3 we introduce the animal ‘backlog’. It’s a deck of cards with one type of animal written on it. One participant (usually the Leg builder) introduces a card from the backlog and places the legs on top of the card. The card is passed through the system so that all team members are aware of the type of animal which needs to be built. 

Again, after 5-7 minutes you tell everyone to stop and make sure they leave all the Lego blocks where they are. The points are counted and this time you give them 1 minute retrospective time to come up with improvements for the final round (round 3). 

Debrief

After round 3 we debrief the simulation, for example, by asking the following questions: What went well? When and where did work pile up (=bottleneck)? Where did you introduce improvements? What was the difference between the different rounds? Did you experience flow? In which round? Did you change your WIP limits after round 2? Did anything change when you started using the backlog?

Materials

Here is a list of the materials needed to run the game. For the Lego blocks, you will need a variety of different sizes, so don’t worry too much about the colors. 

Per team

• Masking tape
• Enough Lego blocks to make 4 cows, 4 horses, 4 sheep and 4 ducks
• Post-its for marking the WIP limits
• Printable from the slide deck:
  • A4 with 3 trucks to transport the animals
  • Scoring sheets
  • Animal cards (the backlog)

General

• Something to keep track of time (smartphone will suffice)
• Slide deck explaining the steps (also contains materials to print)

Final remarks

We have used this game for a couple of trainings already. Participants always seem to enjoy working with Lego and the game lets them experience a real process simulating bottleneck buildup. 

I’ve tried not to think too much about the actual process we are simulating. Those poor Lego animals! As someone who has decided to stop eating meat, because I don’t agree with industrial farming, this game can seem quite contradictory to my beliefs. However, it does limit the amount of post-its and paper waste and, in the end, it results in less clean up time afterwards. Also, no actual animals were harmed during the playing of this game.

This version of the game is licensed under Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International License. In short, it means you can use it for free, you cannot resell it and you are required to share any further modification with the same license format. Read more.

Hope you have fun playing. 

Imagine a scrum team running two week Sprints. They’ve implemented the roles and go through all the ceremonies. From a distance, everything looks perfect. But when you take a closer look, you find out they struggle to deliver a working product at the end of their Sprints. Sprint Reviews never involve their customers or real end users, so they don’t receive frequent feedback on what they are making. A team spirit seems to be missing in the team as no one reacts to either success or failure. There is no drive for continuous improvement, so things never change and they are stuck in their miserable situation. If you are experiencing some of these symptoms, you might be suffering from Zombie Scrum.

About 3 years ago, Christiaan and Johannes first wrote about Zombie Scrum in this blog post.  Barry Overeem and Christiaan Verwijs from The Liberators, together with Johannes Schartau from Holisticon, are currently in the process of writing a book about Zombie Scrum. I talked to Christiaan and Johannes to find out more.

_{Art by Thea Schukken. Created for The Liberators}

Could you give us some background information on why and how you came up with the term ‘Zombie Scrum’? 

“It started out as something we could offer to help people working in an agile environment. We saw so many teams trying out Scrum and from our own experience we know that it is difficult to make it work. We kept seeing people being trapped in lifeless systems. It looked like something from a scary movie and we started using the name ‘Zombie Scrum systems’.“ Johannes explains. “Basically,  it comes down to people brainlessly following some principles, without actually understanding the essence of why they are doing what they are doing. Working with Scrum should be a lively process, we saw a lot of opposite examples of that unfortunately. “ 

What are the main characteristics of a team that is suffering from Zombie Scrum?

Christiaan reiterates that it’s about teams focusing mainly on the process and the mechanics of Scrum, without understanding the purpose behind it. “It’s easy to work on the process, without having frequent interaction with your customers and focusing on delivering value for them continuously. 

If you look from a distance it sure looks like Scrum, but if you look closer you see that the team lacks a beating heart. This is not only a disadvantage for the customer but also sucks for the people within the team. “ 

Was there something that triggered the need to start identifying the symptoms of Zombie Scrum? 

Johannes goes back 4 or 5 years, when conference talks and books were mostly focused on the mechanics of Scrum. “No one was really addressing the fact that making Scrum work for your team is difficult. You only heard the success stories and not the reality that you can also fail at it. From personal experience, we know how painful and difficult it can be, but we also know how Scrum can help you and your team build good stuff and create a fun environment while doing that. 

When we started naming it Zombie Scrum, we received a lot of enthusiasm from the community, it gave us the reassurance that there were more teams out there struggling to make it work. We wanted to make it transparent that by making small changes at a time it’s possible to recover from Zombie Scrum and move into more Healthy Scrum. “ 

What has happened since you started naming it Zombie Scrum? Do you think the situation has improved or gotten worse?

Christiaan laughs, “Since then, fortunately, a lot of people are more aware that it’s not just about the mechanics and going through the motions of the framework. There is more awareness, and we are hoping we also contributed to this. With our Zombie Scrum Symptoms Checker, we are currently gathering a lot of data from scrum teams, but we cannot conclude yet if the situation is improving or not. “ 

“It had a dramatic effect when we started naming it. “, Johannes adds.

“People understand the metaphor, which helps them recognize the symptoms of the narrative. Once teams are able to acknowledge the fact that they have symptoms of Zombie Scrum, they are more likely to take first steps in finding improvements. “ 

Together with Barry Overeem, you both are now in the process of writing a book about Zombie Scrum. Can you give us some insights of your book coming up next year? 

Johannes explains that the book ‘Zombie Scrum – how to survive the impending apocalypse’ will be part of the bigger ecosystem of interventions they are working on, like the Zombie Scrum Resistance website and the Symptoms checker survey. “With the book, we hope to reach a wider audience and therefore help more teams in finding the steps to resist doing Zombie Scrum. In the book readers will find all the interventions that we can think of. It will be easy to read with a lot of funny illustrations. “ 

This is actually the first time Barry, Christiaan and Johannes are collaborating in writing a book. They are still figuring out how to do it effectively and with an agile approach. They have agreed with the publisher Addison-Wesley that they can release each chapter individually so that they can get early feedback on it and improve on each part before the final submission date. They will also be publishing some parts of the book on the website, so readers won’t have to wait till the final publishing date (somewhere in Q3/Q4 of 2020).

You mentioned the survey that you are using to gather data. What are the results so far? Are you noticing any patterns? Anything that stands out?

Christiaan immediately grabs for the latest results. “We launched the first version of the Zombie Scrum Symptom checker in September this year, we have already had responses from 1000 teams. Of course, we still need to take the time to dive into the data, but we can already mention a few of the patterns that are emerging. For example, if you look at the responses with regard to teams working with their customers, about 60% of the teams rarely or never see their users or customers. It must be tough working in those teams where you never meet the people who you are building for. 

While the goal of Scrum is to deliver value continuously, we see from the data that 60% of the teams say they don’t have something valuable to ship after each Sprint, they basically have to wait for months to receive feedback on their product or service. What is surprising is that 43% of the teams say that Scrum is not effective for them. “

So why do you think they are still using Scrum if they feel it’s not effective for them? 

Johannes shouts out: “Because someone told them to do so!”

_{Art by Thea Schukken. Created for The Liberators}

As an incentive for filling in the survey, teams will receive a personal feedback report on how they are doing on the Zombie Scrum vs Healthy Scrum scale. The score they receive is however, relative to the data entered by the teams.  

Is there anything you can say about the quality of the data? Aren’t you afraid that only teams who are self aware will fill in the survey? 

“Good question, I actually don’t know if we have a good representation of teams. “ says Christiaan. ”Maybe teams that really need help, but do not self reflect will not fill in the symptoms checker. We do however see that teams who are struggling are filling in the survey and asking for suggestions on how to improve. “ 

You are also big fans of using Liberating Structures, can you give one of your favorite examples of using LS as an antidote to Zombie Scrum?

Christiaan immediately mentions the structure ‘What I need from you’. “It’s a really powerful structure to clarify what you need from each other. If you are a scrum team you need to understand and agree what you need from each other in the different roles. You can do it multiple times and even involve management, support and customers in the process.” 

Johannes adds that self-organization is an important part of a healthy scrum team. “Liberating Structures are used to support self-organization within the teams. Teams need to learn to specifically ask what they need instead of waiting for someone else to tell them what to do. This way they can improve their working strategy together and most importantly take ownership of it. “

If you look back on the experiences you have had with teams that are suffering from Zombie Scrum, what scares you the most? 

Johannes starts looking scared and says: “The intense meaninglessness that teams experience, while at the same time being too busy and overloaded with work. It chills me to the bone and it’s a waste of people’s lives. “ 

Christiaan adds: “I am worried about teams that never get to talk to real users. They keep saying we are talking to stakeholders. They may have an internal Product Owner, but never get a chance to talk to the users themselves. Very scary! ” 

What do you both hope for the future, will the Scrum community ever be Zombie free?

Johannes gives a big shout: “No!”, but then adds: “We hope that people will be able to recognize the symptoms much sooner. When Zombie Scrum becomes an established term, more teams will be able to recognize it and understand that there is a cure for it. “

Christiaan hopes that people will stop blaming Scrum when it’s not working for them, but understand that they are actually suffering from Zombie Scrum. He adds that what they are doing now will add to the ecosystem of interventions for improving teams. “With the book we want to give teams something tangible. It will not be a theoretical book, but a very practical one containing survival strategies. We will describe easy things to try which will hopefully help teams rediscover the fun part. “

I’ve heard that movie zombies can only be killed by a headshot, do you think this also applies to Scrum Zombies?

“We are not eradicating the Zombies themselves. We see ourselves as scientists instead of the military people with shotguns as in the movies. We believe we can find possible treatments to Zombie Scrum. The people who are infected don’t have to be killed, but we want to show the world that they can recover from it. ” says Johannes.

Christiaan adds: “In the end, it’s not about blaming the teams, but recognizing the symptoms and finding ways to improve. “ 

If teams find themselves stuck in Zombie Scrum now and can’t wait for the book to come out, what would be your suggestion as a first small step?

Christiaan says an important first step is to make sure there is interaction with the users. “Teams can start by inviting just one user to their Sprint Review. Have something prepared especially for this user so that they perceive adding value to the event and are able to give useful feedback to the team. “ 

“Basically, you should always look for ways to get results that help the team inspect the progress faster. “ says Johannes, “Start small and continue from there. “

_{Art by Thea Schukken. Created for The Liberators}

Conclusion

As the interview wraps up, Johannes gives some final remarks to consider: “One thing I want to emphasize is that when you have symptoms of Zombie Scrum, it’s definitely not a hopeless case and there are ways out of it. Most of the times it’s actually pretty easy. What we are going for in the book is to show you that there are small steps you can take towards recovery and as you accumulate these small steps, it will result in bigger changes. 

When someone says: You are doing Zombie Scrum, there should always be a second part of the sentence saying: and there’s a cure for it. “

Christiaan suggests: “Hey, we should put that on t-shirts!”

A big ‘thank you’ to Christiaan and Johannes for taking the time and having a chat with me, though I almost did not survive this interview as Scrum Zombies were lurking around…

Do you recognize any symptoms of Zombie Scrum in your own environment? Let us know and maybe we can bring you back to life again.

The object of the game is to provide insight into the consequences of organizing in component- or end to end feature teams.

Total duration: 15-30 minutes
Playtime: a few minutes
Reflection: about 15 minutes

Requirements (on the basis of 6 players)*:

• A Duplo floor plate
• 36 Duplo bricks (size 2×2) in six different colors
• Something to keep time
• A flip-over or whiteboard and a marker to write down production times
• 2 pictures of different Duplo structures (such as the ones below)

*it is practical to match the amount of colors to the amount of players. I would recommend a minimum of 5 players. Should you have more than 10 players, I would recommend to let them play against each other in groups.

Preparation

Tell the players the object of the game is to build the Duplo structure you will show them on a picture as quickly as possible. The structure consists of six stacks of Duplo bricks that all contain bricks of every color (see picture below). Each player can only touch his/her own bricks.

Explain to the group that each player is analogous to a team in an organization. The different colored bricks represent the people (i.e. skills, capacities, etc.) needed to build a product. Time stops when the entire structure has been correctly completed and all the towers are in the right place on the underfloor.

The game consists of two rounds. Before every round the the group has one minute to discuss how they will build the structure. Exchanging Duplo bricks is not allowed.

Playing the game

Round 1: component teams

1. Divide the Duplo bricks over the players. Each player receives 6 bricks, all the same color.
2. Show the group a photo of the desired structure (such as the one below). Give the team one minute to discuss how they would like to build it. No building is allowed yet.
3. Build! Time how long it takes the group to build the structure correctly. Write down the time it took the team.

An example Duplo structure for round one. Keep it simple, but make sure every stack uses all colors. Positioning also matters!

Round 2: End-to-end (feature) teams

1. Divide the Duplo bricks over the players. Each player receives 6 bricks, one of each color.
2. Show the group a photo of the desired structure. Give the team one minute to discuss how they would like to build it. No building is allowed yet.
3. Build! Time how long it takes the group to build the structure correctly. Write down the time it took the team to build the structure.

An example Duplo structure for round two.

Discussion

Discuss the game and results with the group. Ask them to share their own findings and observations before also sharing your reflections as an Agile Coach/Scrum Master/Facilitator.

Questions worth asking:

• What caused the difference in production time?
• Which dependencies do you see in either situation?
• How much coordination between teams (players) is required in each situation?
• What does that mean for the role of managers in both situations?
• What would happen in both situations if you would disrupt a single teams production? (take away one player’s bricks)
• How would you approach this assignment if you would build the product with only a single team? (one player)

Interesting subjects to discuss relating to this mini-game:

• Independent path to production
• The merits of feature teams compared to component teams
• Building a ‘scale free’ team of teams
• Ease of coordination
• Impediments to a single team hit a team of component teams much harder than a team of end-to-end feature teams
• End-to-end feature teams are more independent and require less coordination among them than component teams

Have fun playing! And should you have any feedback to help improve the game, let me know.