Module 1: Agile Foundations

The Agile Manifesto in Practice

Before you learn Scrum, you need to understand the thinking it grew from. In 2001 a group of seventeen software practitioners met in Utah, in the United States, and wrote the Manifesto for Agile Software Development. It is short, but it changed how many organisations deliver work. If you understand what it actually says, you will avoid many of the misunderstandings that make "agile" fail in practice.

The four values

The manifesto states that its authors came to 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

It then adds an important sentence: while there is value in the items on the right, they value the items on the left more. This is often forgotten. The manifesto does not say "no documentation", "no plans" or "no contracts". It says that when you must choose, prefer the left side.

The twelve principles in plain language

Behind the values sit twelve principles. You can read the original wording at agilemanifesto.org. In plain language they say:

1. The highest priority is satisfying the customer through early and continuous delivery of valuable work.
2. Welcome changing requirements, even late, when they give the customer an advantage.
3. Deliver working results frequently, preferring shorter timescales (weeks rather than months).
4. Business people and the delivery team work together daily.
5. Build projects around motivated people, give them support and trust them.
6. Face-to-face conversation is the most effective way to share information within a team.
7. Working results are the main measure of progress.
8. Work at a sustainable pace that can be maintained indefinitely.
9. Continuous attention to technical excellence and good design improves agility.
10. Simplicity, the art of maximising the work not done, is essential.
11. The best designs and requirements come from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective and adjusts.

Although written for software, these principles apply to many kinds of knowledge work, such as marketing campaigns, policy design or product development.

What it looks like in practice

Consider a hypothetical fintech start-up in Nairobi building a bill payment app. A traditional approach might spend four months writing a detailed specification for every feature, then six months building, then test and release. Feedback from real users arrives after ten months.

An agile approach applying the manifesto would look different. The team works with a product person who talks to customers every week. Within the first month they release a simple version that lets users pay one type of utility bill. Users immediately report that they want to save billers for repeat payments, something nobody had thought important. The team adds it two weeks later. A feature that the original specification included, paying multiple bills at once, turns out to be rarely needed, so it is postponed. This is "maximising the work not done".

The team still writes documentation (for example, how the payment integration works) and still plans, but the plan is short-range and updated as they learn.

Using the manifesto to make decisions

The manifesto is most useful as a test when you face a choice. Ask:

• Will this help us deliver something valuable sooner?
• Does it bring us closer to real customer feedback?
• Does it support the people doing the work, or just add process?
• Can we keep this pace without burning out?

Common mistakes to avoid

• Treating "agile" as permission for no planning or documentation. The right side still has value.
• Adopting agile tools without agile values. A digital board does not make a team agile if managers still dictate every task.
• Ignoring sustainable pace. Frequent delivery does not mean permanent overtime.
• Ignoring technical quality in the rush to deliver. Poor quality slows everything down later.