Traditionally, projects have taken a sequential, step by step approach, starting with the gathering of detailed requirements, design, coding, system and user acceptance testing, bug fixes, and delivery. Lengthy review and approvals often need to take place too. Some benefits of this Waterfall approach are:

• Agreement on what will be delivered, making planning and measuring progress more straight forward.
• Customer engagement is not required after the requirements gathering phase, beyond reviews and status meetings.
• Knowing the full requirement can allow for more careful design rather than a piecemeal design where new components are bolted on and made to fit.

The main negatives are:

• Gathering requirements is often difficult, as users describe the system they already use, plus they find it hard to understand or visualise all of the documents that they are given to review.
• Users tend to really understand the designed system towards the end of development, when it is difficult and costly to change.

Agile addresses these problems:

• The customer has frequent and early opportunities to see the work being delivered, and introduce change as required.
• A scaled back version of the product can be released early, with successive iterations adding more and more functionality.
• The process is focused on the customer, bringing the customer into the project team.

But of course, there are disadvantages

• The customer must be given time to be fully and continuously engaged. BAU must be given a back seat.
• Piecemeal iteration may give need for frequent, wholesale redesign, to correct inefficient design made earlier.

In a world of rapid change and usually uncertainty in what we need to build, the reality is that we can't always afford long development cycles, for projects that may need to be scrapped and rebuilt later on.

A short summary, encapsulated as a manifesto describes the culture of being 'agile' It states that we value:

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

While there is value in the items on the right, we value the items on the left more. The principles underlying this are below. Click on each one to understand what the principle actually means.

Scrum and Kanban are the most commonly used Agile project management frameworks. Both place a high value on continual improvement, optimisation of the work and the process. Both are highly visible and keep everyone informed on what is being done and what is to come.

The key differences for each are:

• Kanban - Products and processes are delivered continuously on an as-needed basis.
• Scrum - Deliverables are determined by set periods of time (sprints) in which a set of work must be completed.

• Kanban - Team members can pick new tasks out of the backlog according to priority once they have completed a task.
• Scrum - A number of tasks are 'pulled' from the backlog for each time boxed iteration (sprint).

• Kanban - Changes can be made at any point, allowing for continuous improvement.
• Scrum - Changes are encouraged only at the sprint review, and not mid-sprint.

The similarities are:

At heart, they both follow agile principles. Both methods use a physical or digital board where people move work between roughly three categories:

• Work that needs to be done
• Work that is in progress
• Work that has been completed

First of all, we need to accept that software or change needs to be done more quickly in order to either gain or maintain a competitive advantage. So does this mean that Agile is the 'winner'?

Agile is all about a set of values and principles, and being able to adapt and adjust; therefore to say that Agile is the only way is actually being anti-agile.

Waterfall projects might become fewer in number but how Agile we can be depends on how prepared the organisation is to change.

In order to improve speed to market, maybe a transforming organisation will break a big project down into mini-projects, each using a variation of waterfall, so that the traditional sequencing of phases is not actually that sequential.

To help us decide which approach we should use, consider the following:

• Requirements are constantly changing (Agile)
• People such as developers and product owners are dedicated to the project (Agile).
• People are distributed or located off-shore (Waterfall).
• Continuous and frequent feedback is avaiable from the customer (Agile).
• There are fixed costs, or any other restrictions (Waterfall).

Just because a characteristic tends towards Waterfall, think what might need to change to allow a more agile approach to be used. For physical location, video conferencing and teams that are dedicated to the task might mean that off-shore projects don't have to be Waterfall.

So to conclude, choose the best method for the project and organisation, but no matter which approach is taken, in the spirit of agile, do, learn, change. Become an agile organisation in increments if necessary.

There is a hierarchy of understanding, with various levels. For simplicity lets start with the vision, which should act as the direction for all other activities. There are other ways of collating understanding but but the most important are the following four.

1. Vision
2. Epic
3. User Story
4. Task

Vision

The product vision should serve as the guiding light to everyone in the team. It states the desired future state and supports the Product Owner in prioritising the features to be built first.

It needs to identify the goals, the customer, and why the product is needed. It needs to be unambiguous and realistic.

In my experience, the vision is often not very well communicated. Project members who work at a level of detail down in the hierarchy make fantastic efforts but its a bit like driving at 100mph in the fog.

Epic

An epic is piece of work that can be broken down into smaller tasks called 'user stories' or 'stories'. It allows work to progress in smaller pieces whilst maintaining progress towards a common objective.

User Story / Story

A user story will focus on people / the customer, on what needs to be done, and why. The format is below:

As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].

It's a very short sentence written from the perspective of a specific stakeholder (there may be user stories for different stakeholders) a and will give the reader an instant understanding of the value that can be gained by doing the work. It doesn't need lots of detail. The principle of agile is 'just enough', and a user story acts as a placeholder, for follow up on the detail later.

Task

Tasks break down user stories or other items in the backlog to a more granular level.

The user story creates understanding of what needs to be done or a software feature from stakeholder / user perspective.

As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].

If the format is not followed there will be risk that implementation is not done correctly.

Common User Story mistakes

• Too many stories - These are great for understanding features from each stakeholder's perspective, but there are also other ways of recording what is needed. These could be things like complicated interactions, processes modeling, andlow fidelity and high fidelity UI design.


• Anonymous User - This is something I've seen more often than not. Rather than stating 'As a user...', it's crucial to understand just who this 'user' is in order to fully understand their need. No more mythical 'users', please!


• Large user stories - These are sometimes so big or ambiguous that they can't be delivered in a short time scale. In likelihood, the user story is actually an epic which hasn't been broken down. A user story needs to be clear, achievable, and testable.


• User Story hand off - The traditional method of development sees diligently written Requirements Documents provided by the BA and business teams to the developers. The problem with this is that the developers often don't understand the requirements. User story hand off is the same. Instead, user stories should be defined in conjunction with the development team.



I've seen these mistakes far too frequently. In fact it's more usual than unusual to see them. Clearly, organisations have some way to go before they can be considered truely Agile.

Scrum is comprised of Sprints, which are fixed periods of time, each of which are typically between one and four weeks. The point to this is accomplish tasks in incremental pieces. Because each sprint is so short, it allows projects to cope with uncertainty and changing requirements.

• Backlog - Everything that needs to be included in the product or project.


• Sprint Planning - At the beginning of a Sprint the team determines which items from the product backlog they will work on during that Sprint.


• Daily Stand Up - Involving up to 11 people including the Scrum Master and Product Owner, the daily stand up should be no more than 15 minutes. In it will be communicated progress and impediments. Answers to the three questions are shared - 
  
  What was done yesterday? What is planned today? Are there any blockers?
  
  Instead of this, the team can simply talk about what they want to achieve today. It's a chance for team members to share information and help out others.


• Sprint Review - At the end of each Sprint, the review covers all that was done and what was not done in the previous Sprint. This will then feed into the next planning session.


• Sprint Retrospective - This provides a chance for the team to to discuss the challenges encountered in the previous Sprint, and what went well or otherwise, with the aim of being to improve the next sprint.