Talking about the pull principle means to talk about not having authorities and hierarchies, but talking about responsibility and commitment. The pull principle means to have the freedom and autonomy to be responsible and committed. And vice versa people who like practicing pull and having their freedom don’t like authorities:

“Says [Marissa] Meyer: ‘They [, Larry Page and Sergey Brin,] don’t like authority and they don’t like being told what to do. [...] To Google’s engineers, ‘Question Authority’ is not an anarchist’s bumper sticker, it’s an innovator’s imperative.” — Gary Hamel in The Future of Management

The freedom of the pull principle not only encourages people to do great things, to be the inventors of tomorrow, but it is absolutely necessary to have committed and responsible people:

“Authoritarians cannot impose commitments, only commands.” — Bill Gore, founder of W. L. Gore & Associates

You can’t command commitment and responsibility to people. Commanding “Be responsible!” isn’t gonna work. Actually, turns out commanding at all isn’t gonna work. Bill Gore says so literally:

“At Gore, tasks can’t be assigned, they can only be accepted; but since associates are measured and rewarded on the basis of their contribution to team success, they have an incentive to commit to more rather than less. [...] [Engineer:] ‘If you tell anybody what to do here, they’ll never work for you again.’” — Gary Hamel in The Future of Management

This is the pure and fully fledged pull principle: no commands, just offers; no assignments, just acceptances; not “Do this!”, just “Here’s something you might be interested in!”.

Why isn’t the world, why aren’t all the organizations working with pull rather than push? Isn’t it obvious that pull has huge advantages over push? If it was that simple, I wouldn’t have to write all these words about pull.

“To a large extent, employees need managers for the same reason 13-year-olds need parents: they are incapable of self-regulation. Adolescents, with their hormone-addled brains and limited life experience, lack the discernment to make consistently wise choices. That’s why smart parents set boundaries on adolescent freedoms. Employees, on the other hand, aren’t short of wisdom and experience, but they do lack information and context – since they are so often disconnected from customers, associates, end products, owners, and the big financial picture. Deprived of the ability to exercice control from within, employees must accept control from above. The result: disaffection. It turns out that employees enjoy being treated like 13-year-olds even less than 13-years-olds.” — Gary Hamel in The Future of Management

Don’t treat people like children, treat them like adults! Don’t impose commands, offer choices! Don’t use push systems, use pull systems!

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.” – Antoine de Saint Exupéry

At it-agile, the company I work for and with, we use pull systems. Of course, whenever it comes to software development or project related activities (like organizing a conferece or the like), we rely on Agile methods like XP, Scrum, and Kanban, and therefore on pull systems. But you might be surprised to see pull at it-agile when it comes to corporate sales and hiring.

In the early days we used to have a central dispositioning approach for our sales stuff at it-agile. A customer called us and our CEO answered the call. He figured out what the customer wanted. Afterwards, he searched for the right guy to do the job.

He knew all the employees very good, so most of the time he found the right person to do the job. This comes with a price: he had to know where everyone was at any given time and how long their job would last. Since we are doing all coaching, training, and consulting, or software development jobs, it’s hard to tell how long a job will last. Our CEO was in a constant controlling mode. He had to be.

This controlling job was easy to do as long as we were only a dozen people in the beginning, but got harder as our organization grew. Over time, we got an officer with procuration and a second CEO, so more manpower to do sales stuff. With more people doing sales stuff, the coordination of sales became more difficult. The decisions became worse, sometimes customers complained.

The biggest pain we had was, that nobody at it-agile really wanted to do sales all the time. We all wanted to do Agile coaching or training, to consult or develop. The more we grew, the bigger the necessity to have corporate sales become a full time job for a few people.

Then we changed to pull.

These days, everyone at it-agile is encouraged to do sales. We coordinate our work with a Kanban board. Whenever a customer calls us, Moneypenny – our organization team – creates a ticket on our board and puts it into the first column called “request”. We then tell the customer, someone will contact him within the next week. Then we wait for someone of us to pull the ticket.

Everyone is allowed to pull this ticket. If nobody pulls it, one of the Moneypennys calls the customer and explains that we’re all booked out at the moment and that he might try again in a few months. If nobody pulls, we’re booked out. It’s that simple.

If someone pulls the ticket, he’s the new ticket owner, the guy with the sales hat on. The ticket owner moves the ticket into the next column “clarify request” and calls the customer. He then clarifies what the customer wants and how we can help him. He documents his findings in the ticket and moves it into the column “staff request: searching”. He tells the customer that he’s now looking for someone in it-agile to do the job. Even though it’s a bit untrue, because he’s not looking: he wants to be found. He’s actually waiting for someone to pull the job.

If nobody pulls the job, the ticket owner calls the customer and explains that we don’t have the capability or capacity to do the job. Furthermore, he might refer him to someone outside of it-agile who might be able to help the customer.

On the other hand, if someone pulls the job, the ticket owner pulls the ticket into the next column “staff request: found”. He calls the customer to tell him that he found someone to do the job. Then he makes the customer an offer with a price tag attached.

This pull system has several advantages for us:

• It’s a self-regulatory system: when we’re “land submerged!”, we don’t do sales stuff and have to apologize to our customers for not being able to take on their job; when we don’t have enough jobs, then we have time for sales stuff. That’s not a black-or-white thing but a greyscale.
• There’s no single-point-of-failure (aka CEO): lots of employees at it-agile can do corporate sales these days, and it’s an open and transparent system so everyone is able and encouraged to join.
• Experts decide, rather than management. Our people are the best ones to say whether they can do the next job – and then they just pull.
• Push doesn’t scale for us, but pull does scale for us. If we’d still push, we’d have a huge part of our organisation controlling everyones job. With the pull system, I see scaling at least for the next dozens of new employees at it-agile.
• it-agile’s employees are self-responsible for getting a job, not through some managers. If you’re an it-agile employee and don’t have a look onto our board on a regular basis, chances are pretty low that you’ll get a job.

