Deploying DevOps in Government - The Second Time is the Charm

Some stories are worth a second, and even third look. The one Mieke Deene (@miekedeenen), told us in her 2017 AllDayDevOps session - where she detailed challenges she had to overcome helping the Dutch government through a DevOps transition - is one of them; which is why we're sharing it again today. 

It is hard to imagine an organization more risk averse than a government agency that doles out government payments to millions of people in need. If they miss a payment by even a day or two, it could mean someone not getting the groceries they need or their rent payment being late - never mind the slew of negative publicity. The UWV is just such an agency. It is the Dutch government agency that is responsible for the collection and payment of social security for all employees and for helping unemployed people get back to work. They are already risk averse, and then their first dip into DevOps didn’t go well.  

Luckily, they still understood the potential benefits of DevOps and decided to try again. In her AllDayDevOps session, Mieke walked us  through  what they did differently their second time around to better moderate risk, and ultimately be successful. 

UWV’s website was, and continues to be, the most visited government website in the Netherlands; at the time of the transformation that was 7 million visits/month - the number has grown since then. Since their services are vittal to millions, they have a goal to deliver mission-critical software without failure. In fact, their three main KPIs are availability, stability, and performance.

In 2012, legislation required OVM to digitize its services. At the time, their website was just a static bit of information, but they needed to become dynamic, offer new self-service functionality, and absorb a major increase in usage without failure. Following their first attempt, they received a warning from external auditors that the website is not future-proof.

They attempted to improve the site in 2013, and used DevOps practices. All of their efforts were focused on increasing stability. Nonetheless, they suffered a major crash and period of unavailability. The result - tightening the change process and a belief in the organization that they are not the best organization for DevOps.

This further tightening of the change process resulted in:

• Process
• More quality gates, more difficult to pass the process
• Hard to release anything
• Stability
• Technical debt, failures
• Major releases with more dependencies
• Business
• Increased costs of operations
• Hard to fulfill tasks
• Less opportunity to innovate
• Culture
• Low trust in change or innovation
• Low trust in suppliers and a blame culture

Mieke and some of her colleagues believed that DevOps could increase the reliability and quality of their applications. So, she proposed and got approval for, a proof of concept project with a small, low impact application.

This time - she saw success! With one success under their belt - her team received approval to expand the DevOps journey to to 30 applications within 1 division - customer service.

Besides the 4 standard DevOps challenges: executive support; legacy systems; culture; and, manual to automation, they had 6 other challenges. Mieke walked through each one and how they responded.

Challenge 1 : Siloed tools and people.

Response. Remove the walls. It was a challenge because people liked the walls, but we actually communicated and discovered what we could do to make other people’s jobs easier.

Challenge 2: Agile values in a traditional waterfall organization.

Response: A campfire culture. They stood up and helped each other. It was a challenge, because people didn’t want to share what was hard, but Mieke created an area where people could experiment and fail as long as they learned from it and shared it. It created commitment, focus, trust, transparency, and courage.

Challenge 3: Risk-averse and a slow change process.

Response: Learn the rules, negotiate, and bend the rules. Mieke invited the change manager to come to the team. They gained his trust because he saw they didn’t skip steps or suffer quality. They continue to have the best relationship with change management and the most liberal rules.

Challenge 4: Asking their hosting partner to help automate their own work, which was billable hours.

Response: They made the hosting company a partner instead of a supplier, which created a mutual goal to deliver quality, speed, and results. This helps them present themselves as a solid, flexible partner.

Challenge 5: Find the balance between the old and new world.

Response: Build a bridge for the old world to reach the future. The bridge isn’t done yet, but they invite people to use it while they are still building it. After all, they all want results but are afraid to get there.

Challenge 6: Skepticism, low trust, and lack of belief.

Response: Visualize your goal and keep that in mind. Be patient and persistent. After a while, an impediment was not seen as a blocker, but as one step closer to the goal.

After six months of struggling, they were finally allowed to deploy to their acceptance environment. In the summer of 2016, they went from 1 to 30 applications, and subsequently saw:  

• Improved quality and stability
• Over-achieved financial benefits
• Two to three releases per year to bi-weekly
• Low trust to high trust
• An increase in organizational confidence

Her advice to anyone advocating or leading a DevOps transformation, especially in a government entity:

• Create a cross-functional team with motivated and skilled members
• Dare to be an island. Create DevOps values and use DevOps techniques even if your organization isn’t ready to call it DevOps yet
• No innovation without resistance - visualize your goal and have patience in working through impediments
• Build trust, create bridges
• Keep learning and improving and create flow
• Look for opportunities and just do it
• Celebrate your success and do it again.

And, to top it off, remember to, “work hard in silence, let success make the noise.”

You can watch all of Mieke’s 30-minute talk for free here and view all presentations from the past three years of All DayDevOps at https://www.alldaydevops.com. The CFP is also open for this year's conference - if you have an awesome story to share, submit it today!