“How can we tell how far along we are with our agile adoption?”

I heard this question again the other day.

Usually, the person who asks the question starts to answer it:

Number of teams using agile

Number of people trained in agile

Number of projects using agile

Number of certified coaches.

Metrics like these won’t tell you what you need to know. More likely, they will lead you astray. How? Let me tell you a story.

Years ago, I worked for a company that was “installing” a Big Methodology from a Big Company.  (The fact that they thought they were “installing” a methodology was probably the first warning sign.)

Every one in the department attended Big Methodology training. (This practice is sometimes called “Sheep Dip” training).

The VP mandated that all projects would use the Big Methodology.

The Installation Team audited to ensure that project managers and teams were complying and producing the required “work products” in accordance with the Required Work Products grid in the back of the very large Big Methodology binder.

Of course, there was some grumbling (from the people the Installation Team referred to as “Change Resisters.”)  Eventually, people did comply. Every one went to training. Projects managers filled out the required templates, and checked the appropriate boxes.  The metrics looked grand!

The VP declared, “Big Methodology is now business as usual!”

At the time, I scoffed at that statement. It was clear to me that people were not using Big Methodology, and that the promised benefits were nowhere in sight. The only things that had really changed were some check boxes and some names (documents became “work products” or “job aids,”).

But, now, I realize that the VP’s statement was TRUE!

We had Big Methodology, and things went on as they had–business as usual! Well, maybe a little worse because people were spending time producing the many documents specified on the Required Work Products grid.

The metrics the VP tracked were easy to count. But they only revealed surface compliance. They didn’t say anything about whether the organization was achieving the improvements promised by Big Methodology and hoped for by the VP.

So when you think about assessing how far along you are in your agile transformation, consider what you are trying to achieve.

I often suggest that managers track three metrics to understand how well their organization is functioning, and whether they are trending in the right direction.

The ratio of fixing work to feature work. How much time are people spending developing valuable new features vs. fixing stuff that wasn’t done right the first time? If you can figure out the sources of fixing work and make some progress there, you have a boost to productivity. Agile methods can address some of the sources of fixing work…but not all of them.

 Cycle time. How long does it take to go from an idea to a valuable product in the hands of a customer? Again agile methods can help with delivery. But if it’s the upstream process–planning for products and releases–is broken, you may not see improvement until you address those issues, as well as the development process.

Number of defects escaping to production. This is a category of fixing-work that is a direct indicator that the quality of the development process is improving.

For each of these metrics, it is the trend that is important, not an absolute number.  The trend will tell you if your attempts at improvement are having an effect. Remember, most changes take time to take hold. If the trend doesn’t move in a month, it may not mean you have taken the wrong action and need to change direction. If the trend isn’t moving over time, then, examine what is happening in the development area. But also look at other aspects of the system. There are few one-to-one cause and effect relationships in complex systems and the trend you see may or may not be directly related to your change. One company I worked with was alarmed to see that defects released to production went up after they started using agile methods. It turned out that prior to the effort to measure defects released to production, no one paid much attention unless the defect brought down a customer site. The increase in the defects trend was related to reporting, not a failure to improve quality.

I find that the three metrics above are generally useful for understanding how a software development organization is functioning as a system. But your reasons for adopting agile methods may be different.  Consider the goals you are trying to achieve.  What signals would tell you that you are moving in the right direction?  How might you measure those?  When you think about measures, be wary of target numbers. Measuring against targets almost always causes distortion. That means that people will behave so as to reach the target, perhaps in ways that are counter to the actual goal behind the target. Distortion will keep you from seeing the real picture, and may also cause real harm to your organization.

Useful metrics give you a window into how the system is functioning, and whether your change is having an effect. The numbers themselves are neither good nor bad. They are information that signals you to go and find out, investigate and reason about the system.

Every team needs leadership, even self-organizing teams.

When I make this statement, some people assume I mean that every team needs a designated leader.  I can’t blame them, most people are accustomed to thinking of leadership residing in a role or a charismatic individual—a “born” leader.

On self-organizing teams, there isn’t one leader.  Agile teams may have a coach; however, the coaches job is to help the team see where they need to improve and help them learn specific skills.  The coach may lead at times, but the coach isn’t the leader.  In fact, if the team looks at the coach as the leader, they’re in trouble. Holding up one person as leader will hamper team development.

