If you work on a self-organized empowered agile team (Scrum or otherwise) and therefore you don’t need to sell change, then you can skip this post. You’re already in the place where you are empowered to fix problems in the code base (your white whale, that we’ve been spending the last four posts talking about).
How do you know if you’re in a self-organized empowered agile team?
If this white whale we’ve been tracking is on your backlog (and it should be), then talk to the Product Owner and team about moving it up into the next sprint.
If there’s actual trust and agency there, then you’ll be able to work on it, just on saying, “This is causing us pain and we need to fix it.”
If that doesn’t work for you, then I am sorry to be the one to tell you this, but you’re probably not on a self-organized empowered agile team; even if your organization uses one or more of those words mashed together.
That’s ok, because you can still sell change, even if you aren’t empowered to make change.
So, you’ve found this part of the codebase that is your white whale, you’ve used metrics to determine how bad it really is objectively; and you’ve ascertained whether it’s a module that affects the customer, or just the health of the system (“just”, as if that’s any less important), and you want to dive in and fix it. There’s just one teensy, tiny thing you have to do before that.
You’ve got to sell that change.
In a business that understands the value of being able to move nimbly, you wouldn’t have to sell very hard, if at all; but unfortunately not all businesses value the expertise software developers bring to the table. There is a if it works, ship it mentality that causes long-term problems for software projects.
What is the outcome your business will see if they let you spend x time on this?
Will they be able to see features and changes sooner?
Will this change open up new features the business/customer has been wanting, but unable to receive due to architectural limitations?
Will the system be faster?
Will developer time maintaining that part of the system (or the system in general) go down due to this change?
Will the team feel better when this part of the system is better? Will it improve morale?
It’s important to speak in terms that whomever you’re selling this change to cares about.
For instance, for business people, there are five major reasons to make change:
1. Increase Revenue
2. Lower Costs
3. acquire new customers
4. Retain Customers
5. Expand into new Markets
Which one (or more) of those five will your fixes enable? How will it enable them?
It’s also important to understand the person or people you’re selling this change to. They’re thinking about these things; but more importantly, they have a set of goals for this quarter that are on their mind. What are those goals? If you haven’t talked to them about those goals, you’ll want to, and you’ll want to see if your changes help further those goals.
You’re not trying to sell just anyone on your change — you want to sell a specific person. In your organization, you know who this is, whether they’re a shadow leader or the titled leader. They’re the one you need to sell your change on. There’s a saying in Basketball Play the man, not the ball. Basically that means that the mechanics of basketball only get you so far; but to actually win, you have to know who you’re playing, and how they play.
This is true in every aspect of your life. This information shouldn’t be used for a zero-sum win; but rather finding a way to win that lifts everyone up. To do that, you have to understand what drives the person you’re talking to and trying to sell the change on.
Now, there’s no way for me to do justice to the art of selling in an email or blog post; literal volumes have been written on the subject; but the point of saying this is that even for software developers: we must sell our changes to other humans in order to make things better.
We as developers like to think of software development as a purely technical task; but that’s not the case. Of course in an ideal world we’d be able to pursue positive change in our codebase because we need it as developers; but as long as the world isn’t ideal and you’re not in a self-organized empowered agile team, you’ll have to sell this change to someone.
Next time we’ll talk about what to do once you’ve sold the change.