Knowledge Base / What is Scrum?
Scrum is based on empiricism
It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice (OGUNNAIKE; RAY, 1994).
Scrum acknowledges that, because it is complex and has a high degree of uncertainty, product development should be conducted empirically. For this reason, Scrum is based on the theory of empirical process control (SCHWABER; SUTHERLAND, 2017), as defined by Ogunaike and Ray (1994).
In the empirical approach for Scrum, we work in successive feedback cycles, learning both about the production methods used and the product being developed as we experiment, verify what is valid and what is not, and adapt whatever is necessary accordingly.
Contrary to what traditional methods preach, it is not realistic to define the features and behaviors of a product in great detail at the beginning of its development. While we obviously work to establish a sufficiently well-defined product goal or vision, the features, behaviors, and details will change during the course of this work as the environment changes, and we better understand the needs of customers and users.
Scrum seeks to maximize the ability of the product development team to respond quickly to these changes. At the same time, the team seeks to become increasingly productive, assessing which practices will be maintained and which will be modified or added.
In this way, we can say that Scrum is based on frequent cycles of transparency (the capacity to perceive), inspection (once perceived, the capacity to assess) and adaptation (once assessed, the capacity to change) both of the product and its development processes so that, by making continuous incremental improvements to both, we always seek to generate the greatest possible value for customers and users.
The Pillars of Scrum Transparency, inspection, and adaptation are considered the empirical pillars of Scrum.
Discussion: civil construction analogy?
Since almost the beginning of the history of software development – the original focus of Scrum –, the comparison with civil construction has been widely used to describe this type of work. They are, however, works of very different natures.
While they have certainly evolved over time, civil construction projects have existed for ages in human history and, in general terms, their manner of execution has remained the same: a long phase of definitions and specifications at the beginning that results in a plan, followed by the execution phase.
Traditional software development methods have emphasized something similar with the waterfall model and its sequential phases of requirements gathering and analysis, specification, development, and testing. Even today, it is common to use the expressions “engineering” or “software engineer,” “architecture” or “software architect,” and even “software construction,” all derived from the analogy with civil construction.
But this model makes sense only for jobs that have a reasonably low level of uncertainty. Given the empirical nature of software development work, comparing it to construction projects makes no sense. The analogy just doesn’t work.