Greg Godbout, Chief Technology Officer at the Environmental Protection Agency offered this advice to agencies: “Agile is not what a software development team does. Lean is not what a software development team does. It’s what the whole organization does, and everyone has to buy into that.”
In the software development world, agile calls for producing software in small, short increments. You may have noticed there are a lot of similarities between agile development and the lean startup approach, which is all about experimenting, failing early, learning quickly and iterating and repeating the process. According to Gartner, “the reality is that all of the agile methodologies are techniques to apply lean principles to software development.”
But agile methods really can be applied to a number of everyday projects that have nothing to do with software development. At GovLoop, we apply agile to nearly every project we do, whether it’s our office move, the way we produce content and even our five-minute scrum meetings, where my teammates and I briefly share what we’re working on that day, what we’ve accomplished and where we may be having challenges.
Facing Opposition to Agile
The challenge for government agencies is how to adopt these methods when they’re faced with procurement practices that do not support agile, internal trust issues and a lack of collaboration across teams. Another challenge, which Godbout highlighted during a FedScoop conference last week, is the fact that government relies heavily on estimations and assumptions without really knowing how long a project will take.
“We do everything we can with assumptions…because what we’re doing in the federal government we’re trying to get to a contract,” he said. “We’re going to begin work with a contract at the most uncertain point in the entire project’s history.
“If you think about it, it’s totally absurd that we don’t finally just admit to ourselves that it is statistically improbable for us to get this right, and that we have to actually play the game.”
For Godbout, playing the game means actually getting started, putting software into the users’ hands, improving it in an iterative processes and moving forward. “We need to stop debating for years on what software will do,” he said.
Whether you’re directly involved in software development or not, one way to end the debate and actually get started on your project is by making small bets, awarding small contracts and testing your assumptions and concerns. When it comes to assumptions, ask yourself if they’re factual and whether those assumptions have been tested.
Are You Really Lean?
When people say they’re doing lean in government, Godbout usually asks them what functionality they’ve removed from their system in the past year. The reason being is that the lean approach is about eliminating waste and delivering products to customers faster.
If people only talk about the functionality they’ve added and not what they’ve removed, they aren’t really doing lean, Godbout said. They’re not really measuring value and keeping their systems simple and usable.
Before joining government as a Presidential Innovation Fellow in 2013, Godbout worked as a consultant helping agencies rescue failing projects. On one project in particular he was asked to update software that was horribly engineered. It took him two weeks to figure out how to fix the software, but users were so unhappy that they weren’t using the system.
So for six months, all he did was remove code and reduce functionality, which he called “dehancements.” The amazing thing is customers were happier as more code was removed. Of course, the agency wasn’t thrilled that it was spending money to remove features, but doing so was adding value.
That’s what lean is all about, Godbout said.
“If you’re in government or if you’re working on a government project, think about over the next month what functionality you’re going to remove from your system and make it more simple and easier to use, and I promise you can build software for half the price and get it out there,” he said.