Creating Value Over Compromise: The Key to Effective Scrum
Written on
Chapter 1: The Pitfall of Compromise
The concept of compromise often brings me discomfort. Phrases like, "Let's find a middle ground," or "We should aim for a win-win solution," trigger skepticism. In my view, the more compromises you accept, the less value you ultimately generate.
Consider a fictional scenario where a couple is deciding on a restaurant. The woman asks, "Should I wear heels or flats?" The man suggests, "Heels would be more appropriate for a fancy dinner." However, the woman prefers flats for comfort. To avoid a debate, she proposes, "I'll wear one of each!" While this may seem amusing, it highlights how compromises can lead to absurd outcomes.
Although this example may seem far-fetched, it's not uncommon to observe similar situations within Scrum teams. It's surprising how often pointless compromises occur, diluting the team's potential for meaningful outcomes.
Decisions made through compromise may appear straightforward, but they rarely yield substantial results. Let's delve deeper into the drawbacks of compromise and identify strategies to escape this trap.
What Constitutes a Compromise?
Intrigued, I consulted a dictionary to clarify the term "compromise." It defines it as an agreement where involved parties lower their expectations or alter their views to reach a consensus.
In my perspective, compromises are detrimental to Scrum teams. The essence of the definition implies that both sides concede something to reach an agreement. While some suggest that compromises lead to win-win scenarios, I contend that they only result in mediocrity. Both parties may feign contentment with the outcome, despite it not aligning with their true desires.
Take a prevalent scenario in Scrum: the Product Owner prioritizes a feature on the Product Backlog, but the development team estimates it will take two Sprints to complete. If the Product Owner insists on limiting it to one Sprint, a series of trade-offs ensues—often compromising quality and functionality. In the end, everyone pretends to be satisfied, yet no one truly is.
"A compromise is the art of dividing a cake in such a way that everyone believes he has the biggest piece." — Ludwig Erhard
Common Compromises Encountered
Throughout my career, I've faced numerous instances where I could either compromise or engage in conflict. Admittedly, I've compromised more than I should have, often out of a fear of confrontation. It took time for me to realize that such compromises constrained my teams and limited our ability to excel.
My key takeaway: Avoid compromising merely to appease everyone. Instead, strive to create something meaningful, even if it involves difficult discussions.
Here are some frequent compromises I've encountered as a Product Owner:
- Stakeholder Requests: In any organization, you will encounter a multitude of requests from different stakeholders. The simplest way to manage this pressure is to seek compromises that satisfy everyone. However, this approach often leads to a lack of direction, reducing you to an order-taker instead of a proactive Product Owner.
- Roadmap Development: The process of creating roadmaps varies significantly across organizations. Sometimes, Product Owners have little to no input, which is a compromise of their role. When they do have influence, conflicts are inevitable, as stakeholders present conflicting demands. Instead of compromising for an easy way out, it's essential to address these conflicts directly to establish a clear path forward.
- Development Pressure: Developers often face overwhelming pressure to deliver numerous features, even when they recognize the urgent need for system refactoring due to technical debt. Accepting this compromise may lead to unsustainable practices and ultimately jeopardize the system's integrity.
- Design Constraints: When time is limited, design work is often the first casualty. Designers may reluctantly accept compromises that result in subpar designs they are not proud of.
- Fragmented Sprints: How do you approach Sprint planning? Do you set a clear Sprint Goal and allow the team to determine how to achieve it, or do you merely select which tasks fit into the Sprint Backlog? The latter often leads to fragmented Sprints that lack focus, resulting in a mix of features, tech debt, bug fixes, and idle time.
From my observations, compromises often arise from a fear of conflict or the belief that all options carry equal weight. Unfortunately, both scenarios tend to produce suboptimal outcomes.
Shift Focus from Compromise to Commitment
If compromises yield unsatisfactory results, what is the alternative? The answer lies in commitment.
It’s not necessary for everyone to agree, but there must be a shared commitment to the best possible alternative. The best decisions stem from placing ego aside and prioritizing collective goals.
It's crucial to listen to the most knowledgeable person on the subject. For instance, when a designer presents a solution, software engineers might immediately voice concerns about implementation complexities, while Product Owners question the effort involved. This approach stifles collaboration. Instead, engineers and Product Owners should aim to fully understand the designer's proposal and ensure it effectively addresses the intended problem.
Let me clarify: I’m not advocating for blind acceptance of any expert's suggestion. Understanding is essential for making informed commitments, while healthy discussions can lead to better compromises when necessary.
"When confronted with a challenge, the committed heart will search for a solution. The undecided heart searches for an escape." — Andy Andrews
Do you want to contribute to Serious Scrum or engage in meaningful discussions about Scrum?