The agile mindset: values and principles

PMP-130 and PMP-131 planned and controlled Project Compass mostly from the predictive side: a scope baseline for the fit-out, a critical path, earned value and formal change control. One part of the project never fitted that mold. The mobile app that lets patrons search the collection, place holds, book rooms and sign up for events was always going to be built iteratively, because nobody could say in advance exactly which features patrons would use or how they would want them to work. This course follows that app team, and the people around it, through agile and hybrid delivery.

Agile and hybrid approaches matter well beyond this one app. At the time of writing (October 2026), PMI describes the PMP exam that took effect on 9 July 2026 as drawing roughly 40 % of its questions from predictive approaches and about 60 % from adaptive and hybrid ones, spread across all three domains rather than kept in a separate section. A question about conflict, stakeholders or risk may well be set on an agile team. Knowing how agile teams think, not only which meetings they hold, is what lets you pick the best answer.

Where this course sits

The PMBOK Guide, eighth edition, released in late 2025, treats delivery approach as something to tailor rather than a choice between camps, and PMI's Agile Practice Guide appeared in a second edition in 2025 and 2026. That edition moves away from treating "hybrid" as a single label and talks instead about a range of approaches that mix predictive and adaptive practices to fit the situation. It also adds material on flow metrics, product management and the use of generative AI. This course follows the same idea: approaches are tools, and the skill is in choosing and combining them.

Why agile approaches emerged

Through the 1990s, many software projects were planned like construction: gather all requirements, design everything, build, then test. The results were often disappointing. Requirements written a year earlier no longer matched what users needed, problems surfaced only in late testing, and teams delivered nothing usable until the very end. Practitioners experimented with lighter methods, among them Scrum, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM) and Feature-Driven Development. In 2001, seventeen of them met and wrote the Manifesto for Agile Software Development, a short statement of what they had found worked.

The core insight is about uncertainty. When the product is well understood and change is expensive, careful upfront planning pays off: you would not pour a foundation and then decide where the walls go. When the product is new, the technology is changing or users cannot describe what they want until they see it, upfront plans become guesses. In those conditions it is cheaper to build a small piece, show it to real users, learn and adjust. Agile methods are organized around making that learning loop short and cheap.

The four values

The Manifesto states four values, each as a preference of one thing over another. The wording matters for the exam: the items on the right still have value, but the items on the left are valued more. Agile teams still write documents, follow plans and sign contracts; they just do not let those things get in the way of the items on the left. In paraphrase:

A common exam trap is an answer that treats a value as a ban. "The team should not write documentation because agile values working software" is wrong. Documentation that someone needs, such as accessibility test results the library must keep, or a hand-over guide for the library's IT staff, is still produced. What changes is that the team writes what is needed, when it is needed, and keeps it light.

The twelve principles in practice

Behind the values sit twelve principles. You do not need to recite them, but you should recognize them in a scenario. They group naturally into a few themes.

Two principles deserve extra attention. "Simplicity, the art of maximizing the amount of work not done" is not laziness; it means not building features, reports or abstractions that nobody needs, which links directly to the lean idea of waste in lesson 6. "Working software is the primary measure of progress" explains why agile status reporting emphasizes demonstrations and burn-up charts rather than estimates of percent complete. Outside software, read "working software" as "a usable increment of the product", such as a finished room, a tested process or a trained group of staff.

Mindset before mechanics

Teams often adopt the visible parts of agile, such as daily stand-ups, sprints and sticky notes, without the thinking behind them. The result is sometimes called "doing agile" rather than "being agile": two-week mini-waterfalls, stand-ups that are status reports to a manager, and backlogs that are really fixed requirements lists. PMI and most agile writers stress that the mindset comes first. The practices exist to support transparency, short feedback loops, collaboration and continuous improvement; if a practice stops doing that, the team should change it.

The empirical idea underneath Scrum, and most agile methods, is often summarized as three pillars: transparency (the work and the problems are visible to everyone who needs to see them), inspection (the team and stakeholders look at the product and the process frequently) and adaptation (when something is off track, they change course quickly). If you are unsure which answer is best in an agile scenario, ask which option makes the situation more transparent, inspects it sooner or adapts faster.

Why delivering early adds value

Delivering in increments is not only about learning. A feature that is live earlier starts producing value earlier, and that value accumulates. The library estimated how many patron visits per month each feature group of the app would serve once it was released. The code compares releasing everything at once in month 9 with releasing one group every two months from month 3.

# Cumulative value delivered by two delivery patterns for the Compass app.
# Each feature group is worth an estimated number of patron visits per month once live.
features = [("Search and availability", 900), ("Holds and renewals", 700),
            ("Account and fines", 400), ("Room booking", 300), ("Event sign-up", 200)]
months = 10
# Big bang: everything goes live in month 9.
big_bang = [sum(v for _, v in features) if m >= 9 else 0 for m in range(1, months + 1)]
# Incremental: one feature group goes live every two months from month 3.
live_from = [3, 5, 7, 9, 9]
incremental = [sum(v for (_, v), start in zip(features, live_from) if m >= start)
               for m in range(1, months + 1)]
print("Month  Big bang  Incremental")
for m in range(months):
    print(f"{m + 1:>5}  {big_bang[m]:>8}  {incremental[m]:>11}")
print("Visits served over 10 months:", sum(big_bang), "vs", sum(incremental))

Month  Big bang  Incremental
    1         0            0
    2         0            0
    3         0          900
    4         0          900
    5         0         1600
    6         0         1600
    7         0         2000
    8         0         2000
    9      2500         2500
   10      2500         2500
Visits served over 10 months: 5000 vs 14000

Over ten months, incremental delivery serves almost three times as many visits, even though both approaches finish the same features in the same month. The numbers are invented, but the shape is general: the most valuable features delivered first produce the biggest gain. Incremental delivery also reduces risk, because if funding were cut in month 7, the library would still have a working app with search, holds and accounts, instead of an unfinished one.

The inverted triangle

Predictive planning usually fixes scope and estimates the time and cost needed to deliver it. Agile planning often turns this around: the team and the timebox are fixed (a set number of people for a set number of sprints), so time and cost are known, and scope is the variable. The product owner chooses the most valuable scope that fits. For Project Compass, the soft opening date is fixed by the lease and the app budget is capped by the contract ceiling, so the app is a natural fit for fixed time and cost with flexible scope. Quality is not one of the variables: the team does not cut testing or accessibility to fit more features in.

Agile beyond software

Although agile grew up in software, the ideas are now used for marketing campaigns, policy work, research, hardware and parts of construction. The test is not the industry but the conditions: can the work be split into pieces that are useful or informative on their own, can users or stakeholders give feedback quickly, and is the cost of changing direction low enough? On Project Compass, the library's communications team used two-week cycles to plan the opening campaign, testing messages with patron focus groups, while the fit-out stayed predictive because walls and wiring are expensive to change. Lesson 2 turns these conditions into a structured way of choosing an approach.