In this post, we’re going to explore Scrum and Scrum Teams (note to readers: this also applies to agile teams). Empowering a team takes more than just saying, “You’re empowered.” In Scrum, effective empowerment requires clear boundaries that define which decisions belong to the team and which need oversight. The “three Ws”—“What,” “When,” and “Why”— help Scrum Masters avoid yo-yo management, shifting between granting and retracting autonomy. Using Esther Derby’s well-thought-out decision matrix, this story explores a critical flaw: empowerment without expertise in Scrum implementations.

Stories of well-intentioned but flawed empowerment are more common in Scrum than we might think. The following fictional story illustrates a common pitfall in Scrum implementations—excessive empowerment without the necessary technical expertise. As you read, keep in mind that while this scenario is fictional, the lessons it contains reflect real challenges Scrum teams face in high-stakes, regulated environments. Through this story, we’ll explore why effective empowerment requires both autonomy and domain-specific knowledge. In addition, we’ll discuss how Tactical Feedback Loops could have made all the difference.

Sally is a certified Scrum Master. She leads a team automating roll-up transactions from stablecoin transactions to the Bitcoin network for the EU market. To succeed, her team must comply with Markets in Crypto-Assets (MiCA) regulation. This regulation requires transaction traceability, stablecoin reserve disclosures, and strict reporting. However, Sally’s experience lies in general project management. She lacks the specialized knowledge needed to navigate crypto markets and regulatory compliance.

The team’s Product Owner, Tom, a crypto expert, is also new to leadership. Coming from a traditional project management background, Tom steps back and lets the team self-organize. Sally was brought in to coach Tom in soft skills, helping him build leadership skills while focusing on project management essentials. In practice, however, Tom’s approach becomes overly passive. Tom avoids the tough decisions needed to refine features in such a high-skill domain.

Trusting in “empowerment,” Sally establishes a decision matrix with Tom and the team, defining their boundaries based on the three Ws.

In her first team meeting, Sally outlines her empowerment approach:

• What: The team owns all decisions related to the roll-up feature’s design and implementation.
• When: They should bring up issues that involve changes beyond the project’s scope.
• Why: Sally explains that her goal is to give the team the autonomy they need to innovate, especially in a fast-evolving field like crypto.

With this setup, Sally encourages Tom to step back further, letting the team handle critical decisions on their own. She focuses on fostering open communication, building team cohesion, and emphasizing psychological safety. Sally stays out of daily technical discussions. She trusts the team to address technical details. However, she failed to set up Tactical Feedback Loops that would have provided structured, real-time oversight to help the team stay compliant with regulatory standards.

As the team develops the feature, they design an automated roll-up process that transfers stablecoin transactions to the Bitcoin network. Without regulatory experience, they overlook some critical MiCA compliance requirements, such as proper transaction traceability and stablecoin reserve disclosures.

Alexander, Sally’s colleague who works in compliance, hears about the project’s direction and expresses concerns. He’s worried that the feature might fall short of MiCA standards. He is also overwhelmed with his own workload as he’s trying to get up to speed on the complex new regulations. When he tries to talk to Sally, he’s met with jargon-heavy conversations about agile principles, empowerment, and self-organization. The agile language and empowerment messaging feel convoluted and add to his cognitive load, making it difficult to communicate his concerns clearly.

Without identifying Tactical Feedback Loops that could have provided regular, domain-specific regulatory checks, Alexander’s concerns go unaddressed. A Regulatory Feedback Loop could have gathered signals on compliance issues in real-time, making it easier for Alexander to raise concerns and the team to address them before release.

Alexander, though skeptical, backs off. He’s been told by his boss that “Scrum and agile are the way to go.” So he feels hesitant to push back harder against Sally’s approach. Given their empowerment, he assumes that the team is equipped to handle these technical details, even though he has lingering concerns. Meanwhile, Tom, the Product Owner, remains largely on the sidelines, focused on timelines rather than technical or regulatory nuances.

The team releases the feature and initially sees positive feedback. However, during a compliance audit, the EU regulatory authorities flag the feature for multiple MiCA violations, specifically around transaction traceability and unverified reserves for stablecoins. The company is at risk of heavy fines, an investigation, and a security breach due to mishandled transaction data.

• Regulatory and Financial Fallout: The lack of compliance oversight leads to severe consequences. The company now faces penalties and a damaged reputation, along with costly retrofits to bring the product into regulatory compliance.
• Loss of Credibility in Scrum: The stakeholders, seeing how the release failed to meet standards, question the efficacy of Scrum. Instead of perceiving this failure as a result of poor implementation, they see it as an inherent flaw in Scrum’s structure. The stakeholders associate “empowerment” with carelessness.
• Overcorrection and Red Tape: As a response, leadership implements rigid, bureaucratic controls over all Scrum teams. Team autonomy is severely restricted, and now all projects must undergo regulatory reviews at multiple stages, destroying Scrum’s flexibility and agility. Team morale plummets under the new burdens of heavy oversight.

Sally’s approach—while well-intentioned—was fundamentally flawed due to the lack of necessary domain-specific knowledge. Her reliance on “soft” empowerment led to misalignment, misplaced trust, and a loss of organizational confidence in Scrum. Here’s why her approach failed:

• Passive Product Ownership: By encouraging Tom to “step back,” Sally inadvertently weakened the Product Owner role. Tom’s passive ownership led to unaddressed risks and a failure to shape the feature in alignment with regulatory requirements, compounding the impact of the team’s technical oversights.
• Misaligned Empowerment in High-Stakes Domains: Sally’s decision matrix, while theoretically sound, was ineffective because it lacked the specificity required to handle compliance in crypto markets. Without the technical knowledge needed to provide this specificity, Sally missed an essential oversight. Additionally, the team failed to identify that a Regulatory Tactical Feedback Loop could have provided necessary checks without sacrificing autonomy.
• The Danger of Soft Skills Without Technical Oversight: Sally assumed empowerment alone would enable the team to make the right decisions. In reality, her hands-off approach led to critical regulatory oversights. In fields like crypto, empowerment without embedded technical or regulatory support isn’t just risky—it’s dangerous.
• Scrum’s Credibility as Collateral Damage: Stakeholders, who only saw the negative outcomes, began to associate Scrum with poor oversight and reckless autonomy. Instead of addressing Sally’s lack of technical grounding, they dismissed Scrum as an unsuitable framework for high-stakes work, damaging its perceived value.

In specialized, high-risk fields, a Scrum Master’s role goes beyond coaching soft skills; they must also provide domain-aligned guidance. Empowerment without this technical grounding isn’t just incomplete. It actively compromises the team and the organization. In environments like crypto, “soft” empowerment is simply not enough; a successful Scrum Master needs to understand the regulatory and technical landscape to provide effective and safe leadership.

Moreover, Product Owners in such fields must take active ownership of regulatory and compliance features, with support and clarity from the Scrum Master. Products Owners must not passively assume the team will handle all aspects autonomously. Additionally, integrating Tactical Feedback Loops—such as Compliance and Technical TFLs—could have helped Sally’s team capture essential feedback on regulatory requirements and technical quality in real time, bridging the gap between empowerment and expertise.

In sum, this scenario reveals a critical flaw in many Scrum implementations today: assuming that empowerment through soft skills alone is sufficient for high-skill domains. For effective empowerment, Scrum Masters and Product Owners alike need facilitation skills and domain knowledge. They should actively establish Tactical Feedback Loops to stay informed on domain-specific requirements. Anything less risks turning empowerment from an asset into a fatal flaw.

Avoid the pitfalls of empowerment without expertise by investing in a domain-specific implementation tailored to your industry’s unique demands. Our Industry Recognized Scrum Program (IRSP) is designed to build intrinsic leadership and well-formed teams within your domain. Through a structured 2-3-year cycle, we collaborate to create a self-sustaining program that cultivates domain-specific expertise and strong, aligned leadership—empowering your organization with a team that’s truly built to thrive.

1. Derby, Esther. (2010, October 19). The Three Ws of Empowerment: A Tale of a Yo-Yo Manager. Esther Derby Associates, Inc.
2. Essential Skills for Leadership in Healthcare by QUT Online. Emphasizes the need for both soft and technical skills in healthcare leadership to effectively manage high-stakes environments.
3. The Skills That Make a Great Sports Coach by Practice. Discusses the importance of both technical and interpersonal skills in sports coaching, highlighting that soft skills alone are insufficient for effective team leadership.