Scrum disempowers developers

What are these technical priorities that are being ignored by your team?

I know some examples of cases where the development team was performing poorly which led to a bad experience with scrum. The symptom is when the development team asks for stories to refactor some code. They don't want to add any new value to the system or enable work in a different area: they've just made a rats nest out of the code or it doesn't live up to their expectations or guidelines. The cure for that? Set coding guidelines (and not just the syntax formatting variety: be hard and opinionated on initialization, patterns, and language features), mentor your team to refactor code after they've got it working and made their tests pass, and encourage developers to leave code in a better state than they found it. Also ensure that the business stakeholders and product managers are not setting unrealistic timelines and expectations. In time you'll find fewer requests to create backlog items to refactor code.

What else is there though? If your product and team leads are not concerned with security, performance, or other important factors you need to make them aware... that has less to do with scrum and more to do with good communication.

I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.

I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.

If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished".

And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."

All large organizations — including Tesla — are composed mostly of mediocre talent. This is mathematically inevitable. Furthermore "talent" is a myth anyway.

https://www.newyorker.com/magazine/2002/07/22/the-talent-myt...

On contrary I found scrum to be empowering for developers at least in my organization. Earlier, we used to have Technical Manager who provided estimate for a feature/project just based on his gut feeling which often was challenging and not feasible. But then developers needed to burn midnight oil to achieve the targeted release date. It often put enormous pressure on highly talented and competitive developers who had to cover up for less skilled developers. Now the development team is empowered to give its own estimation considering all factors. Mind you, in can lead to overestimation, but then we have experienced Technical Lead working also as a scrum master and individual contributor who is there to correct the course.

In general scrum will work best when 1. The product owner is from technical background with enormous experience under his belt in product development/architecture. The Product owner does not work alone in silos to create backlog but interacts with development team regularly to refine the backlog. In our case, the product owner is someone with 20+ years of experience who has worked in roles like developer/architect.

2. The scrum master is also highly technical person who has been working on the product for several years. In our team, the same person wears different hats as per the need like scrum master/technical leader/individual contributor.

It may not be exactly as per scrum guidelines but worked fine so far for us. Ultimately we need to look for good practices in each methodology and bend it as per our needs.

And the non-mediocre talent pool is exceedingly limited, and fickle. They jump to the next opportunity faster than your business cycles.