Paying Someone to do Our Homework: The Risk of Mediocrity with Agile Frameworks
Why Adopting Agile Frameworks is not a Risk-Free Endeavor
There is a conflict at the heart of many software-development organizations. Managers demand predictability and the certainty it provides. At the same time, software organizations are in the invention business. Wait, we’re in the invention business? Why? Because every line of code written means we’re inventing something no one has ever done before. If someone else has already done it, we would simply buy what’s been built and move on to the next thing.
The conflict arises because invention’s inescapable characteristic is that it’s unpredictable. We simply can’t know how long it will take to invent something, no matter how badly we want to know and how much pressure management applies. If this seems doubtful, then we only need to insert ourselves back in time before a given invention was created and ask how long it will take to invent it. For example, before we understood what we were trying to invent, ask how long it would take to do any of the following:
- Convert candles into electric light bulbs and discover electricity along the way.
- Unlock the secret of powered flight.
- Convert horse-drawn carriages into automobiles by discovering that we could exploit petroleum to invent the internal-combustion engine.
- Discover that the universe is expanding.
- Invent the programmable computer.
- Create the numeric concept of zero.
The answer to all of the above items is simple: We know now but couldn’t know then. Our conflict arises from this inability to know beforehand while simultaneously requiring that we do. It was ever thus and still is today.
This conflict and its attendant uncertainty are typically anathemas to senior leadership because most businesses demand predictability. Management must therefore find a way to provide predictability if they want to keep their jobs.
Enter Agile frameworks.
Agile frameworks are popular because they offer the siren song of predictability, taking away the discomfort and anxiety that come from uncertainty. Their proponents often claim success is achievable by following the path set forth in their process, providing the ends by using a prescribed means.
A prescribed means seems beneficial if it provides a simple solution to the complex problem of managing software and gives us predictability. But it can be argued that the real value isn’t in the ends. It’s in the means instead. As frightening and uncertain as they are, the means provide us with the opportunity to learn and discover what software approaches work best for our particular situation. Out of that discovery might come something highly useful to us, something that we wouldn’t discover if our means were restricted by rigid adherence to an Agile framework.
The problem lies not necessarily in the frameworks themselves but in their dogmatic application. By refusing to stray from their rigid boundaries, we hobble our ability to discover and learn what works better for us. How often have you heard a manager or framework proponent say something like this?
“If you aren’t doing story points, then you aren’t being Agile.”
“If you don’t have a scrum of scrums, then you aren’t doing enterprise Agile.”
“Our Agile framework is what gives us predictability.”
We could perhaps accept these admonitions at face value. Still, it’s illustrative to note that the first line of the Agile Manifesto says, “We are uncovering better ways of developing software by doing it and helping others do it.” It does not say, “We have discovered a better way of developing software, and here is how to do it.” The Manifesto makes clear that the act of discovery is central to the process of developing software in an Agile manner.
Are the frameworks effective? Many people use them and appear to be successful in doing so. But it’s a bit simplistic, and perhaps misleading, to ask only if they’re effective. A better question is this: Is it more effective to adhere rigidly to a framework or to embrace the discovery process and learn what might work even better for our situation?
In effect, frameworks offer a shortcut to the destination. We skip all the hard work and diligence involved in using the means to discover what’s best for our particular situation. It’s arguably akin to paying someone to do our homework. There is perhaps a benefit in the time saved by following a predefined path instead of creating our own. The downside is that we might wind up with something less than optimal, effectively settling for what amounts to mediocrity.
It comes down to this: Do we settle for what we believe works for everyone else, or do we discover what works best for us?
Let’s consider two approaches. First, we could avoid all frameworks and embrace discovery instead. This can be an extremely unnerving method because we don’t know if we will discover anything of use until we have spent the money on discovery. There’s uncertainty rearing its ugly head again, but such is the nature of discovery. It takes considerable courage to plunge into it.
Alternatively, we could embrace a framework but use discovery to modify it. We make a conscious effort to avoid becoming dogmatic about it. Instead of dogma, we choose to experiment and discover as we go. However, this is harder than it seems because frameworks typically come with roles and policies that those roles are responsible for enforcing. And try as we might to avoid it, it’s inevitable that once a policy is adopted, a constituency is born whose livelihood depends on perpetuating the policy. That constituency will typically fight to protect its domain, whether it benefits the larger purposes of the organization or not.
Which should we choose? There’s no easy answer.
If we choose pure discovery, we may spend time and money on something little better than a framework.
If we take the framework approach and it turns out to be the optimal solution, we will save money and time by adopting it. Of course, the only way to know if the framework is the optimal choice is first to perform a discovery process to see what else might work better. So it’s kind of a Catch-22. You can only know if a framework will save time and money by first spending the time and money to see if it’s the best approach.
Given that, we’re faced with a choice. Spend money on discovery or risk settling for mediocrity. Each organization must make this determination on its own.
Ultimately, it can be argued that there’s no such thing as certainty in our software world. There is only uncertainty and our false belief in certainty. We probably need to get into a different business if we want certainty and predictability. Once we reject framework dogma and accept uncertainty in its place (however grudgingly), we open ourselves to discovery and might find what works best for us, framework or not.
