I created an Epic in Jura the other day, and there was a field for “Created Customer Value”, that would accept a value less than 100 trillion. So now we’ve got a 99 trillion customer value feature. Bam!
So much emphasis on ROI, but we have to remember the Amazon employees who needed to skip toilet breaks to fill their quota and pee into a bottle. It doesn't have to be always so narrowly focused on ROI. Maybe there is a wiggle room for human matters?
I think a lot of consternation comes from priority being set by the product team, and not from the engineering team. The priorities need to satisfy both parties.
I'm very much a fan of roadmaps, planning, and delivering big product changes quickly, but I'm also pretty aggressive about carving out time for things that are going to improve velocity overall. As an example, right now, one of my team's highest priorities is to remove a bunch of dependencies from local deployment and CI so that a developer can run the whole stack with just "go run main.go" and so that CI tests more of our stack. (Our team runs managed Kubernetes clusters with our company's software stack installed in it, so it's very easy to get into the state where you need accounts with 3 cloud providers and 25 secrets to do anything... and it's a big productivity killer to require all of those for every change. And it means that a lot of test coverage is manual, which is an amazing velocity killer.) No product manager would rate that as the top product priority, but as the engineering TL I know it's a productivity multiplier -- reduce development cycle times and get more story points out of each sprint going forward. An engineer can test 100 of their tweaks per day, instead of 10.
Another option is to schedule slack times into your sprints. Ruthlessly prioritize, figure out how many story points your team can do per sprint, and fill it up. But, if your team typically does 100 story points per week, only take on 80 story points of work, and use the other 20% for "things that come up" or "things that engineers feel like doing". I haven't actually done this, but I plan to in the future, so I don't know what the right number is. But people always feel bad when 100% of their work is chosen for them; so build in time to let people choose their own work. The business gets what they want, the team gets what they want, and everyone is happy.
Finally, slightly off-topic... this is my guiding light for anything related to planning: https://apenwarr.ca/log/20171213 I worked for the author, and our team got a lot of stuff done -- we hit our OKRs every quarter, people believed us when we said "we'll do that next quarter", and we had a lot of fun making a great product. Planning is not bad, planning is great. Don't let it scare you away; planning doesn't mean "the PMs control your life". It just means you know what goal you're working towards.
The way I read it, it was totally independent of human factors, not excluding them. Ruthless prioritisation in this context means to focus your decisions of what to focus on around delivery of value to customers. You definitely have wiggle room for human factors.
Including those factors in your decision making is only way this can work, otherwise you will get poor quality at the end of it. At least that has been my experience in the context of software delivery.
Ugh. This mentality is fine when you want to ship an MVP but it's absolutely poisonous to the team and the project if you hold on to it. You need some slack for people to address the problems they think need solving without needing to justify why they're solving it. From a team perspective, it helps prevent burnout and encourages development, and from a project perspective it's essential to preventing management-driven tunnel vision by allowing the team to explore and prove out things that management doesn't understand yet. I've seen a lot of data-driven projects starve because of a fear of collecting new data, and it's totally invisible to management because they're hitting the KPIs they set for themselves.
Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.
Yup, it's precisely this narrow minded view of software development that's churning out more and more shitty software.
Maintenance is NEVER prioritized by anyone in management. They think "What, we put in the bug fixes, what more do you want!" but they never put in the "Hey, if we reorganize some code here, things will be a lot faster and easier to extend".
Devs on the ground can consistently see "Hey, this system right here, is a major issue that'll cause us a bunch of problems in the future" and that does not matter. Because, quantifying how much money is lost by not fixing the issue is really hard to do. You can't reliably say "If I spent 10 hours fixing this, I'd save 100 hours implementing new features".
It's this sort of short sighted vision that has dev teams running on 20 year old software with a bunch of known CVEs, handcuffed because the answer to "What will upgrading to the latest bring us?" is almost always "some bugs in transition but mostly piece of mind that we won't be vulnerable to a cyber attack."
Oh I wish avoiding code cleanup was the worst of it. I've seen people totally ignore the most easily fixable bugs. Everyone knew what they were and how to fix them, but no one wants to be that person who spent time working on the bug that was only affecting 5% of users if it meant that any of the bugs that were affecting 95% of users were even a day later. Ignoring the ROI, the fact you even need to have that conversation adds cost.
Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.
10 comments
[ 3.5 ms ] story [ 37.7 ms ] threadI'm very much a fan of roadmaps, planning, and delivering big product changes quickly, but I'm also pretty aggressive about carving out time for things that are going to improve velocity overall. As an example, right now, one of my team's highest priorities is to remove a bunch of dependencies from local deployment and CI so that a developer can run the whole stack with just "go run main.go" and so that CI tests more of our stack. (Our team runs managed Kubernetes clusters with our company's software stack installed in it, so it's very easy to get into the state where you need accounts with 3 cloud providers and 25 secrets to do anything... and it's a big productivity killer to require all of those for every change. And it means that a lot of test coverage is manual, which is an amazing velocity killer.) No product manager would rate that as the top product priority, but as the engineering TL I know it's a productivity multiplier -- reduce development cycle times and get more story points out of each sprint going forward. An engineer can test 100 of their tweaks per day, instead of 10.
Another option is to schedule slack times into your sprints. Ruthlessly prioritize, figure out how many story points your team can do per sprint, and fill it up. But, if your team typically does 100 story points per week, only take on 80 story points of work, and use the other 20% for "things that come up" or "things that engineers feel like doing". I haven't actually done this, but I plan to in the future, so I don't know what the right number is. But people always feel bad when 100% of their work is chosen for them; so build in time to let people choose their own work. The business gets what they want, the team gets what they want, and everyone is happy.
Finally, slightly off-topic... this is my guiding light for anything related to planning: https://apenwarr.ca/log/20171213 I worked for the author, and our team got a lot of stuff done -- we hit our OKRs every quarter, people believed us when we said "we'll do that next quarter", and we had a lot of fun making a great product. Planning is not bad, planning is great. Don't let it scare you away; planning doesn't mean "the PMs control your life". It just means you know what goal you're working towards.
Including those factors in your decision making is only way this can work, otherwise you will get poor quality at the end of it. At least that has been my experience in the context of software delivery.
Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.
Maintenance is NEVER prioritized by anyone in management. They think "What, we put in the bug fixes, what more do you want!" but they never put in the "Hey, if we reorganize some code here, things will be a lot faster and easier to extend".
Devs on the ground can consistently see "Hey, this system right here, is a major issue that'll cause us a bunch of problems in the future" and that does not matter. Because, quantifying how much money is lost by not fixing the issue is really hard to do. You can't reliably say "If I spent 10 hours fixing this, I'd save 100 hours implementing new features".
It's this sort of short sighted vision that has dev teams running on 20 year old software with a bunch of known CVEs, handcuffed because the answer to "What will upgrading to the latest bring us?" is almost always "some bugs in transition but mostly piece of mind that we won't be vulnerable to a cyber attack."
Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.