When discussing Agile development, I like to say that the only people who achieve success advocating Agile 101 process adoption by the book are the people actually writing and selling the book. The rest of us need to be flexible when employing the process in the real world of software development.

Agile is not a methodology to be used for fixing things that aren’t broken or for forcing process for the sake of process. In other words, to be successful, we need to be agile with Agile.

Challenges of Agile Adoption

One of the biggest challenges of the Agile adoption framework is identifying real and useful motivations behind the theories and not thinking of the process as a checklist of immutable instructions. Any well-applied software development process should enable, not impede, success.

Security professionals should adhere to these processes for specific and quantifiable reasons, not simply because managers mandate they do so. The processes are designed to deliver high-quality, secure software in a rapid environment, and to eliminate traditional pitfalls common to the waterfall, functional specification, extended delivery planning and development strategies of yesteryear.

For the process to function as a valuable and real enabler for the team, we need to shape and adopt it to our real-life software delivery needs. Early struggles to adopt may be due to the natural difficulty of change; often its value isn’t immediately recognized. In those cases, it’s important to work through the growing pains and give the new approach a fair shot by inspecting and adapting the adoption process as you go.

Eventually, the team will either discover real efficiencies and value from its efforts or conclude that particular aspects of the process just aren’t working. At that point, don’t be afraid to jettison or reconfigure the unsuccessful parts and simply move on.

Inspect and Adapt

To make Agile work, the principle of “inspect and adapt” should be applied to all aspects of the process — from user story formation, definition, breakdown and design to iteration planning, estimation and daily scrum execution.

People typically think of Agile adoption as it applies to process execution — how are my user story breakdowns going? What can we change to make our estimations more useful? How are new requirements or critical support engagements affecting my iteration commitments? Usually, these topics make up the bulk of a sprint retrospective discussion. In that regard, it’s a very useful approach and mindset to iteratively improve the scrum team’s execution from sprint to sprint.

The inspect-and-adapt approach should also be employed in the actual delivery of the functionality, specifically in testing cycles, as new pieces of user stories are implemented. We too often approach a sprint as a mini-waterfall, essentially allotting the first two-thirds or more of the iteration for development and the last one-third or less for stabilization testing and documentation of features.

That approach frequently leads to user stories being unfinished at the end of sprints and activities either bleeding into the next sprint or becoming deprioritized or shuttered entirely at the following planning session. In addition to making the scrum team’s commitment level less predictable at the next sprint planning, this results in lower quality and less secure software being released with each sprint.

Forrester Research Report: Secure Apps at the Speed of DevOps

No Surprises

The Agile process doesn’t like surprises, lingering questions or other unknowns throughout an iteration. More than anything, that applies to the final software product being built and delivered, especially as it relates to the level of quality and security expected from the software.

To achieve an acceptable level of security, quality code must be iterative throughout the sprint, meaning that we must perform testing throughout the process to find bugs, defects and other vulnerabilities early. We can’t wait until each user story is fully completed, and we certainly can’t wait until the very end of the sprint. This is challenging because it can take considerable time to write code, and testing teams generally have a limited number of dedicated quality, testing and security resources.

The theoretical book on Agile 101 would advise that anyone on the scrum team can take on any task or workflow throughout the sprint. Therefore, everyone on the team would a potential tester. In the real world, however, we know it typically doesn’t work that way, at least not in any sustainable fashion. You can only rob Peter to pay Paul so many times before you’re going around in circles, reducing the effectiveness of both your testing and coding efforts.

DevOps to the Rescue

Here’s where automation and DevOps can save the day. Like anything else in Agile development, it can be hard to find time to invest upfront costs in these kinds of exercises. However, a stronger focus on these elements should not come at the expense of getting your regular work completed. They should be viewed as critical tools for a scrum team that wants to operate efficiently and predictably to deliver secure, quality code with every iteration.

Of course, this mindset can run a bit contrary to the traditional Agile philosophy that directs a scrum team to adjust constantly. But in many ways an initial investment in automation and DevOps, combined with ongoing investments in maintenance, updates and supporting automation and a commitment to the DevOps model, can serve as perfect compliments to that development theory.

Having the right automation in place allows coders to code furiously and enables dedicated testers to build and execute acceptance test and use cases. Most importantly, however, it allows for continuous testing throughout the sprint, almost from the minute the first line of code is written. This is critical to ensure the highest level of secure, quality code goes out the door at the end of each iteration.

To learn more about improving your organization’s DevOps effectiveness, consult our complimentary Forrester Research report, “Secure Applications at the Speed of DevOps”.

More from Application Security

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Twitter is the New Poster Child for Failing at Compliance

All companies have to comply with privacy and security laws. They must also comply with any settlements or edicts imposed by regulatory agencies of the U.S. government. But Twitter now finds itself in a precarious position and appears to be failing to take its compliance obligations seriously. The case is a “teachable moment” for all organizations, public and private. The Musk Factor Technology visionary and Silicon Valley founder and CEO, Elon Musk, bought social network Twitter in October for $44…