4 ms·
>I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns
by crdoconnor 9y ago
>I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns that are part of the prioritization decisions.
Ok, so assuming:
* All user stories are prioritized by management.
* Management determines the exact % of time spent on refactoring stories.
* Refactoring stories are prioritized by devs and slotted alongside user stories (according to the % above).
What kind of hypothetical non-technical concerns that are part of managment's prioritization decisions would become a problem?
Because, as far as I can see, in such a case, it wouldn't matter if the devs are not aware of the non-technical concerns because those concerns would still be reflected by the prioritization.
- DougWebb 9y agoIf all three of your assumptions are true, then you're correct. The trick is getting the second two assumptions to be true. Management and devs have to agree on a % time split, and management has to agree with intermingled priorities instead of "dev % goes at the end". Negotiating those agreements is where having a common ground on business concerns helps. And yes, it sure does help when the managers can also see things from the dev's point of view too. In my experience, it's easier for devs to understand business concerns than the other way around, so that's the way I lean.