You have already heard about Agile, but might want to know more, so here is everything you need to know about software development and the agile methodology.

Where does Agile come from?

Software arrived along with the personal computer in the 1970s and 1980s.  1977 was the time when the Apple II was released, as well as when operating systems were created.  These operating systems had to perform many tasks and calculations, and took a long time to write.

The development process was one in which the scope was already defined up front and couldn’t be changed.  This meant long lead times and frustrated developers.

The thought that there had to be a better way to build software was what drove Jon Kern and other developers to create Waterfall.  It was the first software development lifecycle model that was used in successful development projects.  This approach divides the software development process into separate phases, starting with a requirement analysis and ending with a maintenance phase.  This is the final phase where any issues are fixed (with a patch).  It is also in this phase where any enhancements to the product are released.

One of the problems with this method is that if things aren’t well documented or thought through at the conceptual or analysis phase, it isn’t easy to go back and make any changes once an application is in the testing phase.

This was the software development method from which Agile stems.

The Agile Manifesto

Today, Agile encompasses a vast collection of methodologies and techniques all with a strong tie back to the agile manifesto and the earlier evolutionary history of iterative processes.

The Agile Manifesto, drawn up in 2001 by a group of 17 industry leading experts, places a much greater emphasis on people and communication (as opposed to process formalities and documentation).

Through uncovering better ways of developing software by doing it and helping others do it, software development companies value the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile methodologies in general are characterised as being less documentation-intensive and producing more useful and efficient software. This usually means that the project actually delivers less, but more valuable software.

What is Scrum and what does it have to do with Agile?

Scrum is a part of the agile methodology used to manage agile projects.  This process framework is used primarily for software development projects with the aim of delivering new software capability in 2 – 4 week cycles – referred to as Sprints.

Information is made transparent within a scrum, allowing people to make changes during the development cycle rather than at the end.

A number of events occur in a Scrum, and include:

• Sprint Planning (Sprint backlog) – At the start of each sprint the project team will commit to completing a number of items. These items are added to the product backlog, forming a sprint backlog.
• Daily Scrum – During each sprint, the project team will meet on a daily basis for a very brief daily scrum. It is here that daily activities, progress and issues are discussed.  The purpose of this meeting is not to discuss issues in detail, but simply for team members to communicate daily so that everyone is aware of the entire team’s activities, progress and potential problems.  Issues highlighted during the meeting that require further discussion are set aside for specific action by involved team members after the meeting.  In particular each team member must answer three questions in the daily scrum meeting, namely:

1. What tasks have I completed since the previous scrum meeting? (i.e. in the last day)
2. What tasks will I complete before the next scrum meeting? (i.e. in the next day)
3. What impediments or obstacles am I facing that might be or have been preventing me from completing tasks as expected?

• Sprint Review – Once the sprint is complete, it is reviewed, and the team demonstrates what was accomplished during the sprint. The goals identified during the sprint planning are reviewed, and each backlog item assessed.

The definition of completion includes all activities related to a functional requirement. So a piece of functionality is only considered complete if it has been fully tested, documented and deployed.

At the end of each sprint (2-4 weeks), completed functionality is demonstrated to the client. Ideally this functionality will also be deployed to a live environment at the end of each sprint.  This is so that the business can start benefitting from it as quickly as possible.

The Xpedia Scrum methodology

Xpedia applies the principles of agile application implementation in its project approach.

In particular, the Scrum methodology is used to manage agile projects.

Management of project scope is an important part of any project and is addressed effectively in the Xpedia methodology. This is done by managing scope as the single variable in project, thus placing a strong project management focus on managing scope effectively. This concept is illustrated by the scope-time-cost triangle.

The scope-time-cost triangle represents the principle of compromise between scope, time, cost and quality. Any significant change in scope will have a corresponding effect on time and cost.

Quality is represented by the shape of the triangle, a balanced equilateral triangle representing good quality and an unbalanced scalene triangle representing compromised quality.  For example, one can increase scope and cost without affecting timeframe by asking consultants to work overtime.  This could be quite successful, except that if consultants work significant amounts of overtime over a sustained period, there is invariably loss of quality as people simply deliver better quality if they are not overworked.  Similarly, cramming too much scope into a limited timeframe and cost is usually achieved by taking shortcuts, which again represent poor quality.

Xpedia prides itself on delivering quality solutions and will at all times strive to ensure that high standards of quality are maintained and will not be compromised by scope, time or cost pressures.

Thus, Xpedia sets fixed standards of quality and fixed time and cost is agreed with the client at the start of the project.  Over the duration of the project, the only variable remaining is therefore scope.

Because scope is limited by the fixed factors of time, cost and quality, any new requirements must be evaluated against requirements already in the current scope.  If a new requirement is more valuable to the business than some of the requirements already included in the scope, it may be included, but this will mean that the lowest priority requirements, at the low end of the product backlog will be excluded.

This approach ensures that quality is delivered; flexibility is available to cater for new requirements as they arise without affecting the overall project cost; and that return on investment is always optimized to include only the most valuable requirements.  The client always has the option to extend the project to include more requirements, but this doesn’t need to be considered until the most critical requirements are already met and the business is already benefitting from the use of the software.

Why use Agile for software development?

To optimize return on investment is a big reason why to use the agile methodology.

By using Agile in your software development process you can ensure:

• Higher productivity
• Better-quality products
• Reduced time to market
• Improved stakeholder satisfaction
• Better team dynamics
• Less risk

Sources

• scrum.org
• versionone.com