Sometimes, It's the Little Things...

Sometimes, it's the little things that make all the difference in the world for people...like the person that buys a $30k car just because they like where the cup holders are placed. Yes, I laughed at that too, but I've actually seen that happen.

Clients are people too, and I like to look for opportunities to provide a "better than expected value" for them. By that I mean, not just confining ourselves to what the SOW says we're to deliver, but other opportunities to deliver added value...whether it be handling little ancillary issues for them from a project management standpoint, or some helpful little documentation, or just a quick interpersonal check-in.

One way I go about this is I routinely (maybe daily) ask the stakeholder(s) "How can I help you? Is there anything I can do for you?" But you have to really mean it...come at it from a personal approach. The way I look at it, if it's something that lies outside of my realm of job duties, but isn't anything much to do, and helps them...it's worth a lot more in client relations in the long run than the few minutes it may take me to do. Maybe it's scheduling a meeting for them that they were going to schedule, but we're both attending, so I’ll do it. Sometimes, a client may be just overwhelmed with their workload and really flustered, and while there may not be anything I can do for them at the moment to lessen it, they appreciate just being asked. They like to know that someone just cares as a person. (NOTE: If you’re just not that kind of person, don’t attempt this. Being disingenuous with this is worse than not doing it at all)

Another way I've been doing this, as I alluded to, is supporting documentation. I’m talking about little “extras” that help the client, and might be something we would find useful ourselves anyway. By that I mean, we're not burning cycles producing some frivolous document just to provide that "added value" (i.e. make work), but something that they can actually use, but aren’t expecting...think Lean, and the categories of Value-Added, not Value-Added but Necessary, and Waste. Avoid the Waste.

Recently, I worked on a solo project for a client. There was a basic process logic flow that was an early deliverable, but there was one extra request from the client to annotate it. The annotation wasn't in the strict SOW, but I did it and in addition, color-coded the map by processing module to make it even easier to follow. As a result, It proved to be a valuable tool to for the client to easily communicate the logic of the application to both business stakeholders and technical staff. And while a lightweight technical manual was in the deliverable, I added details that weren't defined...such as including that diagram, writing detailed install instructions, etc. Again, these weren't strictly required, but were just something I wanted to include to make things a little easier, a little nicer for my client. And they appreciated it, which is what really made it all worthwhile.

Like I said, sometimes it can be those little details that really make the difference.

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.