My colleagues and I work as agile coaches. Every now and then, new clients invite us to take a look at their agile teams. These clients typically have introduced agile software development several months earlier and usually say that it was, in general, a good decision. They release more often with fewer bugs, changes to the products are made much more easily, customer happiness is increased, and so on. Yet we also see another picture, a more problematic one: the client's organization and the client's team are bull riding together.

FROM BULLS, CALVES, AND COWS

Bull riding is a rodeo discipline, and the goal for the rider is to stay on top of the bull for a specific amount of time. In our metaphor, who do you think is the rider and who is the bull? A lot of people I've asked said that the team is the rider and the organization is the bull. The people who make this distinction have experienced agile teams that were often crazy. Agile coaches call this behavior "hyperproductive," which sometimes seems scary or even crazy to the organization.

Even worse is the opposite viewpoint -- that the agile team is the bull, and the organization is riding the team. Coaches often see this in organizations holding tight or clutching firmly at the hyperproductive team full of energy. Typically, the organization unleashes a force when it adopts agile, which collides with many other organizational parts and patterns. Consequently, the team just doesn't fit into the organizational structure like the former project teams. The agile team has needs and requests that differ from the ones normally used by the organization.

The organization tries to strike back. Not only does it attempt to ride the bull, it attempts to rope the calf, to restrain it, to tie it down to fit in the organizational procedures. Calf roping is another rodeo discipline, where a mounted rider catches a calf with a rope, dismounts, and then ties three legs of the calf as fast as possible.

This is no fun for the calf. In organizations, every time a figurative calf struggles against a rider's rope, an agile coach's heart breaks. Because it's just too sad to see an agile team suffering when the organizational structure doesn't allow it to be awesome.

What coaches wish for agile teams are happy cows on green meadows, perhaps in the Swiss Alps on a warm and cozy summer evening, with rainbows and everything. That's an environment a cow is happy to be in and where it is the most productive. (Please don't take this metaphor any further from this point on: we are not saying you should milk your employees or lead them to the slaughterhouse!)

The question for every organization with agile teams: is there a way to build an environment as adequate to agile teams as the green meadows are for happy cows? The good news is that there is a way. The bad news? There's a catch.

THEORY X AND THEORY Y

Ask yourself the following questions:

• Do you think that people are unmotivated in general, that they don't like working in your organization, and that they wouldn't work there if they weren't treated with "carrots and sticks" on a regular basis?

• Do you think that in your organization people are self-motivated in general, that they enjoy their work, and that they would work on their own even if nobody "controlled" them?

People with an agile mindset are most likely to answer "no" to the first question and "yes" to the second question. As written a decade ago as a principle of the Agile Manifesto: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." But these questions are much older than the Agile Manifesto.

Douglas McGregor was a renowned management professor at the MIT Sloan School of Management in the middle of the 20th century. In 1960, he published a book called The Human Side of Enterprise, ¹ where he defined two theories. McGregor's assumption was that everyone within an organization has an attitude toward these two different directions, which he called "Theory X" and "Theory Y."

Theory X describes people who believe that other people, in general, don't want to work and that they have to be motivated extrinsically. Theory Y, on the other hand, describes people who believe that people, in general, do want to work and they motivate themselves (aka intrinsic motivation). It all breaks down to a central question: do you or do you not trust that your workmates will do a good job on their own?

Ricardo Semler, CEO at Semco, became very famous for his Theory Y attitude. He describes the conflict between Theory Y and Theory X in his book Maverick as follows:

Workers are adults, but once they walk through the plant gate companies transform them into children, forcing them to wear identification badges, stand in line for lunch, ask the foreman for permission to got to the bathroom, bring in the doctor's note when they have been ill, and blindly follow instructions without asking any questions.²

When we as agile coaches see organizations struggling with their agile teams, we ask the organizations about Theory X and Theory Y as a litmus test. The more Theory Y attitude, the bigger their chances to create green meadows. Why? Because their chances are higher to create an environment where people experience flow during their work.

Flow

Flow is a concept in psychology, proposed by Mihaly Csikszentmihalyi, psychology professor at the Claremont Graduate University in California. In a YouTube video, he describes flow as "a state of mind or a state of experience that we feel when we are totally involved in what we are doing."³ It is the thin line where our skills and the difficulties to accomplish a task are in balance, which is called the flow channel.

Flow is the state of mind that organizations want their workers to reach when performing their jobs. Why? Because when they don't, they work at an unsustainable pace, which may end up in burn out or bore out. If the task is too difficult or the skills are too weak, people get anxious. On the other hand, if the task is too easy or there's a mental underload, people end up bored. Employees in flow are totally immersed in the task at hand and therefore more productive.

