Continuous improvement is a fundamental part of any security standard or security management system, so during my career I have had the opportunity to implement, manage or audit different approaches to implement it.

As in the last years I’ve also been exposed to agile development methodologies, I have equally had the opportunity to see close up how continuous improvement can be managed by using the retrospective ritual as part of the scrum ceremonies.

A scrum retrospective is basically a meeting where all the team considers about how the last sprint was, identifying what went well and what didn’t go well. The goal is to come away with a proposal of how to modify the process that everybody on the team agrees with and is committed to for the upcoming sprint.

Sounds simple and it is. And it is this simplicity that surprised me when I realized how powerful and efficient this continuous improvement tool is: by investing 30 minutes on a bi-weekly meeting I saw tangible improvements and results on the morale and the efficiency of the team as well as the process the team was using.

From my point of view, the main advantages of using retrospectives are:

  • Doesn’t require a big investment; 30-60 minutes at the end of each iteration is enough.
  • Being a bottom-up approach has the extra advantage that helps to motivate the team since it’s empowers decision making and is self-organized.
  • The changes are tried on short cycles – if a proposed change does not work, it’s easy and quick to revert to the previous situation

Essentially, the scrum retrospective was created to improve development efficiency and scrum team motivation, so it’s true that it only works well with small teams, less than 8-10 members. However, I’m fully convinced this tool is also applicable to other fields within the security sector to improve the efficiency of any work team and improve security management processes.

We can imagine, for example, security consultants, penetration testers, MSSP or security integration teams using this retrospective approach to drive improvement on the processes used to manage their services or projects as well as being a tool to improve the communication and the motivation of those teams’ members.

It can be a really useful tool as well for a corporate security team by using retrospective as a way to improve the efficiency of the internal security teams. It also helps identify aspects that didn’t work well in the last cycle and find initiatives to improve those aspects in the near future. In order to do this, security professionals could use retrospectives on top of the post-mortem analysis on security incidents to get a wider perspective on, for example, the security incidents that happened during the last cycle (week, month, year…). The two key questions to be asked on those security retrospectives could be:

  • What went well on my security processes during the last iteration? What security incidents have been effectively detected, contained, eradicated or recovered? What are the security controls that helped us to be successful there?
  • What went wrong on my security processes during the last iteration? What security incidents were detected too late or were not properly contained, eradicated or recovered?

By analyzing the answers to these two main questions, the security team will better placed to select which initiatives should be accorded high priority and implemented during the next cycle – improving system efficiency being the basis for implementing a continuous improvement policy that provides tangible results.

In conclusion, it’s true that retrospectives can’t completely replace other traditional approaches for continuous improvement. But I’m convinced that it’s a really effective tool to be applied to a very wide range of situations so it should be always part of the toolbox of any team, service or project manager, not only in the development sphere but also in the security one.

Kudelski Security Team