Choosing an Approach

How to pick a way of working that fits the work: certainty and agreement, the Stacey matrix and Cynefin, when Scrum, Kanban, a predictive plan or a hybrid fits, and frameworks such as PRINCE2 and the PMBOK Guide.

Certainty and agreement

Two questions decide most of the choice. How certain are we about how to do the work? Moving a server rack is a known technique; building a recommendation engine for energy tariffs is not. How much do people agree on what is needed? Replacing end-of-life switches has one obvious goal; "make the portal better" has as many goals as stakeholders.

When both are high, you can plan ahead and execute. When either is low, a detailed plan is mostly guesswork, and short feedback loops pay off. Most organizations have work of every kind, which is why no single approach fits a whole IT department.

The Stacey matrix

The Stacey matrix is a diagram that places work on two axes — how close it is to agreement and how close it is to certainty — and so suggests whether it is simple, complicated, complex or chaotic. It is attributed to the British management scholar Ralph Stacey and appears in countless agile courses, usually to argue that most software development sits in the complex zone.

The Stacey matrix as commonly drawn in agile training. The horizontal axis runs from close to certainty on the left to far from certainty on the right; the vertical axis runs from close to agreement at the bottom to far from agreement at the top. Bands spread out from the bottom-left corner: simple near the corner, then complicated, then complex, and chaotic in the top right. Simple Complicated Complex Chaotic close to certainty far from certainty close to agreement far from agreement
The simplified version used in agile training, not Stacey's original diagram.

Read it like this:

  • Simple — known technique, shared goal. Follow a plan or a checklist.
  • Complicated — either the technique or the goal needs work, but analysis by experts can resolve it. Plan with care.
  • Complex — neither can be settled up front. Learn by doing, in short cycles.
  • Chaotic — no agreement and no known technique. Act first to stabilize, then make sense of it.

The Cynefin framework

The Cynefin framework (pronounced roughly "ku-NEV-in", a Welsh word for habitat) is a sense-making framework developed by Dave Snowden, starting around 1999 at IBM. It distinguishes situations by the relationship between cause and effect, and suggests a different way of deciding in each. It was described in an IBM Systems Journal paper (Kurtz and Snowden, 2003) and widely popularized by a Harvard Business Review article (Snowden and Boone, 2007).

The Cynefin framework as four domains around a central one. Top left: complex, probe-sense-respond. Top right: complicated, sense-analyze-respond. Bottom left: chaotic, act-sense-respond. Bottom right: clear, sense-categorize-respond. In the center: confusion, not knowing which domain applies. Complex probe – sense – respond emergent practice Complicated sense – analyze – respond good practice Chaotic act – sense – respond novel practice Clear sense – categorize – respond best practice Confusion which domain?
Cause and effect are obvious in clear, discoverable by analysis in complicated, visible only in hindsight in complex, and not perceivable in chaotic.
Domain Cause and effect How to decide Kestrel example
Clear Obvious to anyone Sense, categorize, respond: apply the known procedure Resetting a customer's portal password
Complicated Knowable by expert analysis Sense, analyze, respond: ask experts, choose a good option Sizing the database servers for the data center move
Complex Only clear in hindsight Probe, sense, respond: run small safe-to-fail experiments, amplify what works Which portal features reduce calls to the service desk
Chaotic No perceivable relationship Act, sense, respond: stabilize first, then analyze A storm takes out the network and the portal at once

