Toggle Menu

Insights > NextUp Solutions > How to Get Buy-in for Refactoring

How to Get Buy-in for Refactoring

A good Product Owner is driven to maximize value. Oftentimes, that drive supersedes the need to refactor: update code, complete tech debt, and upskill employees. In my experience, many Product Owners hear the word “refactoring” and assume the development team is trying to get out of value-add work and instead “play around with code” without […]

By

August 16, 2022

A good Product Owner is driven to maximize value. Oftentimes, that drive supersedes the need to refactor: update code, complete tech debt, and upskill employees. In my experience, many Product Owners hear the word “refactoring” and assume the development team is trying to get out of value-add work and instead “play around with code” without adding real value.

There are two types of work: work that leads to direct customer value (DCV) and work that leads to indirect customer value (ICV). ICV work, like maintaining the current system, investing in tools, research, and employee training maximizes your ability to deliver direct customer products faster, cheaper, and better.

You can only run a system so long before you must allocate time for ICV work. Otherwise, you jeopardize your ability to continually deliver value. Any type of work, be it physical or mental, requires continual upkeep on the existing infrastructure and the people who maintain said infrastructure.

Refactoring: A Manufacturing Tale

Imagine you create and sell custom wood creations at your wood-working shop. You have limited capacity and money. So, you run your shop at full capacity, only allowing time for new creations. Before long, the equipment you use will become less effective. Soon, the new types of requests from your customers will outpace your current tool capabilities and your employees’ skills. If you don’t allocate time to sharpen the saws, research, potentially acquire new tools, upskill your employees, your operation will come to a halt. You will no longer be able to sell quality goods to your customers.

Refactoring: A Software Development Tale

If you own a software development company, imagine only allocating time for your team to add new features. Eventually, the code base will become brittle and difficult to manage. As a result, new features will continue to take more time to develop. The quality of finished work will also decrease. Future opportunities will be limited if you don’t invest in new technologies. Without allocating time for upskilling and cross-training employees, you will lose your market edge. Without time to innovate and improve, your team members will become disenchanted and find different jobs that leverage their full potential. People aren’t interchangeable parts. When you lose a good employee, you not only lose their coding capabilities, but you also lose their knowledge about your product which took significant time and money to acquire.

Prioritizing Work Types

When people spend time on a task, whatever that task is, it costs your organization money. Employees are paid regardless of what they spend their time on. Time is the only constant. There are only so many hours in a day. A smart Product Owner leverages time to their competitive advantage. They prioritize work based on expected value add, cost of implementation, risk avoidance, and opportunity enablement. They discard potential work items when they discover the cost of implementation is higher than the expected return on investment. A smart Product Owner incorporates DCV work in their backlog as well as ICV work and prioritizes each according to sound financial logic.

Product Owners focus on customer requests and customer-centric features. To fully understand the cost/benefit of indirect customer work, they must rely on the people who implement features. A development team shouldn’t be working on indirect customer work without a sound business case. Nobody wants a development team who is primarily focused on “playing-around-with-code” for their own benefit. They, too, need to consider the cost and benefit to the organization for this type of work. When the development team and the Product Owner align to the overarching goal, they negotiate, plan for, and implement value-add DCV work and ICV work in a strategic cadence.

Capacity Allocation For ICV

The amount of ICV going through your system should usually be substantially less than the amount of DCV. Start by allotting 15-20 percent capacity for ICV.

In Scrum:

In Kanban:

Note that the percent of work you allocate for ICV will vary based on the cost of delay. For example, if you are scrambling to get a release out in the next two weeks, it may not be the optimum time to include ICV work. If the DCV isn’t delivered on time, the cost of delay could be high. Conversely, if you have delayed ICV work for too long, you may need to allocate significantly more time for ICV versus DCV.

The Conclusion on Refactoring

Not carving out time for employees to “sharpen the saw” will eventually lead to failure. Spending too much time sharpening the saw and not enough time delivering value will also lead to failure. Find the right balance of time to allocate to DCV and ICV and incorporate both continuously. Get buy-in by analyzing the data. Weigh the costs and benefits of DCV and ICV work and negotiate capacity allocation for each type of work.

Consider starting with our Certified ScrumMaster or Team Kanban Practitioner trainings!

Category: NextUp Solutions

Tags: