Successful Agile Software Development Requires Customer Feedback, Team Buy-In

John Storts

Several years ago, as a technical writer for another company, I was part of one of the first project teams to use agile software development methods. My job was to document the software graphical user interface (GUI), providing online Help and other end-user assistance.

 

The project team was well-represented by stakeholders throughout the company who were strongly encouraged to collaborate and provide input, regardless of specific areas of expertise. The methods and vocabulary of the old, waterfall style of development were largely cast aside in favor of the vernacular of iterative development. I heard many, new management catchphrases over the course of many meetings. The project turned out to be a modest success in terms of the quality of the product delivered, but I think it failed as an example of a successful agile project.

 

I say this for two reasons. For one, customer feedback during development was scant at best. This lack of sustained communication between end users and developers seems to be the most fundamental and serious break from the way most companies "do" agile software development. Our software builds, or "iterations," managed to roll-in bug fixes and feature requests from the developers, other project team members and in-house software testers, but I rarely heard of end user requests making it into pre-release versions. Communication of this kind during early development stages is one major distinguishing factor between waterfall and agile methods. Did the habits created by the long-established, older methods hinder us from capturing crucial info about what the customer wants?

 

The second reason this project diverged from the tenets of agile: team buy-in of agile for this project was far from complete. It seemed that nearly a third of the team simply wanted to carry on much as they always had during this project. These members' feelings ran from cool ambivalence to hostility. Overall, the reluctance of just a few members of the team created another kind of communication breakdown: knowledge hoarding. Information that should have been shared with the whole team about function milestones were not mentioned in cross-functional team meetings. Delays resulted and functionality targeting specific iterations went undelivered. Agile simply can't be forced on the unwilling or unprepared.

 

For a time, I thought that agile just wasn't right for us. While most of management was under one roof, our developers were spread out across time zones and countries. The organization's roots were in a very "traditional" development culture, and it was clear that some on the team preferred it that way. Looking back, I wonder if additional, upfront agile education and shrewd management-led replacement of unhappy stakeholders might have solved the customer-feedback and team buy-in issues. If full agile adoption proved impossible or inappropriate, we would have been more quick to adapt, perhaps using a hybrid approach of agile and waterfall techniques that better suited the project and team. Then, we might have been able to call both the product and the project an agile success.


 

More from the Knowledge Network and IT Business Edge

Project Development Process

Agile Workforce Research Note

"Agile Project Management" Excerpt

Software Developers Are More Agile, But Not Entirely So

Adopting an Agile Mindset

Mozilla Takes Hybrid Approach to Agile Software Development



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.