Category Archives: Blog

ScrumMasters and Agile Coaches: More than a Title

As I said in an earlier column, it’s not enough to slap the tile of Scrum Master or Agile Coach on a project manager, manager, or whatever other warm body happens by.  It’s also not enough to look for the keywords “CSM” or “coach” on a resume.

If you are serious about helping teams learn and thrive as self-organizing Agile teams, get serious about ScrumMasters and Agile Coaches. Start thinking about the work, the role, and the job–not just the job title.

Here’s my initial take on a job analysis of the role (using the job analysis template from Johanna Rothman‘s very useful book, Hiring the Best.)

First, I considered the qualities, preferences, and skills. Second, I thought about the sort of knowledge and understanding that’s essential for the role.  Then, I thought about elimination factors, patterns of thought and behavior that would eliminate a candidate from consideration.  Of course, you can’t just ask yes/no questions for any of the characteristics on this table. You have to do behavioral interview questions and auditions (see Hiring the Best if you need a refresher on interviewing and auditioning candidates).

QualityR/DPreferenceR/DSkillR/DDemonstrated UnderstandingR/DElimination Factors
InitiativeRWorking in a team environmentRTeam coachingRAgile values, principles, methods, practicesRDirective
FlexibilityRFinds satisfaction in helping others succeed.RFacilitationRTeam and group dynamicsRDefensive
OptimismRAgile practicesRWorking thru influenceDJudgmental
ResilienceRAbility to explain the "why" behind agile practicesRLow threshold for frustration
DeterminationRInterpersonal skillsR
DiscernmentRTeam dynamicsD
SupportiveRSystem thinkingD

R = Required, D = Desirable

After I had a handle on the skills, qualities, and characteristics, I considered the interactions, activities, and deliverables for the job. I summarized it all here:

Who interacts with this person?Team members
Product owner
Manager(s) associated with team members
Other coaches
Primary roleCoach
Secondary roleFacilitator
Secondary roleIntegration with other agile teams
Secondary roleOrganizational change agent
Management componentManage his/her own impediment backlog
Job grade level (consider pay and message to the organization)For purposes of pay level, look at interactions and scope.
ActivitiesCoach one or more teams.
Ensure team enabling conditions are in place.
Create or advocate for those conditions if they are not in place.
Facilitate team meetings (e.g., sprint planning, sprint demo, retrospectives, decision making meetings, etc.)
Ensure that information radiators are up to date.
Develop additional team radiators to address issues unique to the team.
Advocate for the team (e.g., block unnecessary meddling)
Help the team see their own process and improve their processes.
Coach on agile practices
Guide the team in adapting process to fit the local reality w/o losing the intent.
Coach on interpersonal and collaboration skills.
Coach on technical practices
Identify impediments
Use influence skills to remove impediments
Transfer knowledge and skills to team members so the team becomes more self-sufficient.
Up-to-date team radars
Impediment backlog
Knowledge transfer
Essential Qualities and PreferencesInitiative, flexibility, optimism, determination, resilience
Working in a team environment, supportive, not cowed by authority
Desirable Qualities and PreferencesDetachment, discernment
Able to navigate conflict
Essential non-technical skillsCoaching, interpersonal skills, Agile practices
Desirable non-technical skillsFacilitation, influence
Essential technical skillsDepends on which team the coach will work with
Desirable technical skillsDepends on which team the coach will work with
Minimum education
Minimum experienceOne year coaching a team. Two years working with an agile team
Demonstrated understanding of:Coaching
Agile values, principles, methods, practices
Team and group dynamics
Working through influence
Cultural fit factorsThis is in some ways a cultural change role. The candidate must fit the desired cultural pattern, but not be so far from the current culture that he's rejected.
Elimination factorsPreference for directing others, defensiveness, judgmental attitude, low threshold for frustration

Of course, what you look for in an agile coach or Scrum Master will be somewhat different. Each team has different needs for coaching. A given team may need more (or less) help with specific engineering practices. Another team may need more help with retrospectives or planning. The key is to think of this like any other job. ScrumMaster or Agile coach are not a plug-and-play roles. You need to look for fit–with your culture and with the needs of the team.

Readings for Managers: Motivation

I’ve been having conversations lately with people about compensation and reward systems, and the role that money plays in motivation.

All the research I’ve seen concludes that–for most people–money becomes the primary motivator at work when there are no other salient motivators. What might those other motivators be? Sense of purpose, pride in work, belief in the mission of the company, to name a few.

But many managers assume that money is what motivates people (though they themselves are motivated by more lofty goals). Not so. Most people start new jobs highly motivated. They want to do well. But the organizational road blocks (some of which are thrown up by well-intentioned managers) sap that motivation. As managers, we need to let go of motivation myths, understand what really motivates people, and then stop doing things that demotivate them.

A few key readings on motivation:

Teresa Amabile and Steven Kramer: Do Happier People Work Harder? (may require registration)

Katzenbach and Khan: Money is Not the Best Motivator.

Dan Pink on motivation, in pictures, Drive, (or in print.)

You may also find Pfeffer and Sutton’s book Hard Facts interesting. (Probably my favorite business book.)






