Fearlessness and Feedback: The Cornerstones of Agile Development

“Waterfall” service delivery is a plan-based and predictive software development process. In waterfall development, as one stage is put to bed, the next begins. Though still popular in many corners of government, the process often produces solutions that, by the time they’re complete, deliver neither the value nor the return on investment anticipated at the start.

Enter agile development, an incremental, iterative mode of thinking that measures progress not with documents or plans but with demonstrable, working versions of software that improve with feedback. And according to a fall 2015 survey by Grant Thornton, CompTIA and the National Association of State Chief Information Officers (NASCIO), 75 percent of states expect to start improving their agile approaches. But that process does not come without its own challenges.

The fundamental hurdle between predictive, waterfall methods and agile development is understanding, execution competence, and trust in the method, says Brian Reynolds, Principal at Grant Thornton Public Sector.

The old model provides state and local leaders with beaucoup documentation about the scope of their procurement, but it does so at the risk of making inaccurate predictions. Waterfall development precisely plans details (costs, schedules, scope) at the outset of a project, when managers know least about end-user needs, effectively making that plan non-negotiable. That front loading often creates problems during deployment.

Agile development takes an entirely different attitude toward planning, building documentation from the footprints of iterative design and development: user stories, acceptance criteria, test cases, wireframes and other application lifecycle data.

“With agile development, we’re asking government to be involved intimately and to help refine the solution throughout the project, not just during requirements specification at the beginning and acceptance testing at the end,” Reynolds says.

As product owners, governments using agile processes control which elements of a project are built in what order. This affords both the opportunity to establish a triage and the responsibility to bring an understanding of case-specific needs to the table throughout the process. In doing so, governments must define and explain requirements, validate the delivered solution with those requirements and ensure that it functions as intended.

Perhaps unsurprisingly, agile is becoming increasingly popular in government.

"This isn't just for the startups of Silicon Valley anymore," says Scott King, National Managing Principal, State and Local at Grant Thornton Public Sector. "With that said, agencies must consider whether or not their operating environment provides the foundation necessary for success."

That readiness will come when agencies make a number of important considerations.

“When adopting agile, we can’t abandon rigor,” Reynolds says. “As we move toward more limited documentation and specifications, these artifacts must be replaced with collaboration, communication, demonstration and feedback. If we don’t, the process doesn’t work.”

Successful agile development, he says, incorporates some of the same ideas inherent to DevOps, the practice of breaking down stovepipes between development and operations.

Driving agile, DevOps and enabling practices, like continuous delivery, is the need to remove handoffs, improve collaboration and feedback and secure the team’s commitment to project—not task—success. Reynolds says the key is shifting focus from responsibility to accountability.

“People often link the capabilities of the private sector to citizens’ expectations of public-sector technology,” says Graeme Finley, Managing Director at Grant Thornton Public Sector. “In state and local government, there are more touch points to the end user—the citizen—and thus more opportunity for feedback and improvement.”

From this perspective, picking the right project becomes a vital part of agile implementation. State and local governments looking to optimize licensure or renewal processes, for example, have a simple and effective place to start proving the power of agile as it directly affects citizens.

Although continuous feedback is essential, the road doesn’t stop there. Reynolds and Finley both emphasize that culture change will be the real harbinger of the agile adoption.

“It’s not good enough to just have an agile development process and involve end users,” Finley says. “You’ve got to have that core, underlying infrastructure in order to make the thing go.”

King also stressed the importance of “agile thinking,” meaning remembering that value is not measured in requirements but in functional, testable iterations of the software. Agile philosophy requires a culture shift, he says, and the change management required takes time.

Washington State sets an excellent example of supportive infrastructure with WaTech, its central technology agency commissioned by Governor Jay Inslee and overseen by CIO Mike Cockrill.

WaTech grew from three challenges that the agency set out to address: “Change the Way We Work Together,” “Transform Our Customers’ Experiences” and “Execute with Excellence.”

These three ideas are emblematic of the organizational attitude needed for progress in the agile space. But in addition to a desire for change, state and local organizations need to bring a bit of bravery into the mix. Change is scary, but any organization that feels like agile is too big to tackle should think again.

In the end, Agile is about holding individuals and interaction over processes and tools, customer collaboration over contract negotiation and responding to change over following a plan.

“Start small, and don’t be afraid to fail,” Finley says. “But when you fail, fail fast. In agile, changing course quickly is a good thing. It means you’re learning.”

This content is made possible by our sponsor. The editorial staff of Route Fifty was not involved in its preparation.