agile – How to manage the team effectively on a self-managing team?

I first created truly “self-directed” teams in 1995, teams with no team leader or manager involved in daily operations. Now I operate Full Scale agile (yes, lower-case “a”), and I had an earlier consulting practice on teamwork development based on scientific research. Your question has literally filled books, including one I wrote (but now incorporate into my websites)!

In general, I believe Scrum organizations misunderstand the psychology of teams. If a team has a full-time organizer, they are not “self-organizing!” When someone has a degree of assigned hierarchy–as a full-time Scrum Master does–team members’ brains are hard-wired to give some deference to that person and filter their opinions. And the designated leader is hard-wired to expect that to some degree.

Hence I train teams to rotate the Facilitator role (my preferred term). Or if the client already has designated SMs, I train them to manage at least three, and preferably four teams at once. Otherwise, an ethical Facilitator is almost certain to do things he/she/they should not be doing for the team to be fully empowered, because the Facilitator is trying to justify their pay.

There’s a lot more to the process of converting to a truly self-organizing team. It takes time and effort, but there is plenty of evidence dating back decades that it pays off in the long run. My full approach is here (free and open source): Self-Directed Agile.

Even if you don’t go to full self-direction, you can hand off many of the administrative decisions, from hiring through performance appraisals (the linked section has a checklist). Then the manager can become a servant leader focused on coaching instead of controlling; making sure team members have what they need, including information, instead of telling them what they can have; persuasion instead of commanding; listening instead of telling; and so on.

Feel free to tag me if you have questions.

Edits to answer comment questions:

First, be aware that self-directed teams that handle their own hiring, performance appraisals, etc., have existed for more than 70 years, with evidence they are more effective if properly formed. You can disagree with doing it with your teams, but they are historical facts!

HBR articles are not always based on research. That said, you’re right, daily actions by a manager do have value. But two major reviews of the literature on teams (cited below) showed that a manager’s biggest impact within a team or project lifecycle is at four points:

  • Pre-start (how the team is selected and formed),
  • Start (how the team is organized),
  • Mid-point (when there tends to be a readjustment of practices), and
  • End (learning lessons and preparing for the next project).

The daily actions should center on the types of I mentioned before (“coaching instead of controlling,” etc.). The literature on “servant leadership” can tell you more about that.

As for Scrum, I have found it to be an extremely effective method for improving measurable team performance if implemented as a shortcut instead of a permanent solution–like any specific management practice. All of the complaints I see/hear about Scrum come from four root causes: false adoption (using Scrum words without really changing, like replacing a team leader with a full-time Scrum Master); incomplete adoption (you have to learn how the pieces fit together before dropping any); inappropriate application (for example, using Scrum where Kanban is more appropriate); and refusal to allow adaptation after it is mastered.

Additions for subsequent comments:

All of your objections indicate failures at those Pre-start and Start phases (by your employer, not you personally!). For example, the teams should be cross-functional–business people and tech people on the same team. You have to do Scrum (or any other formal method) as described before changing it, to fully understand the impact of those later changes. A great team cannot be created without breaking many of the common rules by which teams are structured (per the Self-Directed Agile section I linked above). And so on. In short, your objections are based on poor team structure or teamwork implementation. All of the concepts I have presented are backed by decades of research and successful practice in the real world.

Sources: Kozlowski, S., and D. Ilgen (2006), “Enhancing the Effectiveness of Work Groups and Teams,” Psychological Science in the Public Interest 7(3):77.; Hackman, R., and N. Katz (2010), “Group Behavior and Performance,” in Fiske, S., D. Gilbert, and G. Lindzey (eds.), Handbook of Social Psychology (195th ed.), Wiley: New York.