It is said that Scrum is easy to understand but difficult to master. However, to me, it appears that Scrum is already difficult to understand since there are many ways to interpret, teach, apply and well… misconceptualise Scrum. I’m not even sure if I truly understand Scrum. Yet, here I am going to tell you about the disadvantages. I see in the typical interpretations of Scrum and how to overcome them.
Using Scrum creates an illusion that you’re agile
Scrum is so widespread that it’s a typical misconception to think that you need Scrum to be agile. Furthermore, people may think that simply doing Scrum makes you agile. Myself, I believe that Scrum can be a good way to start discovering agile but strictly following any rigid framework actually goes against the first value in the Manifesto for Agile Software Development: individuals and interactions over processes and tools.
That said, I don’t think the Agile Manifesto represents the contemporary agile discourse after 20 years of being published. Yet, I think most of its thoughts are still valuable. There is no single definition for agile so I’ll pitch in my definition:
Agile is a practice of delivering maximum value early and continuously by
a) enabling faster and cheaper learning cycles,
b) increasing autonomy and
c) cultivating collaboration within the team and with the stakeholders (especially users/customers).
As I said, Scrum can be a good starting point for a software product team figuring out how to organise their work. After all, Scrum offers some framework for agile – for short learning cycles, team autonomy and collaboration. Most importantly, Scrum incorporates retrospectives (team reflection) which enable the team to inspect and adapt its ways of working.
However, strictly following Scrum can become an impediment as the team matures. If you just follow Scrum, you most likely aren’t agile. Below, I’ll explain why.
Mini waterfalls
If you want to have sprints that you won’t need to replan during the sprint, you have to have clear specifications for all the backlog items, the latest at the sprint planning. This can lead to design and discovery work (such as user research or data analysis) to happen outside sprints – before the backlog items are added to the sprint backlog. And that often leads to extensive up-front design and discovery work, resulting in longer lead times. This makes learning slower and can even reduce collaboration within the team – making the team less agile.
The whole point of agile is to be able to change plans when we learn something new. Sprints can give nice structure for teamwork but don’t leave some of the team capabilities (design, data analysis) outside the sprints and feel free to replan the sprint whenever there is a need for that.
Furthermore, why wait until the sprint review to collaborate with the stakeholders? An agile team should be collaborating with the stakeholders throughout the sprint. Sprint reviews can of course be a good place to bring together all the stakeholders to share thoughts with each other and with the team.
Strict roles
Product Owner (PO) role is often taught/interpreted so that the PO is simply some sort of a backlog dictator and a knowledge broker between the team and the stakeholders. Instead, an agile team should be autonomous and make product decisions (including backlog prioritisation) as a team in collaboration with the stakeholders. That enables a much faster learning cycle.
Similar applies to Scrum Master. I think it’s a weird thought that the Scrum Master should be removing impediments, protecting the team and facilitating the teamwork. Somebody should do that but if the team is self-organising, they should decide as a team how to do that and not just leave it to the Scrum Master.
Yet, these roles can be a good starting point and it can be useful that some people take more responsibility in product management and team facilitation. Just apply the roles in an agile way!
Be warned!
Be warned: If you interpret Scrum strictly, you might interpret that these suggestions would break Scrum so much that the team process can no longer be considered Scrum. Worry not! Following Scrum should not be your objective in the beginning with! You want to be agile. You want to deliver maximum value early and continuously through quick and cheap learning cycles, enabling autonomy and cultivating collaboration.
PS. Simply breaking Scrum is not the point either. Breaking Scrum without understanding agile and Scrum might cause you to end up with ScrumBut and losing even the advantages of Scrum.
You might be interested in also reading these blog posts:
