What’s agile?

On my journey to try to define the meaning of agile, I came through Clean Language. “Clean” is a way to ask the question in a non-directive manner without influencing the answers. So, I decided to ask first my network on social media, “What kind of agile is your Agile?”.

Once I asked my “agile” friends, I applied it in my daily work in the massive transformations, in my retrospectives, during my workshops. I pray that question since near two years now, and I’m still surprised by the answers.

For your understanding, I always ask the question before:

  • Explaining that agile is an evolution of lean manufacturing in the middle of the 1990s
  • Introducing “the Agile Manifesto for Software Development”
  • And finally to present “the Declaration of Interdependence”.

What kind of agile is your Agile?

I ask the question without any explanations at all. What is your gut telling you about agile? And then start the collective improvement of all “gut feelings”.

At this time, around 300 people have been interviewed from entirely different areas: IT, Finance, Governance, Coaching, HR, Pharmaceutical, Manufacturing, Consulting. For better understanding, I clustered the answers in four categories:

  • quantitative means that agile is understood as results
  • behaviour means that agile is how people are interacting together
  • process, agile is perceived like a process or a methodology
  • bypass, people didn´t answer the question due to communication issues or lack of focus

From a quantitative perspective, agile is seen as:

  • fast visible results
  • quick wins
  • deliver quickly
  • quality
  • technical excellence
  • workable software
  • rapid customer satisfaction
  • more time consuming than previous methodologies
  • seeing results and not just work in progress
  • opportunities instead of limitations
  • working on a topic which produces value

From a Behaviour perspective, agile is seen as:

  • flexibility
  • pragmatic
  • mindset
  • adaptability
  • The capacity to say “No.”
  • responsibility
  • multiple competencies
  • client oriented
  • putting me in the shoes of my customer to gain a clear vision of his needs
  • have interaction with customers or users
  • better collaboration
  • business & development working together
  • teamwork
  • close collaboration
  • will empower us to collaborate and share experiences
  • trustful cooperation with project members
  • fully dedicated, I have the feeling that I am moving with
  • motivation
  • happy and satisfied
  • consistency of projects
  • working on topics which fit my skills
  • simplicity
  • meetings, not that often
  • sustainability
  • welcome change
  • challenges instead of problems
  • challenging and exciting tasks with own responsibility and decision power

From a process perspective, agile is seen as:

  • methodology
  • DevOps
  • feedback
  • daily statuses
  • time to market
  • individual and interactions over processes and tools
  • workable functionalities overextended documentation
  • collaboration with the customer over contract-based relations
  • incremental product
  • well defined roles within the agile team

Bypassing the question won’t be detailed here. The reason is that the content of avoiding doesn’t matter; it is withdrawing that matters. As a coach, I try to understand why these people were not able to respond. My interpretation is that 17% of people are not focused enough to answer a simple question due mostly to:

  • Stress
  • Overwhelming multi-tasking
  • Stocking in their expertise
  • Switching from one meeting to another
  • No time to think
  • My boss decides for me

What are the lessons I learned from that running poll?

While addressing people’s guts and not their knowledge (brain), I was positively surprised to discover that 47% of people think that agile is behaviour related. In systemic words, behaviour is the interaction of agents in a system when here, those agents are people.

In the next sections, I will explain how you measure that interaction and how you can create the conditions to enforce that “behaviour”.

What’s not agile?

Defining what something might be is hard work, and setting what ‘isn’t is even harder.

To avoid being polluted by my own biases, I did what I always do, and I ask the team. And in that case, the team is my social network.

While raising that question, I discovered that the answer came slightly more natural than when defining what it is.