We made it from push to pull, and it wasn’t easy. We had to overcome several trust issues, like: Why is nobody else pulling this ticket? Is it because they can’t do the job right or are they just lazy and think someone else will do it for them?

To overcome mistrust, we talked. Whenever we wanted to know why a ticket wasn’t pulled, we asked our employees why they hadn’t pulled. Sometimes we learned that there were good reasons we had not considered (like all the people capable of doing the job were working with other customers at the time), sometimes people were reminded of the capability or capacity they didn’t consider (like someone who thought he couldn’t do a training when others thought he was ready to do it). Over time, we learned to trust the pull principle, and finally ourselves.

Great things happen when you pull, things no one could have imagined. For example, normally our consultants do the sales stuff and both developers and consultants pull job tickets in the “staff requested” column. Once one of four developers had a developer job at one of our customers. That job of hers ended at a time with no developer tickets on the board for a longer time. So she had nothing to do. During her search for new work, she thought: “Hey, I could try to pull a sales ticket.” And so she did and succeeded in doing so.

Who’d've thought? If we still had a push system, I doubt that we would have pushed a sales ticket to a jobless developer. Since we have a pull system, magical things like this happen.

We also use pull to hire people. Whenever someone sends us her application papers, she becomes a ticket on our hiring Kanban board. The ticket gets pulled from one of our senior consultants, who establishes the first contact with the applicant and stays in contact with her until we either say “Good bye!” or “Hello, new member of our family!”.

The senior consultant then sends out a pull request as an email to the rest of the company. He explains who’s applying for a job and requests three other participants for the job interview. People at it-agile will then have a look at the applicant’s papers, and if the applicant looks promising, people will pull a place for the job interview. If the applicant does not look promising, nobody pulls a place for the job interview, and the senior consultant will say “Good bye!” to the applicant eventually.

Again, like looking for their work (aka new jobs) when working at our customers, our own employees are responsible for hiring new people, not some managers.

“With great power comes great responsibility.” — Peter Parker aka Spiderman, super hero character by Stan Lee

Furthermore, we use pull on several smaller occasions:

• Peergroup members and mentors are pulled.
• Conference owners (people responsible for everything we do at a given conference) are pulled.
• Moderators for internal retrospectives or open spaces are pulled.
• Coworkers for a new product, e.g. a new training, are pulled.

Also, meetings are optional:

“Meetings at it-agile are optional. Every employee decides for himself if he attends. […] As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)” — Stefan Roock in it-agile: State of Play

In all these cases, no one at it-agile has the authority or higher place in a hierarchy to command these jobs. We just trust in the responsibility and the commitment of our people. So far, it worked well.

When I write about people pulling work, it’s only half the picture without the customer. He’s the reason people are doing the work in the first place. The customer benefits very much from being part of a pull system.

I mentioned the supermarket and its pull system earlier. Here product costs decreased dramatically due to reduced labour costs, which naturally pleases the customers. And pull has more benefits for customers, when the customer is part of the contractor’s pull system.

Steve Denning, a thought leader in management, sees the work started by the need of a customer and finished when the customer is satisfied, or, as Denning calls it, when the customer is delighted. He named this client-driven iterations, where the contractor iteratively checks if the work has been done on a level high enough for the customer’s satisfaction.

Denning gives an impressive example of client-driven iterations in his case study of Quadrant Homes, a home builder company in the USA. In the 1990s, they built homes like most home builders did:

“First, the company would buy a tract of land, assuming high demand and hoping for appreciation. Then its architects would design the home from the builder’s viewpoint to incorporate the latest housing trends, meet buyer profiles, and match the competition. Next, builders would construct the home in three to four month, adding options that they thought would be appropriate. It was often only toward the end of the construction period that there would actually a real buyer. When the buyer was in hand, Quadrant would conduct a single final walk-through aimed at fixing defects and problems to be covered under the warranty. Finally, the deal would be completed.” — Steve Denning in Radical Management

This is a push system. Homes got built without having a customer hoping that the customer will show up eventually. It’s the balance weight problem again: In this complex system the appearance of a customer is unpredictable.

This approach is also not very customer friendly. When the home is almost finished, the customer can’t make essential changes to his new home; he has to accept what the home builder thought the home owner might like. What are the odds this anticipation was correct? It might work for mainstream homes, but not for indiviuals looking for their made to measure house.

Quadrant Homes wanted to do better than that. They switched from push to pull:

“[Quadrant Homes started] from what the buyer wanted. Instead of building the home and then trying to sell it, Quadrant sells the home before building it and involves the buyer iteratively in the design and building of the house. The customer can choose from multiple footprints and floor plans. Standardized customization offers the flexibility buyers want while reducing complexity for builders.
The buyer, not the builder, chooses the options so they get exactly what they want.” – Steve Denning in Radical Management

Like the people doing the work choose their work, Quadrant’s future house owners choose their own house. Just like the work fits better to workers in a pull system as in a push system, the house fits better to the new house owners.

The pull principle changed the way we work. In the manufacturing process, pull prevents huge inventories and decreases costs, among other useful effects. But the principle does not stop there.

Pull was adopted by software development in the 1990s. Before, traditional software development dealt with its process like Toyoto in the pre Ohno era. There were several stages in a software development process, e.g. analyzing requirements, designing, implementing code, testing, and deployment. People were assigned to the different stages, e.g. 2 analysts were analyzing, 3 developers were implementing code, etc. Usually they ended up with a huge inventory similar to the aforementioned balance weight makers for each of the stages.

