Scrum and ScrumBut: what’s the Difference?
This post is dedicated to developers who’ve never worked with the Scrum framework before or have started but are feeling the difficulties of building an effective team-based collaboration process.
Being a Scrum master with years of experience myself, I’d like to warn you about common mistakes and help by sharing some hints. If you have a vague idea of what Scrum is, read this post about the Agile development approach.
To say that the Scrum process has been studied back and forth is to say nothing new.
It makes no sense to write yet another post … or does it? The Bible of Scrum developers – the official guide – actually leaves plenty of room to explore.
Master the Scrum process
The official guide says:
- More details of the basic principles are covered here.
Why is it so hard to master the Scrum process perfectly?
It’s not a set of rules that you learn by heart once and use in whatever project you like. The key point is that it is primarily a framework, not a methodology as many like to call it. What’s the difference?
Let’s ask the Cambridge dictionary:
- Framework – a supporting structure around which something can be built.
- Methodology – a system of ways of doing, teaching or studying something.
To put it simply, a methodology is a set of practices and techniques that dictate how to act in order to achieve a certain goal. A framework, meanwhile, is more like a skeleton to which you apply techniques and practices (the main thing is not to break the rules of the framework) in order to achieve success.
Why use a Scrum framework?
The framework helps the developers to find such project management practices as are suitable for their particular team. The freedom that any framework provides often leads to the conclusion that the use of Scrum in a team brings no clear advantages. On the contrary, it’s both a burden and a problem.
After all, not every team can independently discover the techniques and tools that will allow for the correct use of the Scrum process and get the maximum benefit from its implementation.
And here we come to a pretty fascinating fact: when a team can't find the right technique, it starts changing the framework, not looking for a new technique or tool. Therefore, the team leaves Scrum and deprives itself of its advantages.
“The framework consists of Scrum Teams and their associated roles, events, artefacts and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage”.
Developers have started to invent different versions of the framework that are more “customised”. Among professional Scrum masters, this phenomenon has even been given a special name – ScrumBut. For a more detailed description, follow this link.
I’d like to take a closer look at some typical ScrumBut cases and explain what’s so bad about them.
ScrumBut cases from my practice
#1 Too busy
"We use Scrum, but having Daily Scrum meetings every day is too much overhead, so we only have one per week".
There can be many reasons for this transformation – from the inadequate division of tasks into smaller and simpler ones to ending up with the transformation of Daily Stand Ups into a Sprint planning meeting that only top managers attend.
- Each reason requires a separate investigation, but the Daily Scrum is necessary in order to synchronise the team and to identify obstacles and difficulties that prevent the developer team from achieving the sprint goals.
- These stand-ups should not turn into something grandiose, requiring huge efforts from the participants.
Now, if you were to sail a ship across the Atlantic, how would you feel about the captain and crew checking their location against the course only once a week? Would you have the patience and strength to endure such a voyage?
#2 Always late
"We use Scrum, but we can't build a piece of functionality in a month, so our Sprints are 6 weeks long".
This point can be seen as a continuation of the previous one. The only difference is that it’s not the ability to quickly synchronise the workflow with other team members that we lose but rather the ability to inspect the results of our work.
The extent to which the product meets our old or new requirements remains unclear.
- The reason for this change most likely lies in the fact that we simply don’t know, so to speak, how to eat an elephant one bite at a time.
Of course, the root of the problem may be on the side of management, but more often than not implementing the ‘divide and conquer’ approach is enough.
#3 Where is my money?
“We use Scrum, but tasks from our Backlog should be paid for by the customer before we take them, so we start a Sprint only after payment.”
- I was told about this case by a developer who’d previously worked with me on other projects. In their team, while the product owner was negotiating payment, the developers were prohibited from taking tasks from the backlog as payment hadn’t yet been received. As a result, they sat there for days, sometimes weeks... It seems to me that what we see here are the clearest examples of using Scrum where it doesn't belong.
If external factors, such as payment, work procedures, meeting schedules etc. are impeding the organisation of work in accordance with the Scrum rules, why not think about using Kanban with the utilisation of resources on several projects? The Scrum process is certainly not a solution when tasks and payments appear periodically.
Using a suitable framework will enable the team to realise their creative potential, while the client can avoid being constantly burdened by payments (you can at least pay for each task separately).
In conclusion
I’d like to clarify that there is no silver bullet that can instantly get rid of all your problems. This is a complex but incredibly interesting tool for organising teamwork for the implementation of complex projects.
Scrum is always unique in each individual team, and, by and large, is a means of finding the most effective, convenient practices for a particular project. Therefore, if you feel the urge to change something in the Scrum process, read the guide again. Most likely you’re doing something wrong.
Chief Product Officer
related
recent
recommended
