Agile and Agile Development Methodologies

Powered by: MindStick Software Pvt. Ltd. Unleash Your Imagination!!

Powered by: MindStick Software Pvt. Ltd. Unleash Your Imagination

Agile and Agile Development

Methodologies

What is Agile?

Agile is a time boxed, iterative approach to software delivery that builds software incrementally from

the start of the project, instead of trying to deliver it all at once near the end. It works by breaking

projects down into little bits of user functionality called user stories prioritizing them, and then

continuously delivering them in short two week cycles called iterations.

How does agile work?

At its core, agile does the same thing we do when faced with to much to do and without enough time.

Step1: Make a List: Meet the customers and note down the list of features he like to see in his software.

We call these things user stories and they become the TO DO list for your projects.

Step2: Size things up: Use Agile estimation technique, we size our stories relatively to each other,

coming up with a guess as to how long each story will take.

Step3: Set Priorities: Like most list, there always seems to be more to do than times allows. So we ask

customers to prioritize their list so we get the most important stuff done first, and save the least

important for the last.

Step4: Start executing: Start delivering some value. We start at the top. Work our way to the bottom.

Building, iterating, and getting feedback from the customer.

Step5: Update the Plan: As we start delivering one or two things is going to happen:

We are going fast enough. Everything’s going as planed or,

We have too much to do and not have enough time.

At this time we have two choices:

1. Do less and cut scope (as recommended)

2. Push out the date and ask for more money.

The Agile way:

The following features make agile different and unique from other development methodologies:

Analysis, design, coding and testing on an Agile project are continuous activates.



Development is iterative.ie. We starting with something very simple and add to it incrementally

over time.

Panning is adaptive i.e. when reality disagree with our plans. Agalists find it easier to change

their plans than reality. We call it adaptive planning.

Roles blur: i.e. when it’s done right, joining agile team is lot like working in a mid-size start-up.

People pitch in and do whatever it takes to make the project successful-regardless of title or

role. On an agile project, narrowly defined roles like analyst, programmer and tester don’t exist

– at least not in traditional sense.

Scope can vary: The issue in agile is “Lots of work in less time”. By fixing time, budget, quality

and being flexing around scope. Agile team maintain integrity of their plans, work within their

means and avoid the burn out.

Requirements can change: Changes usually shunned on software projects because of its high

coast later. But Agile believe that the cost of change can be relatively flat. Through a

combination of modern software engineering practices, and open and honest planning, Agilsts

accept and embrace change even later in the delivery process.

Working software is the primary measure of success: The rate at which team turn their

customer’s wishes into working software is how Agilists measure productivity. Project plans, test

plans and analysis are all well and good but Agilists understand they themselves are of no value

to the end customer.

Agile software development Methodologies:

Most widely used methodologies based on agile concept are XP and Scrum. They differ in particulars but

share the iterative approach.

XP:

XP stands for extreme programming, it concentrates on the development rather than managerial

aspects of software projects. XP was designed so that organizations would be free to adopt all or part of

the methodology.



XP projects start with a release planning phase, followed by several iterations, each of which

concludes with user acceptance testing. When the product has enough features to satisfy users,

the team terminates iteration and releases the software.

Users write “user stories” to describe the need the software should fulfill. User stories help the

team to estimate the time and resources necessary to build the release and to define user

acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to

requirements as the software is being built. This allows requirements to evolve as both users

and developers define what the product will look like.

To create a release plan, the team breaks up the development tasks into iterations. The release

plan defines each iteration plan, which drives the development for that iteration. At the end of

an iteration, users perform acceptance tests against the user stories. If they find bugs, fixing the

bugs becomes a step in the next iteration.

Iterative user acceptance testing, in theory, can result in release of the software. If users decide

that enough user stories have been delivered, the team can choose to terminate the project

before all of the originally planned user stories have been implemented.

SCRUM:

Scrum usually refer as the term in Rugby for a huddle mass of players engaged with each other to get a

job done. In Software development, the job is to put out the release. Scrum for software development

came out of the rapid prototyping community because prototypes wanted a methodology that would

support an environment in which the requirements were not only incomplete at the start, but also could

change rapidly during development. Unlike XP, Scrum methodology includes both managerial and

development processes.

At the center of each scrum project is a backlog of work to be done. This backlog is populated

during the planning phase of a release and defines the scope of the release.

After the team completes the project scope and high-level designs, it divides the development

process into a series of short iterations called sprints. Each sprint aims to implement a fixed

number of backlog items. Before each sprint, the team members identify the backlog items for



the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and

check progress.

During a sprint, the team has a daily meeting called a scrum. Each team member describes the

work to be done that day, progress from the day before, and any blocks that must be cleared. To

keep the meetings short, the scrum is supposed to be conducted with everyone in the same

room—standing up for the whole meeting.

When enough of the backlog has been implemented so that the end users believe the release is

worth putting into production, management closes development. The team then performs

integration testing, training, and documentation as necessary for product release.

Scrum development:

The Scrum development process concentrates on managing sprints. Before each sprint begins,

the team plans the sprint, identifying the backlog items and assigning teams to these items.

Teams develop, wrap, review, and adjust each of the backlog items

During development, the team determines the changes necessary to implement a backlog item.

The team then writes the code, tests it, and documents the changes. During wrap, the team

creates the executable necessary to demonstrate the changes. In review, the team

demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team

consolidates data from the review to update the changes as necessary.

Following each sprint, the entire team—including management, users, and other interested

parties—demonstrates progress from the sprint and reviews the backlog progress. The team

then reviews the remaining backlog and adds, removes, or reprioritizes items as necessary to

account for new information and understanding gathered during the sprint.

Hope you understand the concept of Agile and its methodologies. Thanks for reading this article.

For more fun and details visit us at: http://www.mindstick.com/

http://www.mindstick.com/

Engineering

Agile and Agile Development Methodologies