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 25 years later.
As mentioned in a recent post, 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 accounted 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 (SDWTs) as described in the earlier post.
These were administrative or clerical teams, having nothing to do with software or new product development. I may not recall the 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.” I will also 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.
“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 admit they hadn’t done 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. Specific requests made by those stakeholders were thus 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 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. They tracked 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 the 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: Every member of each team 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 sanction threats ceased.
There are several Agile truths this story tells. One is that the principles underlying Agile not only predate the Manifesto, but were well-enough established by 1994 that I took canned training on implementing them. So don’t let any doubters dismiss the Manifesto as a fad or merely theoretical. 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.
Please share this post at the bottom of the page.