We’ve all been there… Third grooming session in a row where you are looking at a seemingly identical bug report related to an internally known and buggy component, screen, or library! To top this off, you have a new feature to be groomed that is dependant on the piece of code.
This time your team suggests that refactoring is a good idea, but the development priorities have to be approved by stakeholders, the Product Owner, or some type of financial gatekeeper.
Here’s how you can convince business to refactor!
Convince yourself before you convince others
This is crucial! Before you can successfully convince someone else, you need to convince yourself.
You can do that by answering simple questions together with your team:
- How time-consuming this will be
- Which exact issues you will solve by refactoring the selected piece of code
- What will be the benefit for the end customer
- Is there any performance gain expected
- Will this decreased amount of errors end users are experiencing
- Will this save you development time in the future
If you have solid answers to the above questions, you have a strong argument for refactoring a certain piece of code.
Don’t use “Refactoring” while negotiating for improvements
Do not use work Refactoring in communicating the improvements to your stakeholders or business drivers!
There are several reasons for this, but to name a few:
- Although refactoring is vitally important to maintaining complex software, Its often described as a result of low-quality development rather than a byproduct of ever-growing business requirements that increase the complexity of the software
- They most likely have heard it before and on several occasions have disapproved of investing in Refactoring
- The definition of Refactoring is – restructure (the source code of an application or piece of software) so as to improve operation without altering functionality. Which is heavily centered around software development, and this leaves an impression that this will mainly benefit the development team, which is not typically the case and a successfully refactored piece of software brings value to the business and end customers.
Instead, emphasize the gain you will provide to the business or end customer. e.g.
- 4 days improving the load speed of…..
- 2 days replacing the current calendar component with an updating one…..
Evaluate the impact and back it up with real data
After you’ve answered most of the above questions and convinced yourself that investing in refactoring this specific module, library, functionality or screens is worth it, it’s time to add some concrete evidence to your case.
I like to prepare a breakdown of specific bugs or tickets that might have not landed in your team’s backlog if your team would have invested time in improving the selected chunk of code.
It would be a simple list of issues or tickets with links to your issue tracking tool.
You can even take the extra step and collect time spent on these tickets or bugs, which will be additionally motivating for the business as time saved = money saved.
Bonus: Present your case to the team
I’ll honest with you, I’ve been in a situation where after spending hours on preparing a solid case I’ve concluded that this doesn’t make sense from a business perspective.
Also, I’ve learned that if you showcase the amount of work you put in for your team to prepare the case, they get more selective over when to blindly blame refactoring for the number of issues or proposing it as a solution to the problems.