Totev explains that one large barrier to agile adoption is the barrier to change. Large legacy projects, database projects and systems that protect services are all hard to change; they all require more coordination and communication and have slow test cycles. This extra overhead makes the agile idea of quick test, release and feedback cycles all the more challenging.
Dave Nicolette, an agile coach, is quick to agree. As he explains, "If your team is self-contained, without dependencies on others, you can go as fast and as smooth as you want. If you have to coordinate changes, you have to do more up-front and planning work. That doesn't mean you can't 'do' Agile. It just will require more overhead."
The other big difference Nicolette sees is company size. Like Totev, Nicolette agrees that small project don't require a documented process. He continues: "If you have a 200-person company, with only a handful in software development, you might not need a process at all. Likewise, if you have a 2,000-person company, with several hundred in software development, with existing process and a legacy codebase, you might not be able to move fast enough to take advantage of what Agile has to offer."
After talking to Totev, Nicolette, I thought it was time to hear from the company with the largest customer base of software developers-Microsoft-about what it hears from its customers.
Microsoft Customers Less Agile Than They Think?
Microsoft Visual Studio Application Lifecycle Management is many things, but one of them is the process "wrapper" around Visual Studio. Karthik Ravindran, senior director of Visual Studio Product Management, talked to me about the latest release.
Ravindran agrees that software tied to version control and stories, working within a scrum framework, is a popular demand. Then he demonstrates the Scrum Template, a core part of tool. Within that template, work is defined in tasks, estimated and tracked in hours, and not adjusted to actual time.
This stands in contrast to most agile thinkers, who prefer to measure and predict based on past performance, ignoring time-on-task as a measure. Ravindran explains that predictive measures are possible with Visual Studio, but they aren't part of the "out of the box" template.
Given its access to customer research, I expect that Microsoft is building exactly what the market is asking for, that tasks over hours is much more common than measuring throughput (work completed) to predict future cycles. Suddenly, the 54 percent of teams "doing" scrum according to the VersionOne study seems less impressive.
This gets me thinking about how object oriented programming has really been adopted.
The Real State of OOP Today: Form But Not Substance
Most of the people I talk to program in an object-oriented language. But there's a real difference between what they code and the kinds of programming advocated by Kent Beck in Implementation Patterns or Robert C. Martin in Clean Code.
Sign up for CIO Asia eNewsletters.