Scrum as a concept is great - at it's best it cuts through all the noise, gets the proper stake holders to communicate quickly and clearly, aligns everyone at t

Scrum as a concept is great - at it's best it cuts through all the noise, gets the proper stake holders to communicate quickly and clearly, aligns everyone at the right levels, and of course allows for quick movements with large teams. However it takes a level of commitment and often breaks down if you're not active in implementing it. The standup is a perfect example - stakeholders shouldn't be part of it and it shouldn't go into strategy or deeper discussions. Everyone knows that, and understands why that's helpful, yet both of those rules are constantly violated. A good scrum master (and you need one because it's impossible to stick to the rules without someone who feels empowered to enforce them) will keep things on topic, and I remember at one company one scrum master kicking out the stake holder from the standup multiple times. At most companies the power difference is too large to do that. The jargon and emphasis on processes makes it too easy to focus on the surface level of scrum rather than the intention behind it. If it were presented as a flexible set of processes that you can customize to your team and project I think it would be far more successful. And when it comes to Kanban, it really depends on the project. If you're working in a factory setting (like making assets from a list) or if you have a stable product and you're adding orthogonal features, Kanban is ideal and scrum doesn't work. If you're working in a space with unclear or developing requirements and some amount of R&D then scrum is a good fit. Scrum can make large teams move quicker but everyone needs to be on board with WHY it works, instead of HOW (which is typically how it's presented). Ultimately though there is no one-size fits all approach. What you want is as dumb a system as is possible given the complexity of the requirements and communication.