Agile Practices |
1. Agile Practices
Thanks to all of you who participated in the first "After All These Years, What Does it Mean to be Agile" survey. More than 300 people from all over the world answered that survey. A summary of the results can be found here:
http://www.surveymonkey.com/sr.aspx?sm=_2f_2bPoGYfxffyM3td_2fqH9_2fulwV7TXy6BdkDqLswRbUbV0_3d
This follow on survey provides a ranked list of the agile practices based upon the original survey. For each of the practices on the original survey, I provide you a weighted average of the level of support for the practice. A "5" means that a respondent feels the practice is essential and a "1" means a respondent did not feel the practice was important. Therefore, the higher the score for the practice, the more support respondents gave for that practice.
The intent of this survey is simply to gather your reactions to this list in a free form rather than through structured questions. Your input to the community is most appreciated!
4.4 Continuous integration
4.4 Short iterations (30 days or less)
4.4 "Done" criteria
4.4 Automated tests are run with each build
4.3 Automated unit testing
4.3 Iteration reviews/demos
4.3 "Potentially shippable" features at the end of each iteration
4.3 "Whole" multidisciplinary team with one goal
4.3 Synchronous communication
4.3 Embracing changing requirements
4.3 Features in iteration are customer-visible/customer valued
4.3 Prioritized product backlog
4.2 Retrospective
4.2 Collective code ownership
4.2 Sustainable pace
4.1 Refactoring
4.1 "Complete" feature testing done during iteration
4.1 Negotiated scope
4.0 Stand up/Scrum meeting
4.0 Test-driven development unit testing
4.0 Timeboxing
3.9 "Just-in-time" requirements elaboration
3.9 Small teams (12 people or less)
3.9 Daily customer/product manager involvement
3.8 Emergent design
3.8 Release planning
3.8 Configuration management
3.7 Informal design (no big design up front)
3.7 Test-driven development acceptance testing
3.6 Team documentation focuses on decisions rather than planning
3.6 Co-located team
3.6 Team velocity
3.5 Requirements written as informal stories
3.4 Task planning
3.4 Coding standard
3.4 Ten minute build
3.3 Acceptance tests written by product manager
3.2 Pair programming
3.2 Burndown charts
3.1 Code inspections
3.1 Design inspections
2.9 Planning Poker
2.9 Stabilization iterations
2.8 Kanban
Laurie Williams
williams@csc.ncsu.edu
http://collaboration.csc.ncsu.edu/laurie/
http://www.surveymonkey.com/sr.aspx?sm=_2f_2bPoGYfxffyM3td_2fqH9_2fulwV7TXy6BdkDqLswRbUbV0_3d
This follow on survey provides a ranked list of the agile practices based upon the original survey. For each of the practices on the original survey, I provide you a weighted average of the level of support for the practice. A "5" means that a respondent feels the practice is essential and a "1" means a respondent did not feel the practice was important. Therefore, the higher the score for the practice, the more support respondents gave for that practice.
The intent of this survey is simply to gather your reactions to this list in a free form rather than through structured questions. Your input to the community is most appreciated!
4.4 Continuous integration
4.4 Short iterations (30 days or less)
4.4 "Done" criteria
4.4 Automated tests are run with each build
4.3 Automated unit testing
4.3 Iteration reviews/demos
4.3 "Potentially shippable" features at the end of each iteration
4.3 "Whole" multidisciplinary team with one goal
4.3 Synchronous communication
4.3 Embracing changing requirements
4.3 Features in iteration are customer-visible/customer valued
4.3 Prioritized product backlog
4.2 Retrospective
4.2 Collective code ownership
4.2 Sustainable pace
4.1 Refactoring
4.1 "Complete" feature testing done during iteration
4.1 Negotiated scope
4.0 Stand up/Scrum meeting
4.0 Test-driven development unit testing
4.0 Timeboxing
3.9 "Just-in-time" requirements elaboration
3.9 Small teams (12 people or less)
3.9 Daily customer/product manager involvement
3.8 Emergent design
3.8 Release planning
3.8 Configuration management
3.7 Informal design (no big design up front)
3.7 Test-driven development acceptance testing
3.6 Team documentation focuses on decisions rather than planning
3.6 Co-located team
3.6 Team velocity
3.5 Requirements written as informal stories
3.4 Task planning
3.4 Coding standard
3.4 Ten minute build
3.3 Acceptance tests written by product manager
3.2 Pair programming
3.2 Burndown charts
3.1 Code inspections
3.1 Design inspections
2.9 Planning Poker
2.9 Stabilization iterations
2.8 Kanban
Laurie Williams
williams@csc.ncsu.edu
http://collaboration.csc.ncsu.edu/laurie/