Top 10 tips for organizing an Agile IT Security Team

This means that Agile IT security professionals need to understand access management; database security; application design; endpoint, network and server security; and physical security tooling. They need to understand the threats and risks that face an organization and be able to work well with other team members.

Agile security professionals frequently work in paired teams. When people work together, they are forced to reconcile any differences to ensure that they share the vision on a given assignment. The ability to reconcile ensures better understanding of the tasks at hand and how to approach them. It is difficult for both members of the security team to have a misunderstanding when they are required to work together to organize thoughts. Such an approach also aligns itself with the concept of mutual ownership, which means that anyone can fix anything, anywhere, when needed, which is another core function in Agile.

One Principle of Agile IT Security is the principle of collective ownership. Everyone on the team owns every artifact, solution and system. To achieve collective ownership you must consider reducing the area of expertise, or silo, and work on having more generalized team members as much as possible. By having people more generalized we reduce risks, bottle necks, and improve flexibility. We, in effect, become more Agile. By reducing specialists, we reduce the need for as much documentation. We reduce the bottle necks because multiple people on the team can do the same job that will allow a team to load balance work appropriately. It also reduces the risk of not having a skill set due to attrition. If someone leaves the company we have other people who can fill that role.

In Agile, we focus on small deliverables. Small deliverables allow us to build momentum with the team and to see completion early and to level pressure over time. Usually, when we have long projects, we end up missing the dates because the early months were not maximized. Small releases helps a team better manage a large project.

An Agile Spike is used whenever a team is faced with implementing a solution that is not fully understood. A team may be struggling with a number of issues such as the amount of traffic a solution will see, or the number of users that a solution will have. A Spike is a pilot project that attacks risks. Agile Spikes are always time boxed to reduce the risk of scope creep and keep our project on schedule. Whenever a team is faced with uncertainty when implementing a solution, Agile teams will look to create a Spike. Essentially what we do is create model architecture of our solution with our best guesses as to how the system will behave. Once the Spike is developed we can watch and observe this model to better understand how the real solution will behave in production. Our goal is to understand how it is going to behave and learn any early lessons before we begin the real project.

Failure is a huge form of waste but is relatively unavoidable when delivering any new security practices. So the best way to minimize waste is to fail fast. To fail fast you must create an environment were failing is expected and encouraged. When team members are comfortable with the idea of failure, team members will be more vocal about failing and ask for help.

Project Velocity measures the effort involved in delivering the project. Understanding how a team is doing in terms of understanding the requirements and the rate at with the team is working is helpful in understanding if dates are going to be met.

Collaborating together as a team is one of the hallmark principles of Agile mostly because of the simple idea that two brains are better than one. Collaborating comes in two forms, collaborating with a team in the same physical location, and collaborating with a team in geographically different areas. Considerations should be made to help facilitate the collaborative process for both physically located and geographically distributed team.

One of the ways we can estimate the time needed to complete a project is to use a trick learned in the Agile software development community. It’s time to play a little poker. Poker? Yes poker. Using Agile Poker cards, timers, and basic Agile Poker rules we can have a little fun while achieving unparalleled accuracy when planning time.

The game ends when all members agree upon the amount of time needed to complete the project. Or the project owner, the person who will be responsible for delivering the project sees a majority vote that seems reasonable.