PMI-ACP Agile Mindset: Manifesto, Cynefin, Stacey Matrix and Suitability

Embracing an agile mindset means making decisions from the Agile Manifesto's values and principles, and choosing how to work by first understanding how much uncertainty the work holds. It is a way of thinking, not a framework: the same mindset can lead to Scrum on one project, Kanban on another and a predictive plan on a third.

Task 2 of the Mindset domain in PMI's PMI-ACP Examination Content Outline lists five enablers, and this lesson follows them in order:

1. Use agile values and principles to make everyday decisions.
2. Apply the appropriate complexity method (complex adaptive systems, the Stacey matrix, Cynefin) to classify a scenario.
3. Identify the application, importance or risks of each complexity model in a given scenario.
4. Interpret the output of agile suitability tools, such as the suitability filter in PMI's Agile Practice Guide.
5. Integrate agile models based on needs of the use case, team, project and organization.

The thread running through all five is fit the approach to the work. An agile mindset does not apply one framework everywhere; it reads the situation, picks what fits and keeps checking.

The Agile Manifesto's four values each compare two things and say the first is valued more. The manifesto ends the list with the sentence that matters most: while there is value in the items on the right, the items on the left are valued more.

Two misreadings are common and both are wrong:

• Over-reading a value as a ban: "agile teams don't plan", "estimates are pointless", "process is bureaucracy". The right-hand items keep their value, and sometimes a constraint (regulation, a mandated tool, a commercial agreement) requires them.
• Under-applying a value: treating every template as compulsory, deferring a valuable change because it was not in the approved plan, or letting a tool's workflow dictate how people collaborate.

The balanced answer keeps the right-hand item at the level that is useful and lets the left-hand item win when the two conflict.

The twelve principles behind the Agile Manifesto turn the values into decisions. In paraphrase, they say:

1. The highest priority is satisfying the customer through early and continuous delivery of valuable product.
2. Welcome changing requirements, even late, to give the customer a competitive advantage.
3. Deliver working product frequently, preferring shorter timescales.
4. Business people and developers work together daily throughout the project.
5. Build projects around motivated individuals; give them the environment and support they need, and trust them.
6. Face-to-face (live) conversation is the most efficient and effective way to convey information to and within a team.
7. Working product is the primary measure of progress.
8. Agile processes promote sustainable development: sponsors, developers and users should be able to keep a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, the art of maximising the amount of work not done, is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour.

The principles are most useful when they diagnose a problem. Typical diagnoses:

• Business and developers rarely talk directly (questions relayed through intermediaries, answers taking days, features missing the point). Principles 4 and 6 call for frequent, direct contact between the people who need the product and the people building it. Any fix that adds distance, such as more written hand-offs or another layer between them, treats the symptom.
• Output is being bought with long hours. Throughput gained by overwork is borrowed against quality and morale, and it eventually shows up as defects and burnout. Principle 8 points to making that cost visible and renegotiating scope or date with the sponsor, rather than treating extra hours as normal capacity.
• Building for needs that may never come. A plug-in framework so that any future payment provider can be added, when only one provider is planned, is speculative work. Principle 10 says build what is needed now, keep the design clean enough to change, and generalise when real demand appears.
• Someone outside the team wants to decide who does what. Principles 5 and 11 say set clear outcomes and boundaries, support the team and trust it to organise its own work. Any arrangement that moves the allocation decision out of the team, however it is packaged, replaces self-organization with central control.

Working product is the measure of progress

Progress in agile is measured by working, accepted product: increments that meet the definition of done and the acceptance criteria. Tasks closed, hours burned and lines of code all measure activity, not outcome.

This has three practical consequences:

• Report what is usable, not what is busy. The sponsor needs to know which features work and are accepted. An activity measure can look healthy while nothing usable exists, so reporting it gives a falsely optimistic picture.
• No partial credit. A story counts only when it meets the definition of done and its acceptance criteria. Giving credit for stages reached along the way creates false precision.
• Finishing work belongs inside the iteration. Anything the increment needs before it is truly done, testing above all, is still unfinished work when it is pushed to a later phase; it is just unmeasured. Velocity then overstates progress and forecasts built on it are unreliable. Build that work into the definition of done so each increment is genuinely complete.

Cynefin (pronounced roughly "ku-NEV-in"), created by Dave Snowden, is a sense-making framework that classifies a situation by how clearly cause and effect can be known, then names the response that fits. Its domain names have changed over time: Clear was earlier called Simple and then Obvious, and Confusion was earlier called Disorder.

Telling near-twin domains apart

• Complicated vs complex: ask whether analysis could find the answer in advance. A memory leak in a legacy service or the load a bridge can carry can be worked out by an expert, so the situation is complicated, even if your own team lacks that expert. How staff will respond to a new reward scheme cannot be analysed in advance, so it is complex. When experts disagree, check why: competing analyses of a knowable answer are complicated; disagreement because nobody can know yet is a complex-domain signal.
• Clear vs complicated: applying a documented fix is a clear-domain move, and it only fits when the cause is plainly recognisable. If the symptoms could come from more than one cause, the situation needs analysis first.
• Complex vs chaotic: both are unpredictable, but chaos has harm happening now and no time to spare. Anything that delays stabilising, whether experiments, analysis or meetings, comes too late; act first, then make sense of it.

Each Cynefin response is a legitimate practice somewhere, which is why using the wrong one is tempting. The framework is most valuable for showing which practice fits now.

