PMI-ACP Build Transparency: Information Radiators, Team Feedback Loops and Communication for Co-located and Distributed Teams

Building transparency means making the team's real situation, including its status, progress, process, risks, impediments and learning, visible to everyone who needs it, at the moment they need it, without anyone having to ask or wait for a report. The PMI-ACP Examination Content Outline places it as Task 4 of the Mindset domain and lists three enablers, which this lesson follows:

1. Make status, progress, process, risks, impediments and learning accessible to all, for example with information radiators.
2. Establish a feedback loop for the team, so problems and feelings surface while they are still cheap to deal with.
3. Define communication strategies for co-located and distributed teams, so the same openness works whether people share a room or a time zone or neither.

Transparency matters because agile work is empirical: teams inspect what is really happening and adapt. Inspection only works on accurate information, and adaptation only happens when the people who can help see the problem in time. Transparency also builds trust. Stakeholders who can see the work whenever they like stop demanding status meetings, and a team that shows bad news early is believed when it shows good news.

The agile practitioner's role is to help the team make its information visible and keep it honest. The team owns its displays; the practitioner coaches, removes obstacles to openness and challenges anything that hides the truth, including well-meant attempts to protect stakeholders or the team from bad news.

An information radiator is a large, highly visible display of current team information, placed where people pass by, that anyone can read at a glance without asking anyone or logging in to anything. Alistair Cockburn coined the term. A common contrast is the "information refrigerator": information kept in documents, folders or tools that people must open, search for or request. Radiated information comes to people; refrigerated information waits to be fetched.

A good radiator has four qualities:

• Visible: it sits where its audience already is, such as the team area wall or, for remote teams, an online board everyone can open.
• Glanceable: someone walking past understands it in seconds, without a guide.
• Current: it changes as the work changes, ideally because the team updates it as part of doing the work.
• Low effort: it costs the team little to maintain, unlike a report that must be written.

The outline lists six kinds of information to make accessible. Each has typical radiators:

When people keep interrupting a team to ask how things are going, that is a sign the information is not radiating. The fix is to make the information visible where those people already are, so they can pull it whenever they like.

A radiator is only useful while people trust it, and they trust it only while it is accurate, current and used for its intended purpose. The team owns and updates its own displays. When a board goes stale, with finished cards still shown as in progress or real work missing, people stop believing it and fall back to asking individuals for status. A stale radiator is worse than none, because it misleads. The practitioner's response is to help the team agree how it keeps the board current as part of moving the work, because the board is only trusted when the people doing the work keep it.

Fewer is better. Walls tend to collect charts. When there are so many that visitors cannot tell at a glance how the work is going, and the team itself has stopped looking, keep the few displays people actually use and retire the rest. A display that needs explaining or searching has stopped radiating.

Misuse corrupts the data. Velocity is a team's own planning measure, and story points are relative to that one team, so comparing velocity between teams is meaningless. When a manager starts comparing teams or questioning a team's velocity, estimates tend to inflate while delivered value stays the same, and the chart stops telling the truth. Showing points completed per individual has a similar effect: people avoid pairing, reviews and helping others because that work does not add to their own score. The answer is not to hide the chart. The practitioner coaches the person misusing it on what the measure is for and offers measures that fit their real question, and the team radiates whole-team progress rather than individual scores.

Report what the data shows. "Watermelon" status is green on the outside and red inside: a status that looks fine while the team's own data says otherwise, often because amber or red would trigger unwelcome attention. Transparency means reporting the status the data supports, showing the evidence, such as a burnup forecast, and dealing with any punitive reaction to bad news through the people who own that process, not by hiding the news.

Show done, not "nearly done". A large item reported as 90% complete for weeks hides the real position, because percentage complete is a feeling, not a fact. Splitting work into small stories that are either done or not done makes progress on the board honest.

Burndown or burnup when scope changes

Both charts track release progress, but they behave differently when scope moves:

A burndown on its own cannot tell slow delivery apart from growing scope, because both look like a line that stops falling. A burnup separates the two.

Making the process visible means writing the team's working rules where everyone can see them, so people read the board the same way and follow the same rules without asking. When rules live only in someone's notes or in people's heads, members apply them differently and stakeholders misread the board.

• Definition of done: the agreed criteria a story must meet to count as complete. Post it on the board or team wall, not in a scrum master's notebook or a new joiner's onboarding talk.
• Explicit policies: making policies explicit is one of the general practices of the Kanban Method. A typical example is exit criteria for each board column, such as what "ready for test" means. When developers and testers argue about whether a card can move, or stakeholders argue about what a column means, the fix is to agree the policy together and post it on the board.
• Work-in-progress limits, shown on the columns they apply to.
• Classes of service: if urgent requests keep bypassing the board's WIP limits, agree an explicit expedite policy, typically a separate lane with its own small limit and clear entry rules, and post it. Genuine emergencies still move fast, and everything else waits for normal replenishment. If the rules for urgent work aren't on the board, everyone invents their own.

A process rule that is visible can also be inspected and improved, which is why posting policies supports the team's continuous improvement as well as its transparency.

Impediments and risks should go on the shared radiators as soon as they are known, because the people who can remove a blocker or help with a risk can act only if they see it in time.

Impediments

• Mark a card as blocked on the board the moment work on it stops, and keep a visible impediment list. A blocker that is not on the shared display is invisible to the people who could help remove it.
• Show work-item ageing, such as the days a card has spent in its current column, so stalled work stands out while it is happening, not after the fact.
• When an impediment involves another person or team, post the blocked work and the help it needs, without naming or blaming anyone. Keeping a sensitive impediment private protects a relationship at the cost of the delivery date; naming a person turns transparency into blame.

