DevSecOps in the public sector — the cultural change
In this blog series, Zaizi’s Chief Technical Officer Sergio Rojas will take an in-depth look at DevSecOps in the UK Public Sector. The first blog looks at one of the biggest challenges; the cultural change.
DevSecOps is a disruptive philosophy. It requires a cultural change — and, as we know, people are always reluctant to change. The different stages of personal transition and organisational change is depicted well by the Kübler-Ross Change Curve.
When aspects of change are managed effectively, the smoother and shorter the curve will be. In this blog, I will explain how the Change Curve applies to DevSecOps in the UK public sector.
Working for an SME means wearing many hats. As well as overseeing the technological needs of Zaizi, I contribute towards the bid writing process. All the public sector bids I’ve worked on highlighted Agile and DevOps as essential. Bid requirements are written and influenced by leaders setting strategy. Their day-to-day work is to think of ways to deliver better services to citizens whilst at the same time save money. As per the Change Curve, these people understand the value of the ‘Experiment’ phase and know the results and benefits of Agile and DevSecOps.
I’ve participated in all phases defined in GDS’s Agile delivery framework; Discovery, Alpha, Beta (private and public) and Live. I’ve noticed that the views and opinions of people within delivery teams, especially during the Beta and Live phases, is rarely the same as those setting strategies. The managers may know why they want to go into a ‘new’ agile direction but those delivering the work are not always on the same journey. They may be stuck in the old ways of working and need convincing. And it’s this misalignment, or lack of DevOps maturity, that can cause problems within an organisation. I’ve seen this a lot in the public sector.
Examples of DevSecOps in government
For a recent central government project we built the following under a DevSecOps environment:
- Award-winning web applications to establish the organisation as the ‘go to’ place in its area of specialism in the UK.
- Fully automated Digital platform on AWS, enabling continuous improvement to the web-applications.
Security is a given for this organisation but they also understood user experience is also key. Their motto is:
“User experience has to be the best, security has to be good enough.”
I'm lucky to have worked with this organisation and its amazing product-minded professionals — people who have won awards for creating world-class digital services.
Even so, the organisation was divided into two groups. One containing the people I just mentioned, with years of experience around DevSecOps. They pushed for small and frequent releases over Change Advisory Boards (CABs), discussed delivery and service within the same group of people and prioritised working software and well-written automation scripts over heavy documentation.
The other group, in contrast, had not been exposed to DevSecOps and preferred to continue with the approach taken by the previous supplier, aligned to a more traditional/waterfall/ITIL approach. This caused some internal friction and required us to make an extra effort to get everyone on board, which we did successfully.
We had a similar situation recently working for another important central government organisation on a national infrastructure digital service. I have a great relationship with the organisation’s CTO, who has good knowledge and experience of DevSecOps. But achieving cultural change within an organisation requires more than just the leads agreeing and understanding it.
In this project, some of the other external suppliers and internal stakeholders were in charge of legacy systems and they used a rigid waterfall and ITIL approach. In these scenarios, the speed of the whole service is limited to the speed of the slowest part. Adopting heavy processes, like freezing code and attending CABs in order to deliver new features and bug fixes every two weeks, slowed everything down.
Cultivating a DevSecOps culture
So, what do we do when we have to deal with complex cultures and different ways of working? Here are some key takeouts from how we've worked with public sector clients:
- Take an empirical approach to demonstrate value and results. Always define from the very beginning what success looks like and be specific and transparent on the metrics used to measure it. I will dedicate a blog in this series on metrics and how to measure success.
- Work in short cycles to demonstrate progress continuously. This would smoothen and shorten the Kübler-Ross Change Curve by exposing those who are reluctant to change, to experimentation in the early stages.
- Any work done must be linked to the organisation’s key goals/objectives. Prioritisation is key when it comes to Agile and DevSecOps. Every single effort made/penny spent (meetings, workshops, spikes, coding, infrastructure and pipeline automation, etc.) must contribute to achieving the key objectives of the organisation. My advice is that at ‘Show & Tells’ give context around the key organisational goal associated with the work conducted.
- Identify and support DevSecOps champions within the organisation. Contacts and friends are key to every aspect of life. DevSecOps is no exception. It's key to identify those in the organisation that are pro DevSecOps and support them so they can influence and evangelise within the organisation (especially senior stakeholders).
It will come as no surprise that the success of implementing a digital service using an Agile and DevSecOps approach is directly related to how mature and comfortable an organisation is in using these methods. It’s why cultivating the correct culture from the start is crucial to delivering successfully.
Next time, I will look at another important topic; how to build your DevSecOps team to success.