41–42 of 42 posts
It's like a religion. You have a simple gospel, but religious nuts turn it into a faith-based dogma. If you don't get results, it's because you're not following the rituals well enough. You get the idea. In practice, I think it's one of those things where you should follow the rules for a while, until you can tell where it makes sense to break them. If you half-ass the implementation, you end up doing the same things…
Nowhere in Scrum does it mention how to create software. This is for the team to decide. If the team is creating bad software, I struggle to see how it can be attributed to a team management framework they use, unless of course it isn't official Scrum but some bastard child of the organisation.
You are correct that Kanban is effective. But again, it is a tool that can solve problems in certain contexts. It is more suitable than scrum in some organisations, and vice versa in others.
For example, a product that has many high demanding customers who require plans months or even years in advance will find Kanban ineffective for planning. Telecoms companies are good examples of this where their customers take new software and integrate it with their own systems. They require a tight schedule.
On the other hand a bank which has a product that is only used within the company and no external stakeholders may serve better with Kanban.
There is a lot of 'scrum hating' in the comments here. It's important to remember, companies have every incentive to get effective processes that everyone likes. Bad processes means unhappy developers means more turnover. The ones who focus on bureaucracy suffer for it in the long run. Scrum is used by large companies across the world because it works. Is it perfect? Absolutely not. Is it easy to abuse? Certainly - it's flexibility is perhaps it's biggest benefit and flaw. But when it's done well, it's highly effective. Just ask anyone who works in an effective scrum environment.