In the last 15 years, Agile Software Development revolutionized the way developers work similar to the way Toyota did within the automobile world. e.g. pull within Extreme Programming (XP):

“XP uses a ‘pull’ model … Stories are specified in detail immediately before they are implemented. The tests are pulled from the specifications. The programming interface is designed to match the needs of the test. The code is written to match the tests and the interface. The design is refined to match the needs of the code as written. This leads to a decision about which story to specify next. In the meantime, the rest of the stories remain on the wall until chosen for implementation.” — Kent Beck in Extreme Programming Explained 2nd Edition

Like the Toyota Production System, XP wants the later process to indicate its demand to the earlier process, so that the earlier process can exactly deliver what the later process needs. In a pull system, you “read” a chain of processes not from the beginning to the end, but the other way round. You put the cart before the horse. Beginning at the end, you ask: What is it that the later process needs that the earlier process has to deliver? After you identify this need, you’d be able to produce exactly what is needed.

But pull is more. So far, we saw that pull regulates the satisfaction of needs in an economically better way than push systems. But pull also changed how the work which has to be done finds its way to the people doing it. In a push environment, tasks get assigned to workers, whereas in a pull environment, workers sign up for tasks.

Toyota’s balance weight problem, as a complex system, showed the unpredictability of the consumption of balance weights during the wheel balancing process. Unpredictability is an attribute of complex systems. Similarly in software development, there’s a certain kind of unpredictability when it comes to accomplishing tasks, like developing a certain feature for a software.

You call it a push system when the manager decides who’s going to do the next job. Work gets assigned to workers, it gets pushed to them. Push has several disadvantages:

• The manager has to decide, who is the best person to do the job for a given task. But he often lacks the knowledge of whose skills fit the best to do a given job.
• The manager has to distribute the work load appropriately, so that every developer is neither overloaded nor underemployed, and all the tasks for the feature are finished at about the same time. But often he does not know the capability of the developers and his assumptions are based only on estimates (which, by the way, are always inadequate in a complex system).
• The manager is the only one who assigns work to the developers. But that makes him a single point of failure.
• The manager has to control when persons finish their current task all the time, so that he can push another task. But controlling consumes a lot of time (i.e. costs a lot of money), and it demotivates people due to decreased autonomy.
• If the manager does not control the whole time, then he could assign batches of tasks to people. But batches of tasks require inventories for every person (i.e. costs a lot of money).

Like XP, Scrum uses a pull system, and it makes clear who decides on what to work on next:

“Development Teams are structured and empowered by the organization to organize and manage their own work. […] They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality …” — Ken Schwaber and Jeff Sutherland in Scrum Guide (v. 10/2011)

No one tells the people how to do their work. Period. Amen. Do I hear a hallelujah?

In daily work, this means: The list of open jobs/taks, in Scrum called the product backlog, serves for the team as the source to pull the next few items from for the upcoming period of working time, in Scrum called Sprint:

“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — Ken Schwaber and Jeff Sutherland in Scrum Guide (v. 10/2011)

Let’s see what this means regarding the push system problems I mentioned before:

• The people doing the work decide who is the best of them to implement the given task. They decide, because they are the closest to the work and have most of the relevant information available to make the decision who’s best for the job.
• The people doing the work distribute the work load appropriately. If they pull the tasks, nobody is forced to do more than she can, nor get her potential underestimated.
• The people doing the work are pulling work collaboratively. There is no single point of failure anymore.
• The people doing the work know when they finished some tasks, and can then automatically pull more work. They control themselves.
• The people doing the work don’t need batches of work. They simply pull one work item at a time.

Of course, mistakes happen, even if no (!) manager is involved. But there’s a remarkable difference between a manager or a worker making a mistake: the worker can’t blame the manager. The worker can only blame himself if he makes a wrong decision. No one else but the worker is responsible for his own decisions.

And even kanban has arrived in the software development world, unfortunately with the same name, but with a different approach. To distinguish between Ohno’s invention at Toyota and the method used in software development, it’s called Kanban (capital k) or software kanban.

Software kanban has different components, like visualizing the work flow, limiting the work in progress, or continuously improving. One of the most essential parts of Kanban is its pull system:

“Scrum and Kanban are both pull scheduling systems…. This means that the team chooses when and how much work to commit to, they “pull” work when they are ready, rather than having it “pushed” in from the outside. Just like a printer pulls in the next page only when it is ready to print on it (although there is a small & limited batch of paper that it can pull from).” — Henrik Kniberg and Matthias Skarin in Kanban and Scrum – Making the Most of Both

Again, the persons doing the work are in the centre of pull systems. XP, Scrum, and Kanban are all part of the method family called Agile Software Development. And so it’s no surprise that the human itself is part of Agile’s DNA:

“Individuals and interactions over processes and tools” — Agile Manifesto

Two of this value’s creators describe the idea behind it like this:

“Agile development focuses on the talents and skills of individuals and molds process to specific people and teams, not the other way around.” — Jim Highsmith and Alistair Cockburn, Agile development: the people factor

Work assigned to people is a push process with people having to follow the work. People signing up for work is a pull process with work following the people. In a push system, decisions are made by authority in titles and hierarchies. In a pull system, decisions are made by the responsibility and commitment of experts doing the work.

When Clarence Saunders built the very first supermarket, he did not know that he invented a principle that changed the world. It was 1916, when he was annoyed of the fact, that grocery stores – think of small corner shops and the like – only gave one person at a time the chance to order their products. An assistant would then go into the storage room and fetch the goods. This was a very slow way of shopping, and it was also very labour-intensive because of the assistant’s payroll costs.