Peck, peck, peck

A participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n.  Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.

This is not the first time I have heard this assertion.

It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.

This assertion rests on tired analogies from sports or the animal kingdom.

I’m not buying it.

Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches.  Groups of people developing software are people in goal oriented social units–often in teams.

Sometimes, on some teams, it appears that there is one person who is obviously the star. Maybe.

In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?

Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.

Then there are the people whose manager declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers  view them no more than average,  brown-nosers or a hindrance.

I observed a team where one person was viewed as the star by many managers.  To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing  until people caved in because it wasn’t worth the fight.

Rarely, there are people who are real standouts.  But not on every team.

What about the people at the bottom? What is the basis of the assessment?  Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at  synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.

And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?

What if people are measurably different on some dimension?  Software is a collaborative endeavor. What matters is how well the team is doing.  Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.

As a manager, don’t waste your time trying to figure out the pecking order.  Do everything you can to help the team, as a goal oriented social unit, perform to its full capability.  Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit your thinking about rewards to money).  Treat the people whose performance is obviously below par as exceptions, too.  Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company).  It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the team.

Why not velocity as an agile metric?

In response to my recent post on Agile Metrics, a reader asked, “Why did you leave out Velocity?”

Even though it’s not perfect, velocity is the best way we have to understand the capacity of teams. It’s the best way we have to bring some reality to planning for releases.  Watching velocity over time and looking at patterns in burn downs can alert coaches and managers that something is going on, and they need to investigate.

Velocity is important. But as a metric for gauging how your agile adoption is going, it’s opens a door to danger.

Here’s why.

Velocity is easy to manipulate.  Want velocity to go up?  Fudge the definition of done and you finish more stories.  Change the scale and complete more points (what once was a 2 point story is now a 5 point story).

Velocity is easy to misuse.  Managers who don’t see organizations as systems can use it to compare teams or punish teams. Neither of which is helpful.

Velocity—as an agile adoption metric—puts the focus in the wrong place. Focus on velocity implies that if velocity isn’t improving there is something wrong with the team. In some cases, that might be true. But I don’t want people to look by default. When velocity isn’t improving or is erratic, it’s often due to factors that aren’t in the team’s direct control.  There might be a problem with the way the work is flowing into the team. Or the team maybe interrupted every hour with production support calls (or what ever). Or the team may not have the tools they need to do their work.  That’s something for the team and team coach to work on or raise up as an impediment (where mangers can work on it at the system level).

For assessing the progress of an agile adoption, I choose metrics that emphasize system performance to help managers make the shift from “work harder” thinking to “optimize the whole system” thinking. Managers after all, are responsible for creating the environment (structures, policies) and enabling conditions for teams be successful. To do that, they need a way to asses how the system is functioning.  Because I presume that the point isn’t being “agile” but delivering valuable software.

For more about using velocity as a measure, see my post Working Hard or Hardly Working.

Metrics for Agile

“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.

Real Coaches or Hierarchical Control in Coaches Clothing

I recently met with a group of managers who work in organizations adopting agile methods. Several of them asked whether functional managers should become ScrumMasters or coaches.

That’s a risky road.

One manager was adamant. In his view, making managers ScrumMasters was the best course of action. According to this fellow, managers already know people’s strengths and weaknesses. They know the domain, and the organization. So, he reasoned, the managers are already equipped to tell people what to do.

Errr. Not so much.  Coaches and Scrum Masters rarely tell people what to do. Usually, they work by different means–modeling, coaching, teaching.

But it begs the question, can a manager be an agile coach or ScrumMaster?

Here’s what I look for in an agile coach/ ScrumMaster.

Experience. If your company has used serial life cycles or ad hoc methods changing to agile methods is not a trivial matter. Nor is it simply a matter of adopting a few engineering practices or using time boxes.  Succeeding with agile does require engineering practices and time boxes. But the real change happens between peoples ears. It’s a shift in thinking–and not just by the development team. Some people change the way they work by changing their thinking. But many more change their thinking by changing the way they work.  Book learning and training is good, and it’s no substitute for experience in the agile way of working.

A deep understanding of agile practices and methods. Coaches need to know the why and when, as well as the how. They need to understand how practices fit together, the intent behind practices. People do need to adapt methods to local conditions.  Without understanding, adaptation is risky. I’ve seen teams and companies “adapt” themselves right back into the situation they were trying to fix because they didn’t fully understand the “why” behind some agile practices. An agile coach needs to be able to think through what adjustments maintain the essence of a practice, and which adaptations sustain the current pattern.

Coaching skills.  Seems obvious. An agile coach should know something about coaching. That means helping people learn skills through practice and feedback. It means helping people think through issues and see new alternatives.  It may mean providing answers, facilitating, or acting as a mirror. If often means helping people think about the way they are thinking, and helping teams get unstuck.  (It does not necessarily include “life coaching.”)

Coaching is tricky when a person also has the responsibility to rate and rank individuals. Coaching requires openness and trust. When people fear that revealing lack of knowledge or skill will show up on their annual review, they are less likely to ask for help. I know of several companies where managers are now “coaches” (and managers). Its confusing for the team members.  They don’t know who they are talking to–the person who helps, or the the one who will hand out a rating at year end.

