DevSecOps in the public sector — the essentials
In Sergio’s previous ‘DevSecOps in the public sector’ blog, he looked at how to create a great DevSecOps team. This time, he’ll look at how to equip the team with the right guidelines and tools to maximise efficiency.
So we’ve talked about why a cultural change needs to happen within your organisation and how you can create a DevSecOps team, now we’ll look at the essentials that will help everyone work efficiently. This isn’t a top-down approach with management dictating how things should work. Your team needs empowering to come up with how to work. And here’s how you can help.
1. Team with a voice
Command and control environments, where decisions are made by a handful in management, used to be the norm. Delegating the decision-making to the wider team seems scary as management can feel like they’re losing control. But from my experience, this democratisation of decision-making works.
Doing it well requires expertise and maturity across the team. Facilitating creativity and ownership breeds confidence; people are less afraid of proposing ideas. These ideas help increase productivity and efficiency. And it frees management to concentrate on the strategy and the bigger picture.
2. Creating a roadmap
DevSecOps doesn’t mean using the trendiest technologies and tools, nor is it about having over-engineered security controls. DevSecOps is about delivering value faster to business stakeholders and end users.
But what is value? This isn’t always straightforward as people have different perspectives and motivations. A roadmap will help define and align what value means. I am not going to explain in detail how roadmapping works — that deserves a blog in itself. But essentially, a roadmap will contain outcomes that need to be achieved to meet key organisational goals. Each outcome is divided into missions that the team translate into activities. Every single unit of work allocated to the team has to come from those missions and activities, otherwise there’s a good chance the team will be wasting time unnecessarily.
I worked on a project where the customer didn’t have a roadmap. The project owners from the client’s side gave us guidance on what needed doing. But the client’s senior stakeholders couldn’t understand the value. It was clear the client lacked a roadmap that aligned the senior stakeholders’ objectives with what the project owners were trying to deliver. We noticed the void on the client’s side and provided a product manager to guide the customer and ask tough questions about what they wanted to achieve — this formed the roadmap. It helped the client have a consistent understanding of what value was and how to measure it. It also gave our team an understanding of the bigger picture — and the wider context helps when you’re creating a product.
3. A clear backlog
The backlog translates the strategic vision given by the roadmap into smaller stories and tasks. The main difference between a good backlog and a bad backlog is clarity; each story or task needs to be understood by everyone. Lack of clarity, accentuated by tight deadlines, leads to inefficiency. For example, having to re-implement features because the requirement was not understood properly the first time around.
4. Metrics to measure
Having a way to measure the outcomes and missions established by the roadmap is fundamental. Metrics are normally agreed as part of the roadmap and can take many shapes and forms. Every digital service we build takes into consideration the metrics indicated in the 2019 Accelerate State of DevOps Report. It includes deployment frequency, lead time for changes, time to restore service, change failure rate and availability.
5. A wall (or even better, many)
I can’t imagine a DevSecOps team working effectively without walls and whiteboards. Sounds like I’m exaggerating, but I truly believe it! It’s key for transparency — and transparency is needed in an Agile and DevSecOps environment. It helps share information across the whole team and the customer.
We draw architecture diagrams on whiteboards and discuss them with technical stakeholders. We then take pictures of the diagram so that it can be easily shared digitally. We do this for Agile planning and retros, technical diagrams, security threat modelling sessions, product roadmapping etc.
6. A mindset to automate
Modern digital services are continuously evolving and so are security threats. To be successful in improving digital services, it’s important to get teams working on delivering real business value rather than performing repetitive tasks. This is why automation is one of the pillars of DevSecOps.
Traditional operation teams (Google called it the Sysadmin approach in its SRE book) were mainly focused on “keeping the lights on” in fairly non-changing services, reacting to issues when they occurred. Those teams worked on repetitive tasks. Software engineers, on the contrary, get bored with repetitive tasks and have the skills to automate manual work. Every member of a DevSecOps team needs to have the software engineer mindset and capabilities.
7. Effective communications
Poor communication between development, operations and security teams is the very reason DevSecOps exists. Getting everyone on the same page is fundamental to DevSecOps. Here are a few pointers that help Zaizi communicate effectively.
- Don’t assume everyone understands. Ensure the team and client are on the same page. It’s better to be repetitive than make false assumptions.
- Avoid siloed conversations/meetings. Whilst it is impossible and not always effective to have everyone in a meeting, it’s important to include the right people in the right discussions.
- Document and share meeting notes, actions and decisions.
- Use tools to enhance communications. Flexible working is common now but having colleagues working in different locations can be challenging. At Zaizi we overcome this by using collaborative tools, such as Zoom, Google Hangouts, Slack, Trello etc.
- Promote the culture of retro and feedback. It’s fundamental to ensuring everyone in the team has a voice.