Saunders thought there must be a better way. In his stores he called supermarkets, several customers could select products from the shelves at the same time. Instead of a grocery assistant there was a cashier where customers could pay their selected products. That approach was much faster for the customer. Also, product prizes decreased, because there was much less need of labour to serve the same amount of customers. Needless to say, supermarkets were and still are a huge financial success.

Almost 40 years later, a young Japanese manager called Taichi Ohno was very impressed by the concept of a supermarket. He was an executive at the Toyota Motor Corporation, a small automobile production company in Japan these days. The principle behind supermarkets solved a problem for him, which was equally simple and difficult: the balance weight problem.

A modern-day balance weight

You might know balance weights from your own car. After your car gets new tires fit, the mechanic has to balance the wheel afterwards. Without balanced wheels, the faster you’d drive the more the wheels would clatter and eventually would brake your wheel suspension. To prevent this, the mechanic attaches as many little pieces of lead or zinc to the wheel, i.e. the balance weights, as it takes to have the wheel balanced, only a few grams in total.

Now the problem is, you can’t know in advance how many balance weights you’ll need to balance a wheel. At Toyota, they used 5 different kinds of weights, and they were never able to predict, if they would use, say, more 1 gram weights than 2 gram weights on a given day. They were confronted with a complex system, where you can’t predict the future and where only in retrospect pattern emerges and eventually makes sense. Complex systems are unpredictable.

In the early 1950s, Toyota built up to 40,000 cars per year, so they had to use quite a few balancing weights. But still, no biggy, right? Worst case would be that only one balancing weight would be used (very unlikely, but just to make the point here). In this case, the mechanics would have needed the maximum amount of balancing weights in every category, because he was never able to predict today’s kind of balancing weight. So, to prevent the worst case, all Toyota had to do was to produce a large amount of balancing weights, so that the mechanics would never run out of them.

Of course, this comes with a huge downside: For large amounts of balancing weights you need a large inventory, which produces costs not only for building and maintaining the inventory, but also for the costs of having valuable raw material lying around, useless at the moment: money tied up in stocks.

When Ohno saw the supermarket, something clicked in his mind:

“A supermarket is where a customer can get (1) what is needed, (2) at the time needed, (3) in the amount needed. […] In principle, however, the supermarket is a place where we buy according to need. […] From the supermarket we got the idea of viewing the earlier process in a production line as a kind of store. The later process (customer) goes to the earlier process (supermarket) to acquire the required parts (commodities) at the time and in the quantity needed. The earlier process immediately produces the quantity just taken (restocking the shelves).” — Taichi Ohno in Toyota Production System

This was revolutionary. From now on, the mechanic who balances wheels had 10 boxes where he kept the 5 balancing weights: 2 boxes full of 1 gram weights, 2 boxes full of 2 gram weights, and so on. Whenever he used up all weights of one of the boxes, he carried that box to the earlier process, in this case the place where they made the balancing weights. Attached to the box was a card, indicating the kind of balancing weights and the amount needed for the box.

The arrival of this box was the trigger for the balancing weight maker to produce just enough weights to fill up this box. While he was working on the balancing weights, the mechanic could use the second box to continue his work. When the balancing weight maker filled up the first box, he delivered it to the mechanic, and the cycle closed.

Ohno called this system kanban (lowercase k), after the Japanese name for “signal card”, like the card attached to the boxes.

“Kanban was introduced to manage the balance weight problem, one of the most difficult processes in automobile production. […] As a result, inventories of the five weights were kept constant and, eventually, reduced drastically.” – Taichi Ohno in Toyota Production System

This was the beginning of the pull principle at Toyota – and it changed everything. In fact, it was worked so well for the balance weight problem, that Ohno installed it almost everwhere in his company’s automobile production. For Ohno, the Toyota Production System and kanban were the same, and both were a pull system.

“Let’s look at this production flow in reverse: a later process goes to an earlier process to pick up only the right part in the quantity needed at the exact time needed. In this case, wouldn’t it be logical for the earlier process to make only the number of parts withdrawn? As far as communication between the many processes is concerned, wouldn’t it be sufficient to clearly indicate what and how many are needed?
We will call this means of indication kanban … and circulate it between each of the processes to control the amount of production – that is, the amount needed. This was the beginning of the idea.” – Taichi Ohno in Toyota Production System

The system was called a pull system, because the earlier process didn’t push its goods to the later process anymore, but the later process pulled the goods from the earlier process only if there was a need for it.

Pull systems are actually markets, compared to push systems with their hierarchies. The huge benefit of pull systems is their strength when it comes to reallocation. Push systems just suck at that:

“Hierarchies are very good at applying resources – laying out plans, sequencing activities, and meeting deadlines – but they’re lousy at allocating resources – or, more specifically, at reallocating resources from old strategies to new strategies.” — Gary Hamel in The Future of Management

An impressive example of the pull system can be seen in every city. The bigger the city, the more impressive the example of pull:

“Markets are capable of solving highly complex allocational problems. At any point in time, New York City, a metropolis of more than 8 million inhabitants, has a scant three-day supply of food. In a sense, the city is always close to famine.” — Gary Hamel in The Future of Management

But NYC never had a famine. There’s no mayor with the authority to direct the supplies of food to every citizen. The market takes care of that, without central control.

For Toyota, adopting the pull principle from supermarkets became quite successful. Today, Toyota is the biggest car manufacturer in the world, with a production capacity of almost 9 million cars per year.

