Agile methodology is a way of managing projects, especially software projects, that delivers work in short iterations, gathers feedback continuously and adapts the plan as the team learns. It is guided by the four values and twelve principles of the Agile Manifesto and is put into practice through frameworks such as Scrum, Kanban and, at larger scale, SAFe.
This guide explains what agile means in practice: the values and principles, Scrum vs Kanban vs SAFe, how a sprint runs, which metrics matter, agile in fixed-price contracts and with AI-assisted development. It closes with how WWG adopted agile across the company and a short adoption checklist.
TL;DR / Key Takeaways
- Agile is a mindset before it is a process: start with a "good enough" understanding, deliver something that works, then inspect and adapt.
- The Agile Manifesto (2001) sets four values and twelve principles; Scrum, Kanban and SAFe are frameworks that apply them.
- Scrum works in fixed sprints of one month or less, Kanban in a continuous flow with limited work in progress, SAFe coordinates many teams on one Agile Release Train.
- Useful metrics describe flow and outcomes (cycle time, throughput, working software), not how busy people are.
- Agile works with fixed-price contracts when time and budget are fixed and scope is prioritised, and it still applies when AI writes part of the code.
What is agile methodology?
Agile is a project management methodology guided by a set of principles and a general mindset that favours the ability to change strategy quickly and to improve progressively. Instead of trying to predict every element of a project up front, the team starts with a "good enough" understanding, delivers early and adjusts as it proceeds.
The core idea behind agile project management is "inspect and adapt": late changes are welcome at any stage of the project, and changes that bring value become particularly valuable. The team regularly looks at what it has built, what users and stakeholders say, and how it is working, then adjusts both the product and the process.
Agile was created and first used by software developers, but it has spread to other fields. Today it is used by managers in banking, creative teams in agencies, medical staff, start-up founders, marketing professionals and human resources managers. At WWG we apply it in every custom software development project.
What are the four values and twelve principles of the Agile Manifesto?
The Agile Manifesto, written in 2001 by seventeen software practitioners, states four values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The items on the right still matter; those on the left matter more.
The twelve principles turn those values into working rules. They can be grouped into four themes, each one a test you can apply to your own team:
- Deliver value early and often: satisfy the customer through early and continuous delivery, deliver working software frequently (from a couple of weeks to a couple of months, preferring the shorter timescale), and treat working software as the primary measure of progress.
- Embrace change: welcome changing requirements, even late in development, because change can become a competitive advantage for the customer.
- Work together: business people and developers work together daily, motivated individuals are trusted to get the job done, and face-to-face conversation is the best way to share information.
- Keep it sustainable and simple: keep a constant pace, pay continuous attention to technical excellence, maximise the work not done, trust self-organising teams and reflect regularly on how to improve.
How is agile different from waterfall?
Waterfall plans the whole project first and then moves through fixed phases, requirements, design, build, test and release, in sequence. Agile delivers in short cycles that each include all of those activities. Waterfall suits stable, well-understood requirements; agile suits projects where the requirements or the market are likely to change.
Many companies prefer agile because the alternative often needs more preparation and more resources: every requirement must be understood and documented before work starts. The time spent on that initial set-up often delays the start and pushes the first release further away, while agile puts working software in front of users much earlier.
What is the difference between Scrum, Kanban and SAFe?
Scrum, Kanban and SAFe are frameworks that apply agile principles in different ways. Scrum organises one team's work in fixed sprints with defined roles and events. Kanban manages a continuous flow of work by visualising it and limiting work in progress. SAFe scales agile to many teams that plan and deliver together on one Agile Release Train.
| Scrum | Kanban | SAFe | |
|---|---|---|---|
| Unit of work | Sprint of one month or less | Continuous flow of work items | Planning Interval of 8–12 weeks, made of iterations |
| Roles | Product Owner, Scrum Master, Developers | No prescribed roles | Adds Release Train Engineer, Product Management, Business Owners and architects |
| Planning | Sprint Planning at the start of each sprint | Work is pulled when capacity is available | PI Planning for the whole train, then iteration planning per team |
| Main control | Sprint Goal and Definition of Done | Limits on work in progress | PI objectives and the ART planning board |
| Best fit | One product team with a clear owner | Support, operations and teams with unpredictable demand | Several teams with shared dependencies |
The frameworks can be combined: a Scrum team can use a Kanban board, and SAFe teams run Scrum or Kanban inside the train. If several teams need to plan together, our guide to PI Planning explains how SAFe does it.
How does a sprint work in practice?
A sprint is a fixed period of one month or less in which a Scrum team turns backlog items into a usable increment. It starts with Sprint Planning, includes a fifteen-minute Daily Scrum, and ends with a Sprint Review of what was built and a Sprint Retrospective on how the team worked. The next sprint starts immediately.
According to the Scrum Guide, the Scrum Team consists of one Scrum Master, one Product Owner and Developers. The Product Owner orders the Product Backlog and maximises the value of the product, the Developers create the increment, and the Scrum Master is accountable for establishing Scrum and helping the team and the organisation understand and use it.
Sprint Planning is timeboxed to a maximum of eight hours for a one-month sprint, and is usually shorter for shorter sprints. Whatever the length, keep it constant, because a stable rhythm makes planning and forecasting reliable.
Which metrics show whether an agile team is working well?
The useful agile metrics describe flow and outcomes. Cycle time shows how long work takes from start to finish, throughput shows how many items are finished per period, work in progress and work item age show where work gets stuck, and working software in users' hands shows whether any of it creates value.
The Kanban Guide defines the four flow measures precisely. Work in progress is the number of items started but not finished. Throughput is the number of items finished per unit of time. Work item age is the time since an item started, and cycle time is the time between when an item started and when it finished.
Velocity, the amount of work, often in story points, that a Scrum team completes per sprint, is useful for the team's own forecasting. It should not be compared between teams or used as a productivity target, because story points are relative to each team. Pair any delivery metric with outcome measures such as user adoption, defects found in production or business objectives met.
Can agile work in a fixed-price contract?
Yes, if the contract fixes time and budget and treats scope as the variable. The client and the supplier agree on a prioritised backlog, the definition of done and a sprint cadence. Each sprint review becomes an acceptance point, and lower-priority items are swapped or dropped when new needs appear, without renegotiating the whole contract.
What makes this work is transparency. The client sees working software at the end of every sprint, and the most valuable features are always built first, which protects the client if the budget runs out.
What does not work is a fixed price for a fully detailed scope with the word "agile" added, because every change then becomes a change request. A short discovery phase and a clear rule for exchanging scope are the usual safeguards.
How does agile change with AI-assisted development?
Agile still applies when AI assistants write part of the code, but the bottleneck moves. Writing code becomes faster, while reviewing, testing and integrating it takes a larger share of each sprint. Teams need a stricter definition of done, with code review, automated tests and security checks applied to every change regardless of who or what wrote it.
Faster coding makes short feedback loops more valuable, not less: a team that produces more code can also produce more of the wrong thing. Backlog items should state acceptance criteria clearly, because they become the instructions an AI assistant works from.
Estimation changes too. Velocity measured before AI tools arrived is no longer a reliable baseline, so forecasts should be rebuilt from recent cycle time and throughput.
How did WWG adopt agile across the whole company?
WWG has followed agile and lean principles since its early days and, in 2020, extended them beyond development to the whole company. On Thursday 6 August 2020 it held an internal Agile Fundamentals training for the marketing, sales, development and accounting teams, led by two certified trainers, Andriu Romanukha and Olesia Prots.
"I am a big fan of the Agile manifesto," says Mohamed Deramchi, CEO and founder of WWG. "I believe in the principles of lean thinking and I often talk to my collaborators about the concept of incremental planning which, in other words, means improving, always improving. If it doesn't happen, it means something is not going right."
"I relied entirely on Agile methodology," he continues. "I asked myself how to really improve and I analysed everything that happened in my company. I don't think anything like this has ever been done to optimise a company with 20 years of history. The result was a radical but necessary change."
The one-day programme covered agile principles, waterfall vs agile, Kanban, the Penny game, Scrum roles, Scrum events, story point estimation, Scrum artefacts and agile leadership. The benefits we set out to gain were earlier detection of problems, closer cooperation within teams, faster achievement of personal and team goals, and more flexibility. The next step was planning at company level, which we did with our first PI Planning in December 2020. Objectives at that level work best when they are also clear about what OKRs are not.
What should an agile adoption checklist include?
An agile adoption checklist should cover people, cadence, work and measurement. Name a product owner with real decision power, choose one framework and one cadence, make all work visible on a single board, agree a definition of done, and pick a few flow and outcome metrics before the first sprint starts.
- People: a product owner with authority over priorities, a facilitator (Scrum Master or equivalent) and a stable team.
- Cadence: sprint length or review rhythm chosen and kept constant; planning, review and retrospective in the calendar.
- Work: one ordered backlog, items with acceptance criteria, a limit on work in progress.
- Quality: a definition of done that includes review, automated tests and deployment.
- Measurement: cycle time and throughput tracked from day one, plus one outcome metric the business cares about.
Introducing agile practices in an established organisation is usually harder than learning them. WWG's software development process implementation service helps teams set up a cadence and tools that fit their size.
To discuss how agile could work in your organisation or your next project, write to us at business@wwg.it.
Sources
- Agile Manifesto, Manifesto for Agile Software Development (2001) — https://agilemanifesto.org/
- Agile Manifesto, Principles behind the Agile Manifesto — https://agilemanifesto.org/principles.html
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020) — https://scrumguides.org/scrum-guide.html
- John Coleman and Daniel Vacanti, The Kanban Guide (May 2025) — https://kanbanguides.org/the-kanban-guide/2025.5/
- Scaled Agile, Inc., PI Planning — https://framework.scaledagile.com/pi-planning/
- Octal Software, Scrum vs waterfall methodology — https://www.octalsoftware.com.sg/blog/scrum-waterfall-methodology-which-is-right-for-your-project-development/
FAQ
Frequently Asked Questions
No. Agile was created by software developers, but its principles now guide teams in banking, marketing agencies, healthcare, human resources and start-ups. Any team that works on complex problems with changing requirements can benefit from short cycles, visible work and regular feedback, even if it never writes a line of code.
No. Agile is the set of values and principles described in the Agile Manifesto, while Scrum is one specific framework for applying them, with defined roles, events and artefacts. A team can be agile using Kanban or another method, and a team can follow Scrum's rituals mechanically without actually working in an agile way.
Inspect and adapt means regularly examining both the product and the way the team works, then changing whatever is not delivering value. In Scrum it happens in the Sprint Review, for the product, and in the Sprint Retrospective, for the process. Without real adaptation, the meetings become rituals that change nothing.
Story points are a relative measure of the effort, complexity and uncertainty of a backlog item, compared with other items the team has already completed. Teams use them to plan how much work fits into a sprint and to forecast delivery. They are specific to each team and should not be converted into hours or compared across teams.