Before we go any further, let’s define leadership: leadership is creating an environment where everyone can contribute to solve the problem at hand.

On teams that function well, every member of the team leads.  Each person takes responsibility for helping the team move forward.

But acting at random or on gut feel isn’t enough. Empowering leaders can be more effective when they work out of a model that helps them make sense of what they see happening on the team.

One such model is the MOIJ model articulated by Jerry Weinberg.

1. Every team needs motivation—and I don’t mean pep talks, cheerleading and extrinsic rewards.  Teams do best when they are intrinsically motivated, when they derive satisfaction from the work and team relationships.

Team members lead when they work for appropriate harmony and consensus—and engage in constructive conflict.  Leaders pay attention to how other team members are participating, so that everyone can use their talents and creativity. Leaders pay attention to how the whole team is working together, and building a team culture that supports achievement and good working relationships.

When only one person on the team pays attention to motivation, the team doesn’t learn how to create the environment for their own success.

2. Teams need organization.  Organization is more than the boxes on an org chart.  Organization includes physical space, time, and structure.

Leaders make sure that the workspace supports the team with appropriate equipment and information. Teams need someone to lead by pay attention to commitments and the ticking clock.  They need to figure out how to allocate the work so that it gets done and there’s a balance between people expanding their skills and relying on experts who can do the work most quickly. Teams need structures that help them work effectively together, for example, working agreements or configuration management.

When only one person pays attention to organization, he comes across as a nag. After a while, people ignore nags.

3. Teams need information.  They need to see a vision, generate ideas, bring in data and analyze and connect the dots.

Along with a flow of ideas, sometimes, a teams need a Devils Advocate.  A Devil’s Advocate challenges habitual thinking, checks solutions against foundational principles and values.  Without a Devil’s Advocate, teams can slip into group think, or miss risks and weaknesses when they consider options. But like the nagging organizer, no one enjoys a habitual naysayer. When there’s only one Devil’s Advocate he’s likely to be marginalized.  Like all the other leadership activities, it’s important to spread this one around.

Team members also need to know when they have too many ideas, and it’s time to slow the flow. We usually don’t think of following as a leadership activity.  But I’ve seen teams where everyone wanted to have his or her way.  I’ve seen teams sidetracked when members keep throwing in new ideas each time they come close to a decision.  Those teams argue and debate endlessly and don’t make forward progress.  Knowing when to zip the lips and follow is leadership, too.

4. Finally, every team needs people who can recognize when they are stuck and need a jiggle.  My favorite jiggle is a paradoxical question: “How can we make the situation worse?” Simply commenting on the stuck-ness can sometimes shake a team out of their rut. Changing position—standing up if the team has been sitting–can jiggle the team into productive action, as well.

***

What happens when only one person on the team—whether a formal or informal leader—tries to do all the leadership?  I suppose there are the rare individuals who can do it all. But on most teams that aren’t sharing leadership, are missing some leadership ingredients.  When teams rely on one individual they flounder when the leader isn’t available.  Worse, they don’t develop their own capabilities and slide into dependency.

Leadership is about making sure the team is functioning well and creating an environment where everyone can do his or her best work.  And it takes a whole team of leaders to make a self-organizing team.

At a recent conference, I over-heard three managers talking about self-organizing teams.

“You can’t just turn people loose and let a team make all the decisions. They’ll mess things up. And with all these ScrumMasters, coaches, and self-organizing teams, sounds like I’m out of a job,” said one with resignation.

“This time boxing thing is great,” said another. “Put them in a room, turn up the heat, and they’ll perform,” said a second manager.

“Wow, this means I can move people around based on projects, and they’ll just form and self-organize. I can have rolling, ad hoc Scrum teams!” crowed a third.

Time to rectify some misconceptions.

# 1. Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

# 2. All you need to do to form a self-organizing team is provide a goal and apply pressure.

#3. Since the team is self-organizing, they can accommodate moving people on and off the team easily.

Misconception: Self-organizing teams don’t need managers.

There’s a reason we use the term “self-organizing” rather than “self-organized” or “self-managed.” That’s because it’s a process and a characteristic, not something that is done once and for all. Self-organizing, from a social systems perspective only means that the team can create new approaches and adapt to meet new challenges in their environment.

Self-organizing Agile teams do have–bounded—authority to make their own commitments, organize and assign their own work. They craft appropriate strategies to accomplish their goals, and make decisions with (again bounded) economic and organizational impact.

