Knowledge Base / What is Scrum?
Scrum is a framework
Scrum is a simple, lightweight framework and not a methodology or a set of processes.
By definition, a framework is a structure around or over which something is built (FRAMEWORK, 2008). As a framework, Scrum serves as the basis and a guide for carrying out the work but does not define specific and detailed practices to be followed for this.
That is, Scrum does not consist of a set of recipes or formulas. Scrum does not prescribe, for example, how the team should develop the product, how it should facilitate its own work or remove impediments, how business needs should be understood, nor how to work with customers.
Scrum is built on the fact that the practices necessary for successful product development are very context-specific and cannot be prescribed. There is no one solution or set of solutions that works for all situations. To the contrary, people developing a product based on Scrum accountabilities, events, artifacts, and rules need to assess, acquire, and develop a set of practices that will best serve them, and which is constantly reassessed and improved. This is an ongoing effort of discovery, inspection, and adaptation.
Since it is a framework, Scrum can work well when combined with or complemented by different methods and practices established by the market, which are then experimented and adapted by the team to its specific context.
Extreme Programming (XP), for example, is one of these methodologies. Although also considered lightweight, XP prescribes a more complete and specific set of practices that must be followed in order to be successful in software development. As such, when using Scrum, many software development teams borrow certain practices from XP, including pair programming, continuous integration, test-driven development, etc.
Definition: skeleton analogy
We can imagine that a framework is to a methodology as a skeleton is to the human body. The skeleton – that is, the bones – gives the body a structure, but does not move by itself. To be able to move, muscles, tendons and other tissues need to be attached to it. The human body, on the other hand, has everything it needs to move from one point to another.
The Scrum framework provides a working structure, but it is of little use if applied alone. It needs to be complemented by other techniques and practices so that the work can be completed by those using it. A methodology already prescribes much of what is necessary for its application to be successful.
Scrum is a framework and not a methodology. This is because, as I stated earlier, the techniques and practices needed to conduct product development work depend on the context in which that work is performed and cannot be prescribed. There is, though, a number of recognized good practices.
Scrum is simple and lightweight. With it, we seek to not generate or apply anything that will not be effectively useful and used. By prescribing just three accountabilities (Product Owner, Developer, and Scrum Master), five events (Sprint and the Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective meetings) and three artifacts (Product Backlog, Sprint Backlog, and Increment), with their respective commitments (Product Goal, Sprint Goal, and Definition of Done), Scrum can be easily explained and understood (in this book, I’ve included some additional elements).
Nevertheless, contrary to what it may seem, Scrum is not easy to use. Throughout this book I will present some possible alternatives of already-established techniques that have been used successfully by countless teams, and which may help your team in using the framework.
Fun fact: ScrumBut
I first heard about ScrumBut in 2009, at the Scrum Gathering in São Paulo. On that occasion, Ken Schwaber, one of the creators of Scrum, brought up the subject in a live video lecture. A ScrumBut is a partial and dysfunctional use of Scrum which, for that reason, prevents teams from obtaining its expected benefits. However, according to Schwaber, to say that we use Scrum, we must adopt all of its elements.
The idea behind this expression originates in statements like “we use Scrum, but…:”
- “We use Scrum, but our cycles last for months.”
- “We use Scrum, but we only deliver at the end of the project.”
- “We use Scrum, but it’s impossible to stop and do the daily meeting every day.”
Some confusion eventually emerged between “ScrumBut” and “ScrumButt,” which has a cruder and hilarious connotation, in my opinion. Since then, the expression ScrumBut has practically fallen into disuse, mainly because many considered the term pejorative when referring to partial adoptions of Scrum. And I believe this mistaken connotation may have something to do with it.