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”.