But they are not out there on their own, disconnected from the organization. Self-organizing teams exist to produce a product or service that is valuable to the organization and its customers. They are accountable to make their progress visible, and work within financial boundaries. Self-organizing teams may also be self-managed, to one degree or another.

Managers must create the conditions that enable teams to thrive and continue to self-organize. Manager need to work across the organization to create a work system that enables teams to deliver value to customers and the organization. And managers need to work with the team to set appropriate boundaries and constraints. Managers still act as agents for the corporation. Therefore, they still must be involved where there are legal or fiduciary responsibilities.

Misconception: Time boxing forces any group to become a team. Put a group of people together and hand them a challenge and they’ll gel.

I wouldn’t bet on it, and neither should you. Teams do need a clear and compelling work goal. Without that, there’s no reason to form a team. They also need the technical skills required by the work and interpersonal skills to work as a team. They need resources such as tools and access to information and education. They need a connection to the larger organization.

The pressure cooker method of team formation will more likely burn people out than result in the productivity of a real team. Calling a group a team and turning up the heat, doesn’t make it so.

Time boxing is one of the structures than can help teams succeed by providing focus. Working in time boxes creates a natural rhythm of feedback and connection to the team’s purpose. But a time box and goal, in and of themselves, don’t create a team.

Misconception: Self-organizing agile teams should be able to accommodate frequent membership changes. After all, they’re agile aren’t they?

Teams need time to develop the strategies and trust that enables high performance. They need time to understand each others strengths and weaknesses, develop shared knowledge, and learn how to learn together.

When new people constantly arrive and leave, a group may never develop the shared approaches and shared knowledge that permit them to outperform a group of individuals.

Some teams—when they’ve had time to form and create a strong team culture—do become adept at adding new members. Even then, it’s best to limit the number of new members added at any given time. Changing more than 30% of team membership causes the team to reboot. Constant turnover prevents a team from truly forming.

As a manager, you can help by keeping teams together long enough to gel, and by protecting teams from the revolving door syndrome.

Reality

Self-organizing teams are not teams gone mad. Like all teams, they need a compelling goal, skills, information, and enough time to form and perform. And they still need managers to create a supportive context, set appropriate boundaries and constraints and connect the team to the organization.

“The thinking that got us here isn’t the thinking that’s going to get us where we need to be.”  attributed to Albert Einstein

I have  this niggling concern about retrospectives.

I have no doubt that retrospectives that are too short, don’t result in action / experiment, or fail to delve beneath the surface are a waste of time. (I suspect many retrospectives fall into this category, since many people teach that an entire retrospective consists of Keep/Drop/Add or some variant there of. This is seldom sufficient for deep or creative thinking.)

But what about earnest retrospectives that focus on an area of concern, examine data, analyze underlying issues and result in action?  I worry that some of those fall short, too.  Why?  Because the thinking that got us here isn’t the thinking that will get us where we need to be.

People work out of their existing mental models. When they examine their current actions, they may achieve incremental improvements.  But they may  take a potentially useful new practice and kill it with 1000 compromises, shaping the new practice to fit the old mental model.

This can happen even when people are trying to learn a new way of working. The first OO program I wrote looked remarkably procedural– I was trying to wrap my head around the new paradigm, I hadn’t quite gotten there yet. In a retrospective, if people try to improve their agile practices, they may improve them right back to serial development.  Or, people may make a genuine effort to improve, but they only know what they know, and the possibilities for improvement they can see are within the bounds of their current thinking.

So the task, then, is to examine the thinking and expand possibilities.

Single and Double Loop Learning

Single loop learning asks, “How can we do what we are doing better.”

Double loop learning asks “Why do we think this is the right thing to do,” and involves scrutinizing values, thinking, and assumptions.

Transformational improvement and significant learning come from making beliefs, assumptions, and thinking explicit, testing them, and experimenting.

Teams may need a little help to make the jump into the second learning loop, As teams are examining their practices, ask questions that help teams surface assumptions and test them.

• What would have to be true for [a particular practice] to work?

• [practice or action] makes sense when ___________.

• [practice or action] will work perfectly when _________.

• [practice or action] will work well-enough when_________.

• [practice or action] will be harmful when__________.

• What do we know to be true? How do we know that?

