VersionOne's Annual State of Agile Survey - 2013

Each year VersionOne publishes a State of Agile Survey.  In it they include data and assessments about Adile adoption in the enterprise, types of Agile methods and practices in use, reasons for adopting Agile, benefits obtained from implementing Agile, reasons for Agile project/transformation failure, and other topics.

I've noted for years that the key contributors to successful Agile transformation include sponsorship and active participation in the effort by business and technology leaders, ample training, coaching and ongoing support for all stakeholders, and mapping current/traditional practices to the new ways of getting things done.

The survey data indicates that when agile initiatives fail, it is often because of issues related to culture and resistance to change within the organization.  Specifically, people are concerned about a perceived lack of planning and loss of management control that they associate with Agile practices.

Those responsible for the Agile transformation in an organization should explicitly address those perceptions early in the transformation effort.

I've found that most business and technology leaders tend to trust project management practices to which they've grown accustomed over time.  Those practices include:

• Significant time and resources devoted to analysis and requirements definition
• Time and cost estimates derived from the analysis and requirements definition
• A project manager responsible for delivering the defined requirements within the time and cost estimates provided

Without those elements, many leaders believe they have nothing to justify a commitment of resources and no assurance of product delivery with useful features in an acceptable timeframe.  I think this is part of what is behind the findings in the VersionOne survey showing 60% of Agile projects failing due to things like company philosophy or culture at odds with Agile values; external pressure to follow traditional processes; lack of cultural transition; and lack of management support.

In addition to causes of failure, the survey lists greatest concerns about adopting Agile.  Topping that list are: lack of up-front planning; loss of management control; management opposition; and, lack of predictability.

I interpret the causes of failure and the concerns as management (not only technology and product management, but operations, services, sales, customer support, etc.) saying, in essence, "we know we're not satisfied with what we're getting out of the development organization now, but we'd feel better if you just tried to get better at doing things the traditional way rather than moving to some radical new way of doing things that seems to us less transparent and like nothing else we've experienced."

For more than a decade, Agile practices and tools, when used appropriately, have proven to do a better job of delivering value.  How can we assure those leaders who have learned to rely on traditional project management that they will experience even better results using Agile?  Here are some thoughts:

• Requirements - contrary to popular misconceptions, Agile supports rigorous efforts to gather and define product and system requirements.  The difference between Agile and traditional efforts is that the requirements are gathered and elaborated over time, taking advantage of actual experience with the system as it is developed.  I've heard this described as iterative empirical requirements gathering, as opposed to speculative up-front requirements definition.
• Planning - as with requirements gathering, Agile planning is an ongoing, recurring effort, not a one-time, up-front phase.  Agile plans may extend for months into the future.  They emphasize adaptation to feedback from end users/customers as opposed to rigid adherence to a defined delivery schedule.
• Cost - Agile supports fixed cost commitments in the form of resource allocation to an Agile team.  The cost of the team is well understood and controlled.  The team's output, in terms of features, is flexible and determined by the requirements as defined and prioritized by the product owner and stakeholders.
• Tracking / Reporting - traditional projects produce such artifacts as Gantt charts, status reports, Earned Value reports, Defect Reports, etc., that support a baseline established at the outset of the project and status checks against that baseline.  The assumption behind those reports is that the plan established at the beginning of the project is precise and accounts for all desired outputs and associated risks for the lifecycle of the project.  Agile reporting includes Sprint Demos, Release Burnup Charts, Sprint Burndown Charts, Defect Levels, Team Velocity Reports, and others.  The assumption behind Agile reporting is that all stakeholders want to know, and need to know, what is being learned as the team completes work and end users use the delivered features.

Understanding why business and technology leaders resist Agile practices and tools, and addressing those concerns explicitly and honestly, can help increase the chances of success in Agile adoption and organizational transformation.