How to Get Started With DevOps in Government

Typically, government agencies are very process-oriented. So, it’s no surprise that’s what Mieke Deenen has experienced as an independent consultant at Mijlpaal, based in the Netherlands.

As a consultant that works at a government agency responsible for social security benefits, she met many people in similar environments who saw similar frustrations when thinking about how to deploy DevOps.

But, rather than waiting around for something to happen - she got proactive, and created a model to make bringing DevOps to different types of governmental agencies, much easier.

The agency Deenen works for, called UWV, has a core mission to offer people new prospects for work and for participating in society. Just about every adult in the Netherlands is a “client” of UWV. Most of these clients are not tech-savvy, and they’re coming into contact with UWV under difficult circumstances, like unemployment. These people strongly rely on the services that UWV provides.

UWV doesn’t really have a competitor, but they still want to create reliable software that provides fast services to its customers. This is a great point, as it highlights that competition shouldn’t be the only reason to “make things better.” We should, because it’s the right thing to do.

Due to legislation in 2012, UWV had to digitize their existing services in a very short time. This included a self-service platform for customers (to upload CVs, manage profiles, and more). This led to a major increase in usage—and, unfortunately, to a major crash that lasted several days.

Deenen described this as a wake-up call. Their three main KPIs—availability, stability, and performance—were in danger. The current process-oriented way of working was getting in the way of this. This is where their DevOps journey started.

So how do you get started with DevOps in government?

Deenen created a model that can be applied in other (non-government) process-oriented organizations.

Strategy

First, you need a strategy: visualize your goals and decide on an approach. For Deenen and UWV, it was an automated build pipeline.

The key thing here is to start small and then expand. This is contrary to the traditional government approach of big IT projects that usually fail and go over budget. Yet, with DevOps, you don’t know all the issues you will encounter along the way.

How can you start small? Well, you should find out where management is desperate to go faster and where they’re most open to change. Then, you should choose an easy application, using mainstream technology. Lastly, and perhaps most importantly, you should aim for a minimum viable product (MVP).

Screengrab from Deenaen’s presentation: a bridge that illustrates a minimum viable product.

In case of the automated delivery pipeline, Deenen wanted to only deploy a simple .NET application. Nothing more.

After having started small, you then expand, as Deenen explains. To do this, create a roadmap and define your strategy forward. If your organization is using an existing, process-oriented framework (like PRINCE2), you might have to translate this into the correct form. Deenen also mentions you should implement regular feedback loops.

Operational communication

Aside from the bigger strategy, DevOps should include efficient communication. Deenen mentions things like daily standups, but she also brings up dashboards and monthly progress reports. The idea is to communicate to anyone interested, especially (but not limited to) stakeholders. The communication should show the business and financial advantages of the given approach. This should create a solid base of support.

Team

UWV chose to work with their own people instead of bringing in consultants. Deenen wanted to avoid frustrating the employees with consultants that wanted to move too fast. This also allowed her to build motivation, an agile mindset, cooperation, and trust.

Stakeholder management

While the team is the most important contributor of success, Deenen warns us not to forget the stakeholders. We should let them contribute. In the government, this includes groups like:

• Steering committee
• Architecture board
• Security board
• Key people who know the ins and outs of the department, as well as the people in it

As an example of how you could cooperate with stakeholders, Deenen told us how she embraced the security concerns of the security board instead of being frustrated with it. This established a warm relationship with this group. Because of this, she no longer has to focus on security questions, as she has approval from the security board.

The key takeaway here? Including the stakeholders in your change makes them ambassadors of your change.

Process

Deenen realizes that your new way of working will not match the old processes.

UWV had a very siloed process: contracted developers, internal UWV employees and their test environments, and the hosting company. Deenen wanted to join these people together, so they created a separate, physical workspace. This required some negotiation, and not everyone was enthusiastic at first. But after a while, people from different groups got to know each other and started sharing ideas (and failures!).

Another challenge Deenen tackled was the risk-averse, slow-change process in which changes had to be announced 42 days in advance. To alleviate this, she managed to allow an exception for her teams.

Technology

Regarding technology, Deenen continued with the idea of starting small. They started with the mainstream technologies, and moved on to the harder stacks later.

Benefits

This entire process had three main results:

• More business and technical confidence
• Real business benefits that could be measured
• A new corporate policy, ie other teams and departments wanted to use deployment automation too!

The future for DevOps at UWV

Deenen mentions the work that is still in front of them. They want to onboard the remaining applications, identify waste, and start integrating automated tests.

Deenen concluded that starting DevOps in government means creating your own culture and using the strengths of the organization to achieve that.

***

About the author, Peter Morlion: 

Peter is an experienced software developer, across a range of different languages, specializing in getting legacy code back up to modern standards. Based in Belgium, he’s fluent with TDD, CQRS, and other modern software development standards. Connect with Peter at @petermorlion.