Monday evening more that 40 people turned up at a ‘Birds of a Feather’ gathering to consider “What makes agile projects succeed (or Fail)?” as part of Dr. Dobb’s Architecture and Design World in Chicago. In 90 minutes the group generated, discussed, and ranked about 40 different answers to this question, while enjoying some pizza and beverages.
Below, I’m listing all of the ideas as ranked by the group. I’ll elaborate on a few of the ideas that the group focused on. I’ll also provide links to the results from other groups who have considered the same question.
Tier One
* Discipline and leadership
A successful team will take a disciplined approach to implementing agile practices. The group felt that a key to this actually happening was the presence of leadership.
* Good communication
The group felt that this was vital to the success of any project, and that agile methods fostered better communication. Even so, a key differentiator between agile projects that succeeded and those that didn’t, was how easily and honestly information flowed between people on the project.
* The right people
There was a fair amount of discussion about what ‘right’ meant. Ultimately, the group felt that it includes: technical skills, communication skills, interest in doing agile, motivation, and ‘fit’. After the workshop I noticed that there is overlap with the item ‘Team-oriented team members’. If these items had been combined, this would certainly have been the top item.
Tier Two
* Stakeholder buy-in
* Team-oriented team members
* Dedicated resources
Tier Three
* Experienced agile champion on the team
The group talked about the advantages of having an experienced agile practitioner on the team full-time, as well as available to do evangelizing and coaching within the organization.
* Customer participation
* Test Driven Development
* Lack of design (-)
* The right tools
* Good use cases
* Good relationship with customer
* Rapid Prototyping
* Small team size
* Vertical stories
Tier Four
* Planning for refactoring
* Small project size
* Requirements-based testing
* Not needing lots of documentation
* Realizing that agile is no silver bullet
* Open work environment
* Adaptable requirement
* Inexperience (-)
* Data planning
* Flexible customer
* Know your data
* Flexible project size
* Compact stories
* Good product owner
* Appropriate contract
Tier Five
* Avoiding schedule slip-n-slide
* Story completion
* Good interface between agile team and rest of organization
* Short timeline
* Agile stakeholder experience
* Excessive changing requirements (-)
* Embedded architect on the team
You may also be interested in seeing the results from groups that have considered (essentially) the same question:
P-Camp 2008
Code Camp 2007
Agile Open California 2007
Cheers,