In a company with Theory X believers, it's very unlikely to achieve a state of flow. That's because when you don't think that someone is willing to work, you end up controlling the workload, and when you control the workload, it's unlikely that the employee will find a flow channel. (Well, to be honest, in every Theory X company there were almost always a few people working "under the radar" of their managers, at least from time to time. This way they were able to achieve flow states on occasion. Sad thing about this is, achieving flow should be normal, not an exception.)

What Motivates Us

To help workers achieve flow, the best thing management can do is to create an environment that supports flow. Daniel Pink, author of the bestselling book Drive: The Surprising Truth About What Motivates Us, proposes three areas of focus:⁴

1. Autonomy. If you trust your people regarding work (Theory Y), then give them enough space so that they can balance their skills with their challenges.

2. Mastery. With autonomy, you'll release energy within your people, which they in turn use to master their skills and become even better at work.

3. Purpose. To direct the released energy, create a strong purpose (aka vision) that guides everyone in your organization.

Usually when explaining this chain of reasoning, everything sounds plausible and understandable -- at least for Theory Y believers. But that's not enough for most companies. These ideas are just not tangible enough for them. They ask, "What specific steps can we take to create green meadows for our agile teams?" And when my colleagues and I answer, "There is no such thing as a recipe!" they kept insisting by asking, "But what about some tips and clues how and where we could start?"At this point, we introduce AMIs.

AGILE MANAGEMENT INNOVATIONS

Agile management innovations are concrete practices that create an environment within organizations to support agile teams. The abbreviation "AMI" is pronounced like the name "Amy": AY-mee. And if you now think, "My, that sounds lovely!" then this is not an accident, but by intention: Amy means "beloved."

My colleagues and I have collected 26 different AMIs over past years, and we have hands-on experience with all of them (see sidebar "Overview of 26 AMIs"). We use them in our own company, and we help our customers use them in their organizations, too.

The term "management innovations" originated in The Future of Management by American management expert Gary Hamel. According to Hamel, management innovations are:

Anything that substantially alters the way in which the work of management is carried out, or significantly modifies customary organizational forms, and, by doing so, advances organizational goals."⁵

The reason we call our focus "innovations" and not, for example, "practices" or "techniques" is that in our experience 50% of the way a company establishes an AMI depends on company culture. As management guru Peter Drucker purportedly stated, "Culture eats strategy for breakfast," and that's the reason why we see AMIs as impulses and inspirations for organizations searching for ways to establish green meadows. AMIs are not step-by-step descriptions of foolproof procedures. That'd be Theory X thinking. In true Theory Y attitude, AMIs are real-world examples served as food for thought and triggers for change.

Our management innovations are agile, because, as in agile itself, AMIs are focused on the people, (i.e., more on "individuals and interaction" and less on "processes and tools" like the Agile Manifesto states). People with an agile mindset trust their workmates. They help to create green meadows, which illustrates another principle written in the Agile Manifesto: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Let's dig a little deeper into 11 of the aforementioned AMIs. Not only will we explain them to give an impression about how we see AMIs, but we will also give some advice for a few of them as to how an organization could introduce them. Remember that AMIs are not about immediate benefits to the organization but about culture change, and that changing the culture to make it more conducive for agile teams leads to benefits in productivity, innovation, and even employee retention.

Slack

Slack is the idea of allowing employees to work on whatever they want, no strings attached. Companies such as Google made this concept famous. Instead of trying to optimize utilization, slack supports autonomy. Within such autonomy, every employee can follow his or her energy without constraints. Often this results in very innovative concepts and ideas, usually accompanied by an immense amount of learning by each individual with further or advanced training.

Famous companies used and continue to use slack: 3M invented the Post-it Notes within slack, as did W.L. Gore & Associates with its waterproof and breathable fabric Gore-Tex and the amazing Elixir guitar strings. Google's online mail service Gmail, Google News, even Google Agile programming, all started within slack time of its employees.

3M, Gore, and Google offer their employees between 10%-20% of their work time on slack. At my company, we give our employees 30 days of slack every year. The outcomes are numerous. AMI, in both idea and concept, was, for example, invented partly in our slack.

It's very easy to introduce slack within your organization: just start experimenting by giving your employees one day of slack per month. What starts with one day a month could end up similar to companies such as Google and Valve Corporation. Rumor has it that Google wants to introduce full-time slack, at least for their elite employees. Valve, a very successful American video game development company --- known for its blockbuster video games such as Half-Life, Counter-Strike, and Portal -- takes slack one step further. It has already established 100% slack time for its employees.

Konsent

Konsent (yes, with a "k") is a form of decision making. You can try it even in small teams. Instead of a majority vote, konsent is reached when everyone is in agreement with each other. With every majority voting, as long as there's no consent, there's always a minority. It's hard to act in concert if there's at least one in the group whose vote was overruled. In a konsent, everyone's acting in concert.

