What if one of Scrum's ingredients becomes an impediment?
Hi all,
I am currently studying for PSM I and I try to get information from different places about agile and how scrum fits into the scheme. I just saw a video about how scrum evolved to something similar but different at Spotify and in the video they mention that at some point "scrum got into the way". At this point they decided agile > scrum.
This has triggered kind of a philosophical question in me, scrum beeing quite direct about implementing all events, artifacts, roles and rules in the framework. Scrum tells us to inspect and adapt. But what if inspection leads us to the need to question some of the scrum principles in our organization (for example when scaling as in the case of spotify)? Wouldn't this mean some sort of breakout from scrum, induced by scrum (inspect & adapt)? Or is there some silent "inspect & adapt but never leave the framework" rule?
Second question: Could this, at some point, lead to an agile method/framework that adapts itself to the company where it started?
When you deviate from the Scrum Guide, you are no longer doing Scrum. However, that doesn't mean what you are doing is wrong, bad, or not agile. It simply means you aren't doing Scrum and you shouldn't tell others that you are doing Scrum. So it's entirely possible to inspect and adapt your process and decide that you should do something that isn't Scrum because it's right for your team and your organization. However, at that point, you may be on your own, but that may be fine.
To me, the advantage of Scrum is that it's something that's worked well in a variety of organizations in a variety of industries in a variety of different settings. It's a good starting point. But that doesn't mean it's the be-all-end-all process framework. There are reasons for why things are the way they are in Scrum. Adopting Scrum is not risk free, but you take advantage of a tried and tested framework. When you deviate, you are accepting the risks of going off the beaten path.
Sometimes new approaches are developed not because Scrum gets in the way, but because a constrained understanding of how Scrum might be implemented proves an obstruction.
Scrum isn't supposed to solve all of your problems. Sometimes it just makes them painfully obvious. You are then supposed to solve the problem.
For example if setting Sprint Goals requires lengthy discussions where the outcome is a goal that doesn't help much, the best solution might not be to stop setting Sprint Goals. It could be a sign that there's no focus on a product vision, and that might be a challenge for the Product Owner to resolve, with the help of the Scrum Master, stakeholders and management.
Thanks a lot to all, your answers make scrum concepts clearer to me!