When it comes to implementing Scrum, we should remind ourselves why exactly we are implementing the framework. Is it because it allows us to consistently deliver value to the end users? Sounds lovely, but… it’s not the only framework that does that. You can absolutely do agile without Scrum.
Should Scrum be your first choice? It depends. When it comes to starting with a new team, the background of the team members matters a lot. Some cultures simply don’t allow building a horizontal structure in a workplace – there is a culturally imposed hierarchy, which doesn’t make sense breaking for the sake of doing Scrum. Will your Product Owner be truly empowered to make evidence-driven decisions that challenge the directives coming from the stakeholders? Will the team actually be in charge of the Sprint Backlog? Are there any checks in place that would prevent the so-called seagull management?
Some cultures do not share the same values as Scrum does – and while commitment, courage, focus, openness and respect are ideal to have in any venture, it’s barely possible to imagine a, say, Middle-eastern or Japanese culture exhibiting the value of courage and being able to challenge the higher-ups. Despite that, some agile consultants keep bringing forward the idea that Scrum is the way to go, and when implemented as a directive from the management, it leads to the following issues:
- Lack of transparency in the decision-making process – the team is not really in charge of the internal processes. The management (allegedly) knows best what the team members need, creating excessive bureaucracy and it is barely possible to drive the change from the bottom up.
- The inability to confront the existing issues means that the disappointment in the working processes will grow exponentially, thus leading the team members to burn out – leading to a high turnover rate. They have been promised the idea of doing something that doesn’t really match with the reality.
- Unempowered middle-level decision-makers – a Product Owner will function as a Business Analyst at best, writing down user stories that have already been decided by a Product Manager, who has, in their turn, received them from a Product Director or the end client. This presence of middlemen does not nurture the cooperation between the development team and the end users, making it hard to predict what the end user actually wants.
We are certainly not forgetting the cases when Scrum is not needed, because the product itself is straightforward. The team has implemented, say, three or four products that are exactly the same. They know it like the back of their hand – Scrum will not be of good use there, as it is designed to work in complex environments, prone to change. In such cases, the team will lose their capacity on the Scrum ceremonies instead of actually working on the implementation – and instead of finding a Scrum Master, go with a Project Manager to control the delivery and (although unlikely) support the team.
Long story short – don’t push one framework as if it will magically solve all issues you experience in your organization. Consider the benefits and drawbacks of using each of the options, before settling on something particular.
Occasionally agile 