User:NcsuOO517

Agile Software Development

Agile is rapidly becoming the most widely used software development methodology in the development world. It uses a wide variety of practices to achieve a flexible and productive cycle, for the overall goal of delivering a product that meets the customer's requirements. The underlying question is, is agile the right process for every situation? Read on to learn the answer.

Purpose

The agile software development process is a relatively new process introduced in the 1990s [2]. The main purpose behind agile development is to address the inevitable changes that arise as the development process progresses. It consists of short iterations of development, encouraging feedback after every iteration so that requirements can be adjusted accordingly. "Agile is set up to strongly support garnering feedback and guiding the customer toward better understanding what they want and need" [1]. Consequently, the short iterations lead to lower risk and higher productivity in the development cycle [2].

Common Practices

Some common practices that are incorporated into the agile development process include, but are not limited to:

• Extreme Programming (XP) - XP includes such practices as iterative development, team continuity, shared code, and real customer involvement. More about XP
• Scrum - short, daily meetings held by all members of the team, in which each team member answers three questions:
  • What did I do yesterday?
  • What do I plan to do today?
  • What obstacles are standing in my way? [3]
• Retrospectives - held at every iteration meeting, this practice involves each team member writing on an index card. On one side they write what they think went well during the iteration; on the other, they write what they think did not go well. The cards are then passed around and read by each other member of the team, which leads to a discussion about what was said.
• Feature driven development - a method of development in which a team plans, designs, and builds by feature, rather than requirement or by the project as a whole. Figure 1 below shows the process of feature driven development. [3]
• User stories - a story represents a feature that can be completed in one iteration. [3]
• Planning Poker - a practice held at each iteration meeting. Each team member holds a set of "poker" cards that have numbers on them, typically 1, 2, 3, 5, 8, 13, 20, 40, and 100. Team members use the cards to present their estimation of how many story points each user story will take to complete - 8 represents a full iteration. If there is disagreement in estimations, team members discuss why they chose the number they did, and a re-vote is taken. The process continues until the team members agree on an estimation number. [4]
• Team velocities - represent the number of story points a team is able to complete in one iteration. The team velocity is used to decide how many points to assign for the next iteration, based on the "Yesterday's Weather" concept, or the idea that a velocity will remain consistent for each iteration. [4]

Figure 1. Feature Driven Development Life Cycle

To Agile or not to Agile?

Despite its growing popularity in the software industry, a recent study indicates that agile may not be right for everyone. When adhering to the strict principles of agile, teams reported the following disadvantages of the agile process:

• Lack of customer involvement - made gathering requirements extremely difficult, leading to loss of productivity and rework.
• Contract negotiation problems - many customers want a "fixed deadline, fixed price, and fixed scope." Agile embraces change, which isn't possible with a fixed price project.
• Conflicts with design-intensive projects - due to this type of projects implementation, which basically starts with a full set of requirements, it was difficult to implement all aspects of agile.
• Superficial documentation - agile doesn't put much emphasis on documentation which is unacceptable for many projects.
• Adaptation to changing requirements not always needed - in which case, most agile methodologies become pointless.
• Difficulty breaking down the project - with complicated development, small user stories aren't always feasible.
• Distributed team discrepancies - some team collaboration tasks require face-to-face interaction which is lost when teams are spread out nationally or globally.

Obviously the study proved that agile may not be right for everyone. In order to know which software development methodology is best for a team, it is important to look at all the options available and to understand what situations each methodology is best suited for.

Other Software Development Methodologies

Waterfall

The Waterfall software development process is a plan driven methodology that must begin with a full, static set of requirements. The process starts at the top of the "waterfall", as seen in Figure 2, and flows downward through the different phases in a linear fashion, like an actual waterfall [5].

Figure 2. The Waterfall Model

Waterfall vs. Agile

The waterfall method is effective when the development team is provided with a rigid set of requirements, and wishes to have more control over the project [5,6]. It does not require very much customer interaction as the requirements are already laid out [6]. If a customer insists on setting a timeline and budget, the Waterfall method is useful in ensuring that these restrictions are met [5]. It is generally used for large projects [7].

The waterfall method is often criticized for leaving no room for change [5]. Defining all the requirements in the beginning without any modifications is not very realistic, nor does it provide any flexibility for the customer. If problems are found in the end product, the process must start from the beginning again [6].

Iterative/Spiral

While the spiral and iterative methods are not identical, they have similar characteristics that can be grouped together to compare them to agile. The iterative method emphasizes feature driven development by employing cycles of development. It iterates between planning, development, and release (which can be internal). After each release it is tested, reviewed, and reevaluated, and the cycle begins again. The iterations leave room for change and improvements. [8]

Figure 3. The Iterative Model

The spiral method differs somewhat from the iterative method in that it can accommodate the deployment of multiple task simultaneously and in any order. It is characterized by a definitive scope and expectations which must be managed accordingly. [9]

Figure 4. The Spiral Model

Iterative/Spiral vs. Agile

