Agile Software Engineering & Computing Security…two catchy buzz-phrases from the current world of software. Now, at first glance one probably can’t make the immediate connection between the two. So stick with me for a second. I’ve recently been introduced to formal Agile methods (Scrum) and I have to say that I’m really enjoying it and seeing the value. However, I’m am also starting to see why many organizations fail in their initial endeavors into Agile.

Here’s the simple case at hand. My current project involves distributed systems, scalability, and the rough notion of Software as a Service (SaaS). In that, an experienced engineer will quickly rationalize some level of security. Here’s where Agile gets very difficult. My project has started from scratch with three core engineers. Because we are focusing on specific system behaviors during each sprint (including learning some very key technologies) we are not looking to the proverbial horizon. Security, in a very rough form, HAS been captured in the projects backlog. [But, I believe this partly due to the fact that we are generally an other-than-commercial company - and in this case security is part of the company DNA.]

It would be very, very easy for us to get in to full-on development mode solving many problems, while overlooking how security (and thus scalability) fits in to the picture. My previous experience with Agile was a modified XP environment…and this very thing happened. It didn’t really occur to me why, until just recently. We were so focused on meeting the customer’s immediate requirements that we painted ourselves into a “security” corner. I realized late in the game that our infrastructure was not capable of locking down the way that we needed - and much work was needed to get to a satisfactory point. The development/engineering process will take the hit…and traditionalist will say “if you had just done more systems engineering.”

Security is just one aspect of design, that if not enforced from day one as a sprint requirement/task, is almost unrecoverable on the back end. I can only imagine that there are many other “gotcha things” that would wreck an Agile process, and the ability to delivery what the customer really needs at the end. Fortunately, I work with enough “wisefolk” that prevent front-end failure. Again, I can now understand why many Agile attempts hit the wall.

I’m not saying that Agile is at fault. But, I can see how Agile just gets going - and without good oversight and very experienced engineers will eventually get hit with a 2x4.