Benefits of NOT Following the Practice
Now to set the proper tone, this is a reminder that we should generally be following the practices. They help us avoid the common gaps or problems which they were developed to address. But in certain circumstances, we can benefit from intentionally choosing a different path.
Benefit 1: Learning
One such moment is in learning. When you are practicing or allowing someone to learn, it can be valuable for students to experience the lessons firsthand. "The School of Hard Knocks" is one of life’s first teachers. As long as you recognize that you are setting yourself up for potential pain down the road, you can benefit from intentionally choosing an alternative path.
This experiential learning can be both good and bad. For personal practice, intentionally taking the lesson this way can have a relatively low cost and low risk. But, you are opening a can of worms if you allow these practices into production without a roadmap for their migration! You’re trading time and some pain for a deeper understanding of your organization and the value that ‘Best Current Practices’ have.
Benefit 2: Optimizing for Cost
Building on the idea of letting a "not-best current practice" into production, we can see the second reason for not pursuing the best: optimizing for cost. Pursuing the best possible implementation, especially when attempting to build a new product, is choosing to take on some considerable business risk.
In scenarios where you do not know that the product will be profitable, choosing a potentially expensive way to develop or maintain architecture commits you to a hard road. In this circumstance, you don’t know there is a market for the product yet. So building the product with a gold-plated cupholder probably isn’t the best way to spend the company’s money or time right now.
Instead, if you favor a true minimum viable product, you can choose to cut a cheaper, functional test version of your product first. This lets you avoid paying for expensive startup costs while learning about the market fit, and gain the experience your team and organization may need to support a "best current practice" approach as you scale the application up.
As we alluded to in the previous post, this path has its own risks. Pablo Picasso is credited with saying, “Learn the rules like a pro, so you can break them like an artist.” While pursuing the economic reason for not applying a "best current practice", you must be extremely careful not to shoot yourself in the foot!
The challenge is to NOT build yourself into a hole. You need to prepare your solution in ways that enable growth at a given pace for the future. Just keep in mind that pivoting as you learn more, potentially purchases you the application more cheaply, than jumping to the best option first. This is not always the case, but with careful consideration savings in start-up, and value-prop validation can make or break a product proposal.
Benefit 3: Dealing With People
This allows us now to discuss a third, final reason for differing from the industry's "best current practices". That is to intentionally choose certain design shortcomings from reasons that have nothing to do with money but instead deal with people.
It is common knowledge that many agile transformations are fraught with hardship. And as a result of these stormy seas, many fail. Consider what it is like for an organization taking its first steps in an agile transformation. Their fundamental outlook on the work may literally prevent them from understanding and effectively applying certain agile practices entirely.
For example, if you start with a culture that is commanding and controlling, moving towards a trusting culture can be immensely difficult! Going from a directive form of leadership towards one that delegates cannot be done in a single step! The process has to account for the people who will practice it. In a command and control culture, the fundamental skills that allow delegation to work are unpracticed or potentially outright missing, because the people in the organization have never had to use those skills.
So in a sense, the third reason to differ from best current practices is a pragmatic one. It is about people. You do not want to apply a specific process if the people who must practice it are missing the necessary skills. We don’t let toddlers run around onboard a boat without life vests because they lack the core skill of swimming! Running around on the deck where it's slippery could land them in an emergency. That is where the skill of swimming is vital. So, we require the life vest and we should also provide some instructions about not running on the slippery deck.
The benefits of not following the "best current practice" can appear when theory meets reality. We may have to adjust our prescribed process to account for how feasible it is in the current organization. This needs to account for their level of skill, and the organization's maturity in certain capabilities.
Software is written to help deliver value to people. The way we deliver that software, our practices, and our patterns impact how well we can do that. Over time, we’ve learned good patterns through hard use and sharing our stories. So, building on the wisdom of those who came before can really help us accelerate our pace to the end goal: value to real people.
But if we attempt to follow a pattern, we need to carefully consider not just whether the pattern addresses our evident technical challenges. We must also bear in mind whether and how the pattern can be applied to the organization. We must enable the people who will practice it to succeed. And sometimes that means starting with the not-best, so we can build up our skills, still deliver value, and continually reach for the best current practices.