• What do we assume is true?  Can we confirm that?

• Why do we believe that?

• What is untrue, based on our investigation?

• What do we say our values are?

• If an outsider watched us, what would he say our values are?

• What is the gap?  How can we make the gap smaller?

• How could we make things worse?

Chewing on a good subset of these questions usually helps a team see their assumptions, and take a different view on what has worked, what hasn’t worked as expected, and the reasons why.

Then, they are in a better position to choose a more effective action, or design an experiment that will help them learn what action to take.

Some pundits proclaim that leadership rests on charisma, the ability to create a vision, or “presence.” Teams do need a vision and a compelling goal.  But do teams need one charismatic leader? No.Teams need leaders of a different sort. Teams need leaders who don’t need to be out in front, who are able to work quietly, creating an environment where everyone on the team is empowered. Such leaders–empowering leaders—may not get the glory. They do help teams get work done, invite creativity, and build capacity.  How do they work? Not by rousing speeches, through followers or by exuding some magical stuff. Empowering leaders create an environment where everyone is empowered. The act on observation, not gut feel or random action.

As Yogi Berra pointed out, you can observe a lot just by watching.  But what should you watch? How do you make meaning of what you see?

We are bombarded with sensory input, and our brains are built to find patterns. They are also build to filter out data.  Empowering leaders can’t rely on innate observation abilities.  They need to hone their awareness to make their interpretations reliable guides for action. Empowering leaders hone awareness in three areas:

• Self-awareness. They know their own strengths, patterns, blind spots.
• Team Awareness. They understand group dynamics and understand that teams are goal oriented social units.
• System Awareness. They grasp that the team exists within a larger system, which includes the organization as a whole, other teams, customers, work flows, and policies.

The average person knows quite a bit about him or herself.  He knows what he likes, and what he doesn’t like. He probably knows whether he likes to decide quickly, shoot from the hip, or examine all the options before choosing. He probably knows whether he is mad, sad or glad at any given moment. He probably thinks he knows what he’s good at.

Average self-knowledge isn’t good enough for leaders.  Empowering leaders observe their own thoughts and feelings, so they can manage their emotional responses. They separate the data from the interpretations they make of data. They understand their thought patterns, and how they respond to stress. They understand how that not everyone sees the world the same way (and that’s a good thing).

Empowering leaders learn to observe the team and discern patterns of behavior on the group level that effect that ability of the group to get work done. They notice who offers ideas, who challenges ideas. They notice when one person consistently interrupts another team member. Leaders hone their ability to notice the roles people take in group discussions, and pick up on non-verbal cues. This is the information that allows them to determine what is happening, and what (if anything) is needed to adjust the environment so everyone is empowered and able to work. Empowering leaders notice how the physical arrangements affect work, how information is flowing (or not), and when the constraints on the team are too few or too many.

Finally, empowering leaders pay attention to the context, the world the team works in.  How does work flow into the team? What are the relationships with other parts of the organization? Are their policies and procedure that are hindering the team? An empowering leader on a team may not be able to eliminate such factors himself. But he knows how modify the team environment to lessen harm, and to influence out side the team to achieve change.

Awareness gives leaders the ability to make sense of the data. Then, they can choose from a variety of responses that will influence the environment to empower all members of the team to contribute.

I recently talked to a group that’s forming a new “change leadership” team.  Part of the work of the team is improving the organization, and part is capacity building. Four of the people on the team are folks with technical backgrounds who are viewed as having potential to be future leaders in the organization. The fifth person is a manager.

By definition, the manager will have a different role on the team. Because of his role in the organization, he’s accustomed to taking a  broader view of the organization.  He’s got more experience steering change.  He’s led and managed teams.  He has more authority, and access to resources. He can approve expenditures.

One of the tasks for this group in becoming a team is to clarify the managers role, and identify decision boundaries. This is something I do with self-organizing teams. It’s especially important when the manager sits on the team. I find that it helps both the manager and team members break out of the common “looking up/looking down” dynamic.

And, the act of co-creating the relationship helps build trust.

It’s  not necessary to list and delineate every decision that could possibly come up. Usually, there are classes of decisions that can be treated in the same way.  I start by having the group brainstorm all the decisions they are likely to make as they work towards the team goal.  Then, they group the decisions to identify the classes.

Looking at the classes of decisions, I help the group answer these questions:

Who defines the problem or issue?