The central domain is about not knowing which of the four applies. It was called disorder in early versions and is now called confusion (Snowden's newer material splits it further into "aporetic" and "confused"). The earlier names of the clear domain were simple and obvious, so older articles use those words. The decision patterns in the table are the ones commonly cited from Snowden's work; his own site, The Cynefin Co, is the reference for the current wording.

The ITSM topic touches the same idea as complexity thinking. And the lesson for choosing an approach is direct: Scrum's empiricism is a probe-sense-respond loop, designed for the complex domain; a predictive plan is a good fit for clear and complicated work; a major incident is chaotic and needs someone to act now.

Matching work to an approach

Kind of work Good fit Why
Complex product work: new features, uncertain needs, regular releases Scrum Sprints create a regular inspect-and-adapt loop with a goal, stakeholders and a usable Increment
Continuous flow of varied, often unplanned items: operations, support, maintenance Kanban No fixed iteration to protect; work is pulled as capacity frees up and flow is measured
Well-understood work with a fixed sequence or date: data center move, hardware rollout Predictive plan The steps are known, so planning ahead is cheap and lets you coordinate suppliers and dates
Mixed work: fixed contracts or hardware plus uncertain software Hybrid Plan the stable parts ahead, deliver the uncertain parts adaptively, connect them with milestones

Kestrel's portal relaunch is a typical hybrid. The go-live date is tied to a new tariff structure and the hosting contract is fixed — predictive. Which features customers actually need is uncertain, so the Portal team (Product Owner Isabel Santos, Scrum Master Lars de Boer) develops them in Scrum Sprints, with the go-live as a milestone in the overall plan.

Frameworks that span approaches

The PMBOK Guide

The PMBOK Guide (A Guide to the Project Management Body of Knowledge) is the Project Management Institute's (PMI) reference for project management, published together with The Standard for Project Management. Its Eighth Edition appeared in November 2025. It is organized around:

  • Six principles: adopt a holistic view, focus on value, embed quality, lead accountably, integrate sustainability, and build empowered teams.
  • Seven performance domains: governance, scope, schedule, finance, stakeholders, resources and risk.
  • Process guidance, reintroduced after the seventh edition (2021) had dropped it, now in a non-prescriptive form, plus new coverage of AI, project management offices (PMOs) and procurement.

The PMBOK Guide covers predictive, adaptive and hybrid approaches, and its central instruction is tailoring: adapt the approach, processes and documents to the project instead of applying everything to everything. If you studied the seventh edition (12 principles, 8 performance domains), note that the numbers changed.

PRINCE2 Agile

PRINCE2 manages a project by stages, with continued business justification and management by exception; its current edition, PRINCE2 7 (2023), has seven principles, seven practices and seven processes, and one of the principles is to tailor the method to the project.

PRINCE2 Agile is PeopleCert's guidance for combining PRINCE2's project governance (business case, stages, a project board) with agile delivery approaches such as Scrum and Kanban at team level. A widely cited idea is "fix and flex": time and cost are usually held fixed, while scope (and, within limits, some quality criteria) flexes within tolerances agreed with the project board — the iron triangle turned around. PRINCE2 Agile is now in its second version; it has its own Foundation and Practitioner certifications.

Questions to ask before choosing

  1. How well do we understand what is needed? Who decides, and do they agree?
  2. How well do we understand how to build or do it?
  3. Does the work arrive as a planned project, or as a continuous stream of requests and interruptions?
  4. Can we deliver in usable pieces, and can users give feedback on them?
  5. What is fixed: a date, a budget, a contract, a regulation?
  6. What does a mistake cost, and how quickly would we find out?
  7. What does the organization around the team need: reports, governance, sign-offs? Can those be met without breaking the delivery approach?

Common mistakes

  • Agile as a goal in itself. "We are going agile" without a problem to solve. Start from the outcome you need — earlier feedback, less waste, more predictable delivery — and choose the approach that helps.
  • Forcing Scrum on interrupt-driven teams. A network operations team whose day is driven by incidents cannot protect a two-week Sprint Goal; Kanban usually fits better. See Agile in IT Operations.
  • Predictive plans for complex work. A detailed eighteen-month plan for a product nobody has built before.
  • Agile labels on predictive work. Calling project phases "sprints" while requirements are frozen and nothing is released until the end.
  • One approach for the whole department. The portal team, the service desk and the data center move are different kinds of work.