PMP Agile and Hybrid: Scrum, Kanban, and Servant Leadership for the Modern PM

The Agile Manifesto (2001) established 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. This does not mean processes, documentation, contracts, and plans are bad — it means you weight the left-hand items more. The 12 Agile Principles flow from these values: early and continuous delivery of valuable software, welcoming changing requirements even late in development, delivering working products frequently, daily collaboration between developers and business people, building projects around motivated individuals, face-to-face conversation, working product as the primary measure of progress, sustainable development pace, technical excellence, simplicity, self-organising teams, and regular reflection. PMI's Agile Practice Guide (APG) is a primary reference for PMP exam agile questions.

Scrum organises work into Sprints — fixed-length iterations of 1-4 weeks (usually two). Three roles: Product Owner (owns the backlog, prioritises value, single voice for the customer), Scrum Master (servant leader, removes impediments, coaches the team on Scrum — not a project manager), Development Team (self-organising, cross-functional, 3-9 members). Five events: Sprint (the container), Sprint Planning (what can we deliver and how?), Daily Scrum (15-minute sync — what did I do, what will I do, any blockers?), Sprint Review (demo to stakeholders, inspect the increment), Sprint Retrospective (inspect the team's process, create improvement plan). Three artifacts: Product Backlog (prioritised list of all features), Sprint Backlog (items selected for this Sprint plus the plan), Increment (sum of all completed backlog items). Definition of Done (DoD) is the team's agreed criteria for 'done'; Definition of Ready (DoR) is when a backlog item is detailed enough to work.

Kanban visualises work, limits Work in Progress (WIP), and optimises flow. Unlike Scrum, Kanban has no Sprints, no fixed roles, and no prescribed ceremonies — you evolve your existing process. A Kanban board maps work states (Backlog, In Progress, Review, Done) as columns. The critical practice is WIP limits: capping the number of items in each column prevents multitasking overload and exposes bottlenecks. Key metrics: Lead Time (time from customer request to delivery), Cycle Time (time an item is actively being worked), Throughput (items completed per time period), and Cumulative Flow Diagram (CFD) shows whether flow is stable or building a queue. Kanban is ideal for support, maintenance, or operations work where requests arrive continuously and Sprints would feel artificial.

In predictive projects, the PM controls — they plan, assign, track, and report. In agile projects, the PM serves — they remove blockers, shield the team from distractions, facilitate conversations, and help the team self-organise. This is servant leadership: you put the team's needs first so they can deliver value. PMP exam questions frequently present scenarios where a manager is micromanaging or directing agile teams; the correct answer almost always involves empowering the team, coaching rather than commanding, or facilitating rather than deciding. The Scrum Master role embodies servant leadership most explicitly — they do not manage the team, they coach them and protect them from organisational interference.

Hybrid is not a compromise — it is a deliberate choice to apply the right method to each part of the project. Common patterns: use predictive phases for procurement, regulatory approvals, and hardware delivery (where flexibility is low and requirements are fixed), then switch to agile Sprints for software development (where requirements evolve). Scaled frameworks like SAFe (Scaled Agile Framework), LeSS, and Disciplined Agile (DA) help large organisations coordinate multiple agile teams. PMI acquired Disciplined Agile in 2019, so DA concepts appear on the PMP exam. DA's 'Choose Your WoW' (Way of Working) philosophy says no single method fits all contexts — you choose and tailor based on context factors like team size, domain risk, delivery cadence, and regulatory environment.