Who sets the focus and boundaries (e.g., money, timing, unacceptable options, criteria, etc.)

Who identifies candidate options?

Who evaluates chooses among options?

Who implements the chosen option?

Who evaluates the decision, once it’s in place?

At the end of the activity, they have a grid that looks something like this chart (though they usually have names, rather than M and T to stand for manager and team).

Clear decision boundaries makes it explicit which decisions are the managers alone, which are the managers, but involve the team. It also identifies which decisions are shared, and which the team can make even if the manager isn’t around to participate in a particular decision.

This sort of clarity make is easier for teams to act on their empowerment. It also avoids the sort of ill will that can come up when the team believes they will be involved in a decision, and the person with a management role believes differently.

I was talking to my friend Penny the other day about a team she coaches.

There’s a really smart guy on the team. I’ll call him Bob. Most of the time Bob is an asset to the team. But when the team needs to decide on a technical solution under time pressure, he’s not.

“But Bob is a smart guy,” you may say. “How is it he’s not an asset? Won’t he have the best ideas?”

When it comes time to solve a technical problem, Bob is always first to offer his idea. Then, Bob dominates the conversation with a constant stream of words, leaving no opening for another to insert facts, ideas, points of view. When someone does find a voice and interrupts the torrent, Bob cuts him off, declaring “I’m not finished.”

When Bob does finish, and another team members asks a question, Bob implies that the other person doesn’t get it, and might be too stupid to see the brilliance of Bob’s idea.

When another team member proposes a different idea, Bob shreds it. He points out the flaws in the other person’s idea, while pointing to the strengths of his own idea.

When he does let others speak, it’s pretty clear that he isn’t listening to learn. Bob is figuring out how to score his next point.

I don’t believe Bob has bad intentions. I believe he wants to be helpful, and believes he is. Bob is helping the team in many ways, but he’s also hurting the team. Here’s how:

1. The team don’t have enough ideas. Due to Bob’s style, there is seldom more than one idea (Bob’s) that receives serious consideration. That’s not enough. Even if Bob is smart, so are the other people on the team. But Bob is the most extraverted and the best at argument and debate. That’s not the same as having the best ideas.

2. Over time, Bob’s style will wear down the other team members. It’s really not terribly satisfying to be browbeaten, or have all your ideas shot down. At some point, other people will stop offering ideas, and acquiesce rather than endure another argument with Bob.

3. As long as Bob’s ideas prevail, others don’t have a chance to develop their ideas.They are deprived the opportunity to learn, think about problems and risks, and increase their capability. Over the long run, that’s bad for the individuals involved, bad for the team, bad for the organization.

Penny has given Bob feedback on the effects of his behavior. It’s made some impact, but when there’s pressure to come up with a solution, Bob–as most people do–falls back on his default behavior. Chances are, Penny won’t get Bob to change that. Bob’s behavior is driven by his natural tendencies, and years of cultural exposure that taught him that competition and argument are the way to find the best ideas.

However, Penny can change the process so that the team has sufficient ideas to consider, and that credible ideas receive due consideration.

Here’s how:

Separate generating ideas, explaining ideas, exploring ideas, and evaluating ideas. As it is now, all of these are mashed together (and done mostly by Bob).

Equalize participation. From what Penny has told me, I suspect Bob is a strong extravert and the other team members are introverts. That means that Bob is very comfortable thinking out loud, and the other team members need a bit of time to organize their thoughts. Before they have time to do that, Bob is on a roll. One way make room for more participation is to start the process with a few minutes of silent brainstorming. Then, ask each person explain (orally or through sketching) the essentials of his or her best idea.

Apply the Rule of Three. If you don’t have at least three ideas, you don’t have enough ideas, and you probably don’t understand the problem. You may end up with deciding the first idea that came up is the best one…but you may not, or you may refine the first idea based on further discussion.

Test for agreement. Some teams get carried away with voting. But when a decisions are routinely highjacked by one individual, it can help to test for agreement using a gradient of agreement or fist of five.

Establish a small set of tests for technical solutions. In this team, some of the tests that make sense might be:

The solution …

• is the simplest thing that can work.
• doesn’t add to technical debt.
• can be implemented in the timeframe required by service level agreements.

Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas are fully considered. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else.  If the team had a process to consider and refine ideas, that might not happen as much.

It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.

But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.