Understanding of teams and team dynamics. Another skill that would seem obvious, but is often overlooked. When the job is coaching a team, the coach needs to understand something about how people behave in goal-oriented social units. He needs to know the foundations and enabling conditions that allow teams to form and thrive. He needs to recognize when problems are related to the design of the team, when they are system patterns, and when there are individual problems.

Interpersonal and collaboration skills. Coaching is about enabling other people to be more effective. The zeroth step is to make contact with people. If a coach cannot do that, he won’t be able to build relationships and trust. I do sometimes meet coaches who are all about “me.” Doesn’t work. Coaches need to be able to work with others, share credit, and let others shine.

Influence and organizational smarts.  It is silly (or worse) to expect a ScrumMaster to remove significant organizational impediments and drive organizational change–even though that’s often the hype. Coaches need to be savvy about the organization and to have influencing skills, so they can help managers understand the costs of impediments.

If you want empowered teams, you need to change the dynamic between managers and teams.  Slapping a new tittle on a manager (or project manager) will not change the dynamic unless the manager’s mindset and actions also change.

Of course, some managers do have all the qualities and skills to make the transition.  And some teams have the gumption to call out their former managers when they slip back into command and control thinking or acting.  Even when the mangers is willing and capable of changing the way he interacts with a team, it will take time for the new pattern of interaction to take hold.

But for many companies, calling managers “coaches” or “ScrumMasters” is really hierarchical control in coaches clothing.

Organizations still need managers.  Call them managers, and have them do management work–improving the organizational system and translating strategy into action. And get a coach to be the coach.

Essential Readings for Managers I: Pay & Evaluation

I used to make my living writing code.  I was good at it. I was really good at figuring out the problem when the symptom and causes weren’t close together. So they promoted me to manager.

As a new manager, I was sent to a two-day Basic Management Orientation, where they taught me to how to fill out staff requisition forms in quadruplicate, who got the goldenrod copy, the blue copy, the pink copy and the white copy.

I think I could have figured out how to fill out the form on my own. I suspect that was all they knew how to teach, so that was what they taught. But it wasn’t what I needed to know. I suspect there are many managers in technical organizations who have similar stories.

I set out to learn about working with people and managing in a large organization. I sought mentors with in my organization. Many of the managers had never worked any place else or had only  worked for one other company. They knew a lot about “how we do things here,” and how to work within the system. They didn’t know how to work on the system. And most of them didn’t question the system.

My best teachers were from outside the company–professors in my Masters program, Jerry Weinberg and other folks I met through him. Those people got me thinking, learning, and seeing the system.

So in the interest of helping managers learn how to see and work on the system, I am starting an occasional series on research, references, and resources on management topics. For now, I’ll focus on practices that go unquestioned, but aren’t supported by evidence. I’ll share sources and authors that have shaped my thinking about management, organizations, and teams.

I’ll start some myths about pay and performance. The dominate model in the US is differential pay based on rating or ranking. It’s so pervasive, that many don’t even think to question it.  But as Jeffrey Pfeffer says,”diffusion and persistence don’t provide proof of effectiveness.”

Jeffrey Pfeffer: Six Dangerous Myths about Pay (terrible copy, but free).

Jeffrey Pfeffer:  Congressional Testimony on pay-for-performance systems.

If you are interested (and as a manager, you should be) in the effects of annual performance reviews, click “annual reviews” in the tag cloud.

If you are in middle management, you may think you can’t change HR policy. But if you band together with other managers and document the negative effects on productivity and the ability to meet the organizations goals, you might just get some traction.




Solving Symptoms

Recently, I attended two retrospectives.  Different teams, different states, different facilitators. I’m usually on the other side, leading retrospectives.

Both retrospectives followed the “make lists” pattern.  One made two lists  “What worked well” and “What didn’t work well.”  The other made three lists “What worked well,” “What didn’t work well,” & “Issues or questions.”

Once the lists were complete, participants voted on which issues to address and broke into small groups. These groups were called “problem-solving” groups. They were really “symptom-solving” groups.

There may be some agile coaches out there who guide the team to find patterns and underlying causes from these lists. Too often, that doesn’t happen, and the discussion never goes beyond solving symptoms. Too many people teaching Scrum or Agile short-change retrospectives–teaching new ScrumMasters and coaches to make lists, rather than help the team think, learn, and decide together.

Two lists,  three lists–even four lists–are not sufficient. Lists focus on syptoms, as seen from individual points of view. These lists do not build shared understanding. They do not reveal underlying causes, patterns, or structures that influence behavior.

When teams “solve” sypmptons, the problems come back, or the team piles on layers of rules and processes designed to change behavior (I visited one team that had over 20 working agreements–almost all aimed at the symptom level).

It is not surprising to me that teams who do this sort of retro usually find them less than useful.

I’m not saying you have to do retrospectives the way I do them. But please, design and lead your retrospectives to dig beneath the surface, analyze, search beyond symptoms. Otherwise, you are wasting your time.

Empowering Leadership II

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.

Misconceptions about Self-Organizing Teams

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.