I just watched a good Webcast from an IBM agile expert about the state of Agile in the industry, and it had some interesting bits that touch upon agile operations.
Webcast – (registration required, sadly)
It’s by Scott Ambler, IBM’s practice leader for agile development. They surveyed programmers using Dr. Dobbs’ “IT State of the Union” survey, which has wide reach across the world and types of programmers; the data in this presentation comes from that and other surveys. All their surveys and results and even detailed response data (they’ve done a lot over time) are online for your perusal.
In the webcast, he talks some about “core” agile development extending to “disciplined” agile development that extends to address the full system lifecycle, is both risk and value driven, and has governance and standards. “Core” begs the question of “where do requirements and architecture come from?” and “how do I get into production?” Some agile folks who consider themselves purists say these aren’t needed and you should just start coding, he calls this view “phenomenally naive.”
He does mention some times where things like enterprise architecture were slow and introduced huge delays into the process because it took months to do reviews and signoffs. He calls this “dysfunctional” but really isn’t it the way things are unless there’s a pattern to change it? I think project management and enterprise architecture are suffering from the same problem we operations folks are, which is that we’re just now figuring out “what does it mean to incorporate agile concepts into what we do?”
The meat of the preso is over agile team metrics and busting myths about “it’s only for small colocated teams…” Here’s my summary notes.
- Agile teams have a success rate higher than traditional teams. Agile and iterative about tie and come in with much higher (2-4x) result on quality, functionality, cost efficiency, and timeliness than traditional or ad hoc processes.
- Agile is for not just coding, but project selection/initiation, transition, ops, and maintenance. More and more folks are doing that, but some get stuck with doing agile only in the coding and not the surrounding part of the lifecycle.
- Agile is being used by co-located teams in only 45% of the time; all the rest are distributed in some manner. But that does affect success some – “far located” teams have 20% lower success than fully co-located. Don’t distribute if you don’t have to.
- Most orgs are using agile with small teams, the vast majority are size 10 or less. But they see success with even the very large teams.
- We’re seeing people successful with agile under complaince frameworks liek Sarbox, and governance frameworks like ISO – even ITIL is mentioned.
- Agile isn’t just for simple projects – the real mix in the wild is actually weighted at medium to very complex projects.
- Though agile is great for greenfield projects, there’s very large percentages of teams using it on legacy environments. COTS development is the rarest.
- 32% of successful agile teams are working with enterprise architecture and operations teams. Should be more, but that’s a significant inroad. He says those teams are also most successful when behaving agile (or at least lean).
- Biggest problems with agile adoption are a waterfall culture (especially one where the overall governance everyone has to plug into is tuned to waterfall) and stakeholder involvement. Testers say “We need a detailed spec before we can start testing…” DBAs say “Developers can’t code until we have a complete data model…” Management resistance is actually the lowest obstacle (14% of respondents)!
A lot of nice stats. The two biggest takeaways are “agile isn’t just for certain kinds of projects, it’s being used for more than that and is successful in many different areas” and “agile is for the entire lifecycle not just coding.” As advocates of agile systems, I think that’s a good sign that the larger agile community is wandering our way as we’re building up our conception of DevOps and wandering their way ourselves!
the agile admin 