From the network, not agile means:

  • Believing we have any capacity to predict the future: “Once ‘I’ve met a Program Manager of an extensive agile program of 25 teams. He planned all the sprints for the next two years for all teams in his first week.” (Attention, ‘that’s not good!).
  • Telling people what to do and how to do it: it is about commitment and not paternalism.
  • Believing success is in doing what we said we would do: 
  • Doing things or making things that are not needed
  • Not making time for reflection
  • Intolerance of experimentation and failure: trial and error is critical, only once you have tested your idea, you can assume the design is right
  • Imagining what our customers need
  • imposed agile
  • Acting as though the plan were more real than reality.
  • Early documentation
  • The PMO organization
  • “Agile” without retrospective
  • Playing it safe to be perfect rather than taking a risk to be excellent and learn to be better next time.
  • Me climbing a tree
  • Predetermined conclusion
  • No heart, no joy and no chance for improvement.
  • All thing you want that response to: ‘Don’t care about events that change Your Knowledge and continue do the same thing in the same way before the events raise!
  • Reluctance to change 😉
  • Customer-provider relationships
  • Egocentrism and selfishness
  • Agile means quick, able to change, and able to respond. Rocks are not “agile”.

For sure, my audience ‘wasn’t partial and is considering all the negative aspects of the universe as being not agile. But some of them are valid.

What’s organisation?

In June 1980, R.H. Waterman, J.R. Thomas, J, Peters and J.R. Philipps wrote a paper called “Structure is not organization” in order to elaborate their 7-S Framework for organization design. Thirty years later, the question is that tittle remains accurate. Organization isn’t structure. They are two separate ecosystems.

Organization isn’t structure

The structure is the boundary in where you are working with all its codes, rules and job descriptions. It is represented by an organigram with the CEO and the Board of Directors on the top and all the necessary departments, divisions, workstreams and other functional silos to picture out the “chain of command”. The purpose of the structure is to provide safe robustness through multiple layers of controls and accountabilities.

On the other hand, an organization is a social network of people gathering to address a common purpose. That network can be represented by a sociogram highlighting all the social interactions in that system. In organizations, projects and programs can be designed as organizations: people are coming from different areas, business units, etc.. from the enterprise to work on a common goal. To ensure the control of that “value creation”, you have to hire a project or program managers to ensure that “organization” is reaching expectations. And you have to ensure that these projects managers are aligned with their dedicated line managers from the structure. A consequence of that situation: productive people in projects have to deal with two supervisors.

Another angle is the customer perspective. Where is the customer? He is always at the organization level because there is where he gets what he’s buying. The only relationship of the customer with structure is the contract.

In 1999, Kimball Fisher, in his book “Leading Self-Directed Work Teams” described the difference between “Traditional Organization” and Self-Directed Work Teams like this:

Screenshot 2019-08-15 at 13.01.32

To sum, any enterprise has to organizational levels, structure and organization. The purpose of “Structure” is to provide compliance; the use of organization is wealth.

Compliance is worth in a very stable world when the demand bigger than the offer is and where you can afford long term product or service lifecycle. “Structure” is a requisite of scientific management and system thinking where you design your enterprise like a top-down factory.

Unfortunately, we are in the 21st century, and these old models are obsolete. Peter Kruse explained that social networks are in fact and not a calamity. Trying to control these systems through traditional management doesn’t work (try to stop the internet?). Kruse says “The challenge of leadership in 21st century’s network organized society is not to control. It is to resonate with the network.

The titanic metaphor

 In 2017, I was invited to give a talk at the Agile Tour Montreal on the early concept of agile organization which became “A.O.”. Initially, I intended to explain how to build a pigpen as a metaphor emerging from the Agile Animal Farm game I created a couple of years before. But, the tittle sound to be too extreme for that approach. So I decided to use the Titanic as a metaphor.

I guess that everyone knows the story of the Titanic or has seen the Hollywood movie. It is about a big cruiser hurting an iceberg and sinking in frozen water with a lot of people dead or injured.

The Titanic was built for “robustness”. That ship was the pinnacle of comfort and luxury; had state-of-the-art technology onboard like high powered radiotelegraph transmitter and advanced safety features.

Then a “black Swan” occurred. A “black swan” is a “highly improbable and rare event with huge impact” (N.N. Taleb, The Black Swan, 2007). The cruiser detected an iceberg on its way. Even if the distance before impact was long, the inertia of the ship made avoiding collision impossible.

Screenshot 2019-08-08 at 13.21.18

Screenshot 2019-08-08 at 13.22.15

