Agile values

Why it matters

In Project Management Fundamentals you planned a project up front: scope, schedule, critical path. That works well when the requirements are clear and stable, like building a car park. In software and digital products they rarely are. Users only know what they want once they see something, technology changes, and the market moves. Agile is a response to that uncertainty: deliver something small, learn from it, adjust, repeat.

Waterfall in one picture

A waterfall (or predictive, plan-driven) project runs through phases in order:

Requirements -> Design -> Build -> Test -> Deploy

Each phase finishes before the next starts, and changes after sign-off go through change control. Its strengths are predictability and clear documentation. Its weakness is that users see working software only at the end, so a misunderstanding in month one is discovered in month nine, when it is most expensive to fix.

The Agile Manifesto

In February 2001, seventeen software practitioners met in Snowbird, Utah, and wrote the Manifesto for Agile Software Development. It is short enough to read in a minute at agilemanifesto.org. Its four values:

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.

The last line matters. Agile does not say "no documentation" or "no plan". It says that when the two conflict, prefer the left-hand side.

The twelve principles, grouped

The manifesto also lists twelve principles. Grouped by theme:

• Deliver value early and often: satisfy the customer through early and continuous delivery; deliver working software frequently, from every couple of weeks to every couple of months; working software is the primary measure of progress.
• Welcome change: changing requirements are welcome, even late in development.
• Work together: business people and developers work together daily; face-to-face conversation is the most effective way to share information; build projects around motivated individuals and trust them.
• Sustainable pace: teams should be able to keep a constant pace indefinitely.
• Quality and simplicity: continuous attention to technical excellence and good design; simplicity, the art of maximising the amount of work not done, is essential.
• Self-organisation and reflection: the best designs emerge from self-organising teams; at regular intervals the team reflects on how to become more effective and adjusts.

A worked comparison

Our running example for this course: Northside Sports Centre wants an app so members can book courts and classes.

Waterfall plan: three months of requirements and design, five months of build, one month of testing, launch in month nine. The sponsor sees a working app for the first time in month eight.

Agile plan: two-week sprints. By the end of sprint 1 the team can show a member booking a badminton court on a test phone. By sprint 3 a small group of real members uses it for courts only. Their feedback (they mostly book on the bus, so it must work one-handed) changes the design of everything that follows. Classes and payments come later, in the order members value them.

The total budget may be similar. The difference is when you learn, and how much is wasted when you learn something surprising.

When waterfall still fits

Agile is not always better. A plan-driven approach can suit work where:

• requirements are fixed by law or physics and unlikely to change,
• the work cannot be delivered in usable pieces (you cannot ship half a bridge),
• contracts require a fixed scope and price, or
• regulators require full documentation up front.

Many organisations use a hybrid: plan-driven for the overall budget, milestones and hardware, agile within delivery teams. PMI's guidance and the PMP exam now cover predictive, agile and hybrid approaches.

Common mistakes

• "Agile means no planning." Agile teams plan constantly, just in smaller pieces and closer to the work.
• "Agile means no documentation." Teams write what is useful: acceptance criteria, decisions, how to run the system.
• Renaming phases as sprints. Two weeks of requirements followed by two weeks of design is still waterfall.
• Adopting the ceremonies but not the values. Daily stand-ups without trust or customer feedback do not make a team agile.

Quick recap

• Waterfall runs phases in sequence; agile delivers small working increments and adapts.
• The manifesto's four values prefer people, working software, collaboration and responding to change, without discarding the alternatives.
• The twelve principles stress frequent delivery, welcoming change, collaboration, sustainable pace, quality and reflection.
• Waterfall or hybrid still fits fixed, non-incremental or heavily regulated work.