Sit together Whole team Information workspace Energised work Pair programming Stories Weekly cycle Quarterly cycle Slack Ten-minute build Continuous integration Test-first programming Incremental design Communication Simplicity Feedback Courage Respect Humanity Economics Mutual benefit Self-Similarity Improvement Diversity Reflection Flow Opportunity Redundancy Failure Quality Baby steps Accept responsibility Exploration Planning Iterations Release Productionising Maintenance Death Beck, K. and C. Andres (2004). Extreme Programming Explained (2nd Edition), Addison-Wesley Professional. Scrum by Ken Schwaber and Jeff Sutherland (Schwaber et al. 2001) Practices Values Process Phases 30 day iteration (Sprint) Sprint planning meeting Self organising teams Daily scrum meetings Sprint review The scrum master Product backlog Commitment Focus Openness Respect Courage Pre-game Development Post-game Schwaber, K. and M. Beedle (2001). Agile Software Development with Scrum, Prentice Hall PTR. Crystal Clear by Alistair Cockburn (Cockburn 2005) Properties Strategies Techniques Frequent delivery Reflection improvement Osmotic communication Personal safety Focus Easy access to expert users Technical environment with Automated tests, configuration management and frequent integration Exploratory 360° Early victory Walking skeleton Incremental re-architecture Information radiators Methodology shaping Reflection workshop Blitz planning Delphi estimation using expertise ranking Daily stand-up meetings Essential interaction design Process miniature Side-by-side programming Burn charts Cockburn, A. (2002). Agile software development, Addison-Wesley Longman Publishing Co., Inc. Cockburn, A. (2005). Crystal Clear A human -Powered methodology for Small Teams, Addison-Wesley. Adaptive Software Development (ASD) by Jim Highsmith (Highsmith 2000) Lifecycle Phases Lifecycle Characteristics Management
Code reviews can help improving product quality in agile software development Refactoring can help improving product quality in agile software development People Quality Hypotheses Agile software development requires people with high level of communication skills Short iterations have good influence on the morale of the team Iterative development requires developers with high level of experience Integrating new team members is harder with agile methods The smaller the team the higher the communication level between the team members People are happier and more motivated when using agile methods. Process Quality Hypotheses When using agile methods testing is the responsibility of all team members In agile software development governance increases when the team is larger Effectiveness of communication decreases when the team is larger Communication level within the team is higher in agile development than in traditional approaches Agile adoption goes in stages and it improves over iterations, releases and projects In agile development the process matures throughout the project Each release should have a clear focus on one aspect of quality Prioritizing defects is important in agile development Agile methods are more suitable for brand new products In agile development, longer iterations are needed when the team is larger Hypotheses Review (Version II) The generated hypotheses were presented in the Agile Conference in August 2008 during the research in progress workshop. It was a good opportunity to have the hypotheses reviewed and evaluated by the agile conference attendance. The workshop had about 200 people working in groups or 6 to 8. Printed copies of the hypotheses were distributed to the groups. I asked the attendees to evaluate the hypotheses from 1 to 5 according to how much
The results suggest that when a team is collecting metrics, it does not collect only one. For example the team who measured the “business value delivered” metric they also measured every other metric as well. Finally, the reported successful projects had small team sizes (10 or less), frequently measured customer satisfaction, had high code quality, performed retrospective after each iteration, had the whole team participating in the retrospective, had everybody participating in the retrospective, and collected metrics either manually or automatically. Significant Relationships between Different Variables Different types of analysis were conducted on different sets of data throughout the research. Some of the findings were statistically significant, and some were not. In this section, statistically significant relationships between different variables will be summarised. We will focus on the variables that have impact on quality, satisfaction and project success as this is the focus of this thesis. The factors that are related to quality, stakeholder satisfaction, and project success are presented in tables 9-1, 9-2, and 9-3 respectively along with their correlation coefficient values. The numbers 0.01 and 0.05 presents the probability at which the correlation was significant. Variables Adoption Survey 2006 Adoption Survey 2008 Agile Project Governance Survey 0.01 0.05 0.01 0.05 0.01 0.05 Quality Productivity .68 .55 Satisfaction .66 .51 Cost -.06 -.26 Success .36 .31 Organisation experience .20 Retrospective Impact .24 Frequency of customer satisfaction measure .47 Table 91 Variables which have a significant correlation with quality, and their correlation coefficients