10 years since the creation of the Manifesto for Agile Software Development, Paul Krill of Developer World asks: Did it deliver? Unfortunately I don’t think he adequately answered the question in his article. So let me say that the answer is an emphatic “Yes”, as it has provided several templates and tools for solving problems with people and process. And it has to be judged a success because it has provided a means to conquer problems other development methodologies could not.
That said, I can’t really blame Mr. Krill for meandering around the answer. Even Kent Beck waffled on the benefits:
“I don’t have a sound-bite answer for you on that.”
… and said Agile has …
“… contributed to people thinking more carefully about how they develop software, … There’s still a tendency for some people to look for a list of commandments”
It’s tough to cast a black or white judgement like “Success” or Failure” on Agile software development. This is partially because Agile is really a broad concept with different implementations – by design – to address different organizational problems. And it is also because each model can be improperly deployed, or applied to situations it is not suited to. Oh, and let’s not forget your Agile process could be run by morons. All these are impediments to success.
Of course ‘Agile’ does not fix every problem every time. There are plenty of Agile projects that failed – usually despite Agile tools that can spotlight the problems facing the development team. And make no mistake – Agile is there to address your screwy organizational problems, both inside and outside the development team.
Kent Beck’s quotes capture the spirit of this ongoing discussion – for many of the Scrum advocates I meet there is a quasi-religious exactitude with which they follow Ken Schwaber’s outline. To me, Agile has always been a form of object oriented process, and I mix and match the pieces I need. The principal point I am trying to make in my “Agile Development, Security Fail” presentation is that failure to adapt Agile for security makes it harder to develop secure code.
Reader interactions
3 Replies to “The Question of Agile’s Success”
“This model scares people because tons of work happens before much product gets built”
Yeah, ICONIX is not BDUF, but I’m sure someone’s mistakenly called it that before. The DDT (Design-Driven Testing) approach seems to clarify this more, but I’m sure there will be proponents.
The iterative demo approach of Scrum is quite nice, too, though—I’m not going to argue against it, but it is really hard to integrate security into this model unless you somehow trick the dev team into it (which isn’t how appsec should work).
“That sounds suspiciously like threat modeling and design. Am I missing the subtitles of the statement?”
Yes, appsec risk management gap analysis should work like ISO 27k gap analysis. The risk management team (or information security management team) looks at the list of currently implemented controls and compares them to the minimum standard controls, as well as optimal controls. The idea is to build a roadmap.
For example, if a lightweight data validation model is in use today (specialchars or htmlentities) and the minimum acceptable standard is something like OWASP ESAPI for PHP, then a gap has been identified and requires a project to permanently remediate. The optimal control would be ESAPI-like data validation combined with contextual escaping of outputs (or normalization of charsets and encodings). Note that a WAF is not an appsec control in my world, although it could be one in your twisted view of the universe. An appsec control directly involves the software architecture; the components that make up the system.
Verification and testing of appsec controls could involve looking at the app design and doing threat-modeling, sure. I would bring this data into the risk management portfolio via risk assessment heat maps, usually using a qualitative analysis—but this exists outside of the gap analysis. I don’t mean to make this stuff sound complex because it’s really not. Am I doing that?
Dre,
Thanks for the comment, and yes, I remember the previous comments. I have not seen the presentation so I’ll take a look. A couple responses:
—-
Aspect Oriented Programming … conceptually I get it, but never employed the concept into design/coding standards of my projects. Agile with scrum has some benefits in this area from a prioritization standpoint, meaning you focus on the critical items first and add supporting modules and functions later. That misses the coding dimensions of that paradigm. Is it just my impression that good designers have the sense to do this naturally?
It’s probably a topic that needs to be investigated again as it’s useful in the approach to software survivability. Maybe the “Rugged” guys would have something to say on this?
—-
” … identification of data and risk classifications, followed by continuous risk management gap analysis on appsec controls.”
That sounds suspiciously like threat modeling and design. Am I missing the subtitles of the statement?
—-
I don’t think reliance on people and process is the way to look at the issue … process is used to modify human behavior. Supporting tools help us track the behavior and measure how well we track. If there is more than one person coding, you have all three.
—-
Finally, your comment on controls in your code smells like ICONIX. I have met very few people who know what that is, much less can carry it off. There are a handful of software architects I know (not designers per se) who have the skill and dedication to document architecture, design, threat modeling and define controls prior to coding. The problem then becomes engaging the rest of the mere-mortals on the development team so they understand what the hell they are supposed to work on. Works way better with the surgical team model, or where you have a really strong project manager. This model scares people because tons of work happens before much product gets built; demonstrable code is a (political, QA, team awareness) benefit of Agile with scrum.
-Adrian
“To me, Agile has always been a form of object oriented process, and I mix and match the pieces I need”
I once spoke about Ivar Jacobson’s Essential Unified Process (EssUP) and how software lifecycle processes should be more like aspect-oriented programming. The slide deck is available on tssci-security.com under “Why AppSec Tools Suck” from Toorcamp last year.
I hadn’t realized how extremely varied Agile processes could be until I recently came across ICONIX and DDT. Their notion of robustness testing matches up nicely to appsec goals.
Relying on process or people alone isn’t really enough. The standard approach should be identification of data and risk classifications, followed by continuous risk management gap analysis on appsec controls. The whole SDL and related concepts are a bit dated, IMO, even with the Agile SDL updates.
Show me the controls in your code, make it easy to find for future eyes on the code, and match the level of detail in documentation of the data flow and execution flow with the degree of severity in data and risk classifications.
If you don’t have output encoding, you’ve got XSS. If you don’t have parameterized queries or named parameters with variable binding then you’ve got SQLi/XPATHi/LDAPi. Every software weakness has an associated optimal control. Match them up. I don’t care as much about the process of secure development if you can’t speak the language of appsec controls.