A while back I talked to a CEO of a contract development shop.  He wondered how Agile could help him with fixed price, fixed scope contracts to deliver software.

Of course, the requirements that come with these contracts are never complete or completely accurate. The first thing that comes to mind is to stop making impossible contracts.  For this CEO, that doesn’t seem possible, at least at this time, given the context he does business in.

In any fixed cost/scope contract there comes a time when the two parties must have a conversation about the short-comings of the requirements, the delivered software, and the budget.

In a waterfall delivery, all progress reports are proxies. You’re reporting on intangibles–designs, test cases, or code that isn’t fully integrated or tested. This is all reporting on faith, because it is not verified by working software.

When a change request does come up, it’s unanchored from the experience of how actually using the software. It’s only words, and the impacts are made tangible in cost thinking, how much it will cost to modify existing artifacts, ripple effects through the code, test cases, documentation.  There’s usually some accounting for the benefit and risks, but those tend to feel subject to inflation, based on conjecture, squishy. What does feel clear is that the change request process takes up time, and approving the change will cost more money. More often than not, the interaction feels like a tug of war. One side is arguing to spend more money, and the other is working with equal vigor for the opposite.

When the moment of truth arrives–the long tail of testing–it becomes apparent that all the progress reports up until that point weren’t reliable. After you’ve made the up-front promises and signed on the line, you have one big opportunity to build trust. If you blow it, you’re sunk. At that point, it’s difficult to have a conversation about meeting goals–especially when the lawyers get involved.

However, if you are using agile methods, you demonstrate some small piece of software every few weeks. People on both sides of the contract see tangible progress.  They have a chance to correct misunderstandings about requirements, and fill in the gaps in each others understanding. People on both sides of the contract can see and experience the short-coming in the requirements, so it’s not the tug of war a traditional change process sets up. People on both sides have more reliable data on which to make decisions.

Most important though, both parties have had many opportunities to build trust based on something real–working software.

So when that point comes, when both parties to the contract must have a conversation about meeting the aim of the contract, it’s a very different conversation.  The moment of truth will probably come sooner, when people have more options.  The conversation will be based on shared understanding of progress and trust.  And that’s a very different conversation.

Bob Sutton recently posted a piece on Team Guidelines.  The guidelines–all Mom and Apple Pie–where handed down by a new boss for the team to follow.

The list starts with “Show Respect.”

I find it ironic that the new boss is advocating treating people with respect. Arriving with a set of rules for other adults you’ve just met doesn’t feel respectful to me.  And I’m pretty sure that imposing rules won’t have the desired effect.  Modeling behavior, engaging the group in discussion about patterns of interaction, yes. Coming in with the rules like a kindergarten teacher–not so much.

But the post got me thinking about how teams develop norms.

Teams develop norms whether they are paying attention to norms or not.

Teams build up a pattern of interaction and implicit understandings of what people can do, should do, should not do, must and must not do in various situations.  It’s part of being in group of humans.  Often, the patterns form without much thinking about the implications.  Norms form around where people sit in meetings, or acceptable late arrival, and whether someone should bring cookies on Tuesdays.

Effective teams have a shared approach to work (though not a rigid process).  They explicitly work out agreements about “How we do things.” The team’s agreements evolve to address both challenges and aspirations.  Teams find a way to talk about what matters, and decided how they’ll act out those priorities day to day.

When a team develops agreements, it helps to know what they are trying to accomplish, because different sorts of agreements serve different purposes.

Values

…are statements of what is important.  Value may guide behavior, but are not, in themselves, actionable. Values often represent the espoused beliefs in the organization–which don’t always match the values in action.

Example:   Balance work and life. (But pay attention to what really happens.)

Group Norms

…are informal, often implicit standards of behavior that develop from the interactions of the group.

Example: (By observing the group, we can deduces that…) It’s acceptable to be late for meetings.

Ground Rules

…are statements of expected behavior for specific times, places, and situations.

Example: (Posted in the meeting room) Don’t interrupt each other.

Working Agreements

…are protocols that the group develops and agrees to follow. The protocols aim to forge commitment and a shared approach that will help the team meet their goal.

Example: Code is *done* when all programmer and acceptances tests pass, the customer accepts the story, and the code is checked into the development branch.

Simple Rules

