Continuous Improvement is a key tenet of DevOps – we always strive to be better and accept that every process, tool and resource can be improved upon to help our team reach its goals.

I would say that continuous improvement is a goal that most people share in some way – as humans, we always want to be doing our best! We want to grow and evolve over time. But how do we actually make continuous improvement an active and tangible part of our team’s activities? How do we know what to improve? How do we know if we are improving?

PLAN, DO, CHECK, ACT

Continuous improvement is just that – continuous. It operates in a cyclical way, and as such it fits in well with teams working in Agile or iterative ways. Teams that often have opportunities to pause, reflect and change what they’re doing to keep themselves on the right track.

Many Agile teams will have experience with the Deming Cycle, AKA ‘Plan, Do, Check, Act’. This may already be implemented in your teams as a process for improving your work product, but what about as a process for improving your team?

By this, I mean rather than looking to improve the output of your team – whether thats software, hardware, documentation etc. – look to improve the way your team operates. This is what separates DevOps work from other areas of software development.

So what does this look like in practice?

PLAN

This is where you work out what to improve In DevOps, this is often the trickiest step because of how multifaceted the work can be. Start thinking about your scope: Where are the biggest gaps? Where are the biggest wins? Is it documentation, automation, training, testing, or something else?

DevOps is also all about collaboration – you are there to serve the team. So make sure you involve others in your discussions, get their ideas and feedback on where their biggest problems lie or the biggest opportunities are. There are lots of ways to get this feedback, such as:

• Instant Messaging, like Teams or Slack;
• Emails;
• 1:1 calls;
• Team meetings;
• Feedback forms;
• Anonymised feedback tools like Mentimeter.

Once you’ve decided on your scope and gathered your data, the final step of planning is to secure the buy in of others. Present your plan to everyone, outlining your proposed actions and their impact. Remember, it’s unlikely that everyone is going to agree with you, but if you can justify your plan and get enough support it’s still likely to be the right direction for the team.

DO

Now to get into the nitty gritty! Put your plan into action. This can start of with making tasks or tickets in systems like Azure DevOps, GitLab or Jira and defining your tasks at a more granular level. The key thing to remember in the DO phase is record everything. Make notes of what you’re doing, update your task tickets, report on your work in team meetings.

Why? To demonstrate impact. A problem for those working in DevOps can often be that the impact of our work is often hard to measure because we are rarely doing work that brings in revenue directly. Rather we indirectly help teams save money by improving processes and delivery time, and improving the satisfaction of our team members. But recording what we are doing and what the benefit is, we build up evidence for how our work is helping the team succeed.

Another important thing to remember in the DO phase is to not bite off more than you can chew. Continuous improvement is cyclical, and also flexible to change. Focus on making changes and improvements that can be delivered in your sprint timeframe, can be adapted, and are less susceptible to scope creep.

CHECK

All the evidence that you’ve recorded in the DO phase comes into it’s own here. Use the data, metrics and feedback that you’ve collected to check you are on the right path. Did your actions have the intended consequences? You should check this in two ways:

• Quantitative Measures: These would be metrics like delivery time, number of documents, or number of code defects. You can use Continuous Integration/Deployment (CI/CD) tools to help automate the collection of this information.
• Qualitative Measures: This would likely be feedback from your team about the effectiveness of the changes in their development processes. Are they happier? Collection of information is difficult to automate, but can be gathered using the methods listed in the PLAN section.

Both of these types of measurements support each other, and are of equal importance. Metrics alone don’t paint a full picture and there are some aspects that can’t be measured numerically. Likewise, qualitative feedback will always be subjective and not paint a full picture. So looking at the two together gives the best overview.

ACT

Finally, based on your checks, see what needs to change before you plan any future work. Were your methods of gathering feedback effective? Did you run into any obstacles during the DO phase? Were your timescales and deliverables realistic? This is a chance for your DevOps processes themselves to be evaluated and improved, and its critical this reflection happens before any future changes are planned.