Agile, Security, & Compliance—Exploring the Tensions
Can security, compliance, innovation, and Agile methodologies coexist? On September 17, 2019, in Austin, Texas, a TechDebate panel of Agile and technology experts will gather to address this question. To get a sneak preview, I had the chance to talk with one of our panelists, Will Simpson, founder and CEO of the consultancy Ten Eleven Twelve. Will is an executive leader and business transformation expert with a track record of turning around underperforming departments and accelerating growth in business units, teams, and products by leveraging Agile and Lean philosophies.
For more information or to register for this debate, click here. Also, we’re always on the lookout for debaters—if you have something to say, let us know by contacting Ben Bradley (our director of marketing).
Do you see a fundamental tension between Agile practices and security and compliance?
WILL: To answer your question directly, there is not an inherent tension among Agile, security, and compliance. However, within most organizations, there is a tension that comes from Agile being done incorrectly, not from the Agile philosophy itself. The tension is typically rooted in people not viewing security and compliance work as potentially equal in importance to new product features in the backlog.
Because Agile enables teams to go fast, producing results ahead of what product marketing is historically used to, a member of the development team will often create security holes. The product team will typically continue lobbying for new features rather than considering the needed security work on par with the desired new features. The security work is too often delayed, and a small problem can easily become a big problem.
This is not the Agile philosophy’s fault. Rather, it is the implementation of the methodology that is at issue.
So, is the tension security and compliance versus product management tension?
WILL: When addressing this tension, culture beats strategy every time. Your culture needs to operate as an umbrella, with your product team part of your engineering team and your engineering team part of your product team. They should not be separate entities. Even if your organization manages these teams separately, and human resources separate them on the org chart, the product and engineering teams need to function as a single team. In my opinion, until you get that done, you’re not going to solve the problem of effectively prioritizing technical and product issues.
Worse yet, there’s a tendency to divide in directions that aren’t delivering business and customer value anymore. With the teams united in the overall objective of delivering value, you can have a unified Agile backlog where all issues—product, compliance, security, and so on—reside within one backlog.
How can we best balance the need to innovate quickly to maintain a competitive advantage with compliance and security issues?
WILL: The way to balance product and security and compliance issues is with a true understanding of the larger picture. By stepping into the other team’s shoes, you can truly understand how to better prioritize. Maybe a new product feature is a top priority because the security and compliance issues in the backlog are not likely to be significant problems. The pending security and compliance issues are not, in this case, high priorities, but you need new product features to grow or maintain the business.
However, if there are security and compliance issues that can cost the company and customers significantly in money, time, and reputation, you need to bring that work forward possibly prioritizing it above new product features.
A unified backlog allows you to look at everything that is before the team and decide what will deliver the most customer value either from the standpoint of risk management or product functionality.
How has cloud computing affected security and compliance considerations?
WILL: Security and compliance in the cloud are all about understanding your cloud. Whether the cloud is in your own environment or public, you have to gain an understanding of what you can and can’t control. You need to know when you must rely on the provider for security and when you can provide your own.
If you are on a third-party cloud, you have to understand the security and compliance measures the cloud provider is using for its basic infrastructure and the security environment of your specific implementation, which is a completely separate issue. Just as PCs and Macs tend to have different problems, cloud providers also have different problems. There is always going to be a certain amount of bugginess that you have to address, so you need to understand the more likely problems to occur within your cloud.
The cloud computing environment is complicated, but that’s not the problem; it’s always been complicated. The problem is that the cloud computing landscape is confusing.
Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.