I was listening to a podcast on Agile Staffing last week and they succinctly stated a couple things everyone sort of knows but doesn't say that often.
- On small startup type teams, the team is everything, a bad team member can kill the product and the company.
- On particularly agile teams, having agile people is better than having technology experts.
The first point is really clear, be it the leadership of the team or contributors to the team, if any one piece is broken then the whole thing won't work well. The second point is something I think people tend to dismiss, people like to list desired skills in job descriptions more so than desired attitudes and in an interview it's far more likely you'll be asked to write some code or explain some sort of process than you will be given a personality profile.
One pattern that I've seen at a number of companies I've worked at is that new people will be some how challenged and asked to do some heroic amount of work and the company sort of over reaches. After that challenge project is done the team never fully recovers, the team is skeptical of everything and doesn't want to work that hard again. All future projects are exercises in work reduction, not so much in product improvement. The team is reluctant to do anything like the challenge again. You end up with something that's fundamentally not repeatable. Even if you end up with a great result, the team is fried and you can't follow it up.
Another pattern I've seen is the so called "analysis paralysis." The desire to find a singular, "perfect," solution to a problem outweighs the desire to do anything else. Rather than attempting to fix problems or "solve the problem multiple times," or put "band-aids" on problems there is a desire to wait until an ultimate solution is created, which is usually never. With the problem, there are usually some fairly easy things that can be done to make some sort of incremental improvements along the way.
Back to that second point, there are personality traits that help you find people that help you break those patterns. There are people that are willing to iterate on solutions and try to repeat success and those are the people you want to put on teams. Now this is all software talk but does it apply to security and network teams? Is a security policy something that has to be iterated on and changed over time or is there a "perfect" solution that can be reached? You can have the best security guys in the world working for you but if you've overextended them do they still actually work?
Read this book: http://isbn.nu/0123705932/
I would say that, yes, Security and IT are notoriously behind AppDev in process maturity and capability. Further explanation/clarification: Not at every organization, but overall in the technology field.
Quality improvements such as Agile apply to all sorts of fields, especially technology-related ones. That’s the whole point – the design you start with ends up being filled with poorly chosen risk mitigations, with huge risks often overlooked. It’s an anti-pattern known as “Big Design Up Front”.
The Agile solution, which started with the Rational Unified Process (and evolved to the Essential Unified Process today), the Capability Maturity Model (evolved to CMMI today), and Extreme Programming (better done today as Lightweight Scrum, invaded by Ivar Jacobson International’s EssUP process template customization work) is a dominant force in AppDev. Any Agile process usually focuses in on test-first development, followed by code construction that constantly refactors continually-tested code to patterns. In this way, the design can be changed after every iteration instead of “once, ever, end-of-story”.
As Andrew Jaquith and others point out – the hamster wheel of pain (also see: Deming PDCA model, Six Sigma DMAIC, et al) – is the dominant model for Information Security Management. It’s a horrible way to understand and manage risks. At the very least, hybridized models such as FAIR and Balanced Scorecard need to be highly considered – and tend to work better for our purposes. But even these tools are not “agile” enough for some environments. Hence, why EssUP and other models are commonly tailored to an organization trying to balance many different kinds of risks/needs i.e. cross-cutting concerns.
I strongly believe that the “bad team member” thing is ultimately the most important, especially in development, and probably less-so in IT/Operations and InfoSecMgmt. One developer will constantly check-in the worst code at the very last moment. Good luck trying to deal with that person if the process isn’t supportive of constant high-quality AppDev hygiene.