The Small Business Administration was ready to try something different.
For years, the Small Business Administration (SBA), along with the rest of the federal government, has used the waterfall product development methodology. You’re familiar with it: start by gathering requirements, then design the software, then code, then test, then finally release it to the world.
But they started wondering, is this really the best way? Or should we be trying something new? It turns out not even the creator of waterfall, Dr. Winston Royce, thought waterfall was a good idea!
*From page 2 of Dr. Royce’s 1970 paper, [Managing the
Development of Large Software Systems](http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf).*
Federal agencies have been exploring agile, a product development methodology that emphasizes fast iterations and rapid feedback over extensive requirements gathering and planning, for a while. Since the Government Accountability Office studied and recommended using agile practices in 2012, an increasing number of federal agencies have been adopting them.
So the SBA was ready to try it out. They hired an agile vendor, but knew in order to be successful they had to change how they worked, too.
SBA asked 18F Consulting to run an “introduction to agile” workshop for their executives. They wanted the executive team to be familiar with agile: how it worked, agile-specific vocabulary, and why agile will help them succeed.
Dave Zvenyach gave an overview of the workflow of agile, how it differs from waterfall, and defined some common agile terms like sprints, backlogs, and user stories. The SBA executive team paid close attention, asked some great questions, and wrote pages of notes.
But when it comes down to it, much like The Matrix, one can’t be told what agile is. One must experience it for oneself. It was time for the red pill.
We split the group into two teams and told them that, in the next 90 minutes, they would build a product — agile style. There would be three 30-minute sprints, with demos at specific times. No matter what. We would have a five-minute sprint planning meeting as a group, then the teams would have 15 minutes to build, two minutes to demo, and three minutes for retrospective. Dave and I would be the product owner and the customer, respectively.
As the product owner, I gave the teams their user stories:
- As an office worker, I want a laptop stand so I have more desk space.
- As a mobile office worker, I want my stand to be sturdy and not fragile so it doesn’t fall apart when I move it.
- As a marketing manager (for the product), I want an advertisement so people find out about the product and decide to buy it.
And then I dumped a bucket of Lego bricks in front of each team. “Go!”
After a few “I haven’t played with Legos in 40 years…”, they were off!
The first team pretty quickly called me, the product owner, over to ask a question. “Can we see the laptop?” They measured the dimensions, the weight, and generally took a look at what they needed to hold up.
After fifteen minutes, I yelled “LEGOS DOWN. SPRINT IS DONE! Time for demos!”
The first team demo’d their product. It was simple, a few supports and a platform, but it was a great first iteration. After examining it, I announced “You have passed the acceptance tests for this user story!”
“Second team — time to demo!”
The second team got up. “We present to you… the M.O.C.C. The Mobile Office Command Center. It’s a scaled down model of a full service desk, made from the latest in environmentally friendly materials. It has a swivel-out laptop stand, a lamp, drawers, is on wheels so it can be moved around from place to place to support the new mobile office worker.”
I nodded. Inhaled.
"That’s great, team. That looks really cool. The thing is, I asked for a laptop stand. You guys built a desk. I already have a desk. If you had talked to the customer during the sprint, I would have told you this isn’t what I wanted."
And that’s when it hit them. The importance of agile. The importance of talking to users early and often and continuously. The importance of delivering products iteratively, instead of all at once. And more importantly, how this approach can reduce the risk of failure, as well as reducing the consequences of failures.
SBA’s executives continued to iterate on their products and learn about the process. By the end of it, they walked out educated, excited, ready to both work with that agile vendor, and ready to start implementing agile methodologies in their own organizations.
Learn more
If you or your team is interested in learning more about agile, email us at inquiries18F@gsa.gov and let’s talk. This particular workshop was built for executives, but we also run introductory bootcamps for front line workers, specialized workshops for contracting officers, or deep dives for product owners.