At the Play4Agile 2012 conference in Rückersbach, Germany, in February, I especially enjoyed two sessions. Both sessions were about short games which can be played in trainings and workshops with groups, e.g. to warm up or to make a point in demonstrating team dynamics like collaboration or the like.

Below I describe 8 games from these sessions; there were more, but these were my favorites – or I simply couldn’t remember the others.

For each game I list

• the number of participants
• an estimate for the duration
• the learning objectives and purpose
• the material needed
• a short description with instructions for the game’s facilitator
• the possible progression for better understanding the game’s nature

For the learning objectives and purpose, I’ll additionally recommend a short debriefing after the games, where you’ll find even more valuable outcomes.

Spoiler alert: the following instructions might contain key information about learning outcomes and the order of events. While this information is vital for the facilitators, they might spoil the fun and learning if you want to play these games yourself.

Chair Game

number of participants: >= 9 (the more the better)
duration: 15 min
learning objectives/purpose: Success only through collaboration; working together across teams; finding a higher common goal; silent communication
material: >= 20 chairs
short description: Have the participants form 3 groups. Tell the participants not to talk anymore. Give each group one of the following instructions on a card (group should keep it a secret for the other groups):

• arrange all the chairs in the room in a big circle
• put all the chairs in the room upside down
• group all the chairs in the room to pairs

Make sure everyone in the groups reads the instructions. Tell the groups to execute their instructions. If at some point every group is stuck, tell them that there is a solution that every group will be able to successfully execute their instructions at the same time. Debrief when there’s no movement in the room anymore.
possible progression: Groups will first fight each other, later hopefully see that they can all reach their goals together. The end state of the chairs is a big circle with pairs of chairs turned upside down.

Count to 33

number of participants: >= 3 (not more than 20)
duration: 5 min
learning objectives/purpose: simple things can be hard to achieve; listen to others
material: -
short description: Have the participants stand up and form a circle. Let the participants shout out numbers in the sequence from 1 up to 33 clockwise. Give the instruction:

“Whenever your number is dividable by 3 or ends with a 3 you have to clap your hands together instead of shouting out the number.”

Whenever a participant makes a mistake, the following participant has to start all over again with 1. Debrief when the group reaches the number 33.
possible progression: Participants will end up with this sequence (numbers are shouted): 1 2 clap 4 5 clap 7 8 clap 10 11 clap clap 14 clap 16 17 clap 19 20 clap 22 clap clap 25 26 clap 28 29 clap 31 32 clap
miscellaneous: Marcel van Hove pointed out:

“I think it is nicer when the last number is spoken out loud. So maybe stop at 32 or if you play it with nerds try to get to 42! And you can control the duration of the game by setting the goal (number).”

Escape the Room

number of participants: >= 3 (the more the better)
duration: 10 min
learning objectives/purpose: collaboration; silent communication
material: 1 chair per person
short description: All participants sit on a chair randomly distribute in a (large) room. Let participants lift their feets from the ground. Announce the following instructions:

“The goal of the following game is to escape the room. From now on, nobody is allowed to touch the floor or speak anymore.”

possible progression: Some participants hop with their chair to the exit. Others, often the ones furthest away from the exit, will cooperate by forming a bridge with their chairs. Some will also help others, e.g. by ‘islands’ (i.e. participants on chairs not connected to the bridge help by extending the bridge in their direction).

Fruitsalad

number of participants: >= 10 (the more the better)
duration: 10 min
learning objectives/purpose: warm-up; deals with post-meal coma
material: 1 chair per person minus one 1 chair
short description: Have the participants build a circle of chairs with one chair per participant (except for yourself). Assign a fruit out of three or four possible fruits to each participant and yourself, like

“Strawberry, banana, apple, mango, strawberry, banana, apple, mango, strawberry, banana – and I’m an apple.”

Explain the rules:

“Whenever the person in the middle calls out a fruit, the participants that fruit was assigned to have to get up and quickly find a new chair to sit on. When they get up, the person in the middle also tries to find a chair. Given that there is one chair less than the number of participants, one person will end up without a chair, and the game starts over. Instead of a fruit the person in the middle can shout ‘fruitsalad’, which means that everybody has to find another chair. It is not allowed to sit on any of your neighbour’s chairs.”

possible progression: Big fun in a fast paced game, where you have to react quickly.

Counting In The Dark

number of participants: >= 5 (not more than 20)
duration: 15 min
learning objectives/purpose: collaboration; silent communication
material: -
short description: Have the participants stand up and form a circle. Let them close their eyes. Tell them to count to 10 aloud. Whenever two people shout out any two numbers together, let the group start over.
possible progression: People will start calling out numbers with a high possibility for calling them out together, so they have to start over and over again. Since their eyes are closed, they can’t use sign language. They have to collaborate to find a appropriate strategy like letting one person alone do the counting, or by using a counting token which will be passed from one to the other.

Tornado Tim

number of participants: >= 5 (the more the better)
duration: 10-20 min
learning objectives/purpose: getting to know each other
material: -
short description: Have the participants stand up and form a circle. Start by saying and doing three things in this order:

• an adjective beginning with the same letter as your forename
• your forename
• a gesture describing the adjective you mentioned before

Example:

“Hi, I’m burned Bernd. (waving his hand like he touched a hot plate).”

In the next turn the last player’s right neighbour has to repeat what all his predecessors said and did (in the same order), followed by his own adjective, name and gesture. Game ends with the last person.
possible progression: After the game, most of the participants will be able to remember most of the other participants’ names, like burned Bernd, cycling Carsten, rocking Robert, naughty Nadine, … Some participants might even join the current speaker by forming the words with their mouth and do the gestures together with him, and often they will help someone who gets stuck.

