Story inspired by sadly too common facts
For once I try a different way to share through a story telling angle.
Let me know in the comments if you like it!
You’re new on the job. You’re really glad to be here.
You’re getting acquainted with everyone from the team.
You discuss with a developer. He greets you warmly:
– Hi! Welcome aboard!
– Thanks a lot! It’s nice to be here. What are you working on?
– I’m spending the day checking if we’re good to upgrade to the last version of PHP.
– Nice! How is it going?
– Well not as good as I wished. It looks like there is still some issues to tackle and I won’t have the time today to finish it.
– Oh… Is that a problem not to finish today? Is the Sprint Review tomorrow?
– No, we’re still in the middle of the Sprint. It’s just that I have already spent a lot of time on this, I can’t allow myself to keep going.
– I’m not sure to understand you. Isn’t upgrading PHP mandatory? I mean, the new version certainly boosts performance and so on, right?
– Sure it is, the speed upgrade is a monster compared to previous PHP versions. We definitely need this, that would ease the load on the servers.
– Great that we agree! But then, why not finishing it? Shouldn’t you finish an already started User Story instead of starting another one?
– Oh, I get what bothers you. It’s not a User Story on the Product Backlog. I’m doing it on the side of the Sprint.
– Why is that?
– This is technical stuff. It does not change anything from the business point of view. We have to handle it on the side otherwise it well never get prioritized.
You ponder the situation for a moment. “Technical stuff” like upgrading PHP and getting better performance does not change anything from the business point of view?
It seems to you that an upgraded performance would translate — at least marginally — as a smoother user experience, plus less load on the server would translate to either lesser server hosting cost or to a more reliable service. Plus, you are pretty sure that the new version also brings a lot more stuff like security patches and more stability.
Now you get to talk with a tester. He seems a little grumpy. You greet him and try to see what’s going on:
– Hi! I’m the new one. Is everything OK?
– Oh, happy to meet you. And no, it’s not OK. I’ve found big issues on the product but nobody’s ever got any time to fix them. I feel like advocating for the fixes is useless. But if I don’t keep track of bugs and push them to be fixed, nobody cares. I think I’m becoming jaded with the situation.
– Wow, thank you for sharing this. That’s really interesting, and I get that’s not easy on you. Could you tell me more? I’m not sure to fully understand why people don’t work on issues that are part of the Sprint Backlog.
– What? Of no, the issues are not part of the Sprint Backlog. The Product Owner prefer to fill the Sprint with new features only. Anyway, that doesn’t really matter: we have always worked that way, with developers keeping time on the side to work on issues.
(mumbling) – Oh boy, it is starting to be a lot of time set on the side to work on everything but the Sprint Backlog…
– What did you just said?
– Well I just talked with a developer and he explained to me that he already set time on the side to work on “technical stuff”. So I’m starting to wonder when developers do work on the Sprint Backlog if they have already set time aside to work on tooling plus issue fixing.
– How could we do otherwise? These items are not changing anything from a business point of view.
– I’m guessing developers are also setting aside time to work on technical debt, aren’t they?
– Yes indeed but I’m not sure it’s working: we are drowning in technical debt.
– How surprising…
– What would you suggest?
– I don’t know, maybe explain to the business people why all these stuff are so important and then let them prioritize accordingly, thus giving you all the required time to do the job well?
– Things don’t work like that here. It’s all about money and ROI. Features bring money. For all the rest, we have to fight… Or do it by ourselves without asking for permission.
You’re starting to see a pattern. It’s all about money. All the rest doesn’t matter.
You pay a visit to the Product Owner. You want to get a complete snapshot of the situation. He seems worried yet happy to meet you:
– Hi there! Happy to have you on the team! How’s everything going so far?
– Quite well, thank you. What were you working on?
– Oh, Marketing just told me that the priorities changed. So now I have to take the changes into account and it’s giving me headache to try not to disrupt the ongoing work with the new priorities.
– I thought you were working in Sprints?
– We do but it just make sense to change work which has not yet started, right?
– Well it depends… But tell me: how come the priorities change that way, so suddenly?
– It’s always like that. They get numbers, they crunch the numbers, and then they come up with a new strategy.
– What kind of numbers?
– Revenue. Money we make from the various types of customers. Money that new features bring in. So they can make educated decisions on what should be done on the product to further improve revenue.
– And how often technical debt items and bugs are making it into the Sprint Backlog? I guess that in this company it is your job to bridge the gap between the development team and Marketing, am I wrong?
– I wouldn’t have said it that way but it’s an interesting way to describe my job. The thing is, once we have committed to work on the Marketing’s requests, there is not much time left to work on anything else.
– Can’t we convince them that it’s really important?
– Sure we can and we did in some occasions. But it’s really hard to get them to understand why it is so important — compared to the revenue that new features bring in. They don’t really get the technical stuff. All they see is money.
Obviously the “Marketing” is the bad guy out there. They don’t get how things really work in the trenches. All they think about is money. Money. Money.
You keep thinking.
What if that was exactly the solution to the problem? Money.
Why can’t we explain in terms of money why it is so important?
Fixing a bug? Sure, the bug is causing lost money. Fixing the bug brings back revenue. That could be compared to the expected revenue of a new feature and we could prioritize one against the other.
Technical debt? If there is a risk that the production crashes unpredictably, we could put a dollar figure on it. What’s the probability of it happening? How much money would we lose if that happen? Take into account lost revenue due to service breakdown, but also take into account the time taken to understand what’s going on, investigate and fix.
There is also the technical debt that just make developers go slower. Why not project an increase of velocity against the average revenue increase? Let’s suppose that if we produce 10% more features then we’ll get 10% more revenue increase than usual.
And so on…
Yes, that requires some additional work to do the math.
It’s basically about making a mini business plan for each item.
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!