Last week, I had a chance to reflect on eleven years of the Retrospective Facilitators Gathering.
A bit of background on RFG: I started the Gathering in 2002 with Diana Larsen and Norm Kerth. Each year, the different set of volunteers organize the Gathering. Continuity comes from linking the immediate past organizer, the current year organizer, and the next year organizer as part of the organizing group. Most years that’s worked reasonably well.
We’ve used light weight planning and a market place for sessions from the start. But over the years, I and other organizers learned more about self-organizing systems. We lightened our planning even more. We planed the parts that need planning– the venue, and supplies, for example. Those aspects that don’t need close planning emerge organically. But what emerges depends on setting the initial conditions, and attending to containers, differences and exchanges.
Based on a decade of experiments and experience, some considerations for setting the conditions for self-organizing social systems.
1. Initial conditions shape interactions for the life of the group. Small actions can have a big effect, particularly those that amplify the sorts of differences that create division.
2. When structures and espoused values contradict each other, people sense the incongruity–and respond, often in incongruent ways.
3. The more people in implied (“organizers”) leadership positions take responsibility for the decisions and welfare of the group, the less responsibility the group will take for their own decisions and welfare.
As you think about the teams and groups that you work with, how do these factors show up? How might you apply them now?
“A talented employee may join a company because of its charismatic leaders, its generous benefits, and its world class training programs, but how long that employee stays and how productive he is while there is determined by his relationship with his immediate supervisor.” Buckingham & Coffman
Good managers know how to build strong relationships in a traditional manager-led environment. But when a company relies on self-organizing teams to accomplish work, the relationship between an employee and his direct manager may not be his primary affiliation When organizations form real teams, the strongest bonds may be to the team, not the manager.Managers still need to maintain rapport with individuals, but now they also need to maintain a relationship with the team as a whole.
What does that look like? Strong manager-team bonds come from co-creating, clarity, and coherence.
As a manager, you need certain things from the teams you support. It’s reasonable to expect teams to make their status, progress, and road blocks visible. It makes sense to track certain metrics from teams to alert you to problems. You need trend information to reason about how the team is functioning, and how the system is functioning. (I’ll write more about which metrics might be useful and the importance of focusing on trends rather than targets in a future newsletter.)
And the team needs things from you, too. But what the team needs might be different from what a collection of individuals needed. Gather the team and find out. Start with two sheets of flip chart paper one of the team, one for you. Draw a line down the middle creating two columns. Label one Need, and the other Offer. Ask the team to work together to fill out their sheet while you fill out yours. Then compare what you wrote and what the team wrote.
Start with the areas where it looks like there is agreement between what the Team wants and what you offer. Discuss what that would look like. For example, if the team needs you to be available, drill down to see what that means. “Be available” could mean:
The team wants you within 40 feet of the team room at all times (probably not something you can agree to), or
They want to you respond to their emails within 24 hours, or
They want you to designate another manager they can go to if they need management support. or
A weekly check-in, or
Something else completely different.
Then, work through the areas where you and the team seem to be close on what you need from them.
This is a negotiation so be prepared to look for the needs behind requests and offer options. Once you’ve worked through areas of agreement, look at the requests that seem far apart. Some of them may be answered by the discussions you’ve had so far. For those that still need discussion, prioritize, and then ask “If you had that, what would it do for you?” You may learn something interesting about the team’s work environment and how they view your role.
As with any relationship, you don’t have to say Yes to every request. Nor does the team have to do everything your way. Before you go into the session, be clear in your own mind about the critical things you need from the team to do your job. But be flexible on how to achieve them.
Clarity around Decision-Making
The previous discussion may have already covered some decisions. You may want to document those in this step. Then identify all the decisions that affect the team over the course of a typical quarter. Group stickies that seem similar, so you can see classes of decisions. Some examples of categories shared by many groups are hiring, training, tools, and technical decisions.
Looking at the classes of decisions, 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 the chose option is in place?
If you don’t find a pattern in one of the decision classes, the category may be too broad. Try breaking the category down.
At the end of the activity, you’ll have a matrix that looks something like this:
Don’t try to identify every single decision that team will make. Work to identify areas where the team has autonomy and authority. Delineate where you and the team will work together on a decision, and where the decision rests solely within your role as a manager. Clarity enables the team to act–without fear of crossing an invisible tripwire. It also reduces the likelihood of being blindsided by a decision, for you and team members.
Coherence in Values and Actions
In some organizations, it feels like there’s one set of rules for managers and another for non-managers. This condition fractures relationships and erodes trust. Simple Rules (1) are a tool to bring bring coherence, and reduce the feeling that there’s one set of rule for “us” and one from “them.” Unlike working agreements, which usually address protocols for how to work together in a specific context, Simple Rules guide behavior in many situations across departments and levels in an organization.
Simple Rules reflect values and aspirations about behavior. Start with a warm up, identifying common current patterns of behavior in the organization. Based on observed behavior, test what unspoken Simple Rules might drive that behavior. Ask the groups what patterns are effective, and which they might want to modify or add. Generate rules that would help that pattern emerge.
Here are some Simple Rules from other organizations. Even if these seem like good rules, don’t copy–create your own!
Teach and learn in every interaction. (From a non-profit educational institute.)
Use every failure as an opportunity to learn. (From an organization that wanted to foster more intelligent risk taking.)
Raise the red flag early. (From a group that wanted early warning of problems and potential problems.)
As you develop Simple Rules, consider the patterns of behavior that you want to foster. Simple Rules should be “minimum specifications,” rather than detailed prescriptions for behavior. Keep the list short–five to seven rules. More that that is too many to remember, and acts against the ability to apply judgment, take responsibility, and self-organize.
In spite of the cries of a few pundits (and a few self-organizing teams), teams still need managers. But if you want the advantages of the self-organizing team effect, you have to make space for great things to happen. Sketch out the relationships boundaries, and Simple Rules to set the stage for creative approaches, solutions, and responsibility.
In the early days of agile, some pundits (and developers) cried, “We don’t need no stinking managers.”
By now, most people realize that organizations still need management (and people in management roles) after they adopt agile methods. However, if those organizations want all the benefits of agile, managers must also change the way they work.
Managers can play an even more valuable role in organizations as teams become self-organizing and take on more responsibility. But if managers want teams to take more self-responsibility, they need to shift their focus from monitoring the day-to-day work of individuals and let teams grow up. Here are three common areas of confusing as managers and teams negotiate their new relationships.
Messing with Team Membership
No group is a team the first day they are together. Becoming a team takes time–time to learn how each person fits in and contributes, time to lean how to work together, time to develop group identity and trust.
If you want the benefit of the team effect, provide the enabling conditions:
A clear and compelling goal
Time for the team to gel.
Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.
That doesn’t mean that team membership never changes. People leave (or are asked to leave) and people join. Hiring new people for a team should always be a joint decision, involving team members. And when people are asked to leave it shouldn’t be mysterious to the team why that happened. (For more on hiring as a collaborative process, see this article.)
Delegating then De-delegating Decisions
As a general rule, delegating decision making to the people who are closest to the work is an excellent principle. Doing so can remove bottlenecks, lead to faster decision-making, and improve customer responsiveness.
Except when it doesn’t, as happens when a manager and a team haven’t clarified who makes which decisions. Or when a manager delegates a decision, but doesn’t clarify boundaries or constraints around that decision.
When managers see that a team is about to make a poor decision, they may be tempted to countermand that decision. Countermanding a decision prevents the problems that would have been caused by a faulty decision. But it leads do a different kind of problem–loss of trust between the team and the manager. Team members may feel the manager wasn’t serious about delegating decisions in the first place. They may believe that he only delegates decisions on the condition that the team decides exactly what the manager would choose. Such situations will damage a mangers relationship with the team.
If the team makes a decision that will result in real harm to the company, a manager must intervene. How he intervenes makes a difference. To prevent real harm to the relationship, refrain from blame. Acknowledging that key constraints weren’t clear or communicated will help. Use the opportunity to learn from the mistake, and to set appropriate boundaries for team decisions.
Strategic decisions belong to management. But tactical decisions, course corrections, and decisions that affect day-to-day work belong with the development team. Some decisions fall in between, and require both management and front-line input.
Work with the team to identify which decisions are squarely with the team, which ones you share, and which ones are management decisions. Then set boundaries, about cost, impact, and scope.
For example, when it comes to hiring a new team member, the decision about what skills and qualities to look for in a new team member is probably a joint decision. The choice among candidates is best done as a recommendation from the team (which you may over-ride at your own peril). But the offer and salary are neither a team decision or a joint decision. Employment terms and salary (in most organizations) are management decisions.
Clouding Team Commitments
One of the secrets ingredients for team success is that team members make commitments to each other to complete their goal. Peer pressure can be a wonderful thing. But commitments can lead to conflict, it’s not clear who makes commitments to whom about what.
Fred, a member of an agile team, participated in a planning meeting where he and his teammates committed to deliver six stories during the next iteration. Then Fred when to the team manager, Megan, to get approval for a two week vacation, starting the second week of the next sprint–as he had done every spring for the last four years.
But this time, the result was a mess. The other team members were mad at Fred, for committing his effort to the team, when he knew he wouldn’t be in the office for half the next sprint. The team members were mad at Megan, too, for giving Fred permission when they thought he should have talked to them first. Fred and Megan felt attacked–for doing what they’d always done.
Managers are still point-person for matters of company policy. But work commitment a happen between the team as a whole and their product owner or customer. Megan and Fred landed in the middle of that. In the end, Fred took his vacation. The team needed to renegotiate their commitment to the product owner. Megan attended the meeting to explain what had happened to the product owner.
When Fred (gratefully) returned from two weeks at the cabin with his three kids and the in-laws, they all had a sit down. They talked about which commitments the team could make, what the team could negotiate among themselves and where Megan needed to be involved for legal reasons.
I hear managers say they want teams to take more responsibility. The best way to make that happen is for managers to stop acting in ways that take responsibility away from teams. Start with these three areas. Then, spend some time examining your relationship with the team. What else could the team do that would enhance their autonomy and responsibility? What else are you doing that might confuse the team about how much responsibility they really have?
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.
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.
There are lots of teams in small companies and start-ups who are self-managing and self-directing. They manage themselves, they set product direction, and set company priorities. As organizations get bigger, they hire managers. Managers take those responsibilities, and teams become disempowered. When I visit big, established companies, there’s almost always an assumption that teams need close supervision.
Are the people in start-up teams and big-established company teams essentially different?
Some argue that people who are attracted to start ups are “entrepreneurial” an therefor fundamentally different from people who go to work in larger, established companies. I’m ready to accept that people have different preferences for risk and stability. But, as far as I can tell, most people employed in software companies are adults. Adults enter into contracts, choose mates, raise children, and make all sorts of important decisions. Why do we expect that those very same adults need close supervision when they come to work?
Much of the work in growing self-managing teams is changing assumptions, shifting the dynamic between managers and employees, and undoing years of disempowerment. What doesn’t work (usually) is to declare that teams are empowered and self-managed. That leads to a freak-out on both sides.
Going to Extremes
Sometimes I see teams that reject all direction and go their own way, declaring, “We are self-organizing.”
They are missing an important fact. When someone is paid by a company to be part of a team, that team exists within the organizational context. The team has a customer—someone who desires and will pay for its output (or not, in which case the team should cease to exist). If a team doesn’t have a customer who eagerly awaits its product, that’s a management problem.
On the other hand, some managers hear the word “self-organizing” and believe the team is on its own—that the manager can go into semi-retirement. But that’s not the case, either. In fact, it’s a risky oversimplification.
Shift the Dynamic
Teams and their managers are in a relationship, and every relationship has dynamics–patterns of action that are reinforcing.
One of the dynamics that shows up when managers decide to “empower” teams looks like this:
The manager declares the team is empowered. And he waits for the team to start acting that way and “take some responsibility.” In the meanwhile, the team is wondering wether the manager really means it this time. They may be hesitating because they aren’t sure what these new responsibilities are, or how to do them.
After waiting what feels like a long time, the manager steps in. He either pushes the team, or takes action himself. (The worst ones berate the team for not taking responsibility, just for good[?] measure.)
This confirms what the team feared, that the manager didn’t really mean it when he delegated responsibility to them.
And then the cycle starts again, and each spin through the circle chips away at trust.
Find a Balance
In reality, it’s a delicate balance, and the “right” level of self-management depends on the manager, the team, and the context. As a practical matter, managers who want the benefit of the team effect do need to navigate the balance and move towards self-management–stripping away the layers of disempowerment, growing skills and capabilities in the teams, and building trust on both sides of the manager/team relationship. That’s a different path for every team and manager.
So, here are some of the “depends on” factors that I think about….
Teams can take on management work in these areas:
Managing their own work and monitoring their own progress
Managing team membership
Setting direction within the organization
Managing Work and Monitoring Progress
For agile teams, this includes creating the iteration plan, breaking down the tasks and activities, keeping track of progress. These teams aren’t relieved of the responsibility to report their status to management. They use burndown charts, burn-up charts, and task walls, or kanban boards to make progress and problems visible.
Task management is usually the starting point. For some teams, this is as much self-management as they take on. This may make sense for teams who are together for a very short time. But then I’d ask the question, why is the company forming and dissipating teams this way? It takes time for teams to learn to work together, and if they are broken up before they learn that, the organization doesn’t get the benefit of the team effect.
What about bringing the work to the existing teams, rather than forming a new team every time there’s a new project? There still might be some adjustments to team membership, but there would still be less churn that I see in most organizations.
Managers can help teams take responsibility for managing their own work by refraining from continually asking about progress and from piling on more tasks.
If team members aren’t yet able to plan and monitor their own work, coach them to identify the steps and break tasks down into one- to two-day chunks of work, and then get out of the way. Don’t step in and take over planning. Coach and show rather than do.
Managing Team Membership
Some teams manage their own membership throughout the life of the team. In some companies, management announces the projects, and the developers (the programmers. testers, UI developers) with the relevant skills and understanding of the project form their own teams.
It’s more common, though, for managers to assign people to teams, at least initially (although calling a group of people a team doesn’t actually make them a team). I recommend that managers use a collaborative hiring process for self-organizing teams once they’ve formed. Sticking people onto a team without consulting existing team members is a recipe for ungelling the team. At the core, it’s a power play.
Some teams coach members off the team, too; though they seldom have the authority to handle the contractual aspects of terminating employment.
A colleague told me of how they helped a lone-wolf leave their team. One of the engineers had committed to follow Extreme Programming engineering practices but later violated his agreements with the team. When two team members confronted him, he informed them they’d be lost without him and threatened to find another job. His teammates offered to help him buff up his résumé, and he was gone within a week—no manager involved.
That’s far from a typical case, and don’t count on this happening early in the life of a team, or early in the journey to self-management.
If an employee who is unable or unwilling to work within the team doesn’t leave of his own accord, then the manger needs to step in and deal with the situation from an HR perspective. (See Tale of a Too-Hands-Off Manager.)
Before team members can help someone off their team, they need have the skills to offer and receive peer-to-peer feedback and deal with behavior that disrupts work and relationships.
Many teams reach the point where they can handle a range of disagreements, missed expectations, and frictions. Fewer reach the point of helping someone leave–at least in a healthy and respectful way. Mobbing, shunning, and piling-on don’t count for healthy or respectful.
When there’s a problem that’s getting in the way of the work and working relationships, and the team doesn’t have the skills to handle it, it’s time for management action.
Setting Direction within the Organization
Teams make commitments, but they don’t set product priorities in many companies, especially big ones. The vision and definition of the product comes from the customer or product owner (but, take a look at Know Thy Customer). As a team matures, team members may move towards partnership in co-creating the product. This depends on trust and a collaborative relationship with the customer. This is a relationship that requires high domain knowledge, technical knowledge, and a high level of trust.
Remember, there are plenty of teams, especially in start-ups, where they DO set product direction and priorities.
Every Team is Different
The “right” level of self-management depends on the context. Consider how long the team will stay together. It takes time for a team to learn self-management skills. If the team will only be together for a few months–ask why the organization is creating churn–and realize that it probably doesn’t make sense to train team members to manage team membership or involve them in setting direction within the organization. On the other hand, if team members will have a long life together, it’s likely they’ll be adding team members, so teach them to participate in collaborative hiring. Build towards partnership with the product owner group.
A Mile Too Far
It’s possible to push too much management work onto teams. I talked to a manager in an organization that had expended millions of dollars to train teams to self-organize and self-manage. The division then eliminated all but a few management positions.
But the division wasn’t seeing greater creativity and engagement, as it had hoped. Instead, highly trained technical people were leaving the organization in droves. Alarmed, the remaining managers started exit interviews. They learned that people were leaving for other companies that had traditional, manager-led teams—not because they loved being told what to do, but because they wanted to focus on the technical work that they loved.
In the rush to embrace self-organizing and self-managing teams, top management had loaded too many management tasks onto the teams. Team members were spending less than 50 percent of their time on actual technical work.
(One does wonder if this company collected any data on results. But I don’t know that part of the story.)
The term “self-organizing team” is applied rather loosely in the agile community. I sometimes use that short hand myself. In systems terms, every group is self-organizing within their boundaries and constraints. So calling a team self-organizing is redundant and probably not technically correct.
What gets managers and teams cross-wise is confusing the term self-organizing team with self-managing or self-directed team. All teams are self-organizing, but not all teams are self-managing. And not all self-managing teams are self-directed, or self-goverened.
I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible.
But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand up meeting, his reports were vague. “I’m coding,” he’d say.
After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad.
“What’s up?” Will asked. “Do you need some help?”
“No,” Tad replied. “I’m working on it.”
“But we don’t know what progress you’re making,” Sally said.
“I’m working on it,” Tad replied, staring at the notebook in his lap.
“Tad,” Will implored. “You agreed to report tangible progress every day. We all did.”
Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.”
The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information.
“What exactly are you working on, Tad?” he asked.
“The reset feature,” Tad replied.
“When will you finish it?” the coach asked.
“I’ll be done when I’m done,” Tad replied. “I’m working on it.”
“That’s not good enough,” the coach said, laying down the law. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.”
“I’m working on it,” Tad replied.
The coach tried benching Tad, telling him he couldn’t take any more tasks. Tad took them anyway, working at odd times, checking out code, and keeping a local copy on his machine.
After weeks of Tad’s odd behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us get Tad on track.”
“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”
And that was that.
The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s iteration goals. And as their manager continued with his “hands off” attitude, team members’ morale plummeted. It felt like their manager had abandoned them. He had.
Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the performance issue.
Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own. How do you know when a light touch is called for and when action is needed? Ask:
Does the team have the knowledge to solve this problem?
Does the team have the experience to solve this problem?
Does the team have the will to solve this problem?
Does the team have the courage to solve this problem?
If so, give the team some time to work out the issue. If you sense team members are stuck, coach them with open-ended questions to recognize the resources they already have to address the issue.
Is this a new area of responsibility for the team?
If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost.
What are the consequences of failure?
It’s been said we learn more from failure than from success. So do you really want to deprive the team of a learning opportunity? Consider the consequences of letting the team learn from its mistakes. Most projects can survive a missed iteration goal. Most projects can survive going a short way down the wrong technical path.
This article originally appeared as a sidebar to an article in Better Software magazine.
“….leadership may be defined as:
the ability to enhance the environment
so that everyone is empowered
to contribute creatively
to solving the problem(s).”
Gerald M. Weinberg
I talk to many managers (and some coaches) who bemoan that their teams can’t function without a leader (in this case “leader” usually means someone who set standards, assigns work, and tracks progress, tells people what to do. That’s a leader? What ever.)
It is true that some teams need a leader. Occasionally, I run into a software teams whose members were all recent college graduates. Those teams do need guidance. With a team whose members lack real work experience, it might well be folly to create a team charter and then set the team loose on a project that is the life blood of the company. Oh, wait. That’s how some really big tech companies started–and sometimes they weren’t even graduates yet…or in college. So it depends.
When the team isn’t a collection of juniors and still relies on someone else to give day to day direction, make decisions, assign work and track progress, I suspect something else is at play.
Now, I assume that most members of work teams are not utterly dependent people. They are adults. They make important choices–where to live, when to invest. The enter into financial contracts such as taking out a mortgage. They make short and long term decisions about health and investments. They pay the bills on time. Some have marriages, and raise children.
Navigating life is just as challenging as identifying edge cases for testing, designing a data base or writing an algorithm. So you’d think such people could make decisions at work.
What happens when they get to work that makes them incapable of working without supervision?
Teams exist in relationship to the rest of the organization and their managers. The pattern of behavior on the team is in response to the system, environment and how they have been managed. Without intending to, a manager may create a team acts dependent. It’s a dynamic. Here’s how it works.
A manager–let’s call him Ted–tells a team he wants them to take more responsibility and be more empowered.
This is waaaaay different than the Ted the team has come to know. So the team hesitates.
Ted urges the team to step up, then crosses his arms over his chest and waits. The team hesitates some more. Then the tentatively begin a discussion, all the while looking over their shoulders to see how Ted is reacting (at least metaphorically speaking).
Then one of two things usually happens. In one scenarios, the team comes back with a decisions or takes a course of action that Ted thinks is a bad idea. So he countermands the decision. In the other, Ted, impatient with the time the team is taking to make a decision or act, steps in and tells them what to do.
You can guess what happens next. The team takes Ted at his actions, not his words. They know that he didn’t really want them to be more empowered and responsible. He wants to tell them what to do. In any case, once bitten, twice shy.
The next time Ted tells the team to be empowered (there’s a paradox in telling someone else to be empowered, isn’t there?), the team members sit back and wait. Ted can only take it so long before he steps in again.
And then you have this:
It becomes a self-reinforcing pattern.
The good news about dynamics is that they are not immutable; they can be changed.
There are situations that call for one person to lead. Planning meetings, decision meetings, design sessions, customer conversations, and retrospective all benefit from having a leader—where leader is defined as one who provides a process and guides the group to think, learn, and decide together. Some work requires a supporting actor in addition to the one who takes the lead. And some decisions require knowledge that isn’t spread through the team. Then it makes sense to have one leader. But that doesn’t mean it’s a permanent position—far better for the team in the long run if it isn’t.
Teams need leadership and direction. Direction–the problem the team is chartered to solve, comes from management. But leadership comes from within and from all.
I’m a big believer in 1:1 meetings on manager-led teams. It’s a way to connect with people, stay in touch with progress, learn about problems early, coach, work on career goals, offer feedback.
But if you are the manager for a self-organizing team, you need to adjust the way you do 1:1 meetings.
First, unless you are coaching someone on task accomplishment, do not ask about progress and status of tasks. On self-organizing teams, team members organize the work and make commitments to each other. If you as a manager insert yourself into this, you are communicating the the commitment is still to you, not to other team members. If you want to know about task progress, walk into the team room and look at the task wall or burn down chart.
You will probably have less visibility into the day-to-day workings of the team and team members. That means you are less likely to have useful feedback to offer on a regular basis. Ideally, much of the feedback on a team should be peer-to-peer. You need to get involved when the team has tried (using effective feedback techniques, not hints, not vague general statements), there hasn’t been a change, and the behavior is impeding the team. Getting in the middle of a feedback between team members when you don’t need to only creates problems and erodes trust on the team. When someone comes to you hoping you’ll carry a message for them, coach them on how to offer effective feedback, so the situation gets handled where it lives, between the team members.
Don’t meet every week, unless you are coaching on a specific issue (that you are qualified to coach on), or unless there’s a “get well plan” that you need to manage. You do need to stay connected to people; there are lots of informal ways to do this with out meeting every week. Meeting every week sends the message that you still want people to look to you for answers, help, and guidance. You may want that, but consider the effect on the team and their growth and capability.
You may still have a role in approving vacation (work on changing that, since it implies that the company doesn’t trust people very much). Keep that to a formal sign-off role. The first negotiation needs to be with in the team. I talked to a manager who approved a vacation request right after a team had committed to work for an iteration. (Who knows why the person didn’t mention it to the team, but he didn’t. That’s a separate problem.) The manager approved the vacation, then asked the team to cover the guy’s commitments while he was sunning himself on the beach. The team rightly refused, and insisted on renegotiated with the product manager to reflect the fact that they weren’t going to be able to accomplish as much with one team member gone for the entire iteration. The manager realized much later that he’d set the team back in mutual trust and accountability by not sending the guy back to work it out with the team.
Work on professional development, but remember that the team member you are mentoring needs to negotiate tasks and roles with the team. For example, if someone wants to learn more about project management, you don’t get to say “start managing the iteration as a project.” That breaks down the work the team has done to organize their work and erodes shared commitment.
Ask about impediments and blocks outside the team, those that need management action to fix. You can’t fix everything, but you can investigate, look for patterns of blocks mentioned by multiple team members. You can create an impediment backlog and post your burndown to the team.
Ask about HR concerns. For many agile teams, traditional job descriptions, career paths, and other personnel systems don’t fit agile work very well, so you want to know when there’s dissatisfaction and understand when and how policies are getting in the way of teamwork and team work.
Your job with a self-organizing team is to establish conditions for success, make sure the team has appropriate resources and appropriate boundaries, to remove impediments and improve the work system. It’s not to give task direction and hold individuals to account (except as noted above) . The team is responsible for organizing their work, tracking progress, and communicating to you when there’s a problem. You job is not to inflict help–that keeps the team from learning, and keeps them dependent on their manager.
Hierarchy acts as an amplifier, and manager’s actions are always under scrutiny. If you want the team to self-organize and reach their potential, don’t send them a confusing message that they still need to turn to you for day-to-day task guidance, status reporting, and problem-solving.
Self-organizing teams don’t just organize the technical work. They make technical (and non-technical) decisions. Not every situation requires facilitation, but when a team faces an important decision, applying facilitation skills to the problem saves time and yields better results.
Jason was frustrated. The Release 6.0 team had been chewing on a major design decision for two weeks. Jason knew they had to make a decision or they’d run out of time to pursue any option. Jason pulled the five other team members together and told them they weren’t leaving the room without a decision.
Jason started restating the option that Sara had put forward last week.
“I don’t see how that’s going to work,” Josh said.
“Well, I don’t hear you coming up with any better ideas,” said Sara.
“We could go back to the idea Alan suggested last week,” offered Jen.
“Look, we’ve been going back and forth between two ideas, and we’re no closer to a decision now than we were two weeks ago.” Jason sighed and looked around at the rest of the team members seated at the conference table. “You guys got any other ideas?”
Alan and Keith shook their heads. Jen shrugged.
“Fine. We’ll go with Sara’s idea,” Jason said. “We need to move forward or we’ll miss the market window for Release 6.0 completely.”
The Release 6.0 team filed out of the conference room. None of them really liked the idea—not even Sara. But after two weeks of rehashing two competing ideas, the team was tired of talking.
Like the Release 6.0 team, many groups struggle with decisions. Some groups pounce on the first plausible idea only to find out later that they’re down a rat hole. Other groups discuss and argue endlessly and never reach a decision. Still others choose by default or let the loudest voice decide.
In order to make timely decisions that the group can support, teams need to be able to:
Narrow the number of options
When I see teams who argue endlessly, can’t decide, or pick an option no one supports, one (or more) of these elements is missing.
There are dozens of techniques and methods that can help teams reach decisions. Here are three that will help with decisions that require broad support and buy-in. I’ve chosen these methods because I’ve seen teams use them successfully without extensive facilitation skills or a great deal of practice.
There’s no shortage of good ideas in the world. But sometimes, when people are under pressure, ideas are elusive. Many teams generate one or two alternatives and then stop. That’s not enough. Teams need at least three alternatives to have a real choice. Plus, thinking of three alternatives helps the group explore the problem.
Consider using a combination of brain writing and affinity clustering to generate many ideas in a short period of time. Pairing these two techniques allows the group to integrate ideas and find common threads. Traditional brainstorming results in a laundry list of ideas and favors the people who are most vocal. This technique includes individual work, so people who need a bit of quiet time to think can participate fully.
Here’s how it works:
Write down the problem the group is trying to solve in the form of a question and post it where everyone can see. This question will help the group focus their thinking. Here are some examples from groups I’ve worked with.
“What are the risks of implementing the foo feature without backward compatibility?”
“What are ways that we can increase throughput in the amortization function?”
“How can we effectively test the risk areas of the product with our current hardware resources?”
“What are practical ways we can improve communication on the team?”
“What are the most important values we hold as a team?”
Allow 5-10 minutes for individuals to write down their own ideas. Ask for at least ten ideas. When the time is up, form groups of three or four to share individual lists. Have the small groups identify the best ideas and write them on sticky notes. There are bound to be duplicates between groups, but don’t worry—duplicates show where there is common ground.
Using a wall or a whiteboard, post the ideas and cluster them into affinity groups. Don’t start with a set of categories; allow the categories to emerge from the ideas. As people move the ideas into affinity groups, they’ll talk about how ideas are related, which are distinct, and how they fit together. These conversations help the team learn about each other’s ideas. When the affinity clusters are settled, name each cluster. The name represents the group’s agreement on the underlying ideas in each cluster.
Brainstorming and clustering will generate 5-7 alternatives in about 30-40 minutes. Sometimes the alternatives warrant further development before the team evaluates them. Organize small working teams to flesh out just enough detail to permit an assessment.
When I see a team stuck evaluating alternatives, it’s usually for one of two reasons: 1) People don’t have a common definition of the options under discussion, or 2) the group is talking about all the options at the same time.
To ensure that everyone is working from the same definition, write the key points of each alternative on a flip chart and post it where everyone can see it during the evaluation step. Review each alternative and clarify as needed before starting the evaluation.
Overcoming the second problem takes some discipline: Evaluate each option on its own before comparing options to each other.
You can do this by drawing two lines on a piece of flip-chart paper, creating three columns. List the “plusses” and “minuses” of the options in the first two columns. Make a note of what’s interesting about the option in the third column. Answer all three questions for one alternative before moving on to the next.
After the group has completed this activity for all the options, it’s usually obvious that some of the ideas are unsuitable.
Agreeing on an Option
An individual making a decision may agonize over it, but when more than one person is involved, it can turn into an argument. Teams need a way to test their agreement, discuss concerns, and arrive at a decision that all can support.
The Romans indicated their will in the gladiator’s arena with a thumbs up or a thumbs down. A modern modification of Roman voting helps teams arrive at a decision.
Thumbs up = “I support this proposal.”
Thumbs sideways = “I’ll go along with the will of the group.”
Thumbs down = “I do not support this proposal and wish to speak.”
If all thumbs are down, eliminate the option. On a mixed vote, listen to what the thumbs-down people have to say, and re-check agreement. Be cautious about choosing an option if the majority are thumbs sideways: This option has only lukewarm support.
This technique generates consensus. Consensus doesn’t necessarily mean complete unanimity. Consensus means that everyone must be willing to support the idea, even if it’s not his personal first choice.
Sooner or later, you’ll have a situation where one person withholds support for any option. Manage this situation before it happens. At the start of the consensus process, set a time limit:
“We’ll work really hard to reach consensus until the end of this meeting. If we don’t have agreement by that time, we will
turn the decision over to _________, or
take a vote, or
__________ (a technical expert, coach, manager) will decide.”
Most people don’t hold out to be obstinate; they are responding to a deeply held value or belief. Often the lone holdout will move on, but not at the cost of relinquishing an important belief. Respect the belief, use your fallback decision-making method, and move forward. However, when a group seldom reaches consensus, but instead relies on voting or deferring to authority, it’s a sign there are deeper issues at play.
Putting the Techniques to Work
When the Release 6.0 team held their project retrospective, the team identified decision-making as an area they wanted to improve. Of course, not every decision requires a formal process; but when important decisions come along, the team saves time and energy by applying techniques like the ones I’ve described.
If you notice your teams are stuck in one (or more) of the three decision areas, point out what you’re observing. Ask the team if they are willing to try something different to help reach a decision. Then hand them a copy of this article and try the appropriate technique. Teams who learn to self-facilitate spend less time churning and more time on the business of the business.
Adapted from the Technology of Participation methods, The Institute of Cultural Affairs www.ica-usa.org
Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.
One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.
Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to “rescue” the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team’s development.
Absentee Managers throw up their hands and say “you figure it out,” no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.
Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.
Here are three guidelines to help managers gauge their actions with self-organizing teams.
#1. If the team has the skills to solve the problem–or they are on the verge of having the skills–give them space to solve the problem. If they’re stuck or don’t see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it’s not a management problem. Then it’s managements job to fix it.)
#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it’s knees? (If the answer is yes, you’ve got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won’t actually apply sufficient effort unless they believe the issue is urgent. Again, that’s a bigger problem. OTOH, if there’s information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there’s a very simple solution that the team is overlooking, ask questions to help them discover it.
#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there’s a good chance they’ll get it wrong the first time. If the solution space isn’t bounded, then there’s something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there’s appropriate fiscal and management oversight.
There’s always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-led teams….but only if the managers are willing to navigate the balance.
Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.
But there’s still plenty of work for managers to do. It just doesn’t involve task management and having all the answers.