Torpedo

number of participants: >= 6 (not more than 20)
duration: 15 min
learning objectives/purpose: collaboration; warm-up; deals with post-meal coma
material: -
short description: Separate the participants in two teams. Let each team form a queue, where each participant should place their hands on the shoulders of the person in front of him. Name that formation a ship. Name the last person of the ship the captain and the first person of the ship the torpedo. Let the torpedos stretch out their arms (safety reasons!).
Let the ships formate in the room, so that both torpedos face the same wall and the ships are at least 2 meters apart. Let everyone except the captains close their eyes.
Explain to them, that the captains steer the ship. They do so by tapping on the left shoulder of the person in front of them to steer the ship to the left, or by tapping on the right shoulder of the person in front of them to steer the ship to the right. Each tap received by one of the persons on the ship should be passed to the next person, right up to the torpedo.
To fire a torpedo, the captain taps both shoulders. When a torpedo is fired, the person playing the torpedo detaches from the ship by walking straight away from it. When the torpedo hits the other ship, the hit player will be dragged from his ship to the torpedo’s ship, where both the torpedo and the other player go to the end of the ship and one of them becomes the new captain. The first player on the ship becomes the new torpedo (don’t forget the streched out armes!).
Game ends when there’s only one ship left.
(Safety warning: With a bigger group, you might want to recruit up to four persons to prevent the players to run into furniture or walls. Place them in the middle of each wall of the room. Also keep an eye on the torpedo, so that they don’t forget to stretch out their arms all the time and walk slowly when fired.)
possible progression: lively movement in the room; I never saw the end of the game, since the smaller the ships, the easier to steer and to hit something with the torpedo, and the bigger the ship, the easier it is to get hit by a torpedo.

Body Count

number of participants: >= 2
duration: 5 min
learning objectives/purpose: coordination; warm-up for creative work; simple things can be hard to achieve; little changes have huge effects
material: -
short description: Have the participants buddy up. Let them alternating, repeatedly, and aloud count to 3. Example: Person one counts “1″, Person two counts “2″, Person one counts “3″, Person two counts “1″, etc.
After a while (15-30 sec), stop the game and tell the participants to count to 3 again, but this time, whenever one player used to count “1″, she should clap their hands.
After a while, replace counting “2″ with jumping. After another while, replace counting “3″ with a short duck dance (wiggling your bum alone is sufficient).
possible progression: It’s actually hard for people to follow these simple rules. Even the mere alternating counting is hard to do, since the players have to concentrate hard who has to say what. Replacing numbers with gestures is even harder to concentrate on. It’s difficult to do something cognitive and something physical at the same time. It connects different parts of the brain. This will really wake you up.

Special thanks to

• Sam Laing for coming up with the idea and hosting the first session, and for letting me host the second session
• Marcel van Hove and Meike Mertsch for proofreading the game descriptions
• everyone playing with us in these sessions, everyone making this conference such a great event, and all the organizers who created an amazing environment to play within

If you played one of the games according to these instructions, please leave a comment regarding how it turned out for you. Thanks!

At the OOP Conference 2012 in Munich I presented another version of my session “How Agile and Lean Changed My Organization” (in German, called “Wie Agil und Lean meine Organisation veränderte“). This was actually the outcome of the 2nd iteration of a previous version.

Here are the slides (in German):

I got lots of feedback regarding my previous version, which led to several changes:

I used slides, instead of tickets. In the last version, I tried to figure out what content would work out. With the feedback I received, I refined my selection of content, and finally decided to boost the message by supporting it with images on slides.

I said more about it-agile, less about other companies. In the last version, I introduced Agile Management Innovations like pull principle, slack, open space, etc. with examples in companies like Google, Gore, Semco, etc. The feedback I got was: “I thought you were talking about your company, your experiences?” Guilty as charged. So I told more about it-agile and how they used Agile Management Innovations.

I named the techniques Agile Management Innovations, instead of just management innovations. It seems to be a more appropriate name, since those techniques are management innovations derived from Agile contexts. (Well, actually they are derived from Agile and Lean contexts, but Agile and Lean Management Innovations is just too long.) I’ll describe the name and what it stands for in detail in a dedicated blog post in the near future.

I refined the list of Agile Management Innovations I talked about. Those were

• pull principle
• mentorship
• peergroups
• employees as shareholders
• teams
• selforganization
• konsent
• open space
• slack

I hope to write about each of them more in this blog over time, like I did with slack.

I described my personal connection to the topic. Hence there’s slide 3 where you can see me as a German navy maat (a military rank, equivalent to a petty officer in most other navies) :)

Here are the books I recommended in this session:

Drive: The Surprising Truth About What Motivates Us
Read on the reasons, why Semco’s management innovations are actually working.

The Future of Management
Find out why management innovations kick ass and are the future. With case studies of Whole Foods, Gore, and Google.

Related posts:

1. Session “How Agile and Lean Changed My Organization” at Lean Kanban Central Europe

So far, so yay! Employees enjoy slack, organizations enjoy innovations resulting from employee’s slack, and teams are formed to drive innovative ideas. But what happens if an idea originating in slack is successful? With all those innovations some ideas have to be successful eventually, right?

Beyond Slack Time

Different companies, different strategies to cope with slack success: Atlassian had 16 out of 48 slack projects which where incorporated into products, and there seems to be no special strategy how they would execute this transition. Google, on the other hand, introduced a so called “Founders Award” with up to $10 million reward for innovative products.

“The Founders Award are based on the premise that an employee shouldn’t have to join a start-up to get rich.” — Gary Hamel in Future of Management

Gore with its dabble time (their so called slack) and its 1000+ projects introduced a separate process to deal with hopeful innovations:

“Once a project moves beyond the dabble stage, there is a cross-functional review process that periodically puts the development team through an exercise called: “Real, Win, Worth.” — Gary Hamel in Future of Management

What does it mean (and how long does each stage in this process last)?

• Real: Does it solve a customer’s problem? (Check now!)
• Win: Can we make money with it? (Analyse the new business!)
• Worth: Will we benefit from it in a long-term? (Observe over a long period of time!)

At it-agile, whenever someone thinks she has a good idea, she tries to convince a majority of our employees that we should invest in that idea. It’s as simple as that – and much harder than it sounds.

Future of Slack – Google’s and Semco’s 100% slack

More and more companies are jumping on the slack bandwagon. But what’s the future of slack? The idea is simple: If 20% is a good thing, than why not increase the slack time?

Rumour has it Google wants to introduce full-time slack for their elite employees:

“… Google is contemplating launching an in-house incubator, where some of the company’s smartest smarty pants will get to work on their own inspirations full-time.” — E.B. Boyd in Why Google’s “20 Percent Time” Isn’t Stemming Its Brain Drain

Phew, think about that job for a minute. Nobody tells you, what you have to do, all the time. You’re free to experiment with whatever you want. Failures are being welcomed as are learnings. You are able to work with the brightest brains Google has to offer. But of course, the downside could be lot of pressure to invent the next wheel.

Actually, this idea is not new at all. Semco experimented with a small group of people on the subject of full-time slack, called Nucleus of Technology Innovation (NTI):

“Their idea was to take a small group [of 3 people] raised in Semco’s culture and familiar with its people and its products … and set them free. Removed from day-to-day activities, they would no longer worry about production problems, billing, inventory, machines that didn’t work or subordinates who wanted a raise. They would have all their time free to think. They believe that, thus liberated, they would invent new products, refine old ones, devise market strategies, unearth cost reductions and product efficiencies, even dream up new lines of businesses.” — Ricardo Semler in Maverick

Semco established 5 rules for the NTI:

1. No boss for them.
2. No right to hire anyone.
3. Freedom to set their own schedules, job descriptions, own activities.
4. Report twice a year to the partners. Partners decide about their membership in the NTI for the next 6 months.
5. Salary was lower than before (as senior managers), but they got a share of whatever they invented (even from saved costs or selled consultancy), and they decided about their share.

NTI was very succesful within Semco, e.g. they saved costs due to process changes, or they invented new products.

Lookout

So, maybe that’s it then, the future of slack: more slack. But, for the vast majority of companies out there, the future of slack will probably be in having some slack at all.

Do you have more stories to share about slack? Would love to read them! Please consider leaving a comment.

Related posts:

1. [Slack to the Rescue] Harder Than It Sounds
2. [Slack to the Rescue] Forever in Down Under
3. [Slack to the Rescue] What You Want to Do

It’s actually pretty hard to get real data on slack. Most data you can find is diffuse and contains lots of rumours. It seems that especially on Google’s 20 % there are more myths than facts available. 3M and Gore are mostly legend, nothing concrete, almost no details. Atlassian to the rescue!

Atlassian’s 20 % Slack Experiment

Atlassian is an online product development company, known for products like their online collaboration tool Confluence or their online project tracking tool JIRA. They were founded in 2002 in Sydney, Australia, and by now they have almost 300 employees, 20,000 customers in 134 countries, and took a $60 million founding in 2010. It’s a highly successful company.

Atlassian did a slack experiment in 2008 – and blogged about it. With 70 employees and 10,000 customers those days, they feared that innovations would slow down, so they looked at Google and decided to give it a try.

The experiment should last 6 months. They calculated the costs to be $1 million (USD). And they assumed a huge benefit for themselves and their customers.

Given their preconditions, they were right to assume to win. They already had a culture of innovation established with their FedEx days, 24-hour-build-and-ship-it product creations. And, maybe Atlassian’s most valuable property, they had trust and faith in their employees:

“We have an _absolutely awesome_ engineering staff. I can’t wait to see what they come up with.” — Mike Cannon-Brookes, Atlassian’s Co-founder and CEO, in Atlassian’s 20% Time Experiment

Another highlight in their slack experiment was that they wouldn’t consider the experiment failed when their products developed during slack time failed. They added the following to their slack FAQ:

“A failed 20% project is not necessarily a bad thing. 20% is an exercise in innovation and risk, and when you take risks you invite failure. You could work on some cool technology and discover that it doesn’t really produce the result you were after. You could work on a product feature and find that it doesn’t fit in with the direction the product is going. You could just realise, as you develop your project, that it isn’t such a good idea after all.

The best advice is to fail fast. Don’t get stuck in a death-spiral of unproductiveness, don’t spend your days trying to bang a round peg into a square hole. Don’t be afraid to draw a big red line through your project, and move on to something that could bear fruit.
(Warning: mixing this many metaphors can be dangerous.)” — Charles Miller, Atlassian employee, in 20% time nuts and bolts

Atlassian’s Experiment Results

One year after they started their 6-months-experiment they published the results (the original blog post seems to be lost; this is a copy I discovered). The experiment lasted 12 months. These are the numbers:

• number of projects worked on during slack time: 48
• number of people who used slack time: 34
• number of days spent on slack: 248

The last number was the most surprising one. Although Atlassian supposed that not all developers counted all days spent on slack, the official 248 days were only 1.1% slack time in total!

So they worried about the $1 million they spent on slack, when it actually was only about $60,000. They emphasized, that the total number could be 2 or even 3 times higher, but that would be still only a fraction of the estimated million.

More numbers:

• Shortest project in days: 1
• Longest project in days: 18
• Number of projects, which were finished in normal development time and incorporated into products: 16
• Longest project in days, which was finished in normal development time and incorporated into products: 5 (!)

Another interesting outcome of that experiment was, that it was actually hard for developers to schedule slack. Atlassian has frequent releases of their products, which interfered with planned slack time. Also, developers didn’t want to have fun slacking around while others had to do hard work on the products.

Slack Forever at Atlassian

A month after their evaluation blogpost, Atlassian announced that they’ll continue with their slack time initiative, not as an experiment, but as part of what they do and what they are. This is the vision and the rules for their slack:

“The Goal of 20% Time

To encourage innovation in products, development techniques and the Atlassian development ecosystem.

• Not every 20% Time project has to lead to shipped features
• Internal innovation is encouraged – new processes, techniques, libraries
• Contribution to the larger ecosystem counts too, where it assists Atlassian
• Failing is OK”

– John Rotenstein, Atlassian employee, in Atlassian’s 20% Time now out of Beta

Slack Groups: No Budget, No Authority, Full Passion

Created innovations during slack time would be doomed to spend their existence in the shadows of the already money-making top-dog products, if the organization didn’t take care of their delicate flowers.

During slack time employees are already encouraged to form groups for their projects. One reason is to separate the wheat from the chaff:

“Gore is a marketplace for ideas [...] As one engineer put it: ‘If you can’t find enough people to work on your project, maybe it’s not a good idea.’” — Gary Hamel in Future of Management

Another reason for slack projects done by groups is that only good ideas will gain a movement. Google’s employees group themselves together to grouplets to work on products on their own initiative in their 20 % time. Grouplets don’t have a budget and don’t have decision-making authority, but grouplets can influence the rest of the company better as an individual could.

Atlassian has a peer rule for their slack:

“If you want to spend more than 40 hours on one project (one developer-week), you must find three supporters within the company who agree that the project is both a good idea, and viable. After 160 hours, the project also needs to be signed off by Mike or Scott [, founders of Atlassian].” — Charles Miller, Atlassian employee, in 20% time nuts and bolts 

Related posts:

1. [Slack to the Rescue] Harder Than It Sounds
2. [Slack to the Rescue] What You Want to Do
3. [Slack to the Rescue] Culture of Autonomy

I don’t know how slack was introduced at Gore, 3M or Google. We at it-agile introduced slack very carefully. We had big discussions about the concept. Though it was very attractive, we feared the costs. Being a company of programmers and consultants, each day a programmer couldn’t program and a consultant couldn’t consult was lost money. Sure, slack should pay off in the long term, but doubts remained.

How to Introduce Slack? – it-agile’s 13.5 %

We started the discussions in 2007, inspired by the stories of Google’s legendary 20 % time. At the end of 2008 we started an experiment, which was a mix between sprint and slack called slant. In one week we wanted to program an entire new product. In preparation we asked all our employees for product ideas and participation. We chose one idea out of a dozen and started with 5 employees, nearly a quarter of our company those days. It was an experiment, far away from Google’s 20 %, but closer to where we were before the experiment.

We failed to deliver the product at the end of the slant. We succeeded in having an ongoing discussion about slack. The discussion continued in 2009 and went on in 2010, where we finally created another experiment: in 2011 every employee should have 20 days free to spent on anything she wants to do. Before that experiment, every it-agile employee already had 10 days for further education, and those 10 days were then included in the slack time. Still far away from Google’s 20 %, but closer to where we were before the experiment: 8.9 % slack.

At the end of 2011 we evaluated our slack experiment. One condition in the experiment was, that whenever someone did something during his slack time, he should add it to his personal slack wiki page. During one of our tuning days where everyone gathers to tune our company, we printed all those slack wiki pages, and arranged them in a gallery. This way everyone could get a good overview of every slack time spent. After that, we decided that the experiment was successful and that we wanted to continue with the concept of slack time.

For 2012 we decided to add another 10 days of slack for every employee. That’s it-agile’s 13.5 % – for now.

How to Evaluate Slack?

It’s very easy to calculate the costs or opportunity costs of slack. (Number of employees) x (number of days of one employees slack time) x (number of the average daily rate) = big pile of money. But since this is an investment you’d expect a return.

We could’ve counted the number of innovations we achieved, but we didn’t do that before or after the experiments. In retrospect, it’s pointless to figure out which innovation came from slack time and which did not. Nobody can tell the relation between slack time and sudden inspiration that hits you in the shower or during your run through the park.

However, we measured slack, not in innovations, but in motivations. Not a single voice was heard during our last evaluation at the end of 2011 that claimed less slack.

Hard to Spend All Your Slack Time

One baffling outcome from our evaluation was: not everybody used every minute of their slack. Truth be told, almost nobody used all their slack. One reason was that over the year dates of work at the customer collided with dates of slack time, and in those cases work at the customer often won. Another reason was that not every planned slack time was actually possible, due to external circumstances like cancelled classes or illnesses.

We learned from this: every it-agile employee is now allowed to use up to 50 % of the unused slack from the previous year in the current year. That means, in 2012 an it-agile employee, given enough slack time left from 2011, is able to use up to 40 days of slack time – almost 2 months of continuous slack.

Proud

We’re proud of our slack. We took the risk of doing costly experiments, and, so far, it paid out. We fought long and hard over the details – the concept is so cool and tempting, but the details are so subtle and tricky! -, but we found a solution which works for us. Slack has now a prominent place in our culture, and we’re curious of how the journey continues.

Related posts:

1. [Slack to the Rescue] What You Want to Do
2. [Slack to the Rescue] Culture of Autonomy