In a consensus everyone has to be in favor of the motion. In a konsent nobody must be against the motion. That seems to be a small difference between consensus or consent (with a "c") and the Dutch word konsent (with a "k"), yet it's a huge leverage considering the impact it has on the decisions made.

Consider this. A team agrees to make decisions via konsent. When a point comes up that needs to be decided, someone proposes a motion. The team then does a procedure called "thumb voting," which is often used in combination with konsent. Using their thumbs, they indicate three states to each other:

1. Thumbs up. I'm in favor of this motion. I'll commit myself to it, and I will stand up for it.

2. Thumbs aside. I'm indifferent and might not be particularly fond of it, but if this motion is accepted, I'll support it.

3. Thumbs down. I'm against this motion, and I veto. My reason for veto is X.

The last part, the veto, is crucial. When someone gives a veto, he or she has to come up with a reason for it. The other team members can then work with that reason and try to alter the motion so that the vetoing team member would change positions in the decision-making process (i.e., changing thumb down to a thumb aside). Every veto is a chance to attain a better or higher motion than it was before.

True, konsent is sometimes harder and slower to achieve than a majority voting, but only at first sight. If you have an overruled minority after a majority voting, that minority might attack the decision whenever there's an opportunity. Depending on the success of these attacks, majority voting can lead to long-lasting unresolved decisions. On the contrary, konsent means that, if once established, everyone acts in concert. That is because everyone was -- thanks to the possibility of a veto -- heard before the decision was made.

Open Space Technology

Open space technology (OST) is a type of meeting, or to be more precise, a type of conference. Such a meeting or conference is called an open space. At my company, we do open spaces several times a year, company-wide and also within smaller groups. We use it with our customers all the time, sometimes even in trainings.

An open space usually lasts between half a day and two days and has no agenda. There's an inspiring and guiding theme for the whole meeting such as "How to tune our company?" so every attendee will know what the open space is about. Open spaces are moderated by an experienced host who facilitates the attendees. He or she takes care of the meeting process so that the attendees can concentrate on what matters most: communicating with each other.

The agenda is built by the attendees at the beginning of an open space. Everyone who wants to share or exchange something writes a session title on a card together with his or her name as the session host. The name is needed so the attendees know the identity of the session host.

In a format called "marketplace" every session is described shortly by the session host. He or she finds a spot on the agenda. This is repeated with all potential session hosts until the whole agenda emerges with the usual grid with tracks and times you can find in any conference program. At the end of the conference, after all sessions take place, the last thing done within an open space is the closure. Within a closure, all the outcomes from the different sessions are presented in a short summary by the session hosts. Depending on the topic and goal for the open space, participants can then vote on the prioritization of the next steps and further actions. (Beware: while a lot of public conferences with an open space part have a marketplace, they lack of a profound closure where the participants agree on further actions.)

Harrison Owen, the originator of OST, distinguishes OST from any other conference format by applying the following five principles and one law.⁶

1. Whoever comes are the right people.

2. Whenever it starts is the right time.

3. Wherever it happens is the right place.

4. Whatever happens is the only thing that could have.

5. When it's over, it's over.

These five principles are not meant to control but rather to describe the process. The only law, "Law of Two Feet," states that "if at any time you find yourself in any situation where you are neither learning nor contributing -- use you two feet and move to someplace more to your liking." Simply put, if you're not learning or contributing, honor the participants of a session with your retreat.

Compared to slack or konsent, open space needs more preparation and good moderation by an experienced facilitator. It is therefore a little bit harder to experiment with than slack or konsent. I'm continuing to slowly increase the degree of difficulty when introducing AMIs with the next one.

Mentoring and Peer Feedback