To avoid “black swans”, enterprises tend to be as predictable as possible to anticipate risks. VUCA is one of the mantras in the senior levels. Volatility, uncertainty, complexity and ambiguity sound to be the “magic stick”:

  • “Volatility” is reduced by customer experience, market and threats analysis, and workforce control.
  • “Uncertainty” is reduced by data mining and business intelligence tools
  • “Complexity” is reduced, but here only the complexity of work does.
  • “Ambiguity” is reduced through transparency

Unfortunately, VUCA doesn’t solve any “black swans”. Here some examples:

  • BREXIT: UK becomes uncertain for investors and UK citizens
  • D. TRUMP: US tax laws and the revocation of several trade deals impacted international relationships
  • Volkswagen Diesel Scandal: customers want to shift to eco-friendly vehicles like electric cars. German car manufacturers are experts in petrol engines, e-cars technology isn’t available in the EU and has to be imported from abroad. 
  • etc

The focus on robustness is leading to disaster. Continuous improvement of an old tool doesn’t make it more effective. On the contrary, it increases weakness.

Responsiveness over robustness is key.

responsiveness, rɪˈspɒnsɪvnəs/

noun: responsiveness

“the quality of reacting quickly and positively.“a bank’s responsiveness to customer problems engenders trust”

Screenshot 2019-08-08 at 13.52.42

If your enterprise is a collection of light speed boats, you will be able to avoid collision with the iceberg even close to it.

Screenshot 2019-08-08 at 14.00.39

Responsive organizations and its synonym agile organizations are behaving like a crowd flocking like birds following simple rules:

  • Point to the destination (single-objective)
  • Avoid collision (alignment)
  • Follow the lines (within the structure)

Screenshot 2019-08-08 at 14.14.04

A structure in that model, is the first line of defence, a safe-to-fail container allowing emergent behaviour supporting the creation of both knowledge value and business value.

What if your company is massive? Well, the principle remains the same with much more small boats.

What can we learn from that metaphor?

“Structure” is the scaffolding supporting “Organization”. Looking for robustness isn’t bad, but it can make weak the whole structure when an unplanned event occurs.

“Responsiveness” is vital in a complex world because it is impossible to control everything. Every single entity has to have the capacity to respond to threats or opportunities.

  Each team or boat is autonomous and empowered. Team´s activity bucket or backlog is a portfolio of activities. At the top level, enterprise portfolio is a consolidation of all team portfolios in a single view.

The border or the structure is the corporate identity that binds all speed boats together during the cruise.

In “big” responsive organization, the structure is at its lightest using only the required necessary boundaries cleaned from ineffective organizational debt.

And when a “black swan” occurs, each boat can separate from the cruiser in any form they need to respond to that emerging threat. And then gather again in the old way or a brand new one.

Screenshot 2019-08-08 at 14.26.43

Sometimes, from the cruisers cabin perspective (governance) new opportunities to a spin-off, to sell a ship, to buy ships to improve the shape of the cruiser happen. Maybe you need to parallelize destinations; perhaps you need to be more significant for deep sea.


The farmer metaphor (source P. Niedschmidt)

A farmer has three cattle. In a sunny afternoon, the Knight came to visit the farmer and says:

“ Hey farmer, I saw that you have three cattle in your pen. My daughter is getting married this Sunday. I take two cattle.”

The unlucky farmer yelled, “You cannot do this to me!” And the knight answering “ I already did.”.

The farmer was furious and asked for an audition with the duke. He explains to the duke his concerns and the duke answering

“Farmer, this is not my business; you have to respect the chain of command and express your claims to your knight.”

Again the farmer was angry and went to Church.

At the Church, he explained his issue to the priest. And the priest answering:

“My child, prey, prey harder. God will give it to you back one hundred times.”

What can we learn from that metaphor?

  • In a master and servant relationship, you always lose as a servant.
  • On the top of the chain of command, you have the King. And the King is nominated by God.
  • On the top of the Church, you find the pope. And the pope is nominated by God too.
  • Both organizational models are deeply coded in our cultural DNA and let us believe that a corporate matrix (organigram) is the only logical solution to a structure.

