Time to embrace Agile and beyond

Remember the good old days of IT contracting for the federal government? Billion dollar projects over multiple years. Huge cost overruns. Dissatisfied customers. Angry taxpayers. And when the project finally went live, it was already three years out of date.

Not so good old days after all, it seems.

Today’s mantra is do more with less. Be more agile. Leverage IT for greater efficiency, streamlined programs. Shared services, cloud first, future first are the IT mandate of the future.

But in spite of all the good intentions, government procurement processes are stuck in the dark ages. RFIs. RFPs. Contract vehicles. IDIQs. Multiple year awards. Huge waterfall projects. The commercial contracting world looks at the government biz and wonders what planet we’re on.

Every administration, of course, wants to revamp government procurement. Might as well try to vacuum the beach. Even if Washington weren’t broken, the layers of law and regulation are so deep that untangling the procurement morass is a fool’s errand.

If we could separate the government’s archaic procurement and program management approaches from how we build and deliver IT solutions, then we might have a good shot at delivering more with less: flexible, customer-focused solutions that are less about big-iron legacy and more about cloud-friendly, Web-enabled, flexible solutions of the future.

But there’s a catch. We know how to build such solutions: take an iterative approach that works with the customer to better understand dynamic requirements while delivering modular capabilities that respond to changing requirements over time. Less legacy, more agility.

We call such approaches Agile—that is, Agile-with-a-capital-A: software methodologies that favor individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Software projects that follow Agile methodologies like Scrum and Extreme Programming include a customer on the team and take an iterative, skunkworks approach for cranking out high quality software.

For government contractors, such approaches might work for smaller organizations with highly involved customers and small teams, but there’s an obvious impedance mismatch between the small-and-fast context of Agile and the big-and-slow processes that the government favors. Maybe we should throw in the towel and stick with the massive, risky approaches of the past.

Not so fast. There are Agile techniques that work well within the context of government procurement processes. The key lies within the fourth Agile principle: responding to change over following a plan. In other words, if there is some business reason why a given plan won’t work, feel free to change the plan—even if the plan is to follow Agile. We can take Scrum, say, and make tweaks to it to fit it into existing procurement and program management processes, while still maintaining the quality and customer focus benefits of Agile.

The customer, of course, must understand and support the benefits of Agile, and be willing to participate. It’s also essential to add project management and quality controls like those that the Capability Maturity Model Integration (CMMI) provide. But most important of all, it’s essential to implement agile architecture.

Architecture is an established part of any large software initiative, of course, but all too frequently, the architecture effort fragments into subarchitectures: data architecture, information architecture, integration architecture, software architecture and the like. The government’s long-standing efforts with enterprise architecture have improved this fragmentation somewhat, but large initiatives still suffer from inflexible architectural approaches. Agile methodologies don’t solve this problem either, as building software in an Agile way doesn’t guarantee the software is inherently agile.

The focus of agile architecture is building change into all aspects of the overall solution, including both the technology and human elements of the initiative. Identify where the customer requires agility, and build inherently flexible technology that delivers on this agility requirement. This approach shifts the architectural emphasis from integration to governance. The more flexible the tools, the more important it is to establish the organization, the processes, and the policies that form a flexible governance framework.

Governance is the greatest challenge of Service-Oriented Architecture (SOA), a way to expose application functionality and information as modular, reusable services. But without governance, such reuse will never take place. Governance is core to squeezing value out of cloud computing as well. Since automated, managed customer self-service is an essential characteristic of cloud computing, cloud resources (both private and public) are dangerous unless properly governed. Mobile technology faces the same challenges: after all, the bring-your-own-device (BYOD) problem that agencies are facing across the federal space is also a governance challenge.

It is possible, therefore, for government IT initiatives to be Agile—and furthermore, many agencies have shown success with Agile approaches. But the software methodology isn’t the whole story. You must take an architected, quality-driven approach that adjusts Agile approaches to suit existing procurement and program management processes.

If we get it right, we can help our government succeed in its efforts to do more with less.