Mentoring and peer feedback are actually two different AMIs, but they are closely related and on the surface of this overview, very similar to each other. Mentoring means that every employee has the chance to choose a mentor in the company. A mentor is someone who has already been where the mentee wants to go, and is therefore able to guide the mentee on his or her way. Peer feedback, on the other hand, is what a peer group gives to a colleague. It's an alternative to top-down feedback that a boss would give to underlings. A peer group at our company consists of at least three different colleagues. Our peer groups are cross-functional (i.e., there's at least one consultant and one developer in the peer group). At my company we once thought hard about a name for the role of an employee who has a peer group. There were funny and sad names, such as "peee" ("A mentor has a mentee, so a peer group has a peee?!") or "victim" (yeah, we didn't like that one very much). One guy, I forgot who it was, said with a warm and caring tone "sheep" -- and this somehow got stuck in the company.

Every employee at our company is free to volunteer as a mentor or in a peer group. Each employee decides if he or she wants to work with a peer group or with a mentor. If the employee does not want to work with a peer group, he or she can have an annual performance review with a line manager. Mentoring is optional; some employees have different mentors for different domains, such as a development mentor, an agile management mentor, a sales mentor, and so on.

Meetings with a mentor or peer group are not prescribed. Mentoring meetings take place weekly or quarterly and sometimes in between or on demand. Peer groups tend to have a broader schedule, ranging from monthly to biannually.

One of the main challenges for peer groups is scheduling of meetings. The more distributed the company, the more difficult the scheduling. It's hard to find space for a peer group meeting in a fully packed calendar, and it's even harder to arrange such a meeting with about four people (one sheep and three or more peers). Not everyone has the discipline or the organizational skills to schedule such a meeting on a regular basis.

The results with mentoring and peer groups are satisfying so far. The feedback people receive is far more accurate and individual as compared to the boss's feedback. Employees have the choice to get feedback from whomever they consider the best fit for them over a frequency that supports them best. This means that the feedback is usually of better quality and more regular.

Valve has a similar system of peer feedback in place. Its "Handbook for New Employees," a document every new employee reads upon arrival at the office, states:

A set of people (the set changes each time) interviews everyone in the whole company, asking who each person has worked with since the last round of peer reviews and how the experience of working with each person was.... The feedback is then gathered, collated, anonymized, and delivered to each reviewee.⁷

Sociocracy

In 1851, French philosopher Auguste Comte coined the term "sociocracy." The word is a mix of Latin and Greek, and it was the name for a new system of governance, where people with a social relationship to each other would rule, rather than the general mass of people, as in a democracy. During the next 100 years, sociocracy was developed further by Dutch educators, until in the 1970s, when Gerard Endenburg first applied it in a business organization.⁸ He called his sociocratic model the "circular organizing method," and in the next 40 years, Endenburg's model was adopted in all kinds of different organizations and in models such as AMI. Sociocracy consists of the following three principles:

1. Konsent. Discussed earlier, it's the primary decision-making process within a sociocratic system. Endenburg emphasizes that personal decisions such as hiring, firing, and promoting people are decisions also made by konsent.

2. Organizing in circles. A circle is a team of employees. Every employee is part of just one team. Teams are responsible for their own process to achieve their goals, and they are also responsible for the education of their team members (called integral education).

3. Double-linking. Each circle has a leader (elected by konsent of the circle's members), who represents the interests of the team within a higher circle (link #1), and there's a member of the higher circle (also elected by the circle's members) who participates in all decisions made by a lower circle (link #2). Double-linking forms a hierarchy of circles.

While konsent is a decision-making process, organizing in circles and double-linking are ways of structuring organizations in teams. We call this way of structuring organizational partitioning, and it is the next AMI we'll examine.

Organizational Partitioning

Sociocracy was originally designed to be a system for governance, but all kinds of organizations use it today. There are two main practices in a sociocracy: decision making by konsent and organizational partitioning in teams. Organizational partitioning means that every single employee in the company is part of just one team. All the teams are linked to each other in a way that provides learning from each other while maintaining autonomy.

There are several well-renowned companies using organizational partitioning. Handelsbanken is a highly decentralized Swedish bank, where each branch acts like an autonomous team. Whole Foods Market is an American foods supermarket chain, where the basic organizational unit is not the store, but the team (of which a store has several). Also, my own company is completely divided into teams, which have a huge scale of autonomy, but, on the other hand, have a great deal of responsibility, too. Each team is responsible for the following:

• Customer satisfaction

• Employee satisfaction

• Economic viability

• Usefulness for the whole company

• Recruiting and "decruiting"

Sure, organizational partitioning is a very sophisticated setting for a company. You might want to start small by just having one team. Then, success presumed, add another team and figure out how to deal with the interactions of two teams. Add another team, and another, until everyone is in a team. Consider that every team within your company should be small, steady, and empowered.

The fact that a team should be small is a well-known feature of agile teams. Smaller teams do need to maintain less communication connections than larger teams; for instance, with three team members you will have only three communication connections, whereas with five team members you'll end up with 10 connections, and with 10 team members there will already be 45 connections. You can easily calculate the number of connections within a team by using the formula n(n-1)/2, where n is the number of team members. Not surprisingly, a 2012 study shows that smaller teams are more efficient than larger ones.⁹ The same study gives an idea of the negative effects larger teams have (e.g., the larger the team, the worse are their estimates). Google works with teams of three (called "Google units"), whereas Amazon has its famous "two-pizza teams": teams no larger than what can be fed by two big pizzas.

In my experience, steady teams are very uncommon in organizations, so many managers underestimate the costs of changing teams. The most structured and organized way of constantly changing teams is called "resource pooling," or just pooling. Pooling is part of resource management and is used in several different domains, including finance, computing, and project management. The term means to gather resources (aka people) as a set from where projects can be served to fulfill tasks. Bad thing is that this method is very costly.

Almost 40 years ago, Fred Brooks wrote his famous Mythical Man-Month, where he stated Brook's Law: "Adding manpower to a late software project makes it later."¹⁰ Brooks described two reasons for this behavior: (1) the increase in communication connections with the aforementioned problems with larger teams, and (2) the so-called ramp-up time. Ramp-up time is what Brook's called the time a new team member needs to be productive, which is the time to figure out the new domain and the time the new team needs adjusting to its new structure.

While the time needed to figure out the new domain is very obvious to most managers (who hasn't been in a new environment and had to figure out where things are and how they work?), the time needed for a new team to work productively after a change to the team structure is not. A great model to illustrate the costs of a team restructuring is Tuckman's stages of group development.¹¹ According to that model, teams go through four different stages until they are a performing team:

1. Forming. Team members are new to each other and want to know more about each other. Team members are very careful and polite with each other, avoiding controversies.

2. Storming. Team members try to figure out where their place is within the team. They test the waters of the team's environment. Conflicts about different ideas are carried out.

3. Norming. Team members agree on their team rules, on team goals, and what behavior is acceptable. In this stage, team members take responsibilities for the team's work.

4. Performing. Team members shape the team to their needs, so that they can concentrate on achieving their goals. They function as a unit and get their job done.

This walk through the stages can take time for a team. Think months and years, not days and weeks. The thing is, according to Tuckman, every new team has to go to through all the stages to become a high-performing team. Every time a team changes -- and a team changes when you add or remove a team member -- we end up with a new team. This means that by adding or removing team members to or from a team, the new team has to go through all the stages again, until it has the chance to be a high-performing team. Even worse, there is no guarantee that teams will end up as high-performing teams. They could be stuck in the storming stage all the time, or the norms they come up with won't allow them to be performing. Every time a team changes, chances are that the new team won't be a high-performing team, and chances are that an already high-performing team was ripped apart.

Team Empowerment

Teams within organizations partitioned in teams (aka sociocratic circles) face challenges (e.g., being responsible for their processes, for achieving their goals, and for delighting their customers). There are three characteristics a team within an agile organization should possess to be empowered:

1. Autonomy. This is a precondition to intrinsic motivation, as described earlier. A team should get enough freedom to make its own decisions on how to work (i.e., balancing its capacity with its demand). Without the freedom to achieve goals with their own processes, teams are dependent on others to make decisions, which takes up time and is usually too slow for most of the fast-paced markets out there. Also, if you have autonomous teams, they let your organization scale because the decision making is much faster as a direct consequence of the autonomy. Lean and agile expert Mary Poppendieck referred to this issue when she said, "Anything which needs agreement will eventually fail at scale."¹²

2. Self-organization. While autonomy comes from the outside, self-organization is the way a team organizes itself from the inside. Self-organization means that the team members arrange themselves so that they can achieve goals on their own. "They just figured it out by themselves!" is a quite common answer if one asks how a self-organized team came up with a certain solution. A self-organizing team must have a specific environment in which it can self-organize. This environment comes from the organization, partly through organizational partitioning and autonomy, partly through a leader's vision. Why would you want to have self-organizing teams? According to Stephen Denning, author of Radical Management, "Client delight requires continuous innovation, and a self-organizing team is the management arrangement most likely to generate continuous innovation...."¹³

3. Cross-functionality. When every skill required to achieve a goal is present in a team, we call that team a cross-functional team. It's the opposite of a department structure, common in large organizations, where individuals are grouped by their skills. A cross-functional team is able to get a job done without asking others for help. To a certain degree, they work independently. This kind of team structure enables an organization to make decisions very fast, which shortens the lead time and minimizes the need for bureaucracy.

If all these characteristics are in place, we call the team empowered. It can fully function on its own within the context of the organization, it takes responsibility for its actions, and it achieves great results as a hyperproductive team. Organizational partitioning works best with empowered teams, and empowered teams benefit from organizational partitioning when it comes to the autonomy such environments provide.

Happiness Index

A happiness index is a measure of people's mood. While most people think that it's nice to be happy at work, it's actually essential for the success of an organization. Happier people perform better, achieve higher pay, and have less absenteeism.¹⁴ What's even more important in an area of knowledge work, where creativity is key to success, is that happy employees are more creative.¹⁵

So the question is: are your employees happy at work?

There are different approaches to find the answer. One is to maintain a happiness index. Happiness indexes can be raised on a personal, team, or even organizational level. On all these levels the idea is to track the mood over time.

On a personal level, to keep track of the mood over time, the best thing to use is a journal. The individual should write at the end of each day how he or she felt over the day. My colleagues and I recommend doing this with two entries: a quantitative, numeric one and a qualitative, textual one. The quantitative numeric entry could be a number from one to five, or, for those who find this too boring, from one to five happy panda faces. The qualitative textual entry should describe events or circumstances on that specific day that led to the amount of happy panda faces.

On a team level, a niko-niko calendar is a good tool to track the team's mood over time. A niko-niko calendar is also known as "smiley calendar." Niko-niko is Japanese ideophone for smiling. You set up a calendar, and each team member tracks his or her mood after each working day with a smiley, which is the quantitative entry. That could be a happy smiley, a straight smiley, or a frowning smiley. We recommend using different colors with different smileys (e.g., green for a happy smiley, yellow for the straight smiley, and red for the frowning smiley). Each team member should also describe in a few words why he or she chose the specific smiley. The description is the qualitative entry.

If you prefer electronic tracking on a personal or team level, there are a lot of tools on the market, ranging from smartphone apps to browser-based applications. My company finds Mercury App to be quite helpful.¹⁶

On an organizational level, usually the tracking of employee mood is done via an electronic tool. While you can use apps like Mercury App for that, some companies use different approaches. NixonMcInnes's team, for example, uses tennis balls and buckets to measure its happiness index.¹⁷ It also uses a company-wide virtual dashboard for reporting the aggregated happiness of the last few weeks. Atlassian developed MoodApp, an app for a tablet.¹⁸ The app asks employees one question: "How are you feeling today?" Employees will find tablets with the app located at exits when they leave their office. With a click on a smiley (labeled from left to right: "amped," "good," "doin' fine," "meh," "pissed"), they track their mood.

Once you have data about your personal, team, or organization mood, you can use this data to continuously correct the course. On a personal level, you can use the data from the journal to self-reflect about the way you felt in the past. On a team level, the niko-niko calendar is perfect to bring along to a team retrospective. At an organizational level, the collected data about employee mood should be visualized continuously for all employees (think electronic dashboard) and can be used in organizational retreats and retrospectives.

In all this course-correcting settings (personal reflection, retrospectives on team, or organizational level), the data is usually presented as a graph, where the mood is shown over time. You can see when the mood was very low or very high (quantitative, numeric entries), and you can see what triggered that mood during the ups and downs (qualitative, textual entries). Since most people likely concentrate on the problems, my colleagues and I strongly recommend not only looking at where the mood was low, but also where it was high. With periods of low mood the question should be: "What should we change to be happier at work?" And with periods of high mood the question should be: "What should we keep to remain happy at work?" We reflect upon the happiness index's data, and we recommend a good facilitator. In the case of the personal happiness index, that could be a personal coach, whereas in the cases of the team or the organization, an agile coach or team/organization facilitator is very helpful to support the reflection process.

Open Books and Open Salary Structure

Open books means not only every business figure in the company is available to every employee, but also every employee is able to find them on their own and is able to read and interpret them. Why? Because if you see the ideas of self-organization and autonomy as valuable, open books is very helpful. They allow teams and individuals to much better figure out ways to improve their work and to take responsibility for their own actions.

For example, do you remember the previously mentioned responsibilities of my company's teams? One of them was "customer satisfaction." We once had developers and consultants who didn't know what the customer paid for their services or what deals exactly the customer made with our salespersons. After we made our deals with the customers public within the company and explained how to read and interpret them to everybody, our consultants and developers started giving tips to the salespeople regarding things to improve. This behavior resulted in better processes and more satisfied customers.

Another, more strange example of my company is the open salary structure, which is another AMI. It's a special case of open books. Since payroll costs are the biggest part of our overall costs, how could our teams be responsible for economic viability without being able to know their salaries?

Research has not yet come up with a clear answer to the question whether open books improves the job situation or not. There are studies that show a negative correlation between the knowledge of what coworkers get paid and one's own happiness at work, and there are studies that show a positive correlation between the same knowledge and productivity.^{19, 20} However, in terms of transparency and trust, open books is a great fit for agile organizations.

Profit Sharing

Profit sharing means that employees substantially benefit from the company's profit. You have to search a long time to find companies doing that. For example, in Germany the common share for all the employees in a company with profit sharing is 5%-10% -- the rest is for the shareholders. We don't call that a substantial amount. Even worse, in Germany only every 10th company does profit sharing at all.

At Gore, every employee is a stakeholder. After their first year, employees can have 12% of their salary in the form of stocks.²¹ At Semco, the ratio is even better: dividends and stakeholders get 25% profit share, employees 23%, and the rest goes to taxes (40%) and reinvestments (12%).²² Semco's employees decide how they want to split their 23%; so far, their share is split evenly, so every employee gets the same amount. At my company, 25% goes to our stakeholders, 12% goes to our founders, and the remaining 63% goes to our employees, where it is evenly split.

Those are examples of more or less substantial amount. By substantial, we mean that employees should have a significant share, not just a symbolic one. One of the main reasons the employees at my company participate in a self-organizing way and want to handle the responsibility of economic viability and hiring is our profit sharing. Every employee, even our general managers, have the same share of our profit (we're talking amount, not percentage!). That means that every employee knows exactly that spending and earning money has direct consequences for his or her own share. Nobody would say, "Well, it doesn't matter how much it costs. The company will pay for it!" The company is the people. Everyone pays with his or her own money.

PULL

So far, this report has explained a few AMIs and how you can start using them right now. There's a general principle my colleagues and I recommend when you want to apply AMIs to your company: let your employees choose whether they want to be part of an AMI or not -- and trust their choice.

At my company, peer groups and mentors are chosen on one's own free will. Nobody has to have a mentor, and if one doesn't want to have a peer group, he or she can go back to receive top-down feedback from one of our GMs. No team is forced to make decisions with consent, either. Each team decides about its own decision-making process. In some AMIs, voluntariness is already built in. Open space has a built-in voluntariness: the "Law of Two Feed." Valve's employees use desks on wheels, so they can move their desks and projects to any area that they want to work in. (According to the open space law, this one should be called "Law of Four Desk Wheels.")

This principle is called the "pull principle," since it does not push assignments, but offers choices to pull. Bill Gore, founder of W.L. Gore & Associates, put it this way: "Authoritarians cannot impose commitments, only commands."²³ Valve also makes it very clear how it expects the newbies to work:

How does Valve decide what to work on? The same way we make other decisions: by waiting for someone to decide that it's the right thing to do, and then letting them recruit other people to work on it with them ... it's your job to insert yourself wherever you think you should be.²⁴

When making use of AMIs, remember not to push your employees, but to let your people pull them.

LEWIN'S EQUATION

You're ready now to create green meadows (i.e., environments compatible with agile values that suit your agile teams). Creating an environment is actually a very smart thing to do. Kurt Lewin, a German-American psychologist, was a pioneer on the field of social psychology. Lewin's equation looks like this: b = f(p,e). It means that the behavior (b) of a person (p) is the function (f) of the person (p) and his environment (e). Combine this with the idea that nowadays every psychologist and coach knows: You can't change people directly in order to change their behavior. You can, however, change the environment (which is what AMIs help achieve). What do you get? Right, you can only change a person's behavior when you change their environment. If you do, immediately give up trying to change persons directly! Instead, make participating in AMIs optional. Think about green meadows and concentrate on the environment in order to change the behavior of people. All AMIs are focused on changing the environment, and the pull principle protects people from overeager managers who can't wait to see different behavior fast enough.

HOW TO START WITH AMIS

How should you introduce AMIs? My colleagues and I recommend considering what we call management experiments. Experiments are the only way to maneuver in complex waters, and a company with its employees is very complex waters. According to David J. Snowden and Mary E. Boone, complex systems have a very interesting characteristic:

Though a complex system may, in retrospect, appear to be ordered and predictable, hindsight does not lead to foresight because the external conditions and systems constantly change.²⁵

The only way to deal with this behavior of complex system is with experiments. As Snowden and Boone write:

That is why, instead of attempting to impose a course of action, leaders must patiently allow the path forward to reveal itself. They need to probe first, then sense, and then respond.

Experimenting means that you are limiting the risk of the impact of an AMI by performing small steps one at a time. Start by looking for a problem you want to solve or a certain situation you want to improve. Then choose an AMI (or invent one of your own) that might address this problem. Consider that you can't be sure that your problem will be solved by that AMI, since in a complex environment you don't know all the effects in advance, only in retrospect.

After you have identified a problem or situation and an AMI that fits that problem or improves that situation, don't plan the big transfer for everyone. Ask for a few volunteers for the experiment. When you want to try out decision making with konsent, for example, ask for a single team that is uncomfortable with their current decision making. That's enough volunteers you need for now.

Specify what you want to learn through the experiment and come to an agreement regarding the amount of time you need to learn this (e.g., three months). Then start the experiment. After the three-month timebox is over, evaluate the experiment and either discard the AMI (and try another one) or expand the experiment (e.g., to more than the original team). Eventually integrate the AMI into your corporate culture.

FAILURE IS INEVITABLE

Let me make this absolutely clear: there is no other way to work with AMIs than with trial and error. There is no big plan or blueprint for success when it comes to management and people. No one can predict the outcome of an AMI in different corporate cultures since we're all individuals, and that includes the employees in your company, too. That's another reason why my colleagues and I don't see AMIs as practices, but merely as impulses and inspirations. Trial and error means experiment and, yes, failure. It's unlikely that you will succeed with every experiment you are going to set up. To fail is not bad in a complex environment. In fact, it's inevitable in a complex environment.

Most of the 20th century, beginning right after Taylor started the scientific management movement, organizations experienced a complicated environment. In a complicated environment, there is a direct relationship between cause and effect, but only experts are able to see it. Whenever there was a situation at hand and your boss wanted you to take care of it and you failed, that was a bad thing, career-wise, for your ego and for the organization. Failing in a complicated environment means doing something that could have been avoided. For instance, you might have simply asked the right experts who knew everything in the situation's domain. In a complex environment, on the other hand, you can't see beforehand what action will cause an effect. There is no expert you can ask and no knowledge you can use to avoid failure. Do not risk essential parts of your organization when it comes to experiments. Snowden and Boone call these experiments "fail-safe." Fail-safe experimentation means that you should just fail enough to learn about your environment in order to do better next time.²⁶

CONCLUSION

AMIs are impulses and inspirations for companies eager to change their environment in a way that is compatible with agile methodologies. A more compatible environment provides organizations with an increased likelihood of reaping the promised benefits of agile teams. In this report, we identified 26 AMIs in different categories such as money, decisions, teams, and so on, and we discussed 11 AMIs. AMIs allow employees to experience more flow, self-responsibility, and self-organization by fostering autonomy in a structured way. It's best to make participation in AMIs optional (pull principle) and on a timeboxed trial-and-error basis (management experiments).

I wish you a pleasant journey toward green meadows and happy cows! Moo!

ENDNOTES

¹ McGregor, Douglas. The Human Side of Enterprise. McGraw-Hill, 2005.

² Semler, Ricardo. Maverick: The Success Story Behind the World's Most Unusual Workplace. Warner Books, 1993.

³ See http://youtu.be/JjliwSJGDiU.

⁴ Pink, Daniel H. Drive: The Surprising Truth about What Motivates Us. Riverhead Hardcover, 2009.

⁵ Hamel, Gary. The Future of Management. Harvard Business School Press, 2007.

⁶ Owen, Harrison. Open Space Technology: A User's Guide. Berrett-Koehler Publishers, 2008.

⁷ "Handbook for New Employees" (PDF). Valve, 2012 (www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf).

⁸ Endenburg, Gerard. Sociocracy: The Organization of Decision-Making. Eburon, 1998.

⁹ Staats, Bradley R., Katherine L. Milkman, Craig Fox. "The Team Scaling Fallacy: Underestimating The Declining Efficiency of Larger Teams." Organizational Behavior and Human Decision Processes, Vol. 118, No. 2, 2012.

¹⁰ Brooks Jr., Frederick P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.

¹¹ "Tuckman's Stages of Group Development" (Wikipedia).

¹² Poppendieck, Mary. "RE: [leanagile] Process Defined Outside the Team (Was People Times Process)." Yahoo! Groups, 14 March 2009 (http://tech.groups.yahoo.com/group/leanagile/message/2908).

¹³ Denning, Stephen. The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century. Jossey-Bass, 2010.

¹⁴ Williams, Ray B. "How Workplace Happiness Can Boost Productivity." Psychology Today, 20 July 2010 (www.psychologytoday.com/blog/wired-success/201007/how-workplace-happiness-can-boost-productivity).

¹⁵ Roberts, Michael. "The Power of Ordinary Practices." Harvard Business School, 20 September 2006 (http://hbswk.hbs.edu/item/5492.html).

¹⁶ See www.mercuryapp.com.

¹⁷ Winton, Steven. "Is Everybody Happy? Measuring Happiness in the Workplace." NixonMcInnes, 28 September 2010 (www.nixonmcinnes.co.uk/2010/09/28/is-everybody-happy-measuring-happiness-in-the-workplace).

¹⁸ Luijke, Joris. "4 Tactics to Change from Directive Leadership to a Self-Correcting Organisation." Management Innovation eXchange, 3 December 2011 (www.managementexchange.com/story/%22traditional-management%22-%22trust-management%22).

¹⁹ Card, David, Alexandre Mas, Enrico Moretti, and Emmanuel Saez. "Inequality at Work: The Effect of Peer Salaries on Job Satisfaction." American Economic Review, Vol. 102, No. 6, October 2010.

²⁰ i Vidal, Jordi Blanes, and Mareike Nossol."Tournaments Without Prizes: Evidence from Personnel Records." Management Science, Vol. 57, No. 10, October 2011.

²¹ Hamel. See 5.

²² Semler. See 2.

²³ Hamel. See 5.

²⁴ Valve. See 7.

²⁵ Snowden, David J., and Mary E. Boone. "A Leader's Framework for Decision Making." Harvard Business Review, November 2007.

²⁶ Snowden and Boone. See 25.