That model has been hijacked in the Middle Age and Renaissance period when Dutch merchants started to deal with the Indies and China. In a very stereotypical manner, the merchants were able to gather to create the West Indies Company and the Hanseatic Ligue of free cities (North Germany) due to some structural weaknesses. The Church wanted to have more churches and was strongly focused on Reformation and Inquisition. The King wanted to extend his territories and was too occupied in wars against other kings.

That situation led to the creation of what we can tell modern global business.

Jason´s story

Jason is a junior in the company. It is his first job after leaving university.

He is passionate about his job.

The only issue is to getting access to information. Jason has to ask his supervisor when he is available. And usually when the information required comes back to him, it is either too late or outdated.

As a junior, he is very respectful and accepts that situation. The only options he has are:

  • To focus on its career
  • To adopt the same attitude than his supervisor
  • To use politics for his purpose and get closer to the higher authority
  • To address the problem and get fired
  • To leave the company

Jason has another more private passion. He loves to dance. 

In the evening at the salsa dance course, he met Elsa. 

Elsa is a beautiful and enthusiastic young woman.

While dancing together, they also get closer in their private life.

Elsa is the assistant of the CEO of the company where Jason is working.

They are sharing a lot and talking a lot. They’re talking a lot about the company in fact and that also during their free time.

After a while, Jason knew a lot more than his supervisor. 

What can we learn from that story?

Screenshot 2019-08-08 at 17.20.02

“Structure” is what might be. “Organization” is the real relationship not limited by boundaries.

How to experiment it: the sociogram game

It is a game, an exercise that I use all the time to read the existing system called enterprise.

During a kick-off session, all the people of the enterprise are gathering. After icebreaker and introduction, we are starting the experiment.

Disclaimer: that exercise is a very light one and doesn’t dive deep in sociogram details. It gives a first shot of the current working environment.

Let’s start.

  1. Ask to draw your face on a sticky note, add your name, what you are doing, and what you love doing. And you have five minutes.
  2. On a wall, please stick the notes together so I can see your team. Or not if you are working alone. (Time between five and ten minutes depending to the size of the crowd)
  3. Now, on a small red sticky note, write your name on it and stick it on the person who is your manager or boss. (5 minutes)
  4. In another round, use now a small blue sticky note, write your name on it and stick it to the person you are asking for help. (5 minutes)
  5. Once done, everyone is looking at the full picture.

What can we learn from that simple exercise?

  • We can see what each attendee is considering what its team is. I never tell explicitly if the unit is business-related, project-related or whatever chapter or squads.
  • The sharp time box pushes you to give an intuitive answer.
  • The red sticky notes are highlighting the manager in “Structure”.
  • The blue sticky notes are highlighting the “Leader”.  A Leader is the one recognized by its subordinate. You find “natural” or “emergent” leaders in “Organization” only. 
  • When you are lucky, the leader and manager are the same people. But let’s be honest, this happens very rarely.

We can go a little deeper in that experiment to see where value is created?

  • Again with sticky notes, I ask each individual to write on one sticky note each step they need from a demand or request to delivery or accomplishment. It may take a while.
  • Then you ask every individual to put its stickies on a wall (not the same than before).
  • The next has to add its stickies on the first and so on until everyone is completed.
  • The outcome will be very messy: a lot of crossovers, in parallel running activities, double activities.
  • Then ask for refinement and measure how long it takes. It will take a long time. Why this? Workers and managers are often in a tunnel running to complete their tasks. They usually never stopped to take a look at what they are doing.
  • Now, continue the game by giving a business value of one hundred of the whole Flow (picture). Ask a new question again “please use some other sticky notes and distribute points on all the Flow so that the sum makes one hundred. Attention, these points are only related to business value. It may take a while.
  • After that part, make a second round by giving customer value of one hundred and proceed like before. This part is a bit painful because nobody used to think about the customer in the whole process. It is simple to believe that the client is at the beginning and the end of the Flow. But that’s not agile, right!.
  • When this part is complete and if people are not too tired, I ask to balance the Flow. Balancing the Flow means having a perfect equilibrium between business value and customer value, a win/win situation.
  • To complete the whole exercise, I ask everyone to take back. Look at the two walls and ask the last question: “how can we organize ourselves to ensure a permanent win/win flow?”.


