This research aims to produce a System Dynamics model of Agile software projects. In order to model Agile, we must first understand the essence of agility: What makes software development agile? In 2009 and 2010 Forrester Inc. surveyed 1298 and 1093 software professionals respectively, asking them to select the methodology that most closely reflected their development process. As shown in Figure 6, respondents pointed to several popular development methodologies, all of which fall under the Agile umbrella (West et al. 2011). In 2010 almost 40% of all responses named one of the “agile family” of methodologies.
The respondents identified some of the most in-use Agile methodologies, with Scrum being the most popular. In the following section we take a very brief look at some of these methodologies.
Scrum
Scrum’s origins can be traced back to an article that appeared in the January 1986 Harvard Business Review, entitled “The New New Product Development Game”. It contrasts Waterfall-like practices at the National Aeronautics and Space Administration (NASA) to novel approaches at companies like 3M, Fuji-Xerox, Honda, and Cannon. The Waterfall approach is likened to a relay-race, while approaches at successful companies were portrayed as being more akin to rugby teams “moving the scrum downfield” (Takeuchi & Nonaka 1984). Over time, what they called the “rugby approach” later morphed into “Scrum”.
Scrum is an iterative, incremental framework for projects and product or application development. It structures development in cycles of work called Sprints (Deemer et al. 2009). Each sprint is typically a three to four-week long development cycle wherein self-organizing teams prioritize and select a subset of the features of the software to implement. At the end of each sprint, completed features are demonstrated to the customer or user, whose feedback is incorporated into the software in later sprints. This methodology also calls for short daily stand-up meetings, also known as daily scrums, where team members exchange information on progress, next tasks, and surface issues and roadblocks so that they are dealt with quickly. Each sprint culminates with a set of completed software features that are “potentially shippable.” Figure 7 above is a simplified depiction of this process.
Extreme Programming Extreme
Programming, also referred to as XP, is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements (Beck 1999). Like Scrum, it emphasizes iterative and incremental delivery of small releases, as depicted in the XP project flowchart in Figure 8.
The development practices of XP teams are governed by the following rules:
· The Planning Game. Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
· Small releases. Put a simple system into production quickly, then release new versions on a very short cycle.
· Metaphor. Guide all development with a simple shared story of how the whole system works.
· Simple design. The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
· Testing. Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
· Refactoring. Programmers restructure the system without changing its behaviour to remove duplication, improve communication, simplify, or add flexibility.
· Pair programming. All production code is written with two programmers at one machine.
· Collective ownership. Anyone can change any code anywhere in the system at any time.
· Continuous integration. Integrate and build the system many times a day, every time a task is completed.
· 40-hour week. Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
· On-site customer. Include a real, live user on the team, available full-time to answer questions.
· Coding standards. Programmers write all code in accordance with rules emphasizing communication through the code.
XP was perhaps the first methodology, in the late 1990s, which called for automated unit testing of code, and is renowned for also being the first to call for the still-to-this-day controversial practice of pair programming.
