An Introduction to Applying Agile to Software Development Projects

A few years ago a group of developers came together with the purpose of creating a better and more efficient approach to software development projects. Their brainstorming sessions resulted in a value oriented approach to project management, condensed in the format of a manifesto called the Agile Manifesto. This unique philosophy or approach to project management was created in response to the apparent lack of user-satisfaction within the software market.

In short, Agile can be described as a project management solution that encourages frequent inspection and adaptation. When applied to software development projects, Agile allows for the rapid delivery of high quality software by applying a set of basic communication and administration principles. The emphasis throughout the Agile manifesto is on teamwork in the form of face-to-face communication, self-organisation and accountability.

Various companies are applying Agile management principles to their software development projects in order to reduce costs and advance their market effectiveness. What makes the Agile manifesto so attractive is its minimalistic approach that emphasises people, consistency, communication and quality. The Agile Manifesto was compiled in 2001 and is based on four primary values.

The four primary Agile principles:

1. People

The first value in the Agile manifesto chooses individuals and interactions above processes and tools. This important value raises three questions for developers that should provide them with that initial insight that sets the tone for the rest of project.

a) Why are we building this?

Developers are required to take a step back and determine what it is that they want to achieve with this project. It is during this stage that developers can establish the role and purpose that this software solution will have to fulfil in the user-environment.

b) Who are we building this for?

This next question aims to define specific user details. The developers need to establish the role and unique attributes of the individual who will be using this software product.

c) What do these users want?

This third and final question enables software developers to establish what the specific user-requirements are for this product. Agile prescribes a unique approach of documenting these requirements in the format of “user stories”. Each user story is made up of two primary sections, the title and acceptance criteria.

The Title

The title of each user story is formatted in the following way: AS A ROLE, I CAN DO SOMETHING SO THAT I CAN GET SOME BENEFIT. A practical example could read as follow: AS A USER I CAN SIGN UP SO THAT I CAN USE THE SITE.

The Acceptance Criteria

In the acceptance criteria certain practical questions are asked. These might seem pretty obvious but it is often these basic steps that are overlooked during the development processes. The first value in the Agile manifesto chooses individuals and interactions above processes and tools. This important value raises three questions for developers that should provide them with that initial insight that sets the tone for the rest of project.

1. Sign using an email address?
2. Sign up using password?
3. An email can only be used once?
4. Email must be formatted correctly

The Title and acceptance criteria will enable the developers to estimate what it is that they need to do how to present that to the business in a way that is straightforward and intelligible to the user.

2. Delivery

The second value of the Agile manifesto called Delivery, prioritises working software over document comprehension. This basically means that developers should focus on building the right thing from start to finish – with an emphasis on quality -. If the initial stages of the software development project are on par with the exact user-requirements, it will save the developer additional time spent on changes and product revisions. This principle aims to counteract the fact that there are too many unsuccessful products with unnecessary and unused features on the market.

The differences between traditional project management and Agile methods:

Agile was originated to offer developers an alternative project management solution that differs from the traditional waterfall model of development. Agile is value driven whereas the waterfall model seems to adhere to processes that are often inconsistent with the way that developers deliver effective work results.

Agile relies on a project backlog in order to keep things value-driven. The backlog contains a list of all the project requirements, documented as “user–stories”. Each Backlog is sorted in order of priority – with the highest priority user-story listed at the top of the backlog -. Each project backlog has been set in such a way so that it can continually evolve along with the project, meaning that items can be shifted and sorted and recalled effectively and speedily.

Quality Software

Agile was originated to offer developers an alternative project management solution that differs from the traditional waterfall model of development. Agile is value driven whereas the waterfall model seems to adhere to processes that are often inconsistent with the way that developers deliver effective work results.

Through Agile, quality software is achieved through the implementation of the following:

1. Test -driven development
2. Continuous integration
3. Automated acceptance testing

3. Involvement

The third value of the Agile manifesto gives preference to customer collaboration when the topic of contract negotiation is raised. This is achieved through:

1. Story Carding
2. Feedback loops

Story-carding

The term “story-carding” refers to the initial gathering process whereby specific requirements for the software project are laid out. During the story-carding process, the developer or customer representative will sit down with the customer and figure out what exactly it is that the customer is looking for. This session will be documented in the simple format of a user-story and often the project representative will write his/her notes on the back of an index card.

Each index card will contain the primary user requirements at the top and list the rest of the acceptance criteria below. Often the software project team might end up with a stack of index cards after the initial story-carding process. These story-carding sessions can take anything between a few hours to a few days, depending on the scope of the project.

Feedback Loops

One of the objectives of the Agile approach to software development, is to make the entire process as transparent as possible. The aim of the Agile team was to create a project solution where the entire process is accessible and easy to understand. Feedback loops are there to reinforce constant communication throughout the development process. This enables every team member to know exactly what is expected when and where. Feedback loops are applied during the process as well as in the code.

Process

Each process is made up of a sprint planning session, sprint review session, daily scrum-sessions and burn-down charts.

Code

The code itself can also be designed in such a way to radiate information. This is done through continuous integration servers that will let the team know if anything they have added will interfere with anything that has already been developed.

4. Adapting

The final value, called adapting chooses an active response over following a plan.

One of the things that make Agile so attractive to users is the fact that it has been designed to adequately respond and mould itself to an ever-changing business environment.

Sprint sessions

Each sprint session aims to reinforce this attitude of adapting. A Scrum-sprint session refers to the initial process planning platform, made up of practices and predefined roles. The main roles in Scrum are:

1. “ScrumMaster”: This is usually the individual who is in charge of documenting and maintaining the project processes. The Scrum master is often also labelled the project-manager.
2. “Product Owner”: This specific team member will act as a representative for the stakeholders.
3. “Team”: each scrum-team consists of a group of more or less 7 people who do the actual analysis, design, implementation and testing.

Sprint planning should take place on the first day of the sprint. This session is divided into two parts, the first part is attended by the delivery team and the product manager, whereas the second part is usually only attended by the delivery team. The Agile approach values face-to-face communication over written documents, placing an emphasis on and people, interaction, adaptability and quality. An important principle of the Agile approach is that time and resources are fixed while the project scope can be adjusted. This allows companies who make use of the Agile approach to remain flexible and to adapt to the continual changes of the business world.