MGT 647 Module 5 Distributed Decisions Example

Decide Where the Information Is: Decision Rights for Lakeshore Mutual's Agile Teams

Student Name

Master of Business Administration, Aspen University

MGT 647: Project Management Integration Framework

Instructor Name

Month Day, Year

Decide Where the Information Is: Decision Rights for Lakeshore Mutual's Agile Teams

Lakeshore Mutual's claims app team has learned Scrum and begun to share leadership. Yet a review of its last quarter found that speed still stalled outside the team. A feature letting policyholders upload repair estimates was ready in one sprint and then waited nineteen days for sign-off from the claims director, the security office and the architecture board. None of the three changed it. This paper designs decision rights so that the teams can decide what they are best placed to decide, while the company keeps control of what matters most.

Where Decisions Stall

A month of tracking showed that the claims app and support teams together waited on forty-one decisions from outside the team. The median wait was six working days. Most of the decisions concerned changes the teams understood better than the approvers did, such as screen designs, minor data fields and the order of backlog items. The pattern is common in organizations adopting Agile: teams move in two-week cycles while approvals follow monthly committee calendars.

Authority and Information

Aghion and Tirole (1997) distinguished formal authority, the right to make a decision, from real authority, effective control over the decision. A manager with formal authority who lacks information will often simply approve what a better-informed subordinate proposes, so real authority already rests with the subordinate. Their model showed that delegating formal authority increases the subordinate's initiative, because effort to gather information is more worthwhile when one's choices will stand, but costs the principal some control. Delegation therefore makes most sense when the subordinate's information is good, the decision matters less to the principal than the subordinate's initiative, and the two parties' interests are reasonably aligned.

The claims app approvals fit that description. The claims director signed screen changes she had not tested, relying on the product owner's judgment. Formal authority sat with her, real authority with the team. Moving formal authority to the team would remove the wait without losing much control.

The Challenges of Shared Decisions

Moe et al. (2012) studied shared decision making in Agile teams across several companies. They found challenges at strategic, tactical and operational levels: aligning the team's day-to-day decisions with strategic priorities set elsewhere, balancing team autonomy against the needs of other teams and the wider organization, and sustaining shared commitment to decisions once made. Teams sometimes made decisions that conflicted with others' because no one connected the levels.

Drury et al. (2012) surveyed and interviewed Agile practitioners about decisions made in iteration planning, execution, review and retrospectives. They identified six obstacles: unwillingness to commit to decisions, conflicting priorities, unstable resource availability, lack of implementation of decisions, lack of ownership and lack of empowerment. The last two especially concern Lakeshore, where team members unused to deciding may defer to whoever seems senior.

Decision Rights by Level

Guardrails

Guardrails replace approvals with agreed limits. A team may release without sign-off if the release passes automated security checks, makes no change to how customer data is stored or shared and stays within the approved architecture. Changes outside these limits go to the relevant office, which commits to answer within two working days. Each team also keeps a short decision log, so that anyone can see what was decided, by whom and why, which addresses the commitment and ownership obstacles Drury and colleagues described.

Information Must Move Too

Aghion and Tirole's model implies that decision rights work only where the decider has the information. Moving rights to teams therefore means moving information to them. The claims app team will receive the same weekly claims volume, cycle time and complaint data the claims director sees, and the security office will publish its standards as a checklist the team can apply itself. Without that, delegated decisions would be made blind, and the obvious response would be to pull them back up.

Helping Teams Decide

Teams unused to deciding need methods, not only permission. The Scrum Master will introduce two simple practices. For decisions inside a sprint, the team uses consent: a proposal stands unless someone has a reasoned objection, which avoids waiting for full agreement. For larger operational decisions, such as a new technical approach, one member writes a one-page proposal, the team discusses it at a set time and the decision and its reasons go into the decision log. These address the unwillingness to commit and lack of ownership that Drury and colleagues found.

Escalation

When a team cannot agree, or a decision crosses another team's area, the product owners of the affected teams meet within two days. If they cannot resolve it, the claims director decides. Escalations are logged with their outcome, and any type of decision that escalates more than twice a quarter is reviewed, since repeated escalation usually means a decision right is unclear or sits at the wrong level.

Reviewing the Design

The arrangement will be reviewed after one quarter using three measures: the number of decisions waiting outside teams, the median wait and the number of decisions later reversed. A rise in reversals would suggest that some rights moved too far or too fast. A fall in waiting with no rise in reversals would support moving further, for example giving teams authority over small vendor tools under a lower spending limit.

Conclusion

Aghion and Tirole explain why authority should follow information, and Moe, Aurum and Dybå and Drury, Conboy and Power show where shared decisions go wrong. A table of rights by level, guardrails in place of approvals and a quick escalation path let Lakeshore's teams decide at the pace they work.

References

Aghion, P., & Tirole, J. (1997). Formal and real authority in organizations. Journal of Political Economy, 105(1), 1-29. https://doi.org/10.1086/262063

Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in Agile software development teams. Journal of Systems and Software, 85(6), 1239-1254. https://doi.org/10.1016/j.jss.2012.01.058

Moe, N. B., Aurum, A., & Dybå, T. (2012). Challenges of shared decision-making: A multiple case study of agile software development. Information and Software Technology, 54(8), 853-865. https://doi.org/10.1016/j.infsof.2011.11.006