Agile Security

I was first introduced to Agile methodologies in 2014, as the company I was with at the time started moving from a Waterfall approach to Agile with our development teams.  These agile teams typically consisted of a business analyst, scum master, back-end developers, UX developers, and quality assurance analysts. Security had not yet found its place in this new structure, however, we quickly learned that adopting a hybrid form of “ScrumBan“, a combination of Scrum and Kanban, would work out very well for our team.

Initially, to familiarize ourselves with how the development teams were now operating, the Security team formed it’s own scrum team. With scrum team names for the development teams such as “Dizzy Grizzlies” and “Thirsty Goats”, the Security team appropriately adopted the name “The 443”. Two week sprints were selected, and daily 15 minute stand-ups were scheduled. We became familiar with concepts such as “stories” and “epics” and activities such as “sprint planning”, “retrospectives” and “demos”.

Stand Up!

An Agile “Stand Up” meeting, is a brief daily 15 minute scrum team meeting. As you may have guessed from its name, these attendees typically remain standing for this meeting to encourage brevity and keep things moving.

The purpose for this meeting is for each team member to summarize:

  1. What they accomplished yesterday
  2. What they plan to accomplish today
  3. Any impediments or roadblocks are preventing them from completing tasks

This promotes team ownership and awareness of what is happening within the team. Often team members are able to assist each other with issues they are facing, or the scrum master will work to help remove impediments.

Tell Me a Story

In Agile terminology, a “story” is a technical requirement, written in as few sentences as possible using non-technical terminology. A story for the Security team may be “Perform periodic user rights audit”, ”

Stories accumulate in the “backlog” queue. Once ready to be worked, they are pulled into the current sprint where they are tracked on the scrum board categorized into states such as ‘To Do’, ‘In Process’, ‘Needs Testing’, or ‘Done’.

Mind the Backlog

New stories and tasks are added to the backlog, with is a living list of items of various priorities that will need to be evaluated, researched, or worked. The team schedules regular “grooming” meetings to review the backlog and prioritize backlog items. Prior to beginning each spring, items are brought into the new sprint from the backlog.

In our structure, it was not uncommon as priorities shifted for items to be removed from the current sprint, to be addressed at a later date.  One of the unexpected benefit our team has seen many times when grooming the backlog, is backlog items that have been pending for some time being closed out as complete as a result of other activities that have taken place.

At a director level, the backlog gave me a consolidated space to manage priorities, assign stories and tasks to team members, and maintain an overview on what workload was in the pipeline for the team.

Planned Work vs Responsive Activities

One challenge we faced as a Security team implementing Agile centered around how to handle responsive activities. Typical development teams have very structured workloads and sprints. They take in a set amount of work they believe they can complete within the sprint and chip away at it each day.

While Security teams have some level of predictive workload, there is also a significant element of responsive activities that come up each day. To address this, we remained very flexible within our sprints, having our scrum master move stories in and out of the sprint, as necessary. This allowed us to maintain visibility of all pending activity on our scrum board, while remaining flexible to react responsively as business and security demands changed.

Team Accountability

The primary benefit that I always identify from adopting Agile team structure is the team accountability. Each team member is held responsible for completing the work assigned to them. This workload is visible to everyone on the scrum board, and it is encouraged for team members to hold each other accountable when they see tasks or stories stalling with little or no progress.

Each sprint, the team as a whole, is responsible for closing out the items in the sprint. This means the incentive is there to work together and help each other out. We all succeed as a team!

Further Reading