E Learning Volume 5 Number 1 2008 www.wwwords.co.uk/elea Agile Software Development SOLY MATHEW BIJU University of Wollongong in Dubai, United Arab Emirates ABSTRACT Many software development firms are now adopting the agile software development method. This method involves the customer at every level of software development, thus reducing the impact of change in the requirement at a later stage. In this article, the principles of the agile method for software development are explored and there is a focus on its effectiveness in the industry today. The article also describes the two agile development methods used today in the information technology industry Extreme Programming (XP) and Scrum. The major differences between the two methods are examined. This article is based on a recent study and on feedback from developers in the information technology industry. Introduction Previous traditional software development methods (waterfall, spiral, iterative) were very cumbersome and involved a lot of documentation. These methods were very rigid and provided very little or no flexibility. McCauley (2001) states that the underlying philosophy of processoriented methods is that the requirements of the software project are documented, they are locked and frozen before the design and software development process takes place. This process is not flexible enough to accommodate changes in the specifications at a later stage of the development. According to Highsmith & Cockburn (2001): what is new about agile methods is not the practices they use but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and manoeuvrability. This yields a new combination of values and principles that define an agile world view. Project development would be a disaster if the customer was not sure of the final product requirements and could only give the requirements on an incremental basis. Such a method follows the Capability Maturity Model (CCM), which is process-based. The agile method is people-based rather than plan-based. In agile software development, the focus is on customer satisfaction. It is an incremental/iterative software development process which focuses on the quick development of a working model. The agile software development method is based on the following principles: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The agile software development manifesto was published by a group of software practitioners and consultants in 2001 (Cockburn, 2002).[1] 97 http://dx.doi.org/10.2304/elea.2008.5.1.97
Soly Mathew Biju Extreme Programming (XP) Introduction Extreme Programming is one of the commonly used agile software methods (Larman, 2004). It is used in the problem domains where the initial requirements are likely to change to a large extent. XP is based on the following assumptions: Be willing to do rework frequently and fast, as well as welcome customer feedback. It becomes a customer-focused and customer-driven project rather than a plan-driven project. Initial software is developed based on the stories and requirements provided by the user. This software will contain the most important and vital features required by the user. This method is found to be very effective as it involves the customer from the very beginning. The customer writes user stories comprising simple lines of text describing the features they want included in the first release of the working program. The acceptance test for the software is designed and based on these user stories. This will keep a check on whether all the features requested are implemented in the program. The developers then estimate the time for the development activity, for which they will have to meet the customer, reconfirm and make detailed notes of the requirements. The first release should not take longer than three weeks. Hence, this method consists of small release cycles, for which the feedback of the customer and user stories are written, which are then used for the next release of the software. The length of the increments is decided and is usually equal for all releases. The developers are advised to keep their code as simple as possible and the technically latest version, which in turn minimizes the need for documentation. Requirements can be added at any time during the project development. New features can be added to the software as the next increments are provided. Before the next release, the customer will have to prioritize the requirements for that release. The next release will focus on these requirements. All the contents of the release are subject to change, except for the new features implemented (Cauwenberghe, 2002). If analysis of the requirements shows that the increment will take longer than the decided increment length, it is broken down into smaller increments. Each increment will have the developers working on the analysis, design code integration and testing phases iteratively (Cauwenberghe, 2002). It follows an iterative life cycle model with five activities, namely planning, design, coding, testing and integration: Planning occurs at the beginning of each iteration. Design, coding and testing are done incrementally. The source code is continuously integrated into the main branch, one contribution at a time. There are unit tests for all integrated units (regression testing). Working Style The working style is slightly different and it may take some time for the team members to implement this style: Pair programming is followed whereby two programmers work together to develop a particular functionality. This provides a better quality product. There is no concept of peer review. Stand-up meetings are held to discuss the status of the project. These short meetings are held on an everyday basis. There is collective code ownership: everyone is responsible for the complete software. Anyone can make changes to the program if they find that it will improve the code. Unlike traditional project management where the project manager is responsible for the risks, complexity, deadlines, etc., in the case of agile software development, the team will organize and reorganize itself to handle all the pressures of the project. The major difference of XP-style planning and incremental delivery, as in the case of one of the most accepted Unified Process frameworks, is the assumption that architecture and design can 98
Agile Software Development be done incrementally. XP spends very little time on defining the architecture and overall design. It starts directly with the first increment to deliver functionality. XP undertakes the design in the following manner: A system metaphor is used, which names the classes and the objects in a consistent manner and is agreed upon by all the team members. It also describes the overall architecture. It follows the test first method, where the programmer writes the code for testing the program before writing the program. These tests are written incrementally based on the user requirements. These are the tests that the program unit must comply with. Figure 1 shows a sample testing code (Miller, 2003). The code must be written so that it will satisfy these tests. Figure 1. JUnit test for the Person object (Miller, 2003). Refactoring reworks the design to adapt the changes to the environment and requirements iteratively. It follows group design techniques like whiteboard design sessions, classresponsibility-collaborator sessions (CRC), etc. Another controversial assumption is that analysis can be done incrementally. XP performs analysis in the following manner: User stories, which contain brief descriptions of the requirements, are discussed interactively by a team of programmers and the customer. The requirements are then formulated into acceptance test cases which the software should comply with. The planning game is used to do release planning. This is a meeting that occurs once per iteration. The customer and the programmers participate in the planning game. The assumption that the product can be delivered to the customer in an iterative manner makes it most beneficial to the customer. The customer can receive and make use of the most important and valuable functionality within a very short period of time. Thus, customers get a quicker return on their investment. The order in which features should be added to the software can be decided 99
Soly Mathew Biju by the customer. The customer can therefore verify whether what is given is what they want at a very early stage, and can provide feedback to the programmers, thus driving the project in the right direction. Is XP Always the Best Method to Follow? This depends on the project, the team and the customer. If the assumptions of XP hold, there are various benefits to be derived from incremental software delivery. One of them is the early delivery of the first incremental model of useful software. Feedback from the customer gives the required confidence to the programmers and can help drive the next incremental release. Incremental releases can be scheduled, hence there can be predictable delivery. A simple code and minimal documentation save a lot of time. Scrum Another agile software development method is Scrum. Scrum and XP are clearly aligned. In fact, if you walked in on a team doing one of these processes, you might have a hard time quickly deciding whether you had walked in on a Scrum team or an XP team. The differences are often quite subtle, but they are important. Figure 2. Scrum (Tamhane, 2007). There are four main differences between Scrum and XP [2]: 1. Scrum teams typically work in iterations (called sprints ), as shown in Figure 2, that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long. 2. In Scrum, the teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment has been made to delivering a set of product backlog items, that set of items remains unchanged throughout the sprint. XP teams are much more flexible within their iterations. As long as the team has not started work on a particular feature, a new 100
Agile Software Development feature of equivalent size can be swapped into the XP team s iteration in exchange for the unstarted feature. 3. XP teams work in a strict priority order. Features to be developed are prioritized by the customer and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog items but the team determines the sequence in which they will develop the backlog items. 4. Whereas Scrum does not prescribe any engineering practices, XP does. XP engineering practices include things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on. These are small and often subtle differences between Scrum and XP. They can, however, have a profound impact on the team. A possible approach to maximizing the advantages of both approaches is to start with Scrum and then begin using XP engineering practices, such as testdriven development and pair programming. Figure 3 depicts the key differences between the traditional waterfall model and the agile method. Figure 3. Differences between the traditional waterfall model and the agile method. Disadvantages of the Agile Approach If we are adopting the agile method for the first time, we will face the challenge of changing the mindsets of our team members and helping them understand the rules of the new method (Evans, 2006). A lot of rework may be involved, which could be avoided if a complete requirement analysis is done initially. If a proper order of building the software is not followed, we might end up reworking from the beginning to include another set of requirements. This is especially likely if we need to add certain security or performance features to the software. The complete process may slow down if requirement analysis and design have to be performed for each iteration. 101 Conclusion The agile software development process will produce incremental release of software, which is very useful for reducing product risks and delivering a product to a customer s satisfaction. A working model of the product can be delivered at a very early stage. The software will truly be agile and subjected to change until the final delivery. It is always better to have planned a little ahead so as to avoid possible pitfalls. Certain import requirements related to security and
Soly Mathew Biju performance features can be collected in advance. If one is familiar with the domain, has a stable design and has worked in a similar environment, then it is better to follow the waterfall method. If a project is not familiar, has unstable design and involves a lot of risk, it is always advisable to adapt to the agile software development method. Agile has largely become a synonym for modern software practices that work.[3] Notes [1] Manifesto for Agile Software Development. http://www.agilemanifesto.org [2] See Mike Cohn s blog. http://blog.mountaingoatsoftware.com/?p=8 [3] 5Qs on Agile with Steve McConnell. http://www.pmboulevard.com/default.aspx?page=view%20content&cid=2334&parent=5970 References Cauwenberghe, P. van (2002) Going Round and Round and Getting Nowhere Extremely Fast? Another Look at Incremental and Iterative Development, Methods and Tools. http://www.methodsandtools.com/archive/archive.php?id=14 Cockburn (2002).Agile Software Development. Boston: Addison-Wesley. Evans, I. (2006) Agile Delivery at British Telecom, Methods and Tools. http://www.methodsandtools.com/archive/archive.php?id=43 Highsmith, J. & Cockburn, A. (2001) Agile Software Development: the business of innovation, Computer, 34(9), 120-122. Larman, C. (2004) Agile and Iterative Development: a manager s guide. Harlow: Addison-Wesley. McCauley, R. (2001) Agile Development Methods Poised to Upset Status Quo, SIGCSE Bulletin, 33(4), 14-15. Miller, R. (2003) Demystifying Extreme Programming: test-driven programming. http://www.ibm.com/developerworks/java/library/j-xp042203/ Tamhane, S. (2007) Application of IT in Heath Care, presentation at IT seminar, University of Wollongong, Dubai. SOLY MATHEW BIJU is an instructor in the College of Undergraduate Studies of the University of Wollongong in Dubai, teaching programming languages and algorithms and problem solving. She has taught various software engineering and information technology (IT) subjects at different colleges, and is an ISTQB-certified (International Software Testing Qualifications Board) software testing professional for the foundation syllabus. She has also taught numerous online courses in different colleges across Europe and has worked in the IT industry as well as working as a systems administrator leading Windows NT and Lotus Notes teams for British Airways at Heathrow Airport in the United Kingdom and in Pune, India. Correspondence: Dr Soly Mathew Biju, College of Undergraduate Studies, University of Wollongong in Dubai, PO Box 20183, Dubai, United Arab Emirates (solymathewbiju@uowdubai.ac.ae). 102