This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Agile in Security Operations Centers - what's your take?
#1
Our entire organisation has chosen to shift towards an agile approach. We've been doing agile (to be exact: scrum) in our security operations center for about a year now. I wanted to share some experiences and lessons learned:
  1. Moving to a scrum approach is not an easy transition to make. It takes some time and some frustration among your team members. It is important to keep an open culture in which you can express concerns and frustrations and address them.
  2. Scrum revolves around teams of a maximum of 7 people. A higher number is possible, but will make sessions longer and more complex. It may be difficult to find a way to split your team into smaller teams, while still supporting your SOC services and sharing knowledge within the teams. You should also be careful not to introduce process handovers between teams that introduce additional overhead.
  3. Scrum is not intended for operational departments. This means you shouldn't be too strict in implementing scrum rules. In short: make agile work for you, not the other way around.
  4. If you want to make scrum work, you will need a dedicated scrum master. This could be someone from the team. Just realise that this person will be tasked with optimizing the way in which the team works and matures in its agile approach and will have little time left for actual operational security tasks.
  5. There's overhead in the scrum process. It will likely replace several team meetings, but introduces other meetings. This overhead does serve a purpose: to gain visibility in the team workload and make the activities of the team more transparent.
  6. If done properly, scrum can help you accelarate the improvement of your SOC. This is because there's a clear understanding of the tasks at hand and a continuous flow of improvements (stories) that can be conducted.
  7. Not everything is a 'story'. Don't put eveything in your backlog, just the improvements. Operational stuff, such as monitoring duties should not be in there. That's just administration for the sake of administration.
  8. Kanban may solve some of your problems, but introduces others. There's still sessions, there's still planning and there's still a backlog. The basics are similar.
  9. Leave enough room in your sprints (if you've adopted scrum) to do ad-hoc stuff that wasn't foreseable.
  10. Seek to understand and optimize the amount of work a team can perform in any sprint while also responding to ad-hoc requests while having an acceptable workload.
  11. Backlogs can be used as an excuse not to act immediately. This actually makes you less agile. While this seems to be a contradiction, it wil happen if the team has a high workload.
  12. Clean you backlog every now and then. If a certain task wasn't given sufficient priority in the last few months, why should it get any priority in the next months?
Note: scrumban (a combination of scrum and kanban) is also possible. We're only just looking into this, so no lessons learned here yet.

I'm curious as to the experiences of others regarding implementing agile in security operations. What added value did or didn't it bring to your SOC?
Keep calm and share knowledge
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)