When organizations try to apply leadership concepts that were developed for simple, predictable environments to an Agile environment, it creates a lot of waste - not to mention frustration, lost opportunity, and a failed Agile adoption.
In this article, we will discuss 3 concepts that work better in simple business problems and not so well in an Agile environment.
Utilization
The idea of keeping people and resources busy to reduce waste sounds logical but backfires in complex environments. Overemphasizing utilization can create inefficiencies.
Imagine a 30-person team divided into three specialized groups: data loaders, processors, and invoice creators. To keep each group busy, the Product Owner ensures their specialized workstreams are constantly filled. However, this focus on maximizing activity diverts attention from delivering the highest-priority work. Flexibility and cross-skilling—rather than rigid specialization—are crucial for addressing what matters most to customers.
This approach also clashes with Conway's Law, which states that system designs mirror organizational structures. For example, if four teams build a compiler, the result is a four-pass compiler—an outcome dictated by their divided workflows rather than customer needs.
Velocity
When we talk about velocity and agile, what we are really talking about is the number of 'points' worth of work that are delivered per Sprint. Which means that velocity is not something that is used in traditional management approaches at all. So why am I bringing it up in this article?
I'm bringing it up because the second a manager learns about the idea of velocity, they often try to use it as a tool to hold team members accountable. And I totally understand why. When we explain velocity to someone who is new to the concept, people often say something along the lines of "it's a measure of how much can be delivered per Sprint", which is true enough, but it's not the whole truth. Velocity is something that is specific to a team. It's used for planning purposes only because velocity is not necessarily the same as value.
Here's why. Scrum Teams who use velocity for planning purposes usually select a point system of some kind. For example, they might use a simple scale of 1 to five, or they might use the Fibonacci series. They make a decision that certain types of Product Backlog items are worth one point, and others are worth two, and so on. Each item that is pulled into a Sprint is assigned a point value based on effort, complexity and uncertainty. Each item that is completed in a Sprint is added up to find the velocity for that Sprint. Over time, the Scrum Team learns the total point values that they typically complete in each Sprint.
Velocity cannot be compared between two Scrum Teams, because what is worth one point for one team may be assigned a different point value for another team. Teams may also have different levels of skills and different goals.
Not only that, but even when looking at the same team over time, a higher velocity does not necessarily equate to higher value delivered. Maybe the team overestimated the work, or maybe the work that was delivered didn't actually improve customer outcomes.
Sign-Off on Requirements
Sign-offs are often used as a control mechanism to limit changes. The logic seems sound: lock down requirements to avoid disruptions later. But Agile teams welcome change—even late in development. In fact, that’s one of the core principles of Agile. This is why Scrum uses a Product Backlog instead of a static requirements document.
The Product Backlog is dynamic. It evolves as we learn more about what the product needs to deliver value. The Product Owner continuously updates and reorders the Product Backlog based on customer feedback, stakeholder input, and market changes. Unlike a requirements document, which needs signatures to make changes official, the Product Backlog requires no formal sign-offs. The Product Owner has the final say on its content and priorities.
This flexibility is crucial in complex environments. Imagine a team working with a locked-down requirements document. When new information emerges—whether it's a competitor's move, a regulatory change, or unexpected customer feedback—the team faces two options: stick with outdated requirements or go through a cumbersome sign-off process to make changes. Either way, opportunities are lost, and the team’s ability to deliver value is compromised.
Sign-offs can also create tension and delays. When multiple stakeholders need to agree before work can move forward, disagreements often arise, slowing progress. In contrast, Agile empowers the Product Owner to act as the single authority for the Product Backlog, enabling swift adjustments that keep the team aligned with delivering the most value.
This approach might seem risky to those accustomed to rigid controls, but it’s the opposite. By removing bureaucratic bottlenecks, Agile teams stay nimble, reduce waste, and focus on delivering outcomes that matter to customers. Sign-offs may work in simple environments with predictable outputs, but in Agile, they’re more of a hindrance than a help.
Conclusion
In Agile environments, success depends on adaptability, prioritization, and focusing on outcomes over outdated metrics or rigid processes. By rethinking traditional concepts like utilization, velocity, and sign-offs, organizations can avoid waste and fully realize the value of Agile.
To learn more about Scrum, signup for Rebel Scrum's upcoming Applying Professional Scrum course. Are you an Agile leader? Signup for our upcoming Professional Agile Leadership class.