You may have heard it before: Every organization produces exactly the results it was designed to produce and none other. To get better results, we need a better design.
Government is no exception. Of course, the last time we fundamentally redesigned government was 100 years ago. The result we wanted then was an end to widespread, flagrant corruption (think Boss Tweed). The new design emphasized hierarchy, chain of command, clear rules and detailed processes, protections against risks, and central controls. It worked. That design—called bureaucracy—is still with us today.
Now the digital world is challenging government to change its design and its results. As technology continually evolves, citizens’ expectations are rising quickly. When it comes to digital services, “good enough for government” is no longer good enough. To meet and exceed changing citizen expectations, governments must become more flexible, nimble and fast at designing and delivering public services.
Agile methodologies—based on rapid discovery, design, development, testing and delivery—have proven effective at doing so in the commercial sector. Yet plunging Agile into a bureaucratic culture and expecting it to work is like plunging a fresh cucumber into a vat of brine and expecting it to retain its freshness. Just as that cucumber will be pickled, the results we want from Agile will be lost if government doesn’t attend to the context in which we’re using it.
Set the right context
Before diving headfirst into an Agile project, examine the bigger picture of operations and culture. Without the right organizational context, any Agile initiative will be almost certain to fail. As you work to become more nimble and responsive, consider whether and to what extent these elements will help or hinder your efforts:
The way you operate. Think of this as your “organizational DNA.” It’s the set of written and unwritten rules that guide how you do business every day. Are your principles oriented around control (“do things right”) or around performance (“do the right things”)? Do your workers operate with a focus on accountability to chain of command or to the citizens and other customers you serve? Are your people incented to stay out of trouble—or to deliver results?
The way you engage the business. With traditional waterfall development, business owners of a new system meet with IT during the requirements definition phase. After that, they typically have little involvement until the system is nearly complete. Not so with Agile. Business stakeholders must be engaged throughout the process, as requirements are defined, redefined and prioritized, interfaces and other functionality are built and tested, and the system is continually enhanced over time. Do your business stakeholders see the value in collaborating with such intensity? Are they ready to put in the time?
The way you buy services. With very few exceptions, most state and local governments aren’t “there” yet when it comes to Agile procurement. There are ways to get started, however. Consider how to lay the groundwork for bidding farewell to the 1,000-page RFP—and embracing entirely new ways of sourcing services to support Agile, both as a development methodology and as an organizational mindset.
The bottom line? Agile simply will not work in an organizational context that actively resists it. Explore more ideas for setting the right context—and increasing your odds of success.
See this post on LinkedIn: Doing Agile in an organization that isn't.