3.2 Progress Iteratively with Feedback and Collaborate and Promote Visibility

Progress Iteratively with Feedback

Progress iteratively with feedback advises that you "do not attempt to do everything at once." Instead, organize work into smaller, manageable sections — iterations — that can be executed and completed in a timely way. Each iteration delivers something usable, so value arrives early rather than only at the end of a long project. This reduces risk: if priorities shift or an approach proves wrong, you have committed far less than you would have in a single large effort.

The second half of the principle is just as important: feedback. Seeking and using feedback before, during, and after each iteration ensures that actions are focused and appropriate even as conditions change. Feedback comes from users, customers, team members, and measurements of the work itself. ITIL stresses being able to tell constructive feedback from unhelpful input, staying open to criticism, and demonstrating a commitment to improvement based on what you learn. An iteration that ignores its feedback loops is not really iterative — it is just a series of disconnected steps.

Recommendations for Progress Iteratively with Feedback

• Comprehend the whole, but do something — understand the big picture, then act in increments rather than waiting for a perfect plan.
• The ecosystem is constantly changing, so feedback is essential — gather it at every stage.
• Fast does not mean incomplete — each iteration should still meet the agreed quality and value.
• Move in measured, incremental phases while keeping the overall objective in focus.

Iterations and Feedback Working Together

Consider a service desk rolling out a new self-service portal. Rather than launching every feature to all users at once, the team releases a small minimum viable portal to one department, gathers feedback, fixes problems, and expands. Each cycle is an iteration; the feedback from each cycle steers the next. This delivers value early, contains risk, and lets the team change direction cheaply if users react badly.

A common exam distractor pairs iterative delivery with no feedback — e.g., shipping in phases but never checking whether the phases work. That violates the principle, because feedback loops are integral, not optional. Another trap describes one enormous "big bang" release; that is the opposite of progressing iteratively.

Iterations can run in sequence or in parallel, and a large initiative is typically a set of iterations rather than one long march. ITIL also stresses that each iteration should be evaluated for continued relevance — the broader environment changes, so an iteration planned months ago may need re-scoping when its turn arrives. This is why feedback is gathered not only on the work produced but on whether the plan itself still makes sense. Feedback mechanisms include user reactions, measurement of outputs against intended outcomes, lessons from previous iterations, and changes in regulation or demand.

Treating feedback as a first-class input — rather than a report filed after the fact — is what separates genuine iterative progress from a series of disconnected releases.

Collaborate and Promote Visibility

Collaborate and promote visibility has two linked parts. Collaboration means working across boundaries — between teams, between provider and consumer, between IT and the wider business — and crucially involving the right people in the right roles at the right time. Good collaboration drives value co-creation: better information, broader buy-in, and decisions that stick. Who you involve matters more than how many; the principle is about the right people, not simply more people.

Promoting visibility means making work and its flow visible so that nothing important is hidden. ITIL warns against the dangerous assumption that "no news is good news" — a lack of information often hides problems, not their absence. When work-in-progress is invisible, organizations accumulate hidden WIP, hidden bottlenecks, and hidden waste. Surfacing the real volume and status of work lets leaders make informed decisions about priorities and capacity.

Recommendations for Collaborate and Promote Visibility

• Collaboration does not mean consensus — you do not need everyone to agree on everything to move forward.
• Communicate in a way the audience can hear — tailor the message to each group.
• Decisions can only be made on visible data — surface the work so choices are evidence-based.
• Identify good criteria for whom to involve and when.

Why Visibility Matters on the Exam

A classic exam item describes a team where leadership has "heard nothing," so assumes everything is fine, while hidden work piles up. The correct response invokes collaborate and promote visibility: make the work visible, because absence of information is not evidence of success.

Visibility also has a quantitative purpose. When leaders can see the real volume of work flowing through a system, they can decide rationally about priorities, capacity, and what to start or stop. Hidden work — side projects, informal favours, undocumented fixes — competes silently for the same people and erodes the throughput of the work that is actually planned. Making it visible is the first step to managing it. Collaboration, meanwhile, should extend to service consumers, suppliers, and internal teams alike, because value is co-created across all of those relationships.

ITIL is careful to note that collaboration does not require consensus: insisting that everyone agree on everything stalls progress, whereas involving the right contributors and acting on visible evidence keeps work moving.