Risks

• Show each significant risk with its planned response and owner, such as a spike scheduled for the next iteration. Showing the plan alongside the risk is what keeps stakeholders confident: a known risk with a response is reassuring, while a surprise is not.
• A risk burndown chart plots total risk exposure (for each open risk, probability times impact, summed) at the end of each iteration. It shows a trend, whether the work is getting less risky over time, rather than a snapshot of today's risks.
• A risk-adjusted backlog holds risk-response work, such as spikes, as backlog items prioritized beside features. Put that work on the board and in the burnup too: when risk work is invisible, a team that spends real time reducing risk looks as if it is slowing down.

Making learning visible means sharing what the team discovers, such as spike findings, experiment results and lessons, in places and forums where others will actually meet it, so other teams do not repeat the same work. Repeated discoveries across teams are the usual cost of learning that stays out of sight.

• Post spike goals and findings, experiment results and lessons on a shared learning wall or space.
• Open the iteration review to members of other teams; it is already a public look at what was built and learned.
• Stored is not shared. Filing learning somewhere people could look is a refrigerator, not a radiator. Learning spreads when it is brought to people in regular forums they actually attend.
• Keep the retrospective the team's own. Retrospectives depend on candid conversation, so the team shares its outcomes and lessons, not its retrospective notes. Candour in the retrospective is what produces the learning in the first place, so protecting it serves transparency.

Transparency for stakeholders means letting them pull current information from the team's live radiators whenever they want, rather than having the team push reports at them. Reports go out of date the moment they are written and cost the team time; a live board is always current and costs nothing extra.

• Give stakeholders read access to online boards. An online board radiates only to the people who can open it.
• Treat a request for a report as an information need. Find out what the person is trying to learn and show them where the radiators already answer it; if something is genuinely missing, add it to the radiators so everyone benefits.
• Pair openness with an agreed way to feed in. Transparency means everyone sees the same, real work; how outsiders influence that work is a separate agreement, usually through the product owner.

A team feedback loop is an agreed, continuous way for team members to raise problems, observations and feelings with each other as they arise, rather than saving them for a scheduled meeting. Retrospectives are the periodic, formal loop; the transparency enabler asks for something between them too.

• Raise issues as they arise. A problem saved for the next scheduled meeting grows in cost while it waits. Help the team agree how and where to raise issues immediately, for example on the board, in the standup or in the team channel; the habit matters more than the calendar.
• The daily standup is the team's own loop. It exists for members to coordinate with each other, not to report to the scrum master. If everyone faces the scrum master, it has become a status meeting, and blockers that a colleague could solve go unnoticed. The scrum master can step out of the circle so members address one another.
• Make mood visible. A niko-niko calendar (Japanese for "smiley") is a wall calendar where each member marks how they felt about each working day. It gives a lightweight, continuous signal between retrospectives, unlike surveys or check-ins that come too rarely or privately.

How the team gives each other feedback safely, without blame, belongs to fostering psychological safety, the next task in the Mindset domain.

For a co-located team the best communication strategy is to sit the whole team together in one shared space, because the richest and fastest communication is face to face, and much of it happens without anyone planning it.

• Osmotic communication (Cockburn's term): when the team shares a room, information flows in the background as people overhear questions and answers and join in when they can help. Distance removes it quickly: once people who work together sit apart, simple questions start waiting for meetings.
• Caves and commons: an open shared area (the commons) for collaboration, plus quiet spaces nearby (caves) for focused work. Caves give people focus without giving up the shared room.
• Partial co-location: when a key person cannot be with the team full time, agree set, predictable hours when they are. Direct, frequent contact keeps questions short and answers quick.

Matching the channel to the message

Cockburn's communication-effectiveness diagram ranks channels from least to most effective, roughly: paper, audio or video recordings, email, phone, video call, and face to face at a whiteboard, the richest. It actually draws two curves, and the channels that allow live question and answer sit on the higher one; that interactivity is most of what makes a channel rich. The rule is to match richness to difficulty. Routine updates suit written channels; conflicting views, misunderstandings and design debates need a live, rich conversation, ideally with a shared whiteboard. When a written thread has gone round in circles, switch to a short live call and then record the outcome in writing so that everyone, including those who were not there, can follow it.

For a distributed team, the communication strategy has to replace what proximity provides for free: quick answers, overheard decisions and a shared view of the work. The usual tools are a daily overlap window, written decision records, agreed channel norms and fair meeting times.

• Overlap window: an agreed daily period when all locations are online for live questions, so handoffs do not stall for a day.
• Written decision records: record each decision and its reason in the shared channel or document, so members elsewhere are not excluded by conversations they could not hear.
• Channel and response norms: agree which channel is for what and how quickly each expects a reply, so urgent issues are not lost and nobody feels pressured to answer at night.
• Rotate meeting times across time zones so the inconvenience is shared, while keeping the live conversation the team values. Sharing the inconvenience keeps one team rather than one team per site.
• One board, online: a single online board that everyone uses is the radiator for a distributed team.

Hybrid teams

A hybrid team, part in the office and part remote, should default to the medium every member can use live. Otherwise the office conversation becomes the real meeting and remote members hear about decisions afterwards.

• Run design discussions on a shared digital whiteboard, even when the office members are in the same room.
• In meetings, have everyone join from their own device and keep to one conversation, with no side talk in the room. Equal access to the conversation matters more than equipment.
• Keep one board: make the online board the only board and, if the office values a wall view, show it on a large screen. Two boards for the same work drift apart, and then nobody knows which to trust.