Agile Methodology

Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by rapid

delivery of working software product. This method believes that every project

needs to be handled differently and the existing methods need to be tailored to

best suit the project requirements.

Agile represents a group of software engineering methodologies which

promise to deliver increased productivity, quality and project success rate

overall in software development projects. Such methodologies are SCRUM

(Schwaber and Beedle, Agile Software Development with Scrum, 2001), XP

(Beck & Andres, Extreme Programming Explained: Embrace Chance, 2004), or

the lesser-known Crystal (Cockburn, 2001). The outline of Agile Methodologies

was laid down by the Agile Manifesto, published by a group of software

practitioners (Beck et. al, 2001).

Scientific literature on the subject (Highsmith, 2002) suggests that the

differences between traditional methodologies and Agile Methodologies relies on

two main assumptions: First, traditional methodologies assume that customers

do not know their requirements, hence they need guidance from the developers,

but Agile Methodologies assume that both customers and developers do not

have full understanding of requirements when the project starts. Therefore, in

traditional software development environments, developers want a detailed

specification, whereas in Agile Methodologies customers and developers learn

together about the system requirements as the development process evolves.

Second, traditional methodologies assume that customers’ ability to foresee

their future requirements is limited. And such developers have to build in extra

functionalities to meet these future needs, often leading to overdesigned

system. On the other hand, Agile Methodologies emphasize

simplicity.

In the study of Sharp, Robinson, & Petre (2009), it aims to shed light over

using these rather simple artefacts in Agile Methodologies (and simplicity in

Scrum) by analyzing the national and social perspective of using the story

cards and the wall. The authors find that, besides the fact that both the user’s

stories and the wall have their own separate meanings, they have strong

combined meanings (meanings that occur only when they are used together).

Therefore, form a national perspective authors find that using the story cards

and the wall leads to: closeness of mapping between the users’ minds and what

they are trying to express, appropriate level if abstraction, providing means of

secondary notations (ex, by using colours, layout and labels), bringing

consistency in the project, reduce diffuseness of meaning, show hidden

dependencies, and improve overall visibility in the project. From a social

perspective, authors infer that notation does not exist in isolation; it has to be

situated in the reality of a social settings. For instance, the authors show that

in relation to the story cards, the teams have wall or annotating them).

Authorship becomes meaningful, while handwriting and initials become a form

of a secondary notation. In the same time, the wall becomes centric for the

social life of the team – mediates and manages the life of developer. The

position of the card on the wall becomes highly significant – when a card is

moved to “done” area, developers feel professional satisfaction and

achievement.

Cohen et al. (2004) published a review that emphasized the history of

agile development. Showing some of the roots to other disciplines, and in

particular, discussed relations between agile development and the Capability

Maturity Model. The authors believed that agile methods would be consolidated

in the future, just as object—oriented methods were consolidated. Further, they

did not believe that agile methods would rule out traditional methods. Rather,

they believe that agile and traditional methods will have a symbiotic

relationship, in which factors such as the number of people working on a

project, application domain, criticality, and innovativeness will determine

which process to select.

Agile uses an adaptive approach where there is no detailed planning and there

is clarity on future tasks only in respect of what features need to be developed.

There is feature driven development and the researchers adapt to the changing

product requirements dynamically.

The advantage of agile method is that it is a very realistic approach to software

development, it promotes teamwork and cross training, its functionality can be

developed rapidly and demonstrated, it has minimum resource requirements, it

also delivers early partial working solutions and has good model for

environments that change steadily. Agile method is easy to manage and gives

flexibility to developers.

The disadvantage of agile method is that, it is not suitable for handling

complex dependencies, and it has more risk of sustainability, maintainability

and extensibility. Agile depends heavily on customer interaction, so if customer

is not clear, developers can be driven in the wrong direction. There is also a

very high individual dependency, since there is minimum documentation

generated and the transfer of technology to new team members may be quite

challenging due to lack of documentation.

The agile development focuses on the rapid delivery of software and makes

customer as a part of the project development team. It has therefore

emphasized that the need for project planning must be limited for the

development and the project plan must be flexible whereas the conventional or

traditional development focuses on intensive project planning. As the agile

development is about the change therefore, the cost of change in the agile

development is a lower than the cost of change in traditional models.

 Requirements

Plan

Track & Monitor

AGILE

METHOD

Design

Release

Develop

Figure 2.2 Agile Methodology