The Agile Manifesto:
“…we have come to value:
Individuals and interactions over processes and tools,
Working software over comprehensive documentation,
Customer collaboration over contract negotiation,
Responding to change over following a plan,
That is, while there is value in the items on the right, we value the items on the left more.” — The Agile Manifesto
The stage is set
A week before Christmas, the Social Security Administration made an extraordinary effort to build better software to process disability claims on behalf of the American people.
I wasn’t sure it would work. On Friday, we decided to do an intensive morning workshop to more fully introduce the whole team to a hands-on Agile software development experience — the next Wednesday. I had run such workshops before for the internal staff of 18F and for six agencies with the Presidential Innovation Fellows, and they worked — usually.
But we’d run this workshop with an unknown team of developers with an unknown product ownership staff. The team had some limited exposure to Agile concepts, but no practical Agile experience. I wasn’t even sure I’d be able to get the snacks through security.
On the morning of the workshop, Tom, Nick and I were 20 minutes late. I hate to be late. When I walked into the room, I got even more nervous: There were too many people here — about 30. How were we going to keep 30 people occupied and interested for three hours?
Instead of letting my anxiety get the better of me, I put my groceries down. I’ve found that you should never ask people to concentrate for three hours without nutritious food and drink — they will wander away and their energy level will drop.
I launched into my spiel: We were here to practice Agile methods as Kent Beck taught me, we were not here to judge the developers, the idea that we might get something truly valuable and potentially releasable done was a stretch goal … yada yada yada. The clock was ticking as I stated the single solitary rule: “We will have a demo at 10:00, 11:00 and 12:00 no matter what else happens. No matter if we have to stand up and say ‘We got nothing done this sprint!’”
All the other aspects of an Agile Workshop are guidelines, not rules. We were going to organize our work into stories written on 3x5 Post-it notes. Every story is a promise to have a conversation. The developers and the product owners would cooperate to produce estimates in “minutes” because the workshop was so short. The product team would accept the stories or send them back at the demos.
The SSA had done one of the most important things that an agency can do: They had the actual end-users in the room. This is the famous “have the customers in the room.” The users, product owners and UX experts were about 10 people on stage left. Six developers from both the SSA and their vendor were at stage right, seated at six workstations that had been hastily brought in. Their bank of workstations was divided by a big projector — the “stage” upon which the demos would be shown. Other observers sat in the back of the room.
The first sprint brought a quick win
I was in a hurry to get the developers started — in fact, I cut people off abruptly and a little rudely in an effort to do so. The product team already had the stories written — they knew what they wanted. Their end-user disability examiners had clearly expressed a need for a more usable “To Do List” screen in the system, but the product owners had perhaps never had developers right there in the room with them. After a few minutes of conversation about the first stories — it didn’t take very long — the developers got to work while Jason, their leader, continued estimating stories with the product team. We provided some guidance about how to write stories, mostly about how to keep stories simple, but to make sure that each provided some tiny unit of customer (or end-user) value.
About 15 minutes into the first sprint, I was asked to step outside. I unintentionally cut off Michelle, the product owner, who excitedly wanted to tell me something. On my return, Michelle said, “The developers got the first story working already and we have been asking for that for six months.” I knew then that the workshop would be okay. What’s more, Michelle’s exclamation encapsulated Agile tenet #2: Value working software over comprehensive documentation.
The first demo went well — A few stories were done. The developers, all of whom were working under time pressure, had not provided a “back” button for the new screen: Was this a bug or should we write a new story? Here’s how I answered: “When we are estimating in minutes, let’s treat it as a new story — in a two-week sprint we might treat it as a bug and reject the story.” The product team voted to pass the story. The loud applause for the developers was a great example of Agile tenet #1: Value individuals and interactions over processes and tools.
The second sprint and velocity
The new screen was good, but made it quite clear that the text was unpleasantly crowded. We needed to add some padding. This was unquestionably a story; the question that remained was how much padding we should add. Should we specify that in the story? “Nahh,” I said. “Just have the developer call a designer or a customer over to their workstation and tell them “fatter” or “thinner” until you like it.” And that’s how we came to explore Agile tenet #4: Value responding to change over following a plan.
People were becoming familiar with the process now. I could almost see light bulbs flashing over people’s heads — the excitement was that palpable. The developers and customers were talking on their own in too many conversations for us to follow. (Agile tenet #3: Value customer interaction over contract negotiation.)
Seeing one the stories implemented up on the big screen showed us something that perhaps nobody had realized — one of the columns was now redundant. The group decided to take it out to gain even more real estate.
The second demo went well and, like the first, ended in applause. We now had a user-story backlog of estimated stories. We had two sprints of measured “velocity” for each one-hour sprint: 50 “minutes” and 75 “minutes.” We could now predict what stories would get done in the final hour: about 65 “minutes” worth of work. The product team had a good deal more than that in the user-story backlog — no more stories were needed. But the product team did produce a complete force-ranked prioritization of stories on the board. Jason used this to give the work to his team as he saw fit.
People were laughing and having fun (Agile tenet #1: Value individuals and interactions over processes and tools). Nearly all the snacks I’d brought had been devoured by now. I learned something: Hummus is a terrible snack for this kind of thing. It’s messy, and you don’t want to bring a knife through security.
The third sprint
In the final sprint, one story was well underway but wasn’t quite done. I made a show of moving from the “In Test” column back to the “In process” column on our wall. Sometimes that happens. If you meet all of your goals, you aren’t aiming high enough.
The three one-hour sprints the SSA team performed are some of the hardest three hours — and the most rewarding — that a software team will ever work. We sat in the odd glow of exhaustion and exhilaration as we began the retrospective.
The retrospective
I was scribing on big flip-chart sheets as the big bosses walked in. The Chief Program Officer and her Deputy, Terri and John, had returned. We returned to the demo still on the screen to recap the functionality that had been accomplished in a spare three hours.
I was particularly gratified that at least one of the users really enjoyed meeting and applauding for the developers.
Computer programmers are not unfeeling robots. They are highly motivated by praise and applause. If I had to sum up the workshop in a phrase, it would be just that: applause for the developers.
At the time of this writing, we are planning a three-day version of the three-hour workshop in an attempt to get the functionality, which apparently the end-users desire very highly, into their hands as quickly as possible.
This workshop was Agile software development at its best: A cross-functional team cooperating to produce something that end-users really want as rapidly as possible by valuing individuals and interactions, working software, customer collaboration, and responding to change.
Running your own agile workshop
We’ve previously published a guide to running your own 3-Sprint Agile Workshop.
18F Consulting provides Agile coaching, modular contracting expertise and technical advice to Federal agencies at cost-recovery prices.
