A team with a full-time organizer is not “self-organizing!”
My path from technical writer to Agile Coach started at Los Alamos National 
Laboratory 25 years ago. A new project was framed as a rewrite of a manual. But it became clear this required getting four groups on the same page—pun intended—within and across groups, and with U.S. Department of Energy auditors. Those last were threatening the 12,000-person Lab’s ability to make purchases, because of poor equipment management practices.
The concept of “self-directed work teams” (SDWTs) was getting another round of publicity. SDWTs are work groups without a leader involved in daily operations. Some people thought it a fad, but it was already an evidence-supported tool dating back at least to the 1950s. I attended a class and gained permission from Lab managers to turn the groups into SDWTs. Members learned how to rotate the meeting facilitator role; set and enforce their own policies; reach consensus without conflict; and juggle the improvement project with their everyday tasks, without overwork. Those people achieved amazing results, upgrading auditor ratings of their program from “failing” to “outstanding” in two years. Independently, the Receiving warehouse and delivery teams also were attaining stunning metrics using SDWTs.
I was asked to convert more such teams, who universally succeeded. One I trained after it lost its team leader and another member. Despite that 40% reduction in workforce, six months later members reported no decrease of team productivity or increase in stress!
I was so wowed, I left the Lab to create a consulting practice for empowered teams. First I spent six months reading the scientific literature on teamwork nearly full-time, and came across many anecdotes of SDWT success like these[1]:
- At a Green Giant plant in Illinois, a line-employee team reduced average machine changeover time by more than half, realizing $793,000 in downtime and inventory savings.
- The graphics department in Palm Beach County (FL) formed a self-directed team by splitting half of the former supervisor’s pay among the team members in exchange for taking over the supervisor’s duties. Within a year the team created a 21% increase in revenues—while saving the taxpayers the other half of the supervisor’s pay!
- A self-directed team at Tektronix was able to produce in just three days the same number of units formerly produced in 14.
- As reported in a PBS series called “Learning in America,” faculty members were teamed with principals or students to turn around four poor-performing schools around the country with disadvantaged student populations. Sample results from different schools include:
- Attendance rising from chronically low to a rate of 98 percent.
- Sixth-grade standardized scores going from the 44th percentile to the 97th.
- The percentage of students scoring at or above grade level in math growing from only half to more than 90 percent.
Those examples are older than the Agile Manifesto. I want to drive home that Agile early adopters missed an opportunity.
When I learned about Agile at a small startup in 2007, I read Agile Software Development with Scrum[2] and online saw this principle from the Agile Manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.” Finally, I thought, an approach that “gets it” regarding teams! In my ignorance I saw the Scrum Master (SM) role as the equivalent of the SDWT facilitator, even after a two-day SM class. I’ll use the most commonly accepted SM tasks to compare the roles:
| Scrum Master | SDWT Facilitator |
| Runs Scrum meetings (“ceremonies”) | Runs team meetings |
| Coaches team on Agile processes | Coaches team on its process agreements |
| Clears blockers | Assists members requesting help |
| Defends team from outside interference | Serves as point-of-contact and a filter for requests |
In my next Agile role I served as the SM for three teams at once with ease, in fact getting a bit bored. Since then I have trained all of my new Scrum teams as SDWTs when given the choice. I am the initial SM, to provide hands-on training. Then one or two volunteers take over, doing a little less of their normal work when serving as SM, or the team chooses to have everyone learn the role and rotate it. This is possible because of when most of those SM tasks are done:
- The team member would already be in the ceremonies, so no time is lost facilitating those.
- Almost all of the coaching occurs within the ceremonies (including Daily Standups). There are occasional exceptions when a team member asks how to handle something outside of a meeting, or the SM notices the process being violated.
- Blockers are most often declared during ceremonies, and an SM who respects their teammates won’t automatically jump in. Rather, they will ask if the member wants help. In my experience, the answer is usually, “No thanks, I’ll let you know if I need it.”
- The same is true for team defense, much of which takes place during ceremonies with stakeholders. Motivated members don’t need SM intervention to, for example, refer to the Product Owner a stakeholder asking to add work outside of a ceremony.
The last three points hinge on a robust faith in another principle of the Manifesto: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” That makes the Scrum Master position a very part-time job. I have been able to SM four teams at once while also training stakeholders, customers, and executives on Agile. When new jobs came with full-time SMs already there, I trained them to run three teams at once while they coached their divisions, so this doesn’t require my level of experience.
The part-time approach seemed so obvious to me, it was not until a couple of years ago that I realized my “mistake.” Many Agile coaches, maybe most, think the Scrum Master is a full-time role. (Pointedly, many coaches work for consulting and staffing firms that make money by placing as many new SMs as possible.) Perhaps I and the Agile trailblazers were trapped in our own perspectives. Maybe it never occurred to them, as technology people, that a team does not need a team leader. From my viewpoint as a teamwork expert, on the other hand, it never occurred to me that trailblazers challenging so many assumptions about management would miss the full implication of their own “Principle.” By definition, a team with a full-time organizer is not “self-organizing!”
Under Full Scale agile™ (FuSca™), about 10% of working time is invested in the ceremonies, in exchange for greater time savings through efficiency. SMs spend little extra time on the role: There is no “Scrum of Scrums,” and SMs aren’t needed for the minimized release planning. Assuming FuSca SMs put 5 hours a week into the job including ceremonies, that means a single-team, full-time (1:1 FT) SM in another system has to fill upwards of 35 labor hours a week! One person who objected to my opinion turned out to be training other teams and SMs with that time, which suggests he was really an Agile Coach. Otherwise, a 1:1 FT SM will have to turn to the familiar pre-Agile models of the team leader and/or project manager for things to do. The only way to do that is to take decisions and power away from the team.
In my guidance on creating empowered teams, I provide an Administrative Tasks Checklist a manager can use to decide which tasks they will hand over to the team. All of them can be handled by a mature SDWT, freeing the manager to add value other ways. In Scrum, most of the tasks are easily managed by the members, the Scrum process, and/or the work management tool. A 1:1 FT SM who retains these tasks unintentionally blocks the many proven benefits of correctly implemented SDWTs.
In my last long-term gig, I saved the client $100,000 a year in my first week by having them cancel an SM hiring and implementing the part-time approach with current employees. Obviously FT SMs who handle more teams cost less money per team, but that money is still wasted given that current team members could be filling the role with little loss of time from their regular work. Plus, as part-time team members, multi-team SMs violate the Agile ideal of having all members assigned full-time to one team (which fits the teamwork research, too).
Any FT 1:1 SM still reading this will be furious by now. I understand. By doing all those administrative tasks, you are being conscientious and trying to “earn your pay.” But your job should never have existed; it raises the costs of Agile while reducing the potential benefits, no matter how well you do it. I’m not calling for you to be fired—just reassigned so you can add more value (see previous link). But I doubt that will happen. Most managers don’t really trust their workers, and thus feel compelled to assert control through team leaders.
This post is aimed, however, at more progressive managers considering Agile but put off by the cost of hiring a bunch of Scrum Masters. The message for you is, you don’t have to! Guide your team(s) through the process of becoming truly self-organizing, perhaps using FuSca, or hire a temporary Agile coach to help you. You will not only get better performance in the long run, you’ll save a bunch of money.
Please share this post at the bottom of the page.
[1] I regret I did not keep good enough notes early in my research to cite the sources for these; they are buried somewhere in my teamwork bibliography. Other examples may be found in: Peters, T., and R. Waterman (1982), In Search Of Excellence. Warner Books: New York; and, Romig, D. (1999), Breakthrough Teamwork: Outstanding Results Using Structured Teamwork. Performance Research Press.
[2] Schwaber, K., and M. Beedle (2001), Agile Software Development with Scrum. Prentice Hall: Upper Saddle River, NJ.