3 ms·

And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynami

And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynamics are what really matter, and that most managers will resent any process change that makes the actual management dynamics obvious. For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall. One book really helpful to me here looks at the default ideology of current management: https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies-ebook/dp/B09LQSSM77/ref=sr_1_1?keywords=confronting+managerialism&qid=1670614278&sr=8-1 https://www.amazon.com/Confronting-Managerialism-Business-Ec...

nradov 4y ago
In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.
- quickthrower2 4y ago
  It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul. Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer. It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first. Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.
- wpietri 4y ago
  I agree that for certain legacy markets that's the case, but I don't think that's the future of software. One of the things that distinguishes enterprise software is how little the users or their experience matter to making a sale. Those also strike me as defensive choices. Defending against bugs, against bad relationships, against bad design. All of those are true for some markets, but it's no way to create new products because it breaks core feedback loops. Companies that don't have a way to improve will eventually get replaced by those that do. And as you say, they might then become the next company forced to slow their pace by their customers. But I am hopeful that even enterprise companies will learn to move faster.

nradov 4y ago

In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.

quickthrower2 4y ago
It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul. Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer. It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first. Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.
wpietri 4y ago
I agree that for certain legacy markets that's the case, but I don't think that's the future of software. One of the things that distinguishes enterprise software is how little the users or their experience matter to making a sale. Those also strike me as defensive choices. Defending against bugs, against bad relationships, against bad design. All of those are true for some markets, but it's no way to create new products because it breaks core feedback loops. Companies that don't have a way to improve will eventually get replaced by those that do. And as you say, they might then become the next company forced to slow their pace by their customers. But I am hopeful that even enterprise companies will learn to move faster.