Any effective organizational is designed to use the full potential of a social network called people. The purpose of that network is to deliver high added value services or products to a buyer called a customer. The consequence of happy customer or Customer Experience (CX) ensures high performing business value creation or Service Experience (SX).

A smart organization is built around motivated people or People Experience (PX). Organization experience (OX) is the consequence of effective PX, CX and SX in that order.

Unfortunately, when designing performance “Structure” is never on the plate. It usually comes before and at the end of the OX process to ensure compliance.

It is mostly about behaviour : testing with the agile animal farm game

In 2011, I read a blog post of Mario Moreno on an Agile Animal Farm. In the beginning, I found it childish. Then I came back the next day with the feeling that I found something exciting.

At that moment, I was struggling with Agile presentation randomly addressing or paraphrasing the Manifesto for Agile software development. I always had the intuition that “Agile” is more than what is written in the manifesto.

M. Moreno´s post was like an epiphany for me. Here I have a list of behavioural stereotypes to analyse team behaviour from the perspective from individual characters.

When I learned about Agile, the trainers use the chicken and pig metaphor. The pigs are the agilists, empowered, committed and involved. On the other hand, we have chicken, which is the stakeholders.

If you know a bit about Scrum, the pigs are the members of the “Scrum Team”, and the chicken is Management, Customers and Users. The impact of that metaphor is that “chicken only contribute with their eggs” and “pigs are putting their flesh on the set”.

Moreno added more characters here (from the blog post), and I will restitute the original text under brackets:


They are fully engaged in their work, and they are working in a pigpen with other pigs sharing the same love for the job.

They are assertive and accountable for their work.

Example of pigs: from the Gallup State of the Global Workplace report 2017, 15% of people are engaged at work in the whole world. It means 15% of pigs and 85% of other animals.


They are coming and going around work. Chicken are helpful, and they like to contribute with their eggs even if those eggs are rotten or broken. They don’t need to understand how the work is done. Their expectations are the delivery of that work.

Example of chicken:

  • A customer is usually seen as a chicken bringing requirements, budget (time & money), users, etc.…
  • Users are also chicken; they provide feedback.
  • Management is a chicken while bringing the environment, the structure, the organisation where pigs can evolve and create value.
  • Typically other chickens are experts, PMO, trainers, providers…


“They like to stealthily move into and through the team, seeing who has specific skills and ideas. Then they want to steal not only resources (Agile team members) for their teams, but they also take ideas. 

They are not necessarily harmful because they are often so quiet in their manipulative work. Foxes are dedicated to their success”.

Example of foxes:

  • A manager is asking a pig to estimate a project outside of pigs engagement. Here the manager is « stealing » resources and budget of the running project.
  • All impediments and distractions blocking pigs progress are « Foxes “.
  • Contract Managers, Cost Killers, Resource Managers, Interim Managers are often Foxes because of focusing on details and not on the whole activity.
  • The « do-you-have-just-5-minutes » is the most usual trick of “Foxes” to steal time and budget from the “pigpen”.


“They like to fly around the project and not contribute in any manner. Seagulls enjoy “talking” (mostly hearing themselves speak) and pretend they are adding value, but they are only annoying the pigs.

Often, they like to swoop in so it can look like they are involved (and they’ll tell others this). They are often quite harmful, squawk a lot in a “know it all” manner, and often poop on people and their ideas.”

Example of seagulls:

  • Coaches and consultants are often seen as Seagulls
  • Experts are definitively Seagulls if they tell and judge
  • Evangelists, Technology Consultants.


“They are deceiver types who will use the trust of the team to gain insight into topics so they can then “rat” on what is going on to others. Often on Agile teams, they are deceivers because they are really anti-Agile or just plain negative people. 

They often know the decisions that are made based on particular contexts that the team is in but will twist the truth to bring the project down. 

It is essential to identify these deceivers as quickly as possible and get them off the team.”

Example of rats:

  • Business people are willing to get their stuff done before other business people.
  • Managers are willing to get their stuff done before business people.
  • In a large organisation, some Product Owners are « rats » when they are provided different form tiers than the pigs (hidden competition).
  • Some Agile coaches using the power of their image for politics so they can stay longer in the project and other coaches have to leave earlier.
  • Any people who are unable to manage power for the group and are slipping into political self-interest.


