Agile Basics

Agile vs Waterfall

Two common types of project management are Agile and Waterfall and a good way to understand Agile is to compare it to Waterfall.

Waterfall

The simplest way to explain Waterfall is as a sequence (or sequence of sequences). Tasks are planned and carried out in order.

This works best where there is a defined end goal and firm requirements for your project. It also means that a client may not see the fruits of your labour until close to or at the end when it is all finished.

You will produce what you were told to in the first instance but also your client will have no chance to change their minds along the way.

A good example of this style of project would be building a house. You will have set expectations and immovable regulations you need to adhere to and when changes occur they will be mainly led by unforeseen issues emanating from the project itself e.g. underground obstacles or variations affecting foundations.

You cannot build the roof before the foundations etc. so things will need to be done in a strict sequential order.

Agile

Agile is different. Agile was created for software where the rules about ordering tasks can be more flexible. You can, for example, build a facade or user interface for a product that does not work yet. It may lack foundations but it will be able to look the part and give a client a good idea of what the end product may look like.

In software, your wire-framing and initial design could look exactly like your end product if you wish so there is no problem of a client saying: "I thought it would look bigger in real life" because both the plans and the end product exist in the same space.

This flexibility also means that you can show your client an unfinished product or part of a product and get feedback throughout the process. Any problems you have from the client are better to have earlier in the process - this called Failing Fast i.e. not storing up trouble for later but getting the bad news first so you can avoid wasted efforts.

Agile Values

These are comparative values which state that whilst the traditional project values are still important, these should take precedence. These can be seen as revolving around central tenets of the utmost importance of customer service and the effective application of efforts. Responding to and meeting (or exceeding) the needs of the customer is the top priority and feeds into all aspects of the project and methods of working. The Agile methodology seeks to extract the most value from a team and project and minimise wasted efforts through continuous delivery and feedback from the customer.

Individuals and interactions

over processes and tools

Processes and tooling should be a response to communicated needs. Working methods should fit the brief and most recent feedback whilst also accommodating the individuals in the team and utilising their skills in the most effective way.

Working software

over comprehensive documentation

Getting software in front of your customer is more important than writing documentation. A meeting and demonstration of a working product is more valuable than a delayed product with good documentation.

Customer collaboration

over contract negotiation

Agile works by involving the customer throughout the process, including changes of needs and expectations along the way. This should be a collaborative process where expertise is shared in both directions to arrive at the best outcome.

As a result, the full pathway is not clear in the initial stages and having an overly restrictive contract will only result in a sub-optimal product based on flawed initial predictions.

Responding to change

over following a plan

The reason for short sprints / iterations of production is to allow for change. Products change and expand over time. This could be a customer led change, or a change in technology etc. A good project should be able to leverage any external changes to improve the project outcome.

Also, the less time spent on an unnecessary feature, the better it will be for productivity and morale.

The Twelve Principles

These are derived from the values above and are fairly self-explanatory. They can be further grouped into four areas:

1. Value Delivery

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.
• Simplicity--the art of maximising the amount of work not done--is essential.
• Continuous attention to technical excellence and good design enhances agility.

2. Business Collaboration

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.

3. Team Dynamics and Culture

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• The best architectures, requirements, and designs emerge from self-organising teams.

4. Retrospectives and Continuous Learning

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.