10 key principles of Agile Software Development

1. Active User Involvement
It is imperative to have a senior and experienced user representative involved throughout. The benefits are:

• Requirements are clearly communicated and understood (at a high level) at the outset
• Requirements are prioritised appropriately based on the needs of the user and market
• Requirements can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren't read or are misunderstood
• Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood
• As iterations of the product are delivered, that the product meets user expectations
• The product is more intuitive and easy to use
• Developers are accountable, sharing progress openly with the user/business every day
• The user/business shares responsibility for issues arising in development; it’s not a customer-supplier relationship but a joint team effort
• Timely decisions can be made, about features, priorities, issues, and when the product is ready
• Responsibility is shared; the team is responsible together for delivery of the product
• Individuals are accountable, reporting for themselves in daily updates that involve the user/business

2. Agile Development Teams Must Be Empowered
The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

3. Requirements evolve but the timescale is fixed
In Agile Development, requirements evolve, but timescales are fixed. In Agile Development projects, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.

4. Capture requirements at a high level; lightweight & visual
Agile Development teams capture requirements at a high level and on a piecemeal basis, just-in-time for each feature to be developed. Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.

However any requirements captured at the outset should be captured at a high level and in a visual format, perhaps for example as a storyboard of the user interface. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more.

5. Develop small, incremental releases and iterate
One bite at a time! Likewise, agile software development projects are delivered in small bite-sized pieces, delivering small, incremental *releases* and iterating.

6. Focus on frequent delivery of products
Agile software development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

But how frequent is *frequent*?

Scrum says break things into 30 day Sprints. That's certainly frequent compared to most traditional software development projects.

Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the software is just too large to be practical on such a regular basis.

But consider a web site, a web-based product - or even more dynamic something like my blog. There's no rollout overhead - it's an automated central deployment to all users, and for the blog it's a single click. No-one's paying for the service. If something's wrong, no-one dies. And it can be rolled back as quickly as it's deployed. There may be thousands of users, even millions of users of a web site every month. But none of them need to be trained. And you can evaluate the impact on the user experience, and the user's behaviour, through metrics within 24 hours and on an ongoing basis.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes I've described above. Think about what's right for you; your organisation; your product; your market; your customers. Think about what's right for *you*, in your *particular situation*. There is no right or wrong answer. Only what works for you, and what doesn't.

7. Complete each feature before moving on to the next
In agile development, "done" should really mean "DONE!".

Features developed within an iteration (Sprint in Scrum), should be 100% complete by the end of the Sprint.

In an ideal situation, each iteration or Sprint should lead to a release of the product. Certainly that's the case on BAU (Business As Usual) changes to existing products. On projects it's not feasible to do a release after every Sprint, however completing each feature in turn enables a very precise view of progress and how far complete the overall project really is or isn't.

8. Apply the 80/20 rulePareto's law is more commonly known as the 80/20 rule. The theory is about the law of distribution and how many things have a similar distribution curve. This means that *typically* 80% of your results may actually come from only 20% of your efforts!

9. Testing is integrated throughout the project lifecycle – test early and often
In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.

10. A collaborative & cooperative approach between all stakeholders is essential
Agile development relies on close cooperation and collaboration between all team members and stakeholders. Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development.

This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) 'on the same page' throughout the development.