I have spent years managing large projects in the UAE. Then I became a full-time PMP trainer. My students come from the USA, UK, Canada, Australia, the Gulf, Africa, India and beyond. One question comes up in every single batch. "Sir, what is Agile and when do I use it?" This guide gives you my honest answer. No fluff. No jargon. Just what Agile actually is and how it works in practice.
✍By Syed Mujeeb Rehman, PMP
📅Updated March 2026
⏱20 min read
📋Complete guide
Quick Answer
Agile is an iterative, incremental approach to project delivery. It is based on the Agile Manifesto published in 2001 and its 12 principles. Instead of planning everything upfront, teams work in short sprints or iterations. They deliver working output. They get feedback. Then they improve. The most popular frameworks are Scrum (sprints and ceremonies), Kanban (flow-based with WIP limits) and SAFe (for large enterprises). Use Agile when requirements will change. Use Waterfall when they are fixed.
Year the Agile Manifesto was published by 17 software practitioners
71%
Of organisations worldwide now use Agile approaches
50%
Of PMP exam questions are agile or hybrid scenario based
Hybrid
Most mature organisations combine Agile delivery with governance
01 — Foundation
What Is Agile Project Management?
Agile is an iterative approach to delivering projects. You do not plan everything upfront and then execute in one long run. Instead you work in short cycles. Each cycle produces something real. You show it. You get feedback. You improve. Then you repeat.
I come from a construction background. Every project I worked on in the UAE used Waterfall. Fixed scope, fixed plan, sequential phases. That is the right approach when you are building a hotel or a headquarters. You cannot change the foundation after it is poured.
But Agile exists because software is not like concrete. A software product can change direction every two weeks based on what users actually need. That flexibility is the whole point. The Agile Manifesto was written in 2001 by 17 software professionals who were frustrated with slow, bureaucratic, plan-heavy delivery. They wanted a better way. They wrote four values and twelve principles. Any framework that follows those values is an Agile framework.
The 4 Agile Manifesto 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
The things on the right still matter. The things on the left matter more.
These four values do not mean throw away documentation or ignore your plan. They mean when you have to choose, you prioritise people and working output over process and paperwork. A team spending six months writing documents before building anything is following the plan over responding to reality. That is the opposite of Agile.
💡
Agile vs Waterfall in simple terms: Waterfall assumes you can define everything upfront. Agile assumes requirements will change as you build and learn. Neither is always right. The correct choice depends on how stable your requirements are. On a hotel construction project, requirements are fixed. On a mobile app, they change every sprint. See the full Agile vs Waterfall guide for the complete comparison.
02 — The 12 Principles
The 12 Agile Principles — What They Actually Mean
The Agile Manifesto's 12 principles turn the four values into practical guidance. I teach these to every PMP student. The PMP exam tests 50% Agile content. You need to understand these principles properly. Not just memorise them. Understand them.
1
Satisfy the customer through early and continuous delivery
The top priority is delivering something valuable early and keeping it flowing. Do not wait until everything is finished before showing anything.
2
Welcome changing requirements, even late in development
Change is not a sign that planning failed. It is a sign that the team is learning. Agile processes use change as a competitive advantage for the customer.
3
Deliver working software frequently, in weeks rather than months
Short delivery cycles create feedback loops. Without them, teams can build the wrong thing for months before anyone realises it.
4
Business people and developers must work together daily
When the people who need the product and the people building it communicate continuously, misunderstandings get resolved before they become expensive rework.
5
Build projects around motivated individuals and trust them
Give the team what they need. Then let them work. Micromanagement destroys Agile teams. I have seen it happen. Trust is not optional in Agile, it is the foundation.
6
Face-to-face conversation is the most efficient communication
Rich, direct communication resolves ambiguity faster than long emails and documents. Even on remote teams, a five-minute video call beats a twenty-message thread.
7
Working software is the primary measure of progress
A percentage on a Gantt chart is not progress. A delivered, tested, working increment that the customer can use is progress. Nothing else counts.
8
Maintain a sustainable pace indefinitely
Agile is not about working faster. It is about working at a pace the team can sustain long term without burning out. Exhausted teams make mistakes and quit.
9
Continuous attention to technical excellence and good design
Cutting corners creates technical debt. Technical debt destroys a team's ability to adapt. Agility depends on keeping the underlying work clean and well structured.
10
Simplicity — maximising the work not done — is essential
The best feature is sometimes no feature. Agile teams build the minimum that delivers the required value. Everything extra is waste until proven otherwise.
11
Self-organising teams produce the best architectures and designs
The people doing the work understand it better than managers sitting away from it. Empower the team to make technical decisions. They will make better ones.
12
Regularly reflect and adjust at regular intervals
Retrospectives are not optional. They are how the team improves. A team that never reflects never gets better. I tell my students: the retrospective is the most important ceremony in Scrum.
03 — Frameworks
The Main Agile Frameworks
Agile is the philosophy. Frameworks are how you put it into practice. There are many frameworks. But four matter most for PMP candidates and working professionals in 2026. Know these four properly. The rest you can learn later.
🏉
Scrum
Most Widely Used
Fixed-length sprints (usually 2 weeks), three defined roles, five ceremonies and three artefacts. Best for product development teams delivering incremental value in short cycles.
📋
Kanban
Flow-Based
Continuous flow managed on a visual board with WIP limits. No fixed sprints. Work is pulled through stages as capacity allows. Best for support, maintenance and operations teams.
🏢
SAFe
Enterprise Scale
Scaled Agile Framework that coordinates 50 to 100 or more people across multiple Agile teams. Uses Programme Increments for planning. Complex but widely adopted in large organisations.
👑
PRINCE2 Agile
Hybrid Governance
Combines PRINCE2 stage gates and governance with Agile delivery using Scrum or Kanban. Very common in UK public sector where formal governance sits alongside iterative delivery.
⚠️
A word of caution from my training experience: Most teams I encounter are not really doing Agile. They are running Scrum ceremonies without the Agile mindset. Daily standups, sprint planning and retrospectives are just meetings if the team does not actually embrace change, trust each other and focus on working output. The ceremonies without the mindset is often worse than a well-run Waterfall project.
04 — Scrum Deep Dive
Scrum — Roles, Ceremonies and Artefacts
Scrum is the most widely used Agile framework in the world. I teach it in every PMP batch. It organises work into fixed-length sprints of usually two weeks. It has three roles, five ceremonies and three artefacts. Learn these properly. The PMP exam will test you on all of them.
The Three Scrum Roles
🎯
Product Owner
Owns the product backlog. Prioritises features based on business value and stakeholder input. Defines acceptance criteria. Represents the customer to the development team. The Product Owner decides what gets built. Not the Scrum Master. Not management. The Product Owner. This is a point many students miss in the exam.
🛡️
Scrum Master
Facilitates the Scrum process and removes obstacles blocking the team. A servant leader. Not a project manager. The Scrum Master does not assign tasks. Does not manage timelines. Does not report team performance to senior management. Their job is to protect the process and make the team as effective as possible. This distinction is very important for the PMP exam.
⚙️
Development Team
A cross-functional, self-organising group of three to nine people who do the actual work. In Scrum there is no hierarchy within the development team. They decide how to build what the Product Owner has prioritised. No sub-teams. No team leaders. Everyone owns delivery together.
The Five Scrum Ceremonies
Sprint Planning
Start of each sprint
The team selects items from the product backlog, breaks them into tasks and agrees a sprint goal. Time-boxed to two to four hours for a two-week sprint.
Daily Standup
Every day · 15 minutes
Three questions. What did I do yesterday? What will I do today? What is blocking me? A coordination event for the team. Not a status report for managers.
Sprint Review
End of each sprint
The team demonstrates the completed increment to stakeholders and collects feedback. The backlog is updated based on what was learned. Time-boxed to two hours for a two-week sprint.
Retrospective
After sprint review
The team reflects on how they worked, not what they built. They identify one or two things to improve next sprint. This is the engine of continuous improvement. Never skip it.
Backlog Refinement
During sprint · as needed
The Product Owner and team review and estimate upcoming backlog items so that the next sprint planning session runs smoothly. Not a formal Scrum ceremony but practised by almost every team.
💡
The three Scrum artefacts: The Product Backlog is the full prioritised list of everything the product might need. Owned by the Product Owner. The Sprint Backlog is the subset the team committed to for the current sprint. The Increment is the working, tested output produced at the end of each sprint. It must meet the Definition of Done to count as complete.
05 — Kanban
Kanban — Flow-Based Agile Delivery
Kanban started in Toyota's manufacturing system in the 1940s. David Anderson adapted it for knowledge work in 2007. Unlike Scrum, Kanban has no sprints. No fixed roles. No prescribed ceremonies. It is a method for visualising and improving the flow of work through a system.
I explain it to my students this way. Imagine a construction site. Work moves from design to procurement to installation to commissioning. Each stage has a capacity limit. If too much work piles up in one stage, the whole system slows down. Kanban makes that visible. And once it is visible, you can fix it.
The Six Core Kanban Practices
1
Visualise the workflow
Map every step of your process onto a board with columns. What you cannot see, you cannot manage. A visible board is the foundation of everything else in Kanban.
2
Limit Work in Progress (WIP)
Set a maximum number of items allowed in each column. WIP limits expose bottlenecks and force the team to finish work before starting new items. Starting everything and finishing nothing is a common problem. WIP limits solve it.
3
Manage flow
Monitor how work moves through the system. Measure lead time (request to delivery) and cycle time (start to finish). The goal is smooth, predictable flow. Not speed in bursts.
4
Make policies explicit
Write down and display the rules for how work moves between columns. What does done mean? When can work be pulled to the next stage? Shared, visible rules eliminate confusion and inconsistency.
5
Implement feedback loops
Run regular reviews to inspect the system and improve it. Flow reviews, replenishment meetings, retrospectives. Feedback loops are what make Kanban a learning system rather than just a board.
6
Improve collaboratively and evolve experimentally
Kanban is an evolutionary approach. It starts where you are today and improves from there. Use small experiments and data to guide every change. Do not redesign everything at once.
📊
Scrum vs Kanban — how to choose: Use Scrum when you are building a product in iterations and need a structured planning and review cadence. Use Kanban when work arrives continuously such as support tickets, maintenance tasks or marketing requests and you need to manage flow rather than plan sprints. Many teams use both together, running Kanban boards inside Scrum sprints. This is sometimes called Scrumban.
06 — Decision Framework
Agile, Waterfall or Hybrid? How to Choose
My PMP students always want a simple rule. There is no single rule. But there is a clear framework. Ask yourself honest questions about the nature of your project. Then pick the methodology that fits. Not the one that is fashionable. Not the one your organisation uses by default. The one that fits the work.
Use Agile
Requirements are not fully known and will change with user feedback
Software products, digital platforms and innovation projects where learning through delivery is faster and cheaper than specifying everything upfront.
Use Agile
Speed to market matters and early value delivery cannot wait
Agile delivers usable output in weeks. When a competitor threat or market window exists, waiting for a full Waterfall delivery cycle is simply not an option.
Use Agile
Stakeholders can engage regularly and provide ongoing feedback
Agile depends on regular collaboration with the customer or Product Owner. If they cannot attend sprint reviews or refine the backlog, Agile ceremonies become empty exercises with no value.
Use Waterfall
Requirements are fully defined, agreed and locked in a contract
When scope is fixed and changes would require renegotiating a contract, Waterfall's upfront planning and formal change control process is the right fit. This describes most construction and infrastructure work.
Use Waterfall
Phases have a physical sequence that cannot be changed
You cannot pour a foundation and design the building at the same time. On projects like EGA Head Office or Bateen Al Marina Hotel, physical dependencies make a sequential approach the only logical choice.
Use Hybrid
The project needs fixed governance but the delivery details are uncertain
Waterfall stage gates and business cases at programme level. Agile sprints delivering the actual work within each phase. This is the most common model in mature organisations in 2026 and it works well when applied properly.
📌
The hybrid reality in 2026: Most large organisations now use a combination. Waterfall governance at programme level with Agile delivery at team level. Business cases, stage gates, steering committees and budget cycles sit alongside sprint teams delivering work iteratively. This is not a compromise. It is the mature approach. PRINCE2 Agile and the PMI Agile Practice Guide both address this model directly.
07 — Metrics
Agile Metrics — Measuring What Actually Matters
Traditional project metrics like percentage complete and Gantt variance do not work well in Agile. Agile teams use different measures. Measures that reflect real flow, predictability and value delivery. Not just activity.
Metric
What It Measures
How to Use It
Velocity
Story points completed per sprint
Use only for internal forecasting. Never use it to compare teams or pressure individuals to go faster.
Cycle Time
Time from work starting to work finishing
Lower cycle time means faster delivery. Track the trend over time. One sprint does not tell you anything useful.
Lead Time
Time from customer request to delivery
A customer-facing measure. High lead time usually reveals a process bottleneck or too much work in progress.
Throughput
Items completed per unit of time
More stable than velocity for forecasting. Count finished items, not story points.
Sprint Burndown
Work remaining in the current sprint
A visual signal of whether the sprint goal is achievable. Not a tool to put pressure on the team.
Release Burnup
Progress toward a release goal
Shows scope growth versus work completed. Makes scope creep visible before it becomes a crisis.
Escaped Defects
Bugs found in production after release
A quality indicator. Rising escaped defects signal growing technical debt or insufficient testing in sprints.
Team Happiness
Team morale and engagement
Tracked in retrospectives. Consistently unhappy teams consistently deliver poor output. This is not soft. It is important.
⚠️
The velocity trap: Velocity is the most abused metric in Agile. Teams pressured to increase velocity every sprint will inflate their story point estimates rather than actually improve. I have seen this in organisations across different countries. Velocity is for internal forecasting only. Never use it to compare teams. Never use it to evaluate individual performance. If you do, you will destroy its usefulness completely.
08 — Scaling Agile
Scaling Agile — SAFe, LeSS and Nexus
Scrum and Kanban work well for one team of five to nine people. When an organisation has fifty, two hundred or a thousand people working on the same product or programme, you need a way to coordinate all of those teams without bringing back the Waterfall bureaucracy that Agile was designed to replace.
SAFe — Scaled Agile Framework
The most widely adopted enterprise scaling framework. SAFe introduces the Agile Release Train (ART). This is a team of Agile teams, usually 50 to 125 people, aligned to a common programme goal. They synchronise through PI Planning events every 8 to 12 weeks. SAFe provides four configurations depending on organisational size and complexity. Critics say it recreates the top-down planning that Agile was designed to avoid. Supporters say it provides the governance that large regulated organisations genuinely need. Both views have merit.
LeSS — Large-Scale Scrum
LeSS takes the opposite approach to SAFe. Minimal additional rules. Multiple teams work from a single product backlog. They share one Product Owner. They synchronise through a single Sprint. LeSS argues that SAFe's complexity defeats the purpose of Agile. LeSS works best in organisations willing to fundamentally restructure around product teams rather than adding a scaling layer on top of existing structure without changing anything underneath.
Nexus
Nexus is Scrum.org's scaling approach. It is an extension of Scrum for three to nine teams working on a single product. It adds a Nexus Integration Team responsible for keeping everything integrated, plus a combined Nexus Sprint Review. Simpler than SAFe. More prescriptive than LeSS. A good starting point for organisations already experienced with Scrum who need to scale without adopting a full enterprise framework.
💡
Which scaling framework should you choose? If you are scaling beyond three teams for the first time, start with Nexus or LeSS. They are simpler and closer to the original Agile principles. SAFe makes sense when you have strong regulatory or portfolio governance requirements that genuinely need more structure. Do not adopt SAFe just to avoid doing the harder work of restructuring around products and outcomes.
09 — Certifications
Agile Certifications — Which One Should You Get?
The Agile certification market is large and uneven. Some certifications require serious study and a rigorous exam. Others require only two days in a classroom. As a PMP trainer with a 100% pass rate, I have seen what works. Here is my honest view on the main options in 2026.
Certification
Issuer
Difficulty
Best For
PMI-ACP
PMI
Rigorous — exam plus real project experience required
PMs wanting a globally recognised cross-framework Agile credential
PSM I
Scrum.org
Challenging open-book exam with an 85% pass mark
Scrum practitioners wanting a credible, exam-based Scrum certification
CSM
Scrum Alliance
Easy — two-day course plus a basic quiz
Entry-level introduction to Scrum. Very widely held but not very rigorous.
PSPO I
Scrum.org
Rigorous exam with an 85% pass mark
Product Owners wanting a credible, exam-proven credential
SAFe Agilist
Scaled Agile
Moderate — two-day course plus multiple choice exam
Enterprise PMs and leaders implementing SAFe in large organisations
PRINCE2 Agile
Axelos / PeopleCert
Rigorous two-level exam
UK and European PMs combining PRINCE2 governance with Agile delivery
Agile is a set of values and principles from the 2001 Agile Manifesto. It describes an approach to delivery. Not a specific method. Scrum is a framework that puts Agile principles into practice. It does this through specific roles (Product Owner, Scrum Master, Development Team), ceremonies (sprint planning, daily standup, retrospective) and artefacts (product backlog, sprint backlog, increment). Agile is the philosophy. Scrum is one way of practising it. Kanban, XP and SAFe are also Agile frameworks. My students often confuse these two. They are not the same thing.
Yes. Agile principles apply to any project where requirements evolve and stakeholders can engage regularly. Marketing teams, HR, event planning and even parts of construction projects use Agile techniques successfully. The key question is not whether it is a software project. The key question is: can you deliver in increments and incorporate feedback at each stage? Physical construction phases cannot be sprinted. But design, planning and coordination work can absolutely benefit from Agile thinking.
For Scrum specifically, PSM I from Scrum.org is the most rigorous and respected entry-level option. CSM from Scrum Alliance is more widely held but easier to get. For broader Agile knowledge, PMI-ACP is the strongest cross-framework credential and is recognised by both Agile and traditional employers worldwide. For those in the UK and Europe working in a PRINCE2 environment, PRINCE2 Agile is the most relevant choice. As a PMP trainer I always recommend PMI-ACP to serious professionals who want a globally recognised credential.
Scrum sprints are typically one to four weeks. Two weeks is the most common in practice. The sprint length is fixed for a team and only changed rarely and deliberately. Shorter sprints create more feedback loops but add ceremony overhead. Longer sprints reduce overhead but delay feedback. Most teams find two weeks balances both well. Once a sprint length is established, do not change it just because a sprint is going badly. That defeats the purpose of a fixed cadence.
The Definition of Done is a shared agreement about what "complete" means for any piece of work. It typically includes things like code reviewed, tests passing, acceptance criteria met, documentation updated and deployed to a test environment. It creates a consistent quality standard and prevents "done but not really done" situations that cause technical debt to accumulate over time. The team sets the Definition of Done. Not management. And it applies to every single item in every sprint.
The Scrum Master is a servant leader. They facilitate the Scrum process and remove obstacles blocking the team. They are not a project manager. They do not assign tasks. They do not own the backlog. They do not report team performance to senior management. Their job is to protect the team's process, coach the organisation on Agile principles and remove whatever is slowing the team down. This is one of the most tested concepts in the PMP exam. Many students get it wrong because they confuse the Scrum Master with a traditional project manager.
Velocity is the number of story points a Scrum team completes per sprint, averaged over three to five recent sprints. It is used for internal forecasting only. If you divide the remaining backlog points by the average velocity you get an estimate of how many sprints remain. Never use velocity to compare different teams. Never use it to evaluate individual performance. Never pressure a team to increase velocity every sprint. Teams who are pressured will inflate estimates rather than improve. The metric then becomes useless.
This is a genuine debate in the Agile community. SAFe adds significant structure through PI Planning events, Agile Release Trains and portfolio governance layers. Some argue this recreates the Waterfall bureaucracy Agile was designed to replace. Others say it provides the governance that large enterprises genuinely need while still enabling Agile delivery at team level. My view is that SAFe works when leadership is truly committed to Agile values. Without that commitment, it becomes Agile theatre. The ceremonies run. The mindset is absent. The results are poor.
Yes. About 50% of PMP exam questions are Agile or hybrid scenario-based. You must understand Scrum roles, ceremonies and artefacts, Kanban flow management, servant leadership and hybrid project approaches. I have trained hundreds of students from the USA, UK, Canada, Australia and across the Gulf. The students who study only PMBOK and skip the Agile Practice Guide consistently fail. The PMP is no longer a Waterfall exam. It tests applied Agile thinking as heavily as traditional PM knowledge.
A user story is a short description of a feature written from the perspective of the end user. The standard format is: "As a [type of user], I want [some goal] so that [some reason]." User stories are kept short on purpose. The real understanding comes from the conversation between the Product Owner and the team. Not from the written text. Each user story includes acceptance criteria that define when it is considered complete and meeting the Definition of Done.