The word SCRUM is used in the IT context quite as often as coffee and table football … People use it when talking about a variety of aspects superficially similar to each other, but essentially different. It’s true not only for the outsiders, but experienced IT specialists, too.
Linguistic nuances play their role in the overall problem, so we often hear attempts at defining SCRUM as a methodology, method, or framework. The variety of terms only adds to our confusion.
So what is SCRUM, actually? Searching through dictionaries and publications, we can conclude that it is much closer to a method or framework than methodology. But I will leave this discussion to linguists and focus on the useful practical aspects of SCRUM rather than on names.
So let us start with what SCRUM is not. To start with, SCRUM does not strictly and specifically define all the aspects of the product (software) development cycle. It does not define either the perfect documentation templates or step-by-step procedures.
For instance, SCRUM defines the artefact of a prioritised product backlog, yet it does not require it to include a maximum of 20 user stories and 200 story points. It does not tell us directly how to prioritise the user stories, either. Ceremonies are another example, as SCRUM clearly defines the ceremony types and the functions (goals) they are meant to perform, but it does not specify the step-by-step way to carry them out or what tools should be used.
Now we’re getting closer to what SCRUM really is. It certainly defines the frame within which we should act, hence the term quite accurate term framework, leaving each of us a fairly free choice of actions. This is what makes SCRUM so flexible and applicable in a variety of organisations. I’d go even a step further and say that SCRUM is framework for a way of thinking. Lack of strict rules does not kill thinking; on the contrary, it forces us to make independent, informed decisions. The freedom to decide makes the individual team members feel more responsible for the product and, at the same time, it leaves room for reacting to the changes in market, organisational, and technological conditions. The SCRUM principles do not limit our actions – they help us to quickly notice the issues that need fixing. This is how SCRUM smartly takes the best from the empirical approach to processes.
Let’s remember that naming is far less important than finding the sense and real benefits of using one method or another. SCRUM is not a cure for everything or a wall behind which team members can ‘hide.’ Quite the contrary – it exposes any shortfalls and negligence. Skillfully used, SCRUM can engage the programming teams and the entire organisation to continuously inspect its work and self-improve, resulting in a long-term and lasting development.