I hosted the ever-popular ‘What makes agile projects succeed?’ session at Agile Open California this year. As was the case last year, turnout was strong and the lessons learned from many teams were shared in a short period of time. In under 90 minutes the group generated and ranked a list of nearly 40 factors that had been key to the success of agile projects that they had been involved with. We used the Group Wisdom Without Groupthink technique to accomplish this feat. The list below presents, in order, what the assembled group considered to be the most important ingredients to the success of the agile projects.

Before you scroll down to look at the results, check out the drawing that our graphics facilitaor, Elizabeth McClellan, created during the session!

What Make Agile Projects Succeed By Elizabeth McClellan

Top Answer: Short Cycles

Tier Two
Self-Organizing Team
Co-Location (whole team at big table)
QA Involved Early
High-Risk Items First
Clear Business Goal

Tier Three
Test Cases for each Requirement
Stake-holder buy-in to the agile process
Daily Scrum
Customer or Proxy on-site at all times
Keeping estimates ‘real’
Common understanding of ‘done’
Keep the priorities visible to the whole team

Tier Four
Developer ownership of the testing
Individuals taking ownership of what they sign up for
Make issues visible – put them on the wall
Team is accountable, committed, and at the same level
Early deliverables

Tier Five
Pair Programming
Skilled architect
No gold-plating
Keep moral high
Selecting the right people for the team
Senior contributors on the team
Regular and focused review of features
Project manager conducted effective meetings
Collective enthusiasm for the process

Tier Six
Effective decision-making
Building trust within the team
‘Go with the flow’
Wiki used for communication
Communication in all directions
Use of support tools effectively
Small team
Great e-mail with all-hands to quickly handle hot issues
Just-in-time tasking with dev and QA
Everyone has a shared understanding of system and their obligations
Short time between feature requests and implementation

Cheers,

Chris