Software Development Project Success Survey 2008 Scott W. Ambler www.ambysoft.com/scottAmbler.html Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

How To Use These Slides I have provided these slides, and the raw data behind them, so that others can use them in their own work. You may reuse all, or a part of, this slide deck as long as you provide a clear reference to the source. The suggested reference is: Results from Scott Ambler’s December 2008 Software Development Project Success Survey posted at www.ambysoft.com/surveys/success2008.html Most slides have “speaker notes” Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/ The Survey December 2008 Email sent to DDJ mailing list 279 respondents 59% were developers/modelers, 25% were in management 80% had 10+ years in IT 16% worked in orgs of 1000+ IT people 92% worked in commercial firms 68% North American, 16% European Overall goal was to explore how IT professionals define project success. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Project Success Rate by Paradigm Success as defined by the respondent (this is the same for all slides in this deck). See other slides for how IT professionals define success in practice Success rate calculated by summarizing the weighted average of each range (i.e. 90-100% averages to 95%) times the number of respondents. Same approach taken for other slides too. Definitions used in the survey: On an ad-hoc software development project the team does not follow a defined process. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Success Rate by Project Type Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

How People Define Success Functionality: 83% believe that meeting actual needs of stakeholders is more important than building the system to specification Quality: 82% believe that delivering high quality is more important than delivering on time and on budget Money: 70% believe that providing the best ROI is more important than delivering under budget Schedule: 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule It is critical to understand how people actually define process success. The definition of “on time, on budget, meeting the spec” doesn’t seem to hold when we actually ask people what they value. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Effectiveness of Development Paradigms The greater the score the better the paradigm was at addressing that success factor. Score is calculated as follows: (#Very Effective * 10 + #Effective *5 - #Ineffective*5 - #Very Ineffective*10)/#Respondents Definitions used in the survey: On an ad-hoc software development project the team does not follow a defined process. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Iterative Project Success Rates The more distributed a team is, the greater the risk Definitions used in the survey: On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. Co-located teams: Everyone, including primary stakeholders, are in the same room. Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be. Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Agile Project Success Rates The more distributed a team is, the greater the risk Definitions used in the survey: On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP. Co-located teams: Everyone, including primary stakeholders, are in the same room. Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be. Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Traditional Project Success Rates The more distributed a team is, the greater the risk Definitions used in the survey: On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Co-located teams: Everyone, including primary stakeholders, are in the same room. Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be. Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Ad-Hoc Project Success Rates The more distributed a team is, the greater the risk Definitions used in the survey: On an ad-hoc software development project the team does not follow a defined process Co-located teams: Everyone, including primary stakeholders, are in the same room. Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be. Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/

Success Rate by Paradigm and Distribution Success as defined by the respondent (this is the same for all slides in this deck). See other slides for how IT professionals define success in practice Calculated by summarizing the weighted average of each range (i.e. 90-100% averages to 95%) times the number of respondents. Same approach taken for other slides too. Definitions used in the survey: On an ad-hoc software development project the team does not follow a defined process. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/