Become a Business Partner and Stop Begging for Refactoring
When we, developers, earn enough trust from business people, we become their business partners. As such we enjoy a lot more freedom to refactor.
A team I was in a few years ago had worked hard to earn the trust of business people. In a retrospective, we discussed about our failure to work on the improvements we had agreed to. We decided that we would dedicate 20% of our story points to improvements and refactoring. Better yet, we would start the sprint with these, before working on features! Here’s what our sponsor said:
As long you are sure it’s the best thing for the product, I trust you.
This is the kind of autonomy business partners can enjoy.
This the 14th post in a series about how to get sponsorship for large scale refactoring. If you haven’t already, I recommend you start from the beginning.
Becoming a business partner
All the tricks and advices from the previous posts should lead to the following outcomes:
- Time for refactoring
- Trust from business people
With time, it establishes a solid business partnership. This means that business people will acknowledge that we know what we are talking about. When we say we need to refactor something, they’ll let us do without much protest.
Once we reach this level of trust with business people, a new world of practices opens. Here are few I’ve used or heard people talk about.
Negotiate Technical Debt Interests
My friend Xavier told me once that he had discussed how to deal with technical debt with a Scrum coach. The coach looked puzzled, and asked why we did not simply negotiate interests up front! When someone asks for a shortcut, we should explicit the recurring cost to fix it.
Here’s an example: suppose we are asked to deliver a 8 points story in half the time for a sales show. We could say OK provided we’d also pre-plan 2 story points refactoring tasks for the next 4 sprints.
Agree on a decentralized decision rules
Boing had weight issues when designing the 777. Instead of a weight reduction project, management issued a decentralized decision rule.
Any engineer could swap a pound weight reduction with an $300 increase in production cost. (The Principles of Product Development Flow by Donald G. Reinertsen)
Pretty soon, the plane had lost enough weight to be viable. Here’s another example:
If we speed up the build of 1 minute in less than 16 hours of work, we should do it.
If you are wondering how to create such rules, have a look at this post. For yet another example, check this bug definition that came out of an improvement kata.
These rules are powerful because they are agreed to once, but used many times. They also don’t involve any management escalation or delay. Only high level of trust with business people can lead to such rules.
💡 Decentralized decision rules are agreed once, but used many times, without involving management.
Negotiate a refactoring bandwidth
Negotiating refactoring on a task by task basis takes a lot of time. Once we’ve become business partners, we can negotiate a permanent refactoring bandwidth.
💡 Becoming a business partner lets developers have a permanent refactoring bandwidth.
For example, in her talk What ever happened to being eXtreme? Rachel Davies explains how her long lived XP team was doing that. At any moment, among 7 developers, 3 were working on technical (or refactoring) tasks.
Rachel Davies - What Ever Happened to Being eXtreme? from NEWCRAFTS Conferences on Vimeo.
As with decentralized rules of thumb, the main advantage is that negotiation is done once and for all.
Almost there !
This was the 14th post in a series about how to get sponsorship for large scale refactoring. In the next post, I’ll dig into what we must be careful about to remain business partners.
Leave a comment