So at the end of March, I gave a talk at CypherCon in Milwaukee on this. While the title is a bit irreverent, with: When Management Asks You: “Do You Accept Agile As Your Lord and Savior?”, but it comes from multiple discussions with people in the Infosec Field. Too often someone from Senior Management comes in and says that the company or organization is going to apply Agile Methodologies in order to improve performance. But rarely, is this change attempted with change attempted at all levels of management and staff. This means that it’s either up to the Managers to push implementation of specific techniques, such as Scrum, Kanban, Scrumban, SaFE or other methodologies with their teams, with very limited input or acceptance from staff. Or someone from the staff has been assigned the position of Scrum Master and it’s their responsibility to implement these changes within their team, with little input or acceptance from their direct Manager or Management as a whole. This leads to constant failures that have lead to quotes like “Agile is dead”, “Agile doesn’t work”.

The reality behind Agile and its methodologies, like many things, is to adapt it to one’s own Company or Organization’s own procedures and policies, and at the same time adapt those procedures and policies to Agile. You can’t force things one way the other, it’s literally a two way street to do this. But wrapping one’s head around what is Agile can be a bit off putting, since often the first thing people see, is the manifesto…

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto

This is so specific to software development, that it creates problems in understanding what an Operations team, or a SecOps team is actually supposed to do with this. The manifesto actively negates basic principles, policies, and procedures in Operations. Does that mean we get rid of them? Do we ignore them? Honestly, as with any manifesto, it doesn’t help the actual cause it’s fighting for.

Individuals and interactions over processes and tools

SecOps and Operations face issues regarding compliance, regulatory requirements, and insurance policy requirements that have to be met, and often are linked to specific processes being laid out, defined, and implemented. Tools, it often depends on one’s budget, but there is always a minimum set of tools based off of the Operations Program you’re running. Does the manifesto mean they’re all useless and unimportant?

No. In this case, it establishes the idea that you trust people to work together and collaborate, and that they have the required knowledge and experience to do their work with minimal oversight. The existence of Scrum and similar rigid methodologies kinda goes against this, but the key here is team management and communication. Teams should know what they’re doing (having a direction from Product Owners, or their managers), they should communicate daily with their leader to show what they did yesterday, what they’re doing today, and any problems they might be facing in getting their work done. That’s the key takeaway from this line.

• Team sizes should be easily manageable. The fewer people, the simpler the communication lines are
• Team Leaders should communicate with their team members frequently, if not daily
• You consider your staff as knowing what they’re doing, and trusting that they will do things correctly (High Trust)

Working software over comprehensive documentation

Working Software in this case just means the final product. But this is also a bit questionable regarding Operations, as Ops and SecOps are often considered loss centers for a company, they don’t actively make anything. You have to go down to thinking of what work actually is. In this case, it’s better to look at “Work” from the concept of a factory.

Through work, raw materials are transformed into finished product. It is essentially a transformative process.

But what are the raw materials now? Simple, Projects, Incidents, and Tasks/Tickets. They either create change in one’s managed platforms, or allow the continued execution of additional work by other teams. The goal of this line is basically reminding us that our main goals are to meet PKIs and SLAs as much as possible.

Documentation in this case doesn’t mean playbooks, but the documents that are routinely shared with third party regulators. I don’t mean that you don’t do that, but that ideally writing these reports out shouldn’t be the responsibility of the teams. Ideally they can provide the information and data that a dedicated or assigned technical writer can use to actually do this work.

Customer collaboration over contract negotiation

Here’s more communication. In this case, the customer, or product owner, is often Management in Operations divisions or teams. Call them what you want, Project Managers, Product Owners, Managers, Beelzebub (Ok, just kidding with the last one). But in general, the person that’s indicating the direction of work for Team Leads is going to be the Manager. And there’s only one basic concept behind this.

• Teams should know what their objectives are, and that they are clear and actionable

These objectives are essentially just Project Goals (relating to Projects that are dealt with across an entire Company/Organization, or just a single Team/Division). They should be well defined and attainable within reason.

Responding to change over following a plan

This one is fun. It’s where Waterfall comes in (or goes out the door). We’ve all seen and had to deal with Gantt charts. And as a general understanding, they’re out of date rather quickly once a project starts. The idea behind this is pretty simple, not having single large tasks assigned to people or teams. The larger the task, the longer it takes, and the less of a chance you can easily manage if a team member leaves, plans change, or something happens that stops work. The project is basically stopped and can’t continue unless you get someone introduced to a project in progress. You can’t easily transfer someone from their own project if their own tasks are monolithic. And situations like COVID where Company/Organization were forced to quickly enact changes to both infrastructure and business structure, delaying or stopping projects.

• The more atomic (smaller) the work (tasks) are, the quicker they can be done.
  • the easier tasks can be transferred between staff
  • the easier to expand or contract the size of a team as needed
  • the easier to adapt to the changing socioeconomic situation the Company/Organization is faced with.

So overall it’s not that bad, but it’s not easy to parse out the concepts behind the Manifesto for anything outside of development. But it can be done, and the main concepts are simple and foundational. Here are the points that we get from the Manifesto:

Keep Teams Small To Keep Communications Simple,
Project & Operations Work Are Prioritized, Delegate What You Can,
Management & Team Leads Should Be Clear In Their Objectives, Make Sure They’re Actionable
Subdivide Work In Smaller Tasks, It Helps Teams Respond To Changes

Operations Synthesis of the Agile Manifesto

Anyways, I’ll be covering the 12 principles in my next post.