Bakers Unlimited VSRA Workshop

Workshop Purpose

This exercise introduces participants to Value Stream Reference Architecture (VSRA) by having them discover an organization’s support network through conversation and negotiation. Participants will make an initial guess about team types and interaction patterns, determine the support network from their decisions, and then use Valustra to examine what the VSRA analysis reveals about the organization and its team topology.

The exercise is designed to demonstrate that team topology is not obvious from team names alone. It emerges from responsibilities, dependencies, support relationships, and the way teams interact.

Materials

Prepare the following materials before the workshop:

• One runner description sheet for each team, with four copies printed on each sheet and cut apart.
• One manager sheet for each team.
• Pens or pencils for every group.
• A visible timer set for 10 minutes.
• Access to Valustra for entering the team and support information.

The workshop uses nine IT division teams for a fictitious organization, "Bakers Unlimited," a baked goods company with brick-and-mortar stores across the country. The teams are:

• DevOps Engineering
• Storefront Development
• Cyber Security
• Finance Support
• Quality Assurance
• Database
• Infrastructure
• Product Catalog Dev
• Bakery Development

Before Participants Arrive

1. Print and cut the four runner descriptions for each team.
2. Print one manager sheet for each team.
3. Separate the materials so each small group receives one team’s runner descriptions and the matching manager sheet.
4. Arrange the room so managers can remain in fixed locations while runners can move between them.
5. Assign or label a location for each team manager.
6. Open Valustra and prepare a new VSRA project for "Bakers Unlimited", or confirm that the project is ready for data entry. Enter each team name under the organization section but leave the support network and interaction patterns undefined.
7. Make sure participants understand that the support network they create will be entered into Valustra after the timed exercise.

Group Formation

Assuming a workshop size of 30–35 people, divide attendees into small groups of three or four people. Each group represents one of the nine teams. Ask the teams to assign one person in each group to be the manager. The remaining people become runners.

The manager stays at the team’s assigned location throughout the exercise. Runners carry the team description and visit the other team managers.

If a group has three people, use one manager and two runners. If it has four people, use one manager and three runners.

Explain the Direction of Support

Use this wording before starting:

A team should be listed as supporting another team when it provides a capability that the other team generally needs in order to perform its normal duties. For example, if Infrastructure supports Bakery Development, the Infrastructure manager checks the box for Bakery Development on the Infrastructure manager sheet.

For clarity: Infrastructure -> Bakery Development means that Infrastructure supports Bakery Development.

The manager sheet records the teams that their own team supports. Runners are trying to persuade other managers to check their team’s name when the criterion described above is met.

For example, a Bakery Development runner visits the Infrastructure manager to explain why the Bakery Development team needs infrastructure capabilities. If the Infrastructure manager agrees, the Infrastructure manager checks the box beside Bakery Development on the Infrastructure manager sheet.

When a runner convinces a manager that the manager’s team should support the runner’s team, the runner should report back to their own manager that the support has been agreed. Record the relationship in both places: the supporting team’s manager checks the supported team on the “Teams Supported by…” list, and the supported team’s manager strikes through the supporting team’s name on their own list. This prevents a runner from requesting support in the opposite direction. For example, if Infrastructure agrees to support Bakery Development, the Infrastructure manager checks “Bakery Development,” and the Bakery Development manager strikes through “Infrastructure.” If an Infrastructure runner later asks Bakery Development for support, the Bakery Development manager must decline because the relationship has already been established in the opposite direction. Bi-directional support is not allowed. Support must happen only in one direction.

It may not be obvious when a support cycle is created. For example, Team A -> Team B -> Team A. If a cycle is detected, a manager may refuse a request for support on that basis. Valustra will not allow a support network to be entered that contains a cycle. The graph must be a Directed Acyclic Graph (DAG) for the analysis to work correctly. If needed, cycles can be resolved through discussion when the support network is entered into Valustra.

Briefing the Participants

Do not reveal the intended dependency network or the likely team types before the exercise. The value of the activity comes from allowing participants to reason from incomplete information.

Tell participants:

• Read and understand your own team’s description before leaving your team location.
• Do not assume that a team supports you simply because its name sounds relevant.
• Explain what your team needs and why the other team’s capabilities would help.
• Managers make the final decision for their own sheet.
• Managers may ask questions before deciding.
• Managers may decline a request if they are not convinced.
• Runners may return to their own manager if they need clarification about their team’s responsibilities.
• The goal is to make a reasoned decision, not to collect every possible support relationship.
• When support is agreed, the supporting team’s manager checks the supported team, and the supported team’s manager strikes through the supporting team on their own list. Do not request or accept support in the opposite direction.
• Managers: Avoid support cycles in the network. If spotted, refuse to support.
• Choose one guessed team type and one guessed interaction pattern on your manager sheet before the exercise ends.

Exercise Procedure

1. Distribute and Discuss Materials (5 mins)

Give each group:

• One manager sheet for its assigned team.
• Four cut-apart copies of that team’s runner description.
• Writing materials.

Ask the manager to read the sheet and remain at the assigned location. Ask the runners to read the team description carefully before visiting anyone. The team should discuss what teams they will likely want support from before sending out their runners.

2. Make Initial Guesses (3 mins)

Before runners begin, ask the group to discuss and mark its initial guesses for:

• Team type: stream-aligned, enabling, complicated-subsystem, or platform.
• Interaction pattern: collaboration, X-as-a-Service, or facilitating.

The group should make these guesses from the description alone. They will compare them with the Valustra analysis later.

3. Start the Ten-Minute Round

Set the timer for 10 minutes. Runners visit the other team managers and make the case for support.

A runner should explain:

• What their team is responsible for.
• What capability or information their team needs.
• What capability or information the manager’s team could provide to them.
• How the proposed support would help their team deliver value.

The manager should ask questions and decide whether to check the runner’s team on the manager sheet. The manager may accept or decline each request independently.

Runners can split the other teams between themselves, revisit managers, or coordinate their approach. The manager remains in place and keeps the team’s sheet throughout the round.

4. Stop the Round

Call time after 10 minutes, even if some conversations are unfinished. Ask everyone to return to their assigned team location.

Briefly ask each group to review its sheet and make sure:

• The team type guess is selected.
• The interaction pattern guess is selected.
• The support checkboxes reflect the decisions made by the manager.

Do not allow groups to revise decisions based on information they hear after time is called.

Enter the Results into Valustra

Create or open the Bakers Unlimited VSRA project in Valustra.

1. If not already done, add the nine teams under the organization section.
2. For each team, enter the support relationships recorded on its manager sheet and the interaction pattern guessed by the team.
3. Treat a checked team as a support relationship from the checked team to the team whose sheet contains the checkbox.
4. Review the resulting topology diagram.
5. Open the analysis or insights view to examine the calculated team relationships and centrality results.
6. Compare the groups’ guessed team types with Valustra’s suggested analysis. Discuss the interaction-pattern guesses separately, using the negotiation conversations and the topology as evidence.
7. Ask Valustra: solicit questions from the audience that can be used as prompts to the AI. Discuss its responses.
8. Generate and save a report. Share the resulting QR code with the attendees.

When entering the data, preserve the decisions made during the exercise. Do not correct the network before the first analysis. Unexpected or incomplete relationships are useful discussion material.

Debrief Discussion

If needed, use the following questions to guide the discussion:

Discovering the Network

• Which support requests were easiest to explain?
• Which managers received the most requests?
• Which requests were declined, and why?
• Did any team appear to be important to many other teams?
• Were there teams that runners assumed would help but could not make a convincing case for?

Team Types

• Which teams did groups identify as stream-aligned, enabling, complicated-subsystem, or platform?
• What evidence supported each guess?
• Did Valustra’s suggested classifications match the groups’ initial guesses?
• What does a mismatch tell us about the team’s responsibilities or dependencies?

Interaction Patterns

• Which interaction pattern did your group choose for its team, and what evidence supported that choice?
• Based on the conversations, which relationships felt like collaboration?
• Which relationships could be delivered as X-as-a-Service?
• Which relationships seemed more like facilitating or capability transfer?
• Did conversations with different teams suggest that one overall interaction-pattern guess might be too simple?

Flow and Risk

• Which teams had the greatest potential to impede flow?
• Did any team appear to sit on a transitive path between other teams?
• Where did the network create high cognitive load or excessive coordination?
• Which dependency would be most valuable to reduce, clarify, or turn into a self-service capability?

Key Learning Points

Close the exercise by emphasizing these points:

• Isomorphic Typification: A team topology is shaped by the network around a team, not just by its name.
• Flow is a function of the network connections and the cognitive load shared between teams.
• Shared teams may become important flow constraints when many teams depend on them.
• A dependency is not automatically a problem; the interaction mode and clarity of the boundary matter.
• Team type is a useful design hypothesis that can be tested against responsibilities, dependencies, and observed behavior.
• Valustra provides analytical signals, not unquestionable answers. Participants should use the results to ask better organizational design questions.
• The current-state graph is a starting point for considering a target topology and possible improvements.

Suggested Timing

Activity	Time
Introduction to the exercise	5 minutes
Distribute materials and read team descriptions	5 minutes
Initial team type and interaction guesses	3 minutes
Runner and manager negotiation exercise	10 minutes
Collect and enter support relationships in Valustra	10–15 minutes
Review results and debrief	15–20 minutes
Total	48–58 minutes

Facilitator Notes

Keep the first round focused on discovery. If participants ask whether a relationship is officially correct, remind them that they are making a reasoned current-state assessment from limited information.

If a group finishes early, ask its runners to revisit a manager who declined a request and improve the explanation rather than simply asking for a different answer.

If time is tight, enter the dependency network first and postpone detailed discussion of team types and interaction patterns until after the topology is visible.

The most important output is not whether participants reproduce a predetermined answer. It is whether they can explain how responsibilities, support relationships, and interaction choices affect the flow of value through the organization.