Secure Scrum

For 10 years agile development has been finding more and more followers and practitioners. It seems like a sure bet that SCRUM will be the leading process skeleton for lean and agile project management. As for most new technologies also processes and frameworks go through a hype-cycle. At this moment we know a lot about the advantages of SCRUM and maybe we know too little about the pitfalls.

In the area of security SCRUM does have some dangerous assumptions which I personally believe will prove to be major challenges in getting security right in development projects. Let me just mention two here:

• SCRUM assumes that in the team everyone should be able to deal with all aspects of the solution, which would lead us to assume that all developers need to be knowledgeable in security controls and secure programming. However in all the successful projects that I have seen there was a security expert that joined the team almost on a daily basis. I believe the same is true by the way for other non-functional aspects like usability. Not sure what Ken Schwaber thinks about this but I firmly believe that the team works best if team members bring their strengths together. One is interested in security, another is interested in usability (and great design), a third is interested in database scalability and off you go with a great team :). It is good to have a backup in case someone leaves the project but that comes at a cost.
• SCRUM is a project management skeleton but not a software engineering process. Scrum does not tell you how to come up with requirements, it does not tell when and how to integrate and test, and it does not tell how to build a lasting architecture, nor does it have anything to do with secure coding practices. This is not to blame SCRUM for this. SCRUM is great because it is simple and it focuses on very few aspects like prioritizing resources and interacting with stakeholders.

All I intend to say here is; please don't try to invent a secure SCRUM because security is better placed in a solution development life cycle than a process skeleton. And a great lean process skeleton should not be overloaded. If anything SCRUM should be more specific about project and solution risk management. Two years ago an interesting column was posted on infoq (http://www.infoq.com/news/2008/07/managing-risk-with-scrum). 

What are your experiences?