Contents
- Good Intentions Turned Bad
- Different Name, Same Idea
- The Make or Buy Decision
- The SuddenTeams™ Program
Good Intentions Turned Bad
I was duped by the Agile Manifesto.
In 2008, I did a short stint at a 25-person startup in the International District of Seattle. I was filling a project manager slot left abruptly, in a gig I hoped would go longer but intended to be temporary. Once there, I was told that the company used something called “Scrum” and my role was more of a “Scrum Master” than a traditional project manager (PM). Knowing nothing of this (so I thought), I asked if there was a book I could read, and the founder/CEO handed me Agile Software Development with Scrum by Ken Schwaber, co-developer of Scrum, and Mike Beedle.
On reading it, I realized that I had indeed heard of this. At an earlier PM job with a vendor to Microsoft, I learned that one of the customer teams I supported spent a day every three weeks planning the next three weeks. I thought this sounded ridiculous, coming from the perspective of a Project Management Institute-certified Project Management Professional® (PMP®). Beside the point was that even according to PMI’s own data, a small fraction of original project plans reflect later reality.
As I read the book, I realized that the creators of Scrum had to some degree reinvented the wheel. What Schwaber and Beedle were describing was a different approach to agility than one I had taken at the same time Scrum was being developed, the mid-1990s, which achieved the same results. As detailed in the next section, I learned to create “self-directed work teams,” groups that planned and accomplished their work with zero daily involvement from managers. They had no team leader, everybody took a turn facilitating meetings, and managers got status reports after every meeting, once or twice a week.
After five years creating such teams, I founded TeamTrainers™ Consulting in 2000 and began researching the science that explained their successes. I was nearing the end of the first draft of my training manual, The SuddenTeams™ Program, when a group of software managers got together in Utah to compare notes on similar systems they had all developed as alternatives to traditional project management.
I knew nothing about those systems or people for a very simple reason: I had nothing to do with software yet. All of the teams I created or observed were in support organizations, like equipment management, package delivery, and technical writing. While I began peddling my services based on SuddenTeams in February 2001, they created the Manifesto, more properly the “Manifesto for Agile Software Development” (http://agilemanifesto.org/). If by chance you haven’t read it, or haven’t lately, please read it and its “Twelve Principles” linked from that page before continuing, or this site’s more detailed explanation.
The Schwaber/Beedle book led me to the Manifesto and the principles, which, again, were perfectly aligned with everything I knew and had read about self-directed work teams. I was particularly taken by this principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”
“Finally,” I thought excitedly, “somebody gets it!” Here was a group of people who understood the value of what I was doing with TeamTrainers and leaderless teams.
Only, it turns out, they didn’t. They still don’t.
I was so excited, my brain completely filtered out the fact that Schwaber and Beedle in one sentence (only) refer to the Scrum Master as a “manager.” It seemed so obvious elsewhere they were referring to what I was calling the “facilitator” role that rotated among team members, I totally missed that they were taking the classic team leader job and trying to limit that person’s use of power through the Scrum methodology. In fact, it would be another 10 years before I understood that people accustomed to corporate hierarchies were not simply misreading the Scrum materials when they justified making full-time jobs, and even careers for Scrum Masters. The book, and the later Scrum Guide put out by Schwaber and Jeff Sutherland, actually allowed for this.
I’d been duped again by people stuck in a pyramid. Even these forward-thinking leaders were operating within the paradigm that most teams need designated leaders to succeed.
Let me be clear: If the only job of someone on your team is organizing, then you do not have a self-organizing team.
Different Name, Same Idea
I trained four administrative teams to meet the principles of the Agile Manifesto seven years before it was written. Their story busts several myths about Agile that continue to hinder its adoption decades later.
Los Alamos National Laboratory faced a major risk in 1994. Their equipment management system had failed government audits. Roughly a billion-dollars-worth of equipment could not be unaccounted for, dating back to LANL’s birth as the design center for the Manhattan Project. The U.S. Department of Energy (DOE), which is responsible for the federal lab, was threatening sanctions if changes weren’t made. For example, they were going to require DOE approval for all purchases above some ridiculously small amount, like $250, across the 42-square-mile facility.
The means of documenting the new system was rewriting the old equipment management manual, a 500-page beast of dense type. I was hired as a technical writer to do that. But it quickly became clear rewriting the manual really meant redesigning the system and training workers on its use, since the manual had to reflect how things were actually done to pass later audits. That was the driver behind my learning how to train self-directed work teams (also called “self-managing” teams).
These were administrative or clerical teams, having nothing to do with software or new product development. I may not recall members’ titles and roles exactly, but I think they were:
- “property managers” (PMs) who handled daily equipment management needs at the line level—not real estate, despite the title!
- “property administrators” (PAs) who processed forms from PMs and others and recorded transactions
- “property specialists” (PSs) who oversaw and supported these operations across the Lab, and
- “fleet managers” who did PM-like work for the Lab’s vehicles.
The Agile Manifesto would not be written until 2001, and I was unaware of existing methods like Crystal and Kanban now considered “Agile.” To make my argument that these were Agile teams nonetheless, I will analyze them in reference to the Manifesto’s “Principles.” In doing so I will demonstrate how easy it is to apply the Manifesto to non-software work if you ignore the word “software,” or replace it with whatever you deliver.
“Our highest priority is to satisfy the customer through early and continuous delivery…” Given the sanctions DOE was threatening, we needed to show satisfactory progress quickly. We delivered a first draft of a new manual, completely rewritten, redesigned, and pared down to around 300 less-dense pages, in just four months. (That still sounds big, but remember this was a highly regulated nuclear weapons site with classified equipment, and the manual included policies, standard operating procedures, and example forms.) After that we delivered completed individual chapters for final approval rather than waiting until the whole book was finished.
“Welcome changing requirements even late in development…” By calling, meeting with, and submitting drafts to DOE reps often, we gave them ample opportunity to tell us we were off course or add new requirements for the system as it was evolving. Meanwhile, the PMs were providing regular feedback about what would work for Lab employees, who had to comply with the new system.
“Deliver… frequently, from a couple of weeks to a couple of months…” Each team met twice a week initially, and then dropped to once a week after we were running smoothly. At each meeting, the “Old Issues” section of our agenda included all tasks that had come due since the previous meeting. At the meeting, the responsible person had to report on the results, or say they hadn’t been able to do it, ask for help if needed, and provide a new due date. (Sound like a “standup” to you, though weekly in this case?) Those results were reported out to managers and made available to the auditors in a “public” version of the meeting notes. An unredacted version was kept on a server only team members could access, so the team could keep track of prior discussions. Specific requests made by those stakeholders were usually delivered within a week or two of the request. Also, on average I think we delivered a manual chapter every couple of months.
“Business people and (team members) must work together daily throughout the project.” Never a day passed that the PSs and PAs were not in contact with PMs and others like the Export Team. We regularly touched base with those people or their representative teams, described below, to get input on proposed policy changes. I think these interactions were the keys to the rapid adoption of the new system.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Managers agreed not to attend the team meetings except by invitation. They could only insert requirements through the current facilitator, and learned not to assign tasks to individuals except in emergencies. They were also very responsive to team requests for information or political support.
“The most efficient and effective method of conveying information to and within a… team is face-to-face conversation.” All of the PSs and PAs were collocated, with parts of each team sharing offices. The culture of the place was such that everyone walked over to talk to people when they needed information or help, unless one or the other was in the middle of something or didn’t need a quick answer. We also held regular training and feedback-gathering meetings with the PMs and fleet managers.
“Working (deliverables are) the primary measure of progress.” There was zero tracking by managers of what any individual was doing on a weekly, much less hourly basis. I doubt any managers even looked at the team spreadsheets of the tasks for which people had volunteered. Nor were there any project plans. Managers monitored progress primarily through the meeting notes and our outputs, both daily tasks and deliverables from the system improvement project.
“Agile processes promote sustainable development…” I recall no one regularly working more than 40 hours a week except by choice. Letting people volunteer for project tasks and declare their own deadlines ensured the improvement project did not overtax anyone given their daily duties. There were occasional exceptions, notably when everyone pitched in to help the PMs inventory all of the Lab’s tracked equipment—even me! That took three weeks of extra hours, but was an exception that proved the rule and a great example of teams helping each other.
“Continuous attention to technical excellence and good design enhances agility.” These were effectively the goals of the project: We needed the systems to be well-designed and technically easy to use, because otherwise the Lab’s scientists and engineers would not use them. Once we were showing progress there were no more hard deadlines. The teams were just told to make DOE happy, and thus were free to focus on doing the job right.
“Simplicity—the art of maximizing the amount of work not done—is essential.” A question that became a team mantra was, “Why do we do it that way?” To the great credit of these people, they eagerly dropped anything for which the answer was something like, “We’ve always done it that way.” They understood the value of getting rid of unnecessary tasks.
To illustrate the value of this principle, I am going to brag a little about personally saving American taxpayers at least $100,000 in 1995 dollars. When the auditors said we had to put labels on a category of equipment we had not tracked before, I felt they were misreading their own regulations. One line could be interpreted as they had, but it did not explicitly say this had to be done. They eventually accepted that argument, and we were spared the expense of creating, applying, and recording the labels on thousands of items.
“The best architectures, requirements, and designs emerge from self-organizing teams.” The PM and Fleet Manager teams were representative bodies elected by those larger groups. All of the teams created charters with their own team rules, meeting rules, and internal team procedures. There were no team leaders on any of the teams: Every member served in the “facilitator” role on a rotating basis.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The weekly team meetings were for this purpose also. One of the policies all the teams adopted was that once the team chose a practice, members agreed to follow that practice between meetings. But anyone could add concerns that arose as a “New Issue” in the next team meeting, as well as proactive changes. The team then decided whether to change the affected part of its charter accordingly.
The results? These teams raised the auditor ratings of the system from “Failing” to “Outstanding” in two years. They also found records accounting for all but $250,000-worth of the “missing” billion dollars of equipment, an astonishing 99.99975% success rate. The system was approved almost instantly. The sanction threats ceased.
There are several agile truths this story tells. One is that the principles underlying agility not only predate the Manifesto, but were well-enough established by 1994 that I took canned training on how to implement them. So don’t let any doubters dismiss the Manifesto as a fad. The second is that Agile is applicable to virtually any type of team, regardless of team deliverables or member backgrounds. The third is that you don’t need an Agile Coach or full-time Scrum Masters to implement them, just the will to continuously improve and managers willing to drop their egos.
The Make or Buy Decision
Scrum co-developer Sutherland has described how various methods now called “Agile” co-evolved in the early days.[1] Obviously, all of the current methods had to be created by somebody! In “The New New Product Development Game,”[2] a groundbreaking report in Harvard Business Review in 1986, Sutherland’s co-author and others described highly empowered product development groups dating back far further in which executives provided marching orders and money and little else. Another of the Manifesto authors, Andy Hunt, has said its creators thought “there would be an explosion of methods,” suggesting many companies or teams would develop their own approaches.[3]
My point is that your team could easily implement an Agile mindset simply by turning into an SDWT and creating its own method. Adding in the scientific evidence that decentralized firms based on small empowered groups improve financial performance, the best approach for upper managers to create an Agile organization might seem the most radical:
- Decide on a specific need you want to fill, and how much you can spend on a workable design or minimal viable product.
- Choose an initial set of people with all the business and technical skills needed to produce that product or service, and strip them of their job titles.
- Tell them to follow the Agile Manifesto, replacing the word “software” with their product type if it isn’t software.
- Exempt them from all organizational policies not required by law, regulations, or ethics.
- Put them in an offsite conference center with a skilled big-meeting facilitator to self-organize.
That’s it. The rest, including the schedule, is up to the people.
I spent months writing up my system, yet the steps above are the way I wish everyone would implement agility. The goal is complete freedom for all programs to meet their customers’ needs as they see fit. They might choose to implement an initially prescriptive methodology like FuSca, but wouldn’t have to.
Unfortunately, few executives appear willing to implement this approach, despite the data in its favor. My attempts over 14 years when I was a teamwork consultant to get managers to succeed by giving up control met with limited success. One objection I still hear today is that this would show the company is “out of control.” In a sense that is true! But again, the best evidence says a lack of centralized control will improve a firm’s financial performance.
The 1960s counterculture figure Abbie Hoffman wrote a book called Steal this Book. In that spirit I give away this Web “book” and say: “Don’t use my Agile framework!” Create your own. Only if you aren’t allowed to, or need something workable right away, should you go the pre-packaged route. Everyone else, let’s help your team self-organize its agility!
The SuddenTeams™ Program
When I left Los Alamos, I was so excited by SDWTs, I decided to try making a living by promoting them. Here I called on my old research skills, learned in my first career as a journalist. Having heard things in business conferences that did not align with what I knew about psychology based on earlier writing projects, I wanted to know what scientific research said about teamwork. For six months, I spent one day a week in two libraries at the University of New Mexico, reading journal articles and books written by researchers. The result was The SuddenTeams™ Program, a 500-page training manual for converting a standard work group with a team leader into an empowered team. This was before laptops were common, so I printed it out and put it into a binder to follow as I conducted trainings.
I was stunned by how much self-proclaimed “teambuilders” got wrong about teamwork, according to objective data. Most of the teambuilding exercises of the day bordered on fraud (and sadly, they still dominate the industry). It was clear that really improving teamwork required a lot more time and effort than the popular exercises and games still bought today by managers who just want to “check the box”—that is, to prove they did some teambuilding. However, the practices that work don’t cost anything except time and self-discipline.
When the first draft was done, I had founded a training/coaching practice, TeamTrainers™ Consulting. Finding little success in the small city of Albuquerque, I moved to a bigger market, selecting Seattle because I had friends there. Realizing I didn’t like sales enough to make this a full-time gig, I usually did it on the side while developing a career as a project manager. In 2009, I published a book version of The SuddenTeams Program, updated a few years later.
Having shifted into Agile coaching by then, which felt like an extension of my TeamTrainers work, I finally burned out a bit and closed the practice after 14 years. A lot of reference materials for SuddenTeams had been on the TeamTrainers site I was taking down, so I decided to move the whole thing online and give it away!
However, as I began to rebrand this website, I wanted to go back to my roots by putting a greater emphasis on real self-organizing. Plus, SuddenTeams needed some updating, especially given my research on and experience with agility. Fortunately, the core practices continue to be valuable, because human brains still work the way they did in the 1990s. Or 990s. Or 90s. So I folded the Web book into the new site.
SuddenTeams is now “Self-Directed agile.”[4]
↑ Self-Directed agile | → Prepare to Empower
[1] Rigby, Darrell K., Jeff Sutherland, and Hirotaka Takeuchi. “The Secret History of Agile Innovation.” Harvard Business Review, April 20, 2016. https://hbr.org/2016/04/the-secret-history-of-agile-innovation.
[2] Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” Harvard Business Review, January 1, 1986, https://hbr.org/1986/01/the-new-new-product-development-game.
[3] Hunt, Andy, ‘The Problem with Practices’ (presented at Agile RTP, Webinar, 3/1/2022).
[4] Some SuddenTeams sections were moved into “Agile Across the Enterprise,” and the teamwork basics and Troubleshooting sections remain on my career site, “The Radical Agilist.”