The US government is, deliberately and structurally, a low trust environment. Think about why we have a “system of checks and balances.” We have proudly created a government structure that is self-correcting and that incarnates our distrust of each branch of the government. Why is freedom of the press such an important value to us? Because we all want transparency into the government’s actions – not to celebrate its fine management practices, but to know when it is doing something wrong. Within the government, we have Inspectors General to investigate misbehavior, Ombudsmen to make sure we are serving the public, and a Government Accountability Office. To work in the government is to work in an environment where people are watching to make sure you do the right thing. It is a culture of mistrust.
That sounds horrible, and from the standpoint of classic agile software development thinking, it is unworkable. But take a step back – don’t we sort of like this about the government? “Distrust” has unpleasant connotations, but as a systematic way of setting up a government, there is a lot to be said for it. It is another way of saying that the government is accountable to the people. You could almost say – you might want to hold on to your chairs here, agile thinkers – that mistrust is actually a value in the government context. So where does that leave us if agile thinking wants us to deliver as much value as possible, but believes that agile approaches require trust?
It might sound academic, but I think solving this dilemma is critical to finding ways to bring agile thinking into the federal government. A typical IT project experiences this structural distrust over and over: in the reams of documentation it is required to produce, in the layers of oversight and reviews it must face, and in the constraints imposed on it.
I will argue that even in a low trust environment, agile approaches are still the best way to deliver IT systems. And that certain tools – borrowed primarily from DevOps – actually help us resolve the dilemma. Waterfall approaches fit well with mistrustful environments by holding out the promise of accountability and control – but they just don’t work. So how can we bring agile, lean, team-based processes into an environment that is structurally mistrustful, and realize our goal of a lean bureaucracy?
Let’s talk about how to reduce government IT cycle times (mission need to deployed capability). As the Lean principle urges, we need to “optimize the whole.” The “whole” in this case goes well beyond system development. We can implement Continuous Delivery practices but if we don’t address the other parts of the value chain, our impact will be tiny. And we’re shooting for a big impact, right?
To go from mission need to deployed capability, here are some of the steps we may need to pass through: gathering requirements into a monolithic “program,” documenting the program and its plan, satisfying oversight bodies, securing funding, executing one or more procurements (typically for development services, hardware, and software), onboarding contractors, developing and testing the product, having it retested by independent verification and validation (IV&V) partners, configuring production hardware and networks, receiving an Authority to Operate (ATO – verification that it is secure enough to release), passing it through a change control board, and deploying the system.
I’ve probably missed a few things here. But a few things should be clear. First, the “value add” development part is tiny compared to the whole (both in time and cost). Second, there are many opportunities for leaning out the process, even if we still need to execute each of these steps. Third – and most subtly – there are real “business” needs, in the government context, driving each of these steps. We really do need to ensure that the system meets FISMA security requirements. We really do need to secure funding through an appropriations process. And so on.
So the question for me is: how can we meet these “business needs” of the government through the leanest possible process?
I have added a page to this site containing a draft of a Manifesto for Digital Government. I believe that there are many people in the federal government now who would agree with these points. I know I do. Please feel free to help me evolve and improve this manifesto by commenting and proposing edits!
DevOps, more than any other agile way of thinking, can cause dramatic change in how the government does IT. There is a lot to talk about here, but in this post I’ll try to present a simple line of thought that will give you an idea of what I mean.
First, we need a hypothesis on what the critical problem is in government IT. I have claimed in many of my speaking engagements that the problem we should be focused on is that of cycle time (technically lead time), by which I mean the time from recognizing a mission need to deploying an IT capability to address that need. Cycle times can be as long as ten years in the government, though I can’t give a meaningful statistic because as far as I know this is not something that is measured. What is reasonable? I would say something more on the order of a week or so. There is clearly room for improvement.
You might think that a more important problem to solve is waste, or possibly overspending. I propose cycle time instead because it is measurable, actionable, and includes these other problems. Cycle times are long because of waste; if we reduce cycle time it will be by eliminating waste. Is the government overspending on IT? It is hard to say, since we don’t know what the right level of spending should be. But everyone can agree that our spending should be as little as possible for the value we receive. Reducing cycle time will help achieve that goal. And it increases the government’s responsiveness and shortens feedback cycles, which result in better products.
Good, so what does DevOps contribute to achieving shorter cycle times? To keep things simple, let’s think of DevOps as a combination of three things: Lean Software Development, Continuous Delivery, and teaming or integration across development, operations, security, and other functions. Lean Software Development provides the framework and tools for reducing cycle times. Continuous Delivery is the best way we know to structure a software lifecycle to minimize waste. And cross-functional integration further reduces waste, addressing the costly “hidden factories” created by handoffs between development, operations, and security.
There are many more reasons why I believe that DevOps is the key to reforming government IT. I will address them in future posts.
We so often about “bloated bureaucracies” that the two words seem to belong together. Webster’s even uses the expression as a usage example in its definition of bureaucracy: “Both candidates pledge to simplify the state’s bloated bureaucracy.”
It might seem strange, then, that the sociologist Max Weber in his 1920 book The Theory of Social and Economic Organization, claimed that “experience tends universally to show that the purely bureaucratic type of administrative organization … is, from a purely technical point of view, capable of attaining the highest degree of efficiency and is in this sense formally the most rational known means of carrying out imperative control over human beings” (337). In his view bureaucracy was the application of knowledge and expertise rather than capriciousness in an organization. “Indeed, almost all the benefits we take for granted in today’s society—modern medicine, modern science, modern industry—rest on a bureaucratic foundation” (p233).
If the government bureaucracy is bloated, can it be un-bloated? What if we were to look at government processes through the lens of lean management technique? Could we apply Lean Startup ideas, and use Lean Software Development to IT needs, and take a Lean Six Sigma knife to the government? Could we trim out all of the waste? (What would be left then?)
I think maybe we can do this.
The U.S. federal government spends about $82 billion each year on information technology investments. Does the public receive good value for this investment? There are really two questions here: (1) Is the money spent effectively? (2) Is it spent on the right things? The technology environment has changed greatly over the last few decades, as have the country’s needs. Perhaps more importantly, management theory and best practices have changed as well. Has the U.S. government changed to keep pace? Has it incorporated best practices from the private sector, or even from other governments? Is it making the most effective use of its technology to deliver value to its public?
I am not just asking about whether the government is up to date in adopting new gizmos and products that are being invented. I’m asking whether the government is managing its technology investments in the best possible way, and whether it is focused on the right investments.
I hope to start a discussion on these topics by drawing on a number of strains of contemporary thinking, including: agile and lean software development, continuous delivery and DevOps, cloud infrastructure, adaptive leadership, Government 2.0, open data, crowdsourcing, and the work being done by the UK federal IT staff.
Please note that all opinions expressed here are my personal opinions, not those of the government agency I happen to be employed by. I am blogging as an individual citizen, not in my role as a government employee.