Agile Methodologies

Agile methodologies:

An agile methodology is an iterative approach that builds software incrementally instead of delivering the complete project at once (Shelly, 2015). It divides the project into small iterations and continuously delivers different tasks after completion according to the priority of the 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 responds quickly to changes, individual and interaction over process and tools (William, 2010).


In 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 processes.  Although, we studied many agile methodologies in the literature that focus on different aspects of projects. The success of a project depends upon the selection of the best suitable method for software development.

1. Crystal

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 the project team. A larger project requires a complex methodology and more manpower 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 to the project size but each member of the crystal family is assigned color according to the complexity of methodology: the dark color is assigned for the heavier projects.

 2.   Extreme Programming

Extreme programming was introduced by Kent Beck on the basis of some fundamental principles that are 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 lightweight methodology and design for small teams. There are twelve core practices in XP as shown in the figure which describe the activities cycle. The tight cycle of the programmers is shown in the inner loop while the outer loop describes the planning cycle between programmers and customers. Communication and coordination among the team are shown in Figure 2  middle loop.

User requirements are gathered and these requirements are arranged according to priority. The 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). The cost will increase with the increase of manpower 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 relies on code review while working in pairs (Khramtchenko, 2004). In addition, the XP team uses a common name and description (metaphor) for development and guidance. The iteration plan could be adjusted on the basis of new requirements. In the next phase, the developed iteration is checked for bugs.

3.  FDD (Feature-Driven Development)

Jeff De Luca and Peter Coda made FDD (Feature-Driven Development) and got the recognizable name in 1997. Feature-Driven development focuses on the upfront design and building phase rather than focus on the development cycle (Shelly, 2015). FDD relies on two main stages. The first one is preparing a feature list to implement and the second is a feature by feature implementation (Khramtchenko, 2004). In the first step, the developer gathers all the stakeholders’ assumptions and requirements and built a detailed model. This step is very critical and requires full-time customer participation.

In the second step, the development team is divided and a particular feature list is assigned to them to implement. it requires only one to two weeks for implementation.  Each team has a head that is responsible for the code segments that implement a particular feature. FDD strongly supports code ownership. Every developer knows about its own code. FDD suffers if any developer leaves the team but it could be covered to 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.

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 specifications.  All team members and chief architect discuss High-level descriptions and agreed upon object models for each domain area.

b.  Build Feature a List 

Built a list of comprehensive features to develop a system according to the base of the 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 the validity of the system’s sponsors.

c.  Plan by Feature

Prepare a sequence of feature list according to priority and assigned to the chief programmer to develop functions (Palmer and Fleshing, 2002). After that, made an overall schedule of the feature list. Assign classes to the developer (class owner) which are already defined in the “developing an overall model “

d.  Design by Feature and Build by Feature

These are iterative procedures and iteration completes from one to a week. Multiple teams designing and building their own feature list simultaneously. Domain expert guide to complete tasks such as design, coding, unit testing, integration, code, and design inspection (Williams, 2007). When iteration is completed successfully then a completed feature is added into the main build and new features are added from the feature list in the “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 the 1990’s it was most popular among software developers. The incremental prototype is used to control the tight time constraint to develop software. In order to work, phases, sub-phases, roles, and principles are defined. There is no phase for security elements 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 others 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 a feasibility study to define the problem and cost estimation. A feasibility report and plan outline for development are made. In the last three phases, actual development is done where analysis, coding, and testing are done. On the basis of the prototype, we make a decision whether to move to 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 speculating, collaboration, and learn is used by replacing the traditional waterfall cycle.  This method worked with an iterative and incremental method with constant prototyping. ASD does not impose the use of co-located teams but focuses on inter-team collaboration.

There is 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

a.  Speculation

This is basically a planning stage for software development. At this stage, identify requirements so that project objectives and time box could be set. First, decide the length of the iteration then assign the box is to each iteration. Each Team member writes an Objective statement and assigns features to iteration (shelly, 2015).

b. Collaboration

At this stage of collaboration, the team must support and trust each other. In addition, Team members must communicate with each other to collect information and to solve complex problems. Team members cannot make the critical decisions individually so there is a need for team collaboration to reach the common goal.

c.  Learning

At this stage, the development team takes a technical review and provides feedback. The team learns partially developed code and points out the problems to reduce the cost and amount of rework. After the completion of iteration the team should learn about;

  • Team members collect customer feedback after exploring the application and note down the changes specified by the customer.
  • Review performance of team then made the decision for further improvement in performance.
  • Review the project status, and plan for the next iteration.

6. Scrum

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 tasks to a group. It is also called a lightweight process which means minimize the overhead of the process and maximize available time for useful work. In addition, it makes progress in sprints, and the 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 is never extended. (Deemer, 2010).

At the end of each sprint, the team demonstrates the progress of the project to the product owner, stakeholders, and customers. The project’s progress is transparent to the customer even he can change the project execution plan in the middle of the project which is not possible with a traditional approach. Scrum prefers to multitask workers instead of team members working with a single job title so that team members could do any task where the work overload is more. Hence team helps and learn new skills from each other.

Leave a Reply

Your email address will not be published.