We say agile teams are self-organizing. But how far does that go? Should team members have the right to vote someone off the team?
Since the debut of the Survivor television show back in 1997, this is often referred to by asking if a team has the right to vote someone off the island.
Back to Agile’s Origins
Scrum was the first agile approach used in software development. I first learned about it in 1990 from the book Wicked Problems, Righteous Solutions by Peter DeGrace and Leslie Stahl. Their book described a multitude of approaches to the challenges of software development. Their description of Scrum was based on the initial paper on Scrum, The New, New Product Development Game, which appeared in the Harvard Business Review in its January-February issue of 1986.
I often return to this book and article to see what the initial thinking was.
Each of these sources is very clear that team composition is a management responsibility. Hirotaka Takeuchi and Ikujiro Nonaka in their Harvard Business Review article write that “although project teams are largely on their own, they are not uncontrolled.” They then outline seven forms of “subtle control” that are exerted on teams, but always for the good of the product.
One form of subtle control they recommend management retain is control over who is on the team. They cite an executive at Honda who said, “We carefully pick the project members after long deliberation. We analyze the different personalities to see if they would get along. Most people do get along, thanks to our common set of values.”
Hackman’s Four Levels of Team Authority
Takeuchi and Nonaka’s original article on Scrum was published 35 years ago. Is their view on subtle control still appropriate?
To answer that, I think it’s useful to look at the four levels of authority that teams can have as defined by Harvard professor Richard Hackman. He categorized teams into the following categories:
Manager-Led Teams
A manager-led team has authority over the execution of a task. Basically, this type of team is told “do it this way,” and they do.
Self-Managing / Self-Organizing
Hackman used the term self-managing but it’s analogous to what are more commonly called self-organizing teams in the agile space. This type of team has authority over their process. In effect, someone outside the team gives the team a goal and how they achieve it is up to them.
Self-Designing
A self-designing team has all the authority of a self-organizing team but also has authority over who is on the team.
Self-Governing
In addition to all the authority of the team types already listed, a self-governing team has authority over its goal. That is, a self-governing team can decide what its members will develop. Normally there would be some expectation that a self-governing team chooses something in line with the corporate mission or vision. A self-governing team inside Oracle, for example, would probably not have the authority to decide instead to focus on growing organic avocados.
Is Subtle Control Still Appropriate?
Using Hackman’s hierarchy, it’s clear a self-designing team has authority over team membership. I find these teams are still rare in the corporate world of today. They exist, but aren’t yet common.
Will they become common? I think we’re headed in that direction, but moving to a world in which self-designing teams are common will likely be challenging. The careers of many of today’s managers have overlapped the growth in self-organizing teams. A further mindset shift will be hard. Just as the growth in popularity of self-organizing teams has taken decades, it may take nearly as long for self-designing to become the norm.
And, there’s some doubt about whether self-designing teams are even something to strive for. In his book, When, Daniel Pink says a high-performing team “requires a boss—someone or something above and apart from the group itself to set the pace, maintain the standards, and focus the collective mind.”
Some Advice
I love the idea of moving toward self-designing teams. Who better, it’s easy to reason, to determine who should be on a team than its current members?
Except that’s unlikely to be true for all teams. Some teams may opt for homogeneity rather than diversity. Such a team may opt to hire developers who all think alike or with similar technical backgrounds. And this is to say nothing of racial, gender or cultural diversity.
Other teams may seek to hire new team members who are a little less skilled than they are. By doing so, current team members reason, they look better to their bosses.
Problems such as these arise from teams not always wanting what’s best for the overall organization. This happens when there is a lack of alignment between organizational goals and individual compensation.
It’s fixable. But can managers always expect team members to choose someone who is 1% better for the project over someone who is 1% more pleasant to work with?
Incremental Steps Toward Self Designing
It’s very possible to take incremental steps toward self-designing teams. For example, a team can be given authority over a budget to bring on contractors while not being given authority to hire and fire company employees.
This is what I tend to do rather than give a team full authority over hiring and firing. They can bring on contractors within an allocated budget. But they cannot hire or fire employees.
I find that this strikes a good balance and is a step toward more complete self design. It also fits better with policies or preferences from human resources or personnel departments. In today’s litigious world, additional oversight on hiring and firing could well be worth it.
You Have Four Weeks: Another Step Closer
Years ago I experimented with another small step toward self-designing teams that worked well. The idea came out of having to fire a programmer on one of our teams for bad performance. After I let him go, one of the other programmers made a fairly offhand comment to me that, “I’m so glad you got right of him. I thought we were going to be stuck with him forever.”
This comment told me that by the time a manager realizes an employee needs to be let go, the team has been painfully aware of that for weeks or perhaps months. I wasn’t close enough to see the need to let this programmer go as quickly as those who worked with him all day, every day.
Then once I was aware, I didn’t act instantly because firing someone is not pleasant. I’ve had to do it enough over the years that I’m OK doing it. But, it’s still not fun, and I hope it never will be. So I stalled a couple of weeks before bringing the situation to the attention of our human resources director. She had me put the programmer on a one-month performance improvement program to give him a chance to do better.
No wonder another team member said, “I thought we were going to be stuck with him forever.”
What this taught me was that by the time a manager becomes aware of a performance problem, the team has likely known it for weeks or months.
And so we put in place a policy that a team could vote someone off the team. It had to be a unanimous agreement among the other team members. When someone was voted off a team, I (as the VP of Software Development) met with the person and explained the situation.
I then gave the person four weeks (two two-week sprints in that organization) to find a new team. That person would essentially walk around to other teams saying, “Do you want my help? I’m a free resource? Anyone need help?”
Teams might try the person with a time-limited assignment that helped within the current sprint. Other teams would take a person on either happily or for a one-sprint experiment.
If by the end of the four weeks, the person had not found a new team willing to accept a new team member, that told me a lot about the person. Clearly the person was not valued by other teams. In some cases, the person was technically excellent but came with other baggage, such as being too negative, and teams would pass.
After four weeks, if someone had not found a new team, I moved them to report directly to me. I also initiated a performance improvement plan by working with human resources.
Most people I moved to work directly under me were ultimately let go. That’s a shame. But it was the right thing to do.
Fortunately, however, very few people got to that point. Most did find another team who did welcome their contributions. Sometimes a person who is a bad fit with one team can be a great fit with another team.
And, again, who better to know that than the teams themselves.
By working this way, we gained many of the benefits of having self-designing teams. But managers in the organization retained the “subtle control” we felt was necessary on rare occasions, such as when a team had become too homogeneous.
The world does seem to be heading toward self-designing teams. (And even very probably self-governing teams.) Taking steps, even partial ones, in that direction could very well be a good move for your team and your organization.