• Complex: probe, sense, respond. Run several small safe-to-fail probes in parallel (for example, a time-boxed prototype trial), each cheap to reverse. Sense what happens, then scale up the probes producing good signals and shut down the rest; Snowden calls this amplifying and dampening. Insisting on a detailed forecast before any probe runs treats complex work as if analysis could predict it.
• Chaotic: act, sense, respond. Restore stability first (roll back, fail over, disable the change), then sense where stability exists and respond to move the situation into a domain where analysis can find the cause. Root-cause analysis still happens, but after stabilisation.
• Complicated: sense, analyze, respond. Bring in people with the right expertise, analyse, then act.
• Clear: sense, categorize, respond. Recognise the case and apply the established practice.

Risks Cynefin highlights

• Complacency and the cliff. The boundary between clear and chaotic is drawn as a cliff. Long success breeds complacency: established practices harden, people stop questioning them and early warning signs get explained away. When the context shifts, the system can fall straight into chaos rather than easing into the complicated domain. The defence is to keep reviewing best practice and listen to weak signals.
• Analysis when action is needed. In chaos, waiting for a workshop or a full diagnosis prolongs the harm.
• Applying one domain's habits everywhere. Experts tend to see everything as complicated, process people as clear, innovators as complex. In confusion, settling the argument by picking a single domain for the whole situation, by whatever method, repeats the error; decompose the situation and classify each part.
• Healthy movement is normal. Work moving from complex to complicated as the team learns is expected, not a risk.

The Stacey matrix, as used in agile practice, positions work on two axes: agreement on requirements (do stakeholders agree on what is needed?) and certainty of technology or approach (does the team know how to build it?). The closer the work is to full agreement and full certainty, the simpler it is.

Reading the matrix correctly

• Read one axis at a time. Stakeholders who disagree on what is needed have an agreement problem, which calls for facilitation and agreement-building whatever the technology. A team that knows exactly what to build but has never used the platform faces uncertainty about how, which calls for short cycles and spikes. Agreement on one axis does not cancel uncertainty on the other.
• Simple work can be planned. A routine repeat of something the organisation has done many times, such as a standard office move with a proven checklist, sits in the simple zone. Adding iteration and exploration there only adds overhead, because there is little left to learn.
• Agile handles uncertainty, not anarchy. Far from both agreement and certainty, feedback cannot converge: each stakeholder judges every increment against a different goal. First reduce the uncertainty (align the goals, de-risk the technology) to bring the work into the complex zone, then iterate. Neither more planning nor more iterating creates agreement that does not exist.

Ralph Stacey himself later moved away from the matrix; the exam uses the adaptation found in agile practice described here.

A complex adaptive system (CAS) is a system of many agents (people, teams) who interact, adapt to one another and produce patterns at the level of the whole that nobody designed. Agile teams and organisations behave this way, which is why command-and-control blueprints work poorly for them.

The defining point is that the whole cannot be predicted by analysing each part on its own: new order appears from the interactions between agents, and the system keeps adapting as conditions change.

Leading a complex adaptive system

• Set a few simple rules and boundaries (for example, a shared definition of done), then observe and adapt the rules from what emerges. A detailed, centrally designed process assumes predictable behaviour; people work around it, and enforcing compliance rewards following steps over achieving results.
• Practices are context-bound. What emerged in one team is a starting point for others to adapt, not a template to install unchanged.
• Self-organization still needs boundaries. Without shared goals and constraints there is no common direction and nothing for teams to learn from each other against.
• Change small things and watch. Because of non-linearity, make small changes, observe their effects and be ready to reverse them; never assume a "minor" change is harmless.

The agile suitability filter, described in PMI's Agile Practice Guide, is a structured assessment that a sponsor, the team and the practitioner complete together to see whether an agile, hybrid or predictive approach suits a project. Each attribute is scored and the scores are plotted on a radar (spider) chart.

The attributes fall into three groups. Each one's direction matters, not just its name:

Comparing candidate projects means checking each attribute's direction rather than counting favourable-sounding labels. A candidate that sits near the centre on every attribute is a stronger pilot than one that looks good overall but pulls hard towards the edge on a single attribute.

The suitability filter starts a conversation; it does not output a decision. Two patterns come up repeatedly.

• One outlier in an otherwise agile profile is a risk to address, not a verdict. If every attribute sits near the centre except one, treat that attribute as a specific problem and work on it, with the sponsor or leadership where the fix is in their gift, before committing. The generic mistakes are letting one score overturn the rest of the evidence, accepting the weakness without a plan, or adjusting the assessment so the weakness no longer shows. Some weaknesses have structural fixes: team size, for example, is handled by organising several small cross-functional teams that coordinate with each other.
• When sponsor and team score the same attribute very differently, the gap is the finding. Divergence on culture attributes such as trust or decision-making usually reveals a problem that would undermine an agile approach. Merging the two sets into one number, or choosing whose view counts, removes exactly the information the filter surfaced; talk through why the views differ first.

Suitability is also not a one-off: as the culture, team or project changes, the result can change, and attributes that score poorly today can be improved.

Integrating agile models means combining or tailoring approaches so that each part of the work gets what it needs, at the level of the use case, the team, the project or the organization. The mindset is to add what the current model lacks rather than replace what already works.

Integration can also run over time (a hybrid that explores iteratively, then delivers a known build predictively) or by phase. Choosing the inter-team coordination mechanism in detail (scrum of scrums, team of teams) and tailoring practices to a team's understanding of agile are covered in the PMI-ACP topic Promote collaborative team environment.