3 ms·
True, however I'd say this is a problem with having an incompetent person in charge, not a problem with the process. I've had the experience you describe but al
by fpig 9y ago
True, however I'd say this is a problem with having an incompetent person in charge, not a problem with the process. I've had the experience you describe but also the opposite experience where people understood the need to rework things and what the business impact of not doing it will be. What makes a difference are 2 things:
1. The person making a decision like "should we do refactoring" should not be incompetent. They should be technically great and also in tune with the company's business needs. I know some smaller companies have non-technical people in all non-dev roles, so it's either the devs who do the work deciding or a non-technical person deciding, but that is just stupidity, at the very least the guy who is the boss of the development team should be a development guy. I seriously doubt that at for example Microsoft or Google, a non-technical person makes this type of decision.
2. The incentive system should not be messed up. Especially at companies with multiple levels of traditional managers, you have problems like people treating their job almost like a game, where they try to make their numbers good at the end of the year or avoid ever telling their bosses something their bosses don't want to hear... They completely lose alignment with the company's interests and treat their job like a game of looking good to their boss, so even if they understand the need for something they might say no to avoid missing a deadline they told their boss they would hit etc... This doesn't really happen at SD companies because most of them are new and never developed this type of culture but it happens at companies that are in another field and just have a SD department
I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less. I still think you should "sell" refactoring to your boss, but the "boss" at a level where "should we refactor" decisions are being made should be an extremely technical guy who also knows how it will affect the business side of the project.
- crdoconnor 9y ago>True, however I'd say this is a problem with having an incompetent person in charge, not a problem with the process. No, it's a process problem. Devs can't directly assess the relative importance of setting up a CI server compared to the new login workflow. If they could, there wouldn't be any need for a PO. POs probably don't grasp exactly how important setting up a CI server is. And why should they? >The person making a decision like "should we do refactoring" should not be incompetent. That's a given. If they're incompetent, no matter what process you give them they will inevitably just make things worse. >I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less. Yeah, sometimes more, sometimes less depending upon how much pressure customers are putting on you, if the trade show is next week, if it's a quiet week, etc. IMHO PO should choose the % each sprint and devs should choose what goes in it. >I still think you should "sell" refactoring to your boss That's tantamount to saying you don't want it to get done, because devs are typically shitty salespeople. Also: do you really care whether module B is decoupled from module A or a new CI server is set up? Why not just say "spend 30% of your time this sprint on code quality improvements" and leave it at that? At most, the devs should sell the % of time they want each sprint. Honestly though, I'd be happy to let that be 100% at the PO's discretion. Just don't make me try to explain to a non-techie why it's important that I need to refactor some tests.
- fpig 9y agoI think what you don't understand in my post is that I am saying POs should grasp those things. I just don't see the reasoning behind hiring someone who is non-technical for such a position. And the answer to "why should they" is precisely because they can then understand the development side better and these types of problems are avoided. It allows them to make more informed decisions. Basically, why should they not?