Scrum disempowers developers

OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 ). I'm trying to take a bit more of a systematic, longer, researched and justified view of things, so any feedback is very welcome!

What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent?

Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust.

No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.

> What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent?

Isn’t he the same guy who’s been learning that more process is necessary to make cars safely and on-schedule? I’d be reluctant to draw any broad conclusion from one optimistic aphorism.

OP do you work at my company by any chance? This is scarily accurate.

What I've mostly noticed is that when people show up with cynicism or actual anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved (edit: though this might be sample bias, as Scrum is by far the most popular methodology).

I'm sure it's working really well for some folks. A large fraction of the magic of any agile system is the folks involved and their familiarity and experience with it. I work for Pivotal, our wheelbarrow is XP with Lean trimmings. I've seen it up close for 4 years in both consulting and large product development and -- summarising -- it works.

But no small part of it working is the context. Our context is that we hire carefully and that the entire organisation is interested in, and supportive of, the way we work. It is fantastically easier to do agile well in an environment where it is already done well (which is why we ask our clients to come work in our office).

If I had to pick the most destructive part of Scrum, it's the sprint commitment. Yes, it's called forecasts now, but folks are held to it anyhow. All it does is create a dynamic which generates either waste or burnout. Software should be releasable at all times, not once every two weeks. New features should be presented to a Product Manager as they are done done, not according to what is an essentially coincidental cadence chosen because two weeks is easy to mark on a calendar.

At Pivotal the closest we came to sprints was setting up a quarterly release cycle for our flagship product, PCF. The first few were a mess and we massively overshot our planned dates several times. We switched to something much closer to our normal way of working: release trains. Every quarter we make a release. If a component product has a feature ready at that time, the feature gets shipped. If it doesn't, it doesn't. And that's that.

We already have a lot of our customers who've adopted automation to update their PCF platforms for patches on a rolling basis. My fond secret hope is that one day, we'll be able to drop the quarterly release cycle as well and just ship things when they're ready to ship.