Agile methodologies is an iterative approach that builds software incrementally instead of delivering complete project at once (Shelly, 2015). It divides the project into small iterations and continuously delivers different tasks after completion according to priority of user. Iteration length in agile methodologies varies between one to four weeks. According to researchers shorter iterations have lower complexity and risk, better feedback, and higher productivity and success rates (Larman, 2003). Agile methodologies are best to reduce the cost of software development.
Actually agile development is an umbrella activity that illustrates different agile methodologies like Scrum, XP, Crystal, FDD and DSDM as shown in figure 1. Agile works over comprehensive documentation, customer collaboration during software development. It response quickly to changes, individual and interaction over process and tools (William, 2010).
Figure 1 Agile development is umbrella activity
In the recent years, agile development methods gained popularity as an iterative, incremental and quick response to changes using short development cycles. Agile methodologies reduce the problems of traditional software development methods and adapt changes with the help of incremental and iterative process. Although, we studied many agile methodologies in literature which focus on different aspects of projects. The success of project depends upon the selection of best suitable method for software development.
Alistair Cockburn in 1998 made Crystal which is a lightweight family of methodologies. The main focus of crystal methodology is strong communication and interaction among people of project team. Larger project requires complex methodology and more man power with better coordination (Williams, 2010). Different crystal methodologies like Clear, Yellow, Orange, Red, Maroon, Blue and violet are introduced in the literature. Although Crystal methodologies are classified according the project size but each member of crystal family is assigned color according the complexity of methodology: the dark color is assigned for heavier project.
2. Extreme Programming
Extreme programming was introduced by Kent Beck on the base of some fundamental principles that is communication, simplicity, feedback, courage and respect. In XP, executable code and automated test drivers are produced instead of detail of requirements and design documentation. XP is a light weight methodology and design for small team. There are twelve core practices in XP as shown in figure which describe the activities cycle. Tight cycle of the programmers is shown in inner loop while outer loop describe the planning cycle between programmers and customer. Communication and coordination among team is shown in Figure 2 middle loop.
Figure 2 XP Practice
User requirements are gathered and these requirements are arranged according to priority. Project is completed in different iterations and coding of these iterations is developed with the help of pair programming. Pair programming required 15% more effort than solo programming (Maurer and Martel, 2002). Cost will increase with the increase of man power as shown in figure3. XP does not support code ownership because every developer has code understanding and can modify it. there is no special meeting for code review meeting in because XP rely on code review while working in pairs (Khramtchenko, 2004). In addition, XP team use common name and description (metaphor) for development and guidance. Iteration plan could be adjusted on the base of new requirements. In next phase, developed iteration is checked for bugs.
Figure 3 Cost increase with man power
3. FDD (Feature-Driven Development)
Jeff De Luca and Peter Coda made FDD (Feature-Driven development) and got recognizable name in 1997. Feature-Driven development focus on upfront design and building phase rather than focus on development cycle (Shelly, 2015). FDD rely on two main stages. First one is preparing a feature list to implement and second is feature by feature implementation (Khramtchenko, 2004). In first step, developer gathers all the stakeholders’ assumptions and requirement and built detail model. This step is very critical and require full time customer participation.
In second step, development team is divided and particular feature list is assigned them to implement. it requires only one to two weeks for implementation. Each team has head that is responsible for code segment that implement particular feature. FDD strongly support code ownership. Every developer knows about its owned code. FDD suffers if any developer leaves the team but it could be covered in some extent by reviewing design and sufficient code documentation. In addition, code review meeting also helps developers to view code of other developers. There are different development processes in Feature –Driven Development as shown in Figure 4.
Figure 4. FDD (Feature-Driven Development) process
Feature Driven-Development processes are described here one by one.
a. Develop an Overall Model
At this stage, describe High level descriptions. This stage prepares Use cases and functional specification. All team members and chief architect discuss High level descriptions and agreed upon object model for each domain area.
b. Build Feature a List
Built list of comprehensive feature to develop a system according base of object model and functional specification. In feature list all function that is mandatory for the client point of view is added. After that, finalize the feature list after viewing of user and validity of system’s sponsors.
c. Plan by Feature
Prepare sequence of feature list according to priority and assigned to chief programmer to develop functions (Palmer and Fleshing, 2002). After that, made overall schedule of feature list. Assign classes to developer (class owner) which are already defined in the “developing an overall model “
d. Design by Feature and Build by Feature
These are iterative procedure and iteration completes from one to weeks. Multiple teams designing and building their own feature list simultaneously. Domain expert guide to complete task such as design, coding, unit testing, integration, code and design inspection (Williams, 2007). When iteration is completed successfully then completed feature is added into main build and new features are added from feature list in “design and build feature process” to develop.
4. Dynamic Systems Development Method (DSDM)
Dynamic Systems Development Method (DSDM ) is an incremental agile method and in 1990’s it was most popular among software developers. Incremental prototype is used to control the tight time constraint to develop software. In order to work, phases, sub-phases, roles and principles defined. There is no phase for security element so DSDM is unable to develop secure software (sani et al., 2013).
The DSDM framework is suitable for agile and traditional development processes (Benjamin, 2004). Usually, DSDM projects work with one or two teams: the second team tests the product developed by other but researchers suggest that in a single team about 5 to 6 people are ideal (Benjamin, 2004). There are main four phases in DSDM that is feasibility, functional model iteration, design, build iteration and implementation with several sub phases.
Initially, do feasibility study to define problem and cost estimation. Feasibility report and plan outline for development is made. In last three phases actual development is done where analysis, coding and testing is done. On the base of prototype we make decision whether to move in the next phase or not (shelly, 2015).
5. Adaptive Software Development (ASD)
Adaptive Software Development (ASD) was developed by James A. Highsmith. In ASD repeating series of speculate, collaborate and learn is used by replacing the traditional water fall cycle. This method worked with iterative and incremental method with constant prototyping. ASD does not impose the use co-located team but focus on inter-team collaboration.
There are three main process cycle of Adaptive Software Development as shown in Figure 5 which provides continuous learning and adaptation.
Figure 5 Adaptive Software Development Life Cycle Model
This is basically a planning stage for the software development. At this stage, identify requirements so that project objectives and time box could be set. First decide length of iteration then assign box is to the each iteration. Each Team member writes Objective statement and assign features to iteration (shelly, 2015).
At this stage of collaboration team must support and trust on each other. In addition, Team members must communicate with each other to collect information and to solve complex problem. Team members cannot make critical decision individually so there is need of team collaboration to reach the common goal.
At this stage, the development team takes a technical review and provides feedback. Team learns partially developed code and point out the problems to reduce the cost and amount of rework. After the completion of iteration the team should learn about;
- Team member’s collects customer feedback after explore the application and note down the changes specified by the customer.
- Review performance of team then made decision for further improvement in performance.
- Review the project status, and plan for next iteration.
Scrum is an iterative and incremental AGILE methodology. The SCRUM methodology is suitable for all types of project, product and application development. (Ionel, 2008). In Scrum problem is divided into tasks and assign task to group. It is also called lightweight process which means minimize the overhead of process and maximize available time for useful work. In addition, it makes progress in sprints and duration of each sprint is about four to six weeks. The time of sprints is fixed and it ends on a specific date whether the work has been completed or not, and are never extended. (Deemer, 2010).
At the end of each sprint, team demonstrates the progress of project to the product owner, stakeholder and customer. Project’s progress is transparent to customer even he can change the project execution plan in the middle of the project which is not possible with traditional approach. Scrum prefers multitask worker instead of team members working with single job title so that team members could do any task where the work overload is more. Hence team help and learn new skills from each other.