Agile incorporates iterative development into its process, along with a lot more - so why would someone want to cut out the "more"? "Iterative projects are best suited for organizations that want incremental delivery but aren't yet willing to move to the more apparently free-form agile methods," writes Matthew Hotle [7]. Hotle points out that not all projects are suitable for agile development. Iterative development supports a sequenced approach and rapid changes in requirements. It often requires less time and resources than agile, and typically works for any size project. With more interaction with the customer and organization of teams and tasks, it is easier to meet deadlines and cost restrictions [10].

Agile still dominates over iterative and spiral methods when the customer has very unstable requirements. Its lack of structure and expectations of change provide the best solution in this situation. [7]

Rapid Application Development (RAD)

The name speaks for itself - the Rapid Application Development (RAD) process is designed to speed up the development process. RAD is a prototype-based process that emphasizes team collaboration and user involvement [11]. It is also an iterative process and graphically resembles the iterative model presented in Figure 2. In order to achieve rapid solutions, RAD tends to skimp on the design phase and documentation [12].

RAD vs. Agile

RAD is useful when a customer wants a solution fast, without concern over extensive documentation or sustainable design. With a team experienced in the RAD process and a controlled scope, a project can be delivered in a cost effective, timely manner [11]. RAD benefits from re-using code, so if a system already has a strong foundation, an extensive design and documentation may not be important [13].

RAD is not appropriate for a customer's first client/server project [13]. If a customer places importance on sustainable design or documentation, agile or another method would definitely be the better choice. Also, an inexperienced team would work much better under a different process.

Rational Unified Process (RUP)

The Rational Unified Process (RUP) was designed to encourage both feedback and structure in development. The process is broken down into four phases: inception, elaboration, construction, and transition. RUP places high priority on risk management in all phases and on thorough documentation. While it is considered an iterative process, most of the requirements are expected to be specified towards the beginning of development, giving RUP more of a linear feel. [14]

RUP was actually designed to be a process framework - it consists of many different processes that a development team can pick and choose from to implement for their specific project. Because of this, RUP usually requires someone experienced with the methodology to help in choosing the appropriate techniques. The different processes and their breakdown between the four phases are shown in Figure 5. [15]

Figure 5. The Rational Unified Processes

RUP vs. Agile

For large projects, RUP dominates over agile. RUP is also the preferred methodology when customers require more structure and adherence to a plan, or when customers have limited time for interaction [15]. However, RUP has failed in many cases because those who attempt to use it don't understand that it is a framework to be customized to fit their project's needs [12]. The process of tailoring RUP to the project can be time consuming and complex, therefore not ideal for projects on a strict timeline or budget [14].

Conclusion

Hoda's study proved that the full implementation of the agile methodology was not suitable for every project [1]. One conclusion resulting from the study was that "both Scrum and XP suit similar kinds of projects: a small, co-located team; an on-site or available customer representative; an emphasis on coding and testing early; and frequent feedback into updated requirements" [1]. Large projects, or those with limited available interaction within a team or with the customer, can benefit more from adopting other software development methodologies; if desired, a team can then integrate certain agile aspects, such as Scrum or user stories, within their process to form a hybrid that's best suited for their project [1, 5, 16].

References

[1] Hoda, Rashina et al. "Agility in Context." Proceedings of the ACM international conference on Object oriented programming systems languages and applications. OOPSLA Conference 2010: 74-88. ACM DL.

[2] Williams, Laurie. "A Survey of Agile Development Methodologies." 2007.

[3] Williams, Laurie. "Agile Software Development Methods and Practices." 2009.

[4] Williams, Laurie. "Agile Estimating and Planning." 2007.

[5] Rising, Jim. "Sashimi Waterfall Software Development Process." Managed Mayhem. 06 May 2009.

[6] Kaushik, Preetam. "Agile vs. Waterfall - Is There a Real Winner?" Bright Hub. 27 Sep 2009.

[7] Hotle, Matthew. "Waterfalls, Products and Projects: A Primer to Software Development Methods." Gartner. 26 Feb 2008.

[8] Smith, S.E. "What is Iterative Development?" WiseGEEK. 08 Sep 2010.

[9] Inmon, William H. et al. DW 2.0: The Architecture for the Next Generation of Data Warehousing. Morgan Kaufmann: 2008.

[10] Lucks, Steven. "Agile / Extreme Programming or Spiral method - You Decide?" Ecademy. 07 Apr 2007.

[11] Shelly, Gary B. and Harry J. Rosenblatt. Systems Analysis and Design. Cengage Learning: 2009.

[12] Rooney, Dave. "Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.)" Practical Agility. 18 Nov 2008.

[13] Borysowich, Craig. "Rapid Application Development (RAD) Critical Success Factors." Observations from a Tech Architect: Enterprise Implementation Issues & Solutions. 02 Oct 2010.

[14] Collins, Chris. "Unified Process vs Agile Processes." 11 Jun 2008.

[15] Kousen, Kenneth A. "Software Development Process Models: RUP vs. Agile." Kousen IT, Inc. 2006.

[16] All, Ann. "Agile vs. Waterfall Development: How About Both?" Business of Tech. 01 Jul 2010.