Principles of Agile

Having recently attended a two-day seminar on Agile Theory and Practice, I’m going to make some notes on the main takeaways from the seminar. Broadly speaking, the Agile approach to software development is largely the opposite of the Waterfall model.

Within Waterfall, a strict process is adhered to, usually following a path that goes something like:

Requirements → Design → Build → Test → Release → Maintain

Sometimes, this may be the most appropriate system to apply to a project. Perhaps the client doesn’t want to be involved at every turn, or maybe the project simply doesn’t lend itself to the ‘bits-and-pieces’ system of agile.

While Waterfall may be appropriate for many projects, it has its problems. The most obvious issue is that none of these stages can be started until the previous stage has ended, each stage being completely independent of all the others. Additionally, the end user / client doesn’t see any form of a working product until quite late in the process, usually somewhere around either the Test or Release stage.

Agile takes a very different approach. Emphasis is placed on delivering working software as soon as possible, and collaborating with the end user at every opportunity. Projects are allowed, even encouraged, to evolve over time as small pieces of it are delivered and demonstrated.

It is more of a mindset than a methodology:

Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more

So says the Agile Manifesto, which is built upon 12 core principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The Backlog, Sprints, and Team Velocity

‘Backlog’ can sound like an intimidating term, but within Agile workflows, it just means ‘the amount of work to be done’. At the beginning of a project, this will likely be quite a lot of features that all need to be developed, but after each ‘sprint’, the number of features should drop.

‘Sprints’ are a common means of employing Agile techniques. The idea is that a development team will designate a period of time in which to complete a sprint, usually around a week, possibly as much as a month, but really, the shorter the better. The team then predicts how much of the backlog they will aim to complete within this sprint. Then they just get to it. At the end of the sprint, they reconvene – ideally with the end user there too – and look over how much they’ve achieved. Any completed backlog tasks are reviewed by the client and if they’re happy, they are marked as completed, thereby removing them from the backlog.

They also discuss whether their projections for the sprint were accurate. Were their estimations unreasonable? Did they run out of time? Did they complete ahead of schedule? By evaluating in this way, they learn something about their ‘Team Velocity’, so for their next sprint they can allocate backlog tasks more appropriately.

Next, they start the whole process again. The backlog will be diminished this time, and they can more easily predict how much of it will be completed within the sprint’s timeframe. The process repeats again and again until the project is completed, and after each sprint, estimations of team velocity get more and more accurate. Additionally, wherever requirements might change, or an innovation in technology becomes available, these can be integrated into the process straight away.

The best part of all this, is that the client / end user is involved after every sprint. This has numerous benefits:

• the client can witness progress being made in real-time
• the client can interact with features of the project as soon as they are completed
• if the client has new / changing ideas, these can be discussed as soon as they arise
• the team receives almost instant feedback for every feature they develop and can act upon it in the next sprint