Scrum disempowers developers

Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups.

There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value.

I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in " is more valuable than "If you have a bad team then Scrum is bad".

Besides, smart people still have egos, personal ambitions not lined up with project, biases, weaknesses, personal antipaties and make mistakes. Good process with accountability and responsibility makes wonder with all those.

There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers.

Two ways to tackle technical debt in projects:

1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever.

2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months.

An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.

Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.