_posts/2015-02-10-a-story-of-an-agile-workshop.md
---
title: A story of an agile workshop
date: '2015-02-11'
layout: post
image: /assets/blog/agile-workshop/workshop3.JPG
tags:
- agile
- workshop
- best practices
- culture change
authors:
- robert
- blacktm
description: "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!"
excerpt: "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!"
---
## 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](http://www.agilemanifesto.org/)
## 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.)
<img src="{{ site.baseurl }}/assets/blog/agile-workshop/workshop2.jpg" alt="The SSA developers at work." class="align-left" />
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.
<img src="{{ site.baseurl }}/assets/blog/agile-workshop/workshop1.jpg" class="align-left" alt="The actual users in the room and having fun." />
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.
<br/>
## 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](https://18f.gsa.gov/2014/10/21/how-to-run-your-own-3-sprint-agile-workshop/).
[18F Consulting]({{ site.baseurl }}/consulting/) provides Agile
coaching, modular contracting expertise and technical advice to Federal
agencies at cost-recovery prices.
<img src="{{ site.baseurl }}/assets/blog/agile-workshop/workshop4.png" alt="The completed stories and velocity chart after Sprint 2." class="float-left" />