…are short statements that guide interactions and  decision making within the group and across other groups within the organization.  Simple Rules can generalize across many situations, and make values actionable. Simple Rules aim at brining coherence across the organization.

Example: Use every failure as an opportunity to learn.

All of these represent social contracts between group members. Effective teams use all of these tools to create a pattern of interaction and results that enhance their ability to reach goals and improve quality of both work life and results.

Reaching collaboration and high performance is possible without explicit agreements.  It’s much easier (and more likely) for a team to reach high performance when they pay attention to the pattern they want to create and use these tools to help shape the pattern.

Values, ground rules, working agreements, and simple rules each serve a different purpose. Some teams find it useful to both simple rules (which help make values actionable) and working agreements (which address specific practices).

For both simple rules and working agreements, the list should be…

• focused on amplifying desired patterns of behavior
• aimed at helping the team achieve their task and team-work goals
• generalizable
• minimum specifications
• short: no more than seven items on each list (fewer than seven is even better)

Many teams I meet have some variety of agreements about how to act. The groups that do best have a short list, and refresh it as needed.  I visited one group that had a list of 20 team rules.  That’s too many for anyone to remember. And, such a long list is indicative of a different issue–probably that the group members hadn’t developed common language around practices and had very different mental models of how software development works.

I don’t think every group needs to have a list of values, ground rules, group norms and simple rules. The point isn’t to explicitly govern all aspects of behavior.  I visited a group once that had a list of 20 ground rules. It’s always interesting to see how and whether team members hold the group and individuals to their espoused standards.  So look at the posted rules, and then observe how people really act.

“However they arise, such rules test a group’s own credibility. For example, if everyone agrees to make team meetings a top priority and then members fail to show up, it signals that the group may not be able to manage even the simplest of details, let alone conquer its performance challenges. The rules must be enforced. One team we know decided on total confidentiality to encourage open discussion. Early on a member violated the rule by talking to outsiders. When the rest of the team learned that the leader had gently, but firmly, reprimanded the offender, team discussions became even more open, free-wheeling, and, ultimately, creative.”

 

An effective hierarchy provides enough central control for coordinated action in achieving the aim of the organization. At the same time, the hierarchy must provides enough autonomy for subsystems to function, self-organize, flourish.

Yes.  But how to do that? Let me walk you through a scenario that describes the challenge.

I’ve seen a number of organizations decentralize control and decision making, only to pull it back to the home office. If you watch long enough, many of these companies after experiencing centralized control for a while, go back to decentralized control–like a pendulum swinging back and forth.

Here’s how it goes.

As a result of centralized control, decisions are slow.  Slow decisions and top down plans that require an act of god to change lead to poor financial performance, and customer dissatisfaction. Because people are effectively denied discretion, creativity plummets. Rigid plans and targets don’t allow people to take advantage of new opportunities.

When the financial results start to trend down, senior management notices.  They want faster decisions, and front-line people who are responsive to customers. They want creativity, innovation. They want to seize emergent opportunities and respond nimbly to change.  They want better financial results.  Who wouldn’t want all those things.  So they decentralize.

After the initial flush of enthusiasm, they start noticing problems. Visibility decreases. Decision making and spending feel out of control. Some subunits make inappropriate decisions. Subunits optimize at their level, forgetting the overall goal of the organization. Some subunit managers go rogue, and strike out in directions that make no sense for the overall company strategy. Financial results dip.

And the managers want a return to clear lines of communication and authority. They want visibility, coordinated action. They want predictability, consistency. They want CONTROL. So the pull decision making, planning, budgeting back to the center.

While the supposed solution seems to be swinging between two poles, the organization and the people in it experiencing an oscillating effect.

In truth, the company doesn’t want either end of the pole.  They want the upside of both centralized control and decentralized control.  They want enough control to effectively coordinate actions of the various parts of the system to achieve the goal of the organization,  And they want enough autonomy so that all parts of the system can flourish, self-organize and respond to opportunities and change.

Why do systems oscillate?  Delayed feedback and an over-vigorous correction.  This happens on the organizational level, but it can also happen on a smaller scale anywhere in the system where feedback is slow and well-intentioned people over-correct when they do get feedback on system performance.

In order to achieve the upsides, organizations need to manage the downsides.  And that requires faster and more robust feedback loops. Those feedback loops will provide information about system behavior sooner, and allow smaller more nuanced adjustments.

I’ll write about some of those feedback loops next.