Ever wondered what agile really is? What the benefits of implementing an agile team are? Or why agile projects are often more successful? Below is an overview of the Agile Principles, the core framework around how to operate agile projects.
The Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile teams believe that the best way to make clients happy is to organise the work so that we can deliver valuable software early and often. This is very different to traditional waterfall projects where nothing of any business value is delivered until everything is done.
When we are doing this we need to realise that we have two customers. One customer is the client, but they also have a customer who uses the software produced. Our clients are most likely to be satisfied when their customers are satisfied.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
When clients engage us they have some idea of what they want but this changes as they learn more about what’s possible and what their customers want. They often have to see and experience the product before they know what they really need.
Agile teams embrace change as it is natural and inevitable. We make change easy so that we can respond quickly to feedback on the products we develop. If customers are not responding well to what we’ve done we want to be able to change quickly so we get the outcomes that we’re all looking for.
Waterfall makes changes hard so that project teams can protect themselves from the cost of change and so that companies can charge clients a lot of money for change requests. Agile makes change easy so that we can deliver the most value to our clients at all times.
Agile isn’t a blank cheque. If a customer wants to change something that we haven’t started work on yet then we can do it instead of something else of equal size. If we have started work on something that clients want to change or if clients don’t want to take anything out then they have to provide extra time and budget to do these changes.
One way we make change easy is to do just enough analysis and design just in time so that we don’t waste a lot of effort designing something that’s going to change.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
We deliver working software frequently so we can get a product to market quickly. We want to reduce the risk that we’ve made errors, or that were working on something that isn’t required, by testing what were developing with customers as soon as we can.
If we deliver benefits early and incrementally we will also deliver a greater return on investment to our clients.
4. Business people and developers must work together daily throughout the project.
In traditional waterfall projects the scope, time and cost of the project are fixed. Project managers make sure that business people can’t talk to developers so that developers don’t make changes or provide estimates without management approval. But if developers aren’t allowed to talk to business people then communication has to be through documentation, which increases the project time and cost and leads to misunderstandings and errors.
When business people and developers are sitting together they communicate easily and understand each other better. This means that they can identify and resolve issues quickly and make decisions faster which increases value and reduces costs.
5. We build projects around motivated individuals; Give them the environment and support they need, and trust them to get the job done.
The traditional view is that to get good work from people you need to strictly control them and tell them exactly what to do. Like in a call center where they monitor how long people go to the toilet.
The agile view is that most people get a lot of satisfaction from doing good work. This view is supported by research which shows that people are motivated by autonomy, mastery and purpose (see Steven Pink video). Agile is a fundamental change from “command and control” management to “coaching and support”.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
In traditional projects a lot of communication is done through big documents and email so that changes can be stopped and so that managers can’t be blamed when things go wrong. But communicating by documents and email is slow and takes a lot of work and often leads to a lot of misunderstanding and rework.
The most effective way to communicate important information is regularly and in person. When business people and developers sit together they can communicate easily, resolve issues quickly and make decisions faster. This reduces project time and cost.
7. Working software is the primary measure of progress.
Big organisations can spend years and millions of dollars producing requirement and design documents before they even start to code. None of this delivers any value to customers or users.
Agile recognises that a business is wasting time and money if it isn’t delivering working software to users. This is why the primary measure of progress is the continuous delivery of a useful product or service, not the delivery of documents.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Waterfall projects often fall behind plan because the plan was incorrect. Management often demand that the team get back on track by working long hours for a long time. When this happens people become exhausted, quality and output drops and there is a lot of blame. This isn’t productive over long term.
Agile is about organising the work so that everyone has reasonable working hours and they can continue at a constant pace for a long time. This is more productive than short spikes of enormously long hours.
9. Continuous attention to technical excellence and good design enhances agility.
When project teams are poorly organised or under a lot of pressure they often take a lot of shortcuts to get a quick result. This creates technical problems which has a high cost later on.
Agile teams pay attention to technical excellence and good design throughout the project so that they can get the work done faster later on.
10. Simplicity – the art of maximising the amount of work not done – is essential.
Research shows that 64 percent of the features of enterprise products are “rarely or never used”. If we could simplify a project to just build the features that people use often then we could reduce the time and cost of a software project by two thirds.
The simplicity rule applies in lots of other areas of a project as well. For example, in a traditional project you could spend six months writing a 120 page requirements document that is rarely used. If you developed the requirements just in time for development you could save six months of work.
11. The best architecture, requirements and design emerge from self-organising teams.
In agile we assume that people are adults who want to do a good job. We think that the skilled and motivated people doing work are in the best position to discover and improve on the way the work is delivered. If we coach and support people and help them to understand the needs of the client and organisation then they will come up with the best solution themselves.
Sometimes people take this to mean that an agile team is not accountable to anyone. This is far from the case. Our highest priority is to satisfy the customer which means that we have to put the client at the centre of everything we do. We need to talk to them often and demonstrate progress on delivering value to them every day.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
One of the most fundamental principles of agile is that every team has a continuous improvement cycle. We achieve this by holding a retrospective every two weeks with the team and client to work out what we did well and what we could do better. If we did nothing else we would improve our process until we had reinvented the agile approach.
Agile is defined by the values and principles in the Agile Manifesto. It is not defined by Scrum. Scrum is just one of many frameworks or methods of implementing Agile. This means that you can be Agile without doing Scrum.
To really understand Agile you should read the values and principles regularly and think about how to apply them.