4 ms·

> people with power either don't care or have interests that actually work against getting things done quickly and reliably. This is what I have seen, time and

> people with power either don't care or have interests that actually work against getting things done quickly and reliably. This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus. I've also seen it arise as a simple "too many cooks in the kitchen" situation. Ironically, the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.

wpietri 6y ago
Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them. I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning. Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation https://www.slideshare.net/rfan622/launch-scale-presentation Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan. As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.
yencabulator 6y ago
> [...] the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time. The way I've always tried to solve that is to have a single person (often a team lead, unfortunately) become that singular frontman, who listens to the n parties but is the one combining their input into one decision. That is, take away n-1's access to edit the issues, tell them it's an internal tool, and they should talk to the one person. And if you disagree with the frontman, that's between you and them, not between you and the issue tracker. This really is what a product manager should be doing (but I rarely see that actually work). Of course, corporate politics means people try to find a way around them.

wpietri 6y ago

Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them. I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning. Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation https://www.slideshare.net/rfan622/launch-scale-presentation Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan. As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.

yencabulator 6y ago

> [...] the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time. The way I've always tried to solve that is to have a single person (often a team lead, unfortunately) become that singular frontman, who listens to the n parties but is the one combining their input into one decision. That is, take away n-1's access to edit the issues, tell them it's an internal tool, and they should talk to the one person. And if you disagree with the frontman, that's between you and them, not between you and the issue tracker. This really is what a product manager should be doing (but I rarely see that actually work). Of course, corporate politics means people try to find a way around them.