Product thinking
5 min read

Agile summarised

Louise Hill
Share this post
Three people in a meeting looking at a laptop and having a discussion.


Confidently converse with product teams by understanding the philosophy that underpins much of their working life.

In early 2001, in the mountains of Utah, 17 developers met to discuss the future of software development. They were unhappy about the state of affairs. They agreed, the biggest issue was that companies were so focused on extensively planning and documenting their software development cycles that they forgot what was ultimately important—pleasing their customers. The Agile Manifesto emerged from this extended weekend, with 4 values and 12 principles they could all agree on and this manifesto changed the face of software development forever.

The values

Fundamentally they priorititsed:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiations
  • Responding to change over following a plan

The writers stated that although there was some advantage in the items on the right, they favoured the items on the left more.

The principles

Key ways of working:

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

The manifesto has been interpreted in many ways. Many organisations have picked out certain elements of Agile and applied them. However, fundamentally for an Agile purest, the key is to apply all the cultural values and principles—in doing this they believe great results will follow.

How can Agile help your team or company?

The behaviours outlined in the manifesto have since contributed to the creation of groundbreaking software. Several Agile methodologies have emerged which we continue to see used regularly in product teams.

What does Agile look like in practice?

There are many Agile-influenced methodologies out there, including Lean, which you can read more about here.

Below are two others which are incredibly popular.

Diagram showing how a scrum team works. the product owner controls the product backlog, then plans the sprint with the dev team. Items to build move into the sprint backlog, then the dev team build them for a sprint (1–4 weeks). A scrum master facilitates the sprint and the daily scrum (24 hours). Once the sprint is over there is a review, retrospective and the process is repeated.
How scrum processes and teammates fit together


Scrum is a framework for effective team collaboration on complex products. It involves meetings, roles, and tools that give teams better structure to manage their workload. Teams have a Scrum Master, Product Owner and a Scrum Team (3-9 business representatives, designers and developers). A Product Owner creates and maintains a product backlog (all the features that need to be implemented from the business perspective), the Scrum Master holds estimation meetings with the team and then chosen features are moved into short ‘sprints’ (regular time periods defined by the team). The team defines when these features are complete (definition-of-done) and delivers and tests these features within the team's sprints. Every morning the scrum master facilitates a stand-up meeting of 15mins where each team member discusses what they did yesterday, what they will do today and any ‘blockers’ (problems) they may have. After the sprint has ended, the scrum master facilitates a 'retrospective', where the whole team assess how to improve within the next sprint. Then they plan the next sprint and begin the process again.

An illustration of a Kanban board showing 3 columns with sticky notes in. Their headings are: "To do, doing, done".
An example Kanban board—a visual way of showing how a project is going


The Japanese word “kanban”, means “visual board” or a “sign’. The process was first developed and applied at Toyota. Kanban boards have simple titles like ‘requested’, ‘in progress’ and ‘done’ and work is prioritised and moved into relevant columns as projects progress. Designers often work within Kanban, as it is a very visual way to communicate how a project is going. Typically Kanban teams run standups and retrospectives, like a Scrum team.

So how can I help you with working in an Agile way?

We have experience working in Scrum, Kanban and Lean product and design teams. We can help advise on how to work best with developers as a business, or how best to integrate design into Agile teams.