Obeya: how a big room helps teams see and decide together

An obeya room is where a team reviews goals, progress, dependencies and problems in one place, so it can decide together instead of passing separate status reports up and down. Instead of reading the schedule apart from customer needs, technical risks and targets, people see them side by side. Five parts set it apart from a wall of charts:

Each review compares what is happening with what was expected, then agrees what to do about the gaps. A practical cycle:

1. 1

   Prepare the information. Owners update measures, milestones, risks and requests before the review, not during it.

2. 2

   Establish the situation. Look at what changed since last time and which goals it may affect.

3. 3

   Focus on exceptions. Spend the time on gaps, uncertainty, dependencies and decisions, not on items that are on track.

4. 4

   Agree a response. Name the next action, its owner and any help needed.

5. 5

   Check earlier commitments. Review last round's actions and what the team learned from them.

An illustrative case: a service launch where marketing is ready but operations has not tested the support process. Separate updates would both read green. In the obeya the team asks whether the launch date still holds and decides to cut scope, add support or change the order.

Keep coordination apart from deep investigation. If a technical issue needs analysis, send a smaller group to study it and say what answer must come back to the room.

Show what the team needs to understand the situation and decide, not everything that exists. In product development that can mean the vision, schedule, targets, design choices, risks and problem solving under way. Five zones cover most rooms:

Fit the zones to the project's real challenges. An empty zone is a question to ask, not a gap to fill with charts.

Try reading each chart with its owner out of the room. If someone else cannot tell what it means and what needs attention, fix the labels before adding more. Each measure should show:

• What is measured: The measure and its unit, in plain words.
• The period: Which week, month or build it covers.
• The target: What good looks like, so the gap is visible.
• The last update: A date, so stale data stands out.
• Why it is red or amber: One line on the condition behind the color.

Give handoffs as much space as tasks. A milestone may depend on an approval, a test result, a supplier input or a decision from another function. For each one, write the receiving team's need beside the delivering team's promise, and say what ready means, not only when the item is due. An illustrative handoff card:

Written this way, an abstract dependency becomes something both sides can talk about.

Use one when an important outcome depends on several functions seeing the same situation and deciding together, and when progress inside each team does not add up to progress for the whole. Illustrative uses:

Name the problem first. Approvals are late because the people who decide never review the same evidence together is a reason for an obeya. If a small team already coordinates well, a simpler fix beats another management layer.

Obeya overlaps with other visual tools, but the conversation around the facts is what makes it a management system:

These are not competing choices. Keep useful dashboards, schedules and kanban boards, and let the obeya point to them. Decide where an action lives so nobody updates the same commitment in three places.

Start with the management need, not the furniture or software, and run the first room as a pilot:

1. 1

   Write the purpose and boundaries. One or two sentences naming the outcome, the teams and the coordination problem, for example: this obeya supports launch readiness by making cross-team dependencies and open decisions visible. Also say what stays out, such as individual workload talks, deep technical reviews and personnel matters.

2. 2

   Choose participants and decision rights. Invite people because they bring knowledge, own a dependency or can approve a decision, not for seniority alone. Agree who hosts, who keeps each zone current and which decisions the group can make itself. For the rest, set the escalation route.

3. 3

   Build the smallest useful set of visuals. Goals, a few measures, key dependencies and current problems, with simple labels. Test the layout on a real issue: can the group connect a gap to the work, find missing information and agree a response?

4. 4

   Pilot, review and simplify. After a few reviews, ask which visuals changed a decision, which were hard to keep current and which facts were missing. Remove what nobody uses, and retire an old report or meeting for each new element.

Write down the few rules that made the pilot work: information owners, review rhythm, decision limits and escalation. Keep them short enough to read in the room. Check that people can keep the room going without heavy preparation before copying it to another team.

A virtual obeya applies the same idea in a shared digital workspace. It should let distributed people work on the facts, not watch a slide show. Test each format against how your team will really take part:

For a hybrid pilot, ask someone to join remotely and do an ordinary task: find a risk, open its evidence and add a comment. What gets in their way is what to fix before setting the routine.

Judge digital obeya software by the work it supports, not the number of templates. Questions for a trial:

• Overview and detail: Can people move between the big picture and the supporting record easily?
• Updates: Can owners update their own zone without special help?
• Sources: Are source records, dates and owners clear on every item?
• Access: Can sensitive information be restricted safely?
• History: Can people find earlier decisions and actions?
• Accessibility: Does it work on ordinary screens and with assistive tools?
• Export: Can the information leave the platform if you switch?

In the trial, have people do real tasks: update a measure, record a decision, find an overdue action and prepare for a review. The daily management software category lists tools. One naming note: OFS Obeya is an office furniture range, a separate product from the lean method.

A starting agenda, to adapt to the work rather than copy:

1. 1

   Purpose

   Confirm the outcome or milestone that needs attention.

2. 2

   What changed

   Note important developments since the last review.

3. 3

   Gaps and dependencies

   Focus on items that need coordination or help.

4. 4

   Decisions

   Make the ones the group can make and route the rest.

5. 5

   Commitments

   Read back owners, next steps and review points.

Ask presenters to separate what they saw from what they think caused it. Testing is incomplete is different from testing is incomplete because the specification changed; the second needs checking. Set the meeting rhythm to the pace of the work, and end by asking each action owner to repeat their commitment. If the same issue comes back unchanged, ask whether the earlier response was enough rather than setting a new date.

1. 1

   More charts as more transparency. Every visual needs a decision it supports.

2. 2

   Solving everything in the meeting. Agree the next study and bring the evidence back.

3. 3

   Red means someone failed. Ask what help or change is needed first. If bad news brings blame, the walls turn green and stop telling the truth.

4. 4

   Stale information. An obeya with old data is worse than none, because people stop trusting it.

5. 5

   Schedules only. A room that tracks dates but not performance, risks or decisions is a project plan on a wall.

6. 6

   Software as alignment. Check that people read the goals and priorities the same way.

7. 7

   Closing on task done. Check whether the action produced the result before closing the issue.

Schedule housekeeping every few weeks: remove old material, review long-open items and ask someone new to explain the big picture. Their confusion shows what to fix.

Judge it against the problem that led you to build it, not by how good the room looks. Set a baseline before the pilot and keep a few checks:

Track other changes during the pilot, such as staffing or scope, and do not credit every improvement to the room. Pair the operational evidence with what participants say, and expand only when the practice proves worth keeping. Leader standard work can give the review a place in each leader's week.