“They are a lazy type on an Agile team that really do not pitch in but instead like to sleep. Cats are almost purposefully not assertive, have been used to just “getting by” on projects for years, and are not interested in feeling ownership of the work.

They typically neither positive nor negative and like to be left alone. 

The other team members will begin to notice this behaviour and realise they are not interested in becoming part of the team.”

Example of cats:

  • Typically someone established in the organisation for a long time
  • That is the purpose of « poor consulting », cheap price, keeping the place as long it’s possible and only focusing on how much to charge and not the value to deliver.
  • Laggards in the “Crossing the Chasm model”.


“They are command-and-control types who think they can continue to tell their folks what to do even though they are dedicated to their Agile teams.

Sometimes referred to like bullies, they charge right into the team and attempt to direct them to their work and often deviate the team from building product functionality. 

Typically, Bulls are not interested in the Agile mindset. They see it as a challenge to their authority (technical or managerial) or don’t really understand or care about the business benefits of Agile, but instead want to maintain their status.”

Example of Bulls:

  • Bulls is the standard of «The Mediterranean » (“Macho” management style).
  • Listen to « Daddy » (Paternalistic approach).
  • Don’t think, act and apply the process (Patronizing)
  • Some Agile coaches and trainers are misbehaving that way while imposing methodologies and tools for their own sake.
  • A lot of people are waiting to get access to this kind of behaviour.  Their “DNA” has been programmed for this since centuries: “I want to work hard to become a project manager, then a manager. And then you will follow my orders.”
  • Masters & servants/slaves relationship (Command and Control)
  • They are people to think and people to execute (Neo Cartesianism, Scientific Management).

Shepherd Dog

“And finally no farm is complete without the Shepherd Dog.  

However, on an Agile farm, it cannot be just any Shepherd Dog. But instead, a benevolent Shepherd Dog who is kind to his animals and ensure the animals have what they need to grow and prosper.  

The Agile Animal Shepherd Dog encourages, inspires, and allows for team autonomy and self-organisation.”

Here I deviated from the original post. In the Agile Animal Farm game, our Shepherd Dog is a pig. It is “Babe, the Shepherd Pig” like in the movie.

“Babe” is an agile coach or if you like a “servant-leader”.

Let’s discover the game and what we can simulate.

First round: discovery and collective learning

  • Make teams of five people (minimum is three teams).
  • Each team sits around a table with some paper and pens.
  • You have a set of cards with the animals drawn on it. Come to each team member with « animals » cards and ask to choose an animal to play.
  • During 5 minutes, each team has to draw a landscape with five flowers in different colours and each team member has to play its “animal” character.
  • After that five minutes, check the result and ask the crowd who played what animal.

Lessons to learn: Even with low information, the crowd experienced collective learning and had a fun moment. To increase the learning factor, all teams are more from one team desk to the other for each debriefing.

Second round: discovery and collective learning

  • While keeping the same configuration then previously, this time, I attribute an animal card to each participant.
  • On purpose, I never attribute the Shepherd Dog but try, instead to create chaos. The idea of chaos is to experiment with an awful situation with the highest emotions possible. Because in life, everything is neither black or white, testing the “bad” limits generate a positive counteraction. Some samples:
    • Team A with Bulls, Seagulls and Chicken
    • Team B with Rats, Cats and Foxes
    • Team C with only Seagulls
    • Team D with one Pig, Foxes, Cats and Bulls
  • The requirements are the same than the first time: we want to highlight behaviours.
  • Again, each participant tries to identify who was playing what animal.
  • The noise level might be high due to the number of seagulls and some bulls yelling. That’s part of the game and is a lot of fun. Remember, people are playing roles.
  • Outcome:
    • Team A: no results. Bulls tried to command-and-control, Seagulls analysed and commented, Chicken gave pens, paper or whatever.
    • Team B: no results. Rats steal pens and paper; Cats said nothing and Foxes takes other team´s pen and designed another picture.
    • Team C: no results. The loudest team at all debating on concepts and previous experiences.
    • Team D: a small result. The Pig was annoyed by the other animals. Bulls tried to patronise the Pig; the Fox changed the picture to something else. And the Cat was sleeping in the corner.
  • Debriefing:
    • The level of energy rose up, and some of the players can link it easily with real-life experience.
    • We try all together to identify some patterns.

Third round: experiment structure

    • Create five different teams with the following functional attributes:
      • One Project Management team
      • One Production Team
      • One Quality Management Team
      • One Delivery Team
      • And one Supervision Team
    • Give them five minutes to organize themselves
    • Give them the same requirements than before and at the same time box of five minutes.
    • Outcome:
      • When you are lucky, something might be produced but not delivered at the end of the five minutes.
      • The best were stocked at Quality Control
    • Debriefing:
      • From this exercise, we learned that the teams at the end of the queue were waiting and started having “cat” behaviour.
      • Quality Control people due to the waiting period played their roles very seriously, and a couple of Seagulls and Bulls emerged from very peaceful people.
      • Production Team was very engaged with mostly pigs. Quality Management Team and Project Management started “bullying” the Production team while drawing creating unnecessary stress.
      • Majority of the participant saw the issue afterwards, and some switched entirely in their daily routine “role” and didn’t get it.
      • The organizational request was on purpose non-specific, allowing the participants to organize themselves to address all of my demand. But no-one did.
    • Lessons to learn:
      • The first two rounds have been controlled by the facilitator (me), allowing the participant to act only.
      • That round was more challenging while giving inexplicit freedom to self-organize.
      • Even if self-organization is handled in private life, it sounds that isn’t obvious at work. 

Fourth round: all together

  • Make one big team.
  • Do not assign any animal cards at all.
  • During 5 minutes, the big team has to draw or make a landscape with five flowers in different colours like before.
  • Debriefing:
    • The requirement has been completely fulfilled but by a tiny amount of people.
    • The most pro-active people have taken over the production of the picture, and the others couldn’t help due to lack of space.
    • Less than twenty per cent of the attendees could perform like pigs. The eighty per cent rest moved in Cat, Seagull behaviour.
  • Lessons learned:
    • The large group are regressing the engagement.
    • Some people were « cats » just because they were not enough extravert.
    • Large groups are amplifying the « bad » behaviours just because of the density, and it leads to wrong interpretation.
    • This big team performed well, but only a tiny part of the teammates had enough space to create « value ».
    • It was a short demonstration of team performance: 30 people do not perform better than 5.
    • Before judging someone in your team, check first if there is enough space for that person to express its talent.

For what is this game suitable?

I use this game for time to time in retrospectives to highlight how the system is behaving.

The “animals” became personas used to express in a non-aggressive manner “feelings”. Example: “ Pierre, I give you the « bull » because two days ago you pushed me to attend the daily meeting and I had an email to answer…”, “Ok, Tina. I’m sorry, I thought you were “cat” at that time”.

Another example came from a crowd in Brussels. The seven teams worked in a very agile way in a year, and they struggled a lot with the infrastructure department located in another city. During a coordination meeting, the agile teams didn’t behave positively and aggressed the head of the infrastructure verbally. While debriefing with the Senior Manager after the meeting, he started to cry in front of me.

After some apologies and ensuring my full support, I gathered the teams together and told them that the whole crowd acted like a “bull” towards the head of the infrastructure. They were shocked. And we used that time to retrospect and find a way to improve our relationship. 

The lesson to learn in that example is that using the animal metaphors helped not to finger point but helped to understand that the crowd´s system has to be extended to infrastructure. And we all have to thing to “pig” that relation.

My lesson to learn is that pigs are performing better with pigs. A large pigpen is a collection of small pigpens interacting as a whole in the same manner.

This exercise will help to understand that “Organization” is based around of self-organised people and it is called here “pigpen”. “Structure” is coded in our cultural DNA, like in the king pyramid metaphor (the story of the farmer).

Even if we all understand what is better for us, the evolution from “Structure” to “Organization” has to be an empirical switch from one level of conscience to the next until the hardcoded old model becomes obsolete.


Published by PierreENeis

Certified Agile Coach & Trainer, Organization Developer & Advisor

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: