Microsoft’s new SDL Perpetuates Some Misconceptions of Agile

Recently, Microsoft published its updated Security Development Lifecycle (SDL), version 4.1a. It includes provisions for incorporating security tasks into Agile development, so naturally I was interested to read it. While on balance I understand what Microsoft is trying to do with this effort, I found a few misconceptions and knocks on Agile that I felt were unfair and disconcerting.
The chief misconception of Agile that I see perpetuated in this document is that Agile releases after every sprint (iteration). While this is possible, it is not necessarily the case and certainly not required by the framework.

On p. 47, in the section on “Melding the Agile and SDL Worlds,” the authors make the statement:

“With Agile release cycles taking as little as one week, there simply isn’t enough time for teams to complete all of the SDL requirements for every release.”

There are two issues with this statement, and similar statements throughout the document. First, the statement assumes a release after each sprint. Agile focuses on producing potentially releasable product in every sprint – and this is an important distinction. As you use Agile in your organization, if you don’t need to release after a one-week sprint, then don’t release. There’s no rule that says you must. Second, the statement seemingly knocks Agile for having sprints (they say “release cycles”) that are ‘too short’ to accomplish all the necessary tasks for SDL requirements. Again, there is no hard and fast rule here for Agile, other than the strong suggestion (call it a rule if you want) that sprints should be time-boxed to 30 calendar days maximum and that sprints stay the same length for consistency. But a team and Product Owner can choose a sprint length that is appropriate for their development model and business needs…if a team is choosing one-week sprints but can’t fit in security tasks deemed necessary, then the sprint timeframe needs to be lengthened.

There were also a few statements with respect to Agile and security in general with which I took exception. In the Introduction on p. 47, the authors make these statements:

“Historically, security has not been given the attention it needs when developing software with Agile methods.”

“There is a perception today that Agile methods do not create secure code, and, on further analysis, the perception is reality. There is very little “secure Agile” expertise available in the market today.”

The problem here is that the authors blame Agile methods for this shortcoming (real or perceived), and not the implementation of those methods, or rather the prioritization of the requirements or user stories undertaken in those Agile methods. If security requirements aren’t being given the attention they need, that’s flat out a failure of prioritization of the requirements by the Product Owner, not a failure of the methodology. You could conduct a sprint consisting entirely of security-related requirements, if those are the top priority, and that would be perfectly valid. Also, the very notion that there is little “secure Agile” expertise in the market is a logical fallacy called a “Complex Question”: unrelated points conjoined as a single proposition. In other words, there’s no such animal as “secure Agile.” There’s Agile. Security is but one consideration among others that can, and should, drive the prioritization of a product backlog.

I then came across this little gem of a paragraph on p. 50 of the document:

“Although SDL-Agile was designed for teams with short release cycles, teams with longer release cycles are still eligible to use the SDL-Agile process. However, they may find that they are actually performing more security work (emphasis added) than if they had used the classic, waterfall-based SDL. Requirements that a team only needs to complete once in classic SDL may need to be met five or six (or more) times in SDL-Agile over the course of a long project. However, this is not necessarily a bad thing and may help the team to create a more secure product.”

This smells to me like the framers of Microsoft SDL-Agile decided that there were certain security requirements that needed to be performed every sprint without consideration of the release schedule of the product. And, in fact, they seem to admit to as much in the preceding paragraph. This is all well and good, I suppose, if you’re OK with doing five or six times the required work for a release as you could otherwise do. But if that’s so, why would one ever choose to do that?

I’d like to offer a couple of options for the SDL-Agile folks to consider. First, remember that Agile doesn’t require you to release after each sprint, only that you produce potentially releasable product.  Second, consider using a “Release Sprint”: a sprint of those activities required before a release that may not be required in each development sprint. This could contain security-based stories as well as other typical release-related activities like, perhaps, user acceptance testing or compliance reviews. But my overarching advice to them, and to you, is to not let misconceptions of Agile hamper your implementation of it. Instead, just understand and respect the basic framework, and look for opportunities to apply the framework, principles, and culture of Agile within your organization. Do those things and I suspect that you’ll be pleased with the results.

As always, I welcome your comments.