It is often true that the common understanding of the terms “Agile” and “Scrum” are conflated leaving the impression that the terms vaguely synonymous and can be used interchangeably as in the pictured web article below. This is unfortunate as it obscures the important differences between the practices and can lead to confusion about how to apply them in real-world situations.
To ensure clarity in using the terms in this forum, I’ll provide definitions of each term and demonstrate how they are both related and yet quite different. As a point of usage in this forum, Agile is capitalized to emphasize that it is different than the standard definition of the word ‘agile’ and is effectively a proper noun referring to the following definition.
Agile is sets of values and principles governing software product development methods given in a document called the Agile Manifesto. It is based on analysis of prior software development methods, but intentionally diverging from those methods, that is, the stated principles are prescriptive rather than descriptive. The manifesto provides a list of value statements or preferences about how to conduct software product development but does not provide any specifics on how they should be implemented. Those values are:
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
Given that these are preferences rather than absolutes, they do not preclude one over the other and so for example, one can say that a project plan is important, but it must not be too rigid, to accommodate changes in technology or the environment, stakeholders’ priorities, and people’s understanding of the problem and its solution. The signers of the manifesto developed as well, a set of twelve principles which they indicated were the basis for the manifesto. One such principle is “Regularly, the team reflects on how to become more effective, and adjusts accordingly” which is the basis of the practice of retrospectives.
Scrum, on the other hand, is a specific product development method based on Agile principles. It is one of several such methods addressing different development needs. These methods also include feature-driven development (FDD), Extreme Programming (XP), Kanban, and Scaled Agile Framework (SAFe). Scrum focuses on the design and build portions of software development, provides a specific vocabulary and process elements, and is based on a collection of assumptions which includes Agile values as well as others related to the team, the product, governance, etc.
In a sense, Agile is a mode of being as one approaches software development and
Scrum is a prescription for what to do when engaging in software development.
I emphasize this distinction because it is entirely possible for an organization to adopt Scrum or elements of Scrum and still not fully understand or follow Agile principles. A team that rigidly follows Scrum without fully understanding all of its elements and their intended purposes and does not adapt those elements to the unique situation of their team, product, organizational culture, etc. is not actually being Agile. Similarly, a team that takes the Agile values to extremes, say focusing entirely on building software to the exclusion of providing appropriate documents, is also not being Agile.
