VersionOne's Annual State of Agile Survey - 2013
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
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."
- 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.