Scrum, day 45: organizational constraints

Today's objective: explain why a recurring delivery problem may require an organizational decision, then propose a specific change with visible consequences.

Read alongside: Mastering Professional Scrum, chapter 7, focusing on organizational evolution and developing people and teams. Allow roughly five minutes for this companion, plus the book reading.

A team improvement reaches a boundary

The fictional ShiftSwap team has improved refinement, reduced started work, and made its quality standard clearer. Yet operational verification still waits for a specialist assigned across several unrelated initiatives. The specialist is capable and helpful, but their schedule is controlled by competing priorities outside the team.

The Developers could make their request earlier or improve the information they provide. Those local changes may help. They cannot guarantee the specialist's availability when every initiative receives the same urgent priority.

The team has reached a boundary where its effectiveness depends on an organizational choice. Recognizing that boundary should lead to a more precise conversation, not a general complaint that management must “be more agile.”

Describe the recurring mechanism

Radu and the Developers trace several recent delays. Each product change needed a short operational check. Requests entered a shared queue, priorities changed frequently, and the team could not predict when feedback would arrive.

The consequence was late discovery and repeated replanning. The problem was not simply that one person was slow. Their allocation and the surrounding priority system made timely collaboration difficult.

This account helps the organization consider remedies at the right level. Hiring another specialist may help if capacity is genuinely insufficient. It may not solve conflicting priorities, unclear request criteria, or a structure that creates unnecessary dependence on specialist approval.

Understand the reason for the arrangement

The organization shares the specialist because their expertise is scarce and several products need it. That is a real concern. Permanently assigning them to ShiftSwap might improve one team's work while making other important work harder.

The conversation should therefore examine the whole effect. Which requests truly need specialist judgment? Which checks could become part of ordinary team capability? Could predictable collaboration windows help? Could tools or clearer standards reduce repeated consultation?

Understanding the current arrangement's purpose makes the proposal more credible. The team is asking for a better way to meet both product and organizational needs, rather than treating its own local queue as the only consequence that matters.

Offer a bounded experiment

The team proposes a trial: for the next two Sprints, the specialist joins a short discussion of relevant upcoming changes and pairs on one recurring verification task with a Developer. The organization protects that time and makes any displaced work visible.

The expected effects are earlier identification of operational concerns and growing capability within the team. The trial does not assume that every specialist task can be transferred or that ShiftSwap deserves unlimited priority.

The organization can inspect waiting time, late discoveries, the specialist's workload, and consequences for other teams. This creates a basis for deciding whether the arrangement should continue or change.

Examine incentives as well as structure

Suppose the specialist is evaluated mainly on the number of individual requests closed. Spending time teaching another Developer may reduce that count temporarily, even if it improves the organization's future capability.

The trial then conflicts with the reward system. Asking the specialist to collaborate more while penalizing the time required sends contradictory signals. A manager may need to recognize the learning contribution explicitly and adjust expectations.

Similar contradictions appear when Developers are rewarded for individual task output while expected to help others finish, or when Product Owners are judged by adherence to a fixed feature list while expected to adapt to evidence. Local behavior often reflects the conditions people are given.

Keep the proposal connected to a product consequence

An organizational discussion can quickly expand into a debate about reporting lines and preferred methods. ShiftSwap should keep the original consequence visible: important operational information arrives too late to support dependable delivery.

That does not mean structural changes are irrelevant. It means the proposed structure should be evaluated by whether it improves the work and preserves other important needs. Renaming a department or changing a chart is not evidence that the constraint has been removed.

The team can describe the decision required, the people affected, and the evidence it will inspect. This gives organizational leaders a concrete opportunity to help rather than a request to endorse an abstract philosophy.

Recognize what the team can still do

While the wider decision is pending, the Developers can improve request clarity, expose dependencies in their forecast, and avoid starting work based on assumed specialist availability. They can also identify safe learning opportunities within current boundaries.

These actions do not eliminate the structural problem. They make its effects more manageable and provide better evidence for the organizational conversation. The team should avoid both extremes: pretending it can solve everything internally and treating the external constraint as a reason to stop improving anything.

The Scrum Guide's description of the Scrum Team includes organizational empowerment to manage the work. That condition needs practical support through allocation, authority, and capability.

Prepare a concrete request

Choose a recurring problem that persists despite local adjustments. Describe the mechanism, the product consequence, and the organizational decision that might change it.

Propose a limited trial and identify who else could be affected. Include evidence that would show both benefit and unwanted effects. State what the team can improve immediately while the wider decision is considered.

Reflection: is your proposed remedy changing the condition that produces the problem, or asking people to work harder inside the same condition?

Next, day 46 examines how people respond when these consequences become visible.