In the 1990’s, Scrum was one of a number of light frameworks that informed the creation of the Manifesto for Agile Software development. The Agile Manifesto, as we usually refer to it.
The Agile Manifesto hasn’t changed since its creation in 2001. Scrum however, has been updated many times. Is the connection between the Agile Manifesto and Scrum still there?
The agile manifesto has stood the test of time well. The four value statements, and twelve principles, are as valid today as they’ve always been. Let’s have a quick reminder of the values
The Agile Manifesto Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
There is value in the items on the right, but the items on the left are more valued
Do note the statement at the bottom of the table. There is still value in processes, tools, comprehensive documentation, contract negotiation and following a plan. It’s just that the authors preferred the items to the left of the value statement. Let’s take a look at the connections between these preferred values and Scrum.
The Agile Manifesto and Scrum
Individuals and Interactions
The first thing that comes to mind when I think about individuals and interactions, is the Sprint Retrospective. Here’s a direct lift from the Scrum Guide:
“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.“
It’s almost a word perfect lift from the agile manifesto.
Working software
Scrum no longer addresses ‘software’ directly. It targets ‘product’ instead. So, if we swap the phrase ‘working software’ with the phrase ‘working product’, we see many connections.
For example, the Sprint Review requires that the Scrum Team and stakeholders collaborate on a ‘done’ increment. That is, the current working state of the product.
Another example is the definition of done. This phrase is mentioned 16 times in the Scrum Guide. It describes the state of the product increment when it meets the quality measures required for the product. It leaves us in no doubt regarding the importance of working product.
Customer Collaboration
Whenever I think of customer collaboration, I’m immediately reminded of the Sprint Review in Scrum and the work of the Product Owner.
As I mentioned in the last section, the Sprint Review is where the Scrum Team and the stakeholders collaborate. Amongst the things they discuss are changes in the environment and what to do next. Stakeholders may consist of customers, or their representatives.
The Product Owner is accountable for maximizing the value of the product. How they do this can vary greatly. A consistent approach though, is to collaborate with customers, especially on agreeing a definition of value.
Responding to Change
Responding to change is tightly interwoven throughout Scrum. This may be because Scrum is based on empirical process control. The pillars of empiricism are transparency, inspection and adaptation and all events in Scrum are formal opportunities to inspect and adapt.
Perhaps the most obvious example is, once again, the Sprint Review. At this event, we collaborate with stakeholders and actively seek their feedback. That feedback may lead to changes in the product backlog, a positive response to requested changes.
Agile Manifesto Principles and Scrum
As well as the four value statements, the agile manifesto has twelve principles. For the purposes of comparison, I’m once again replacing the word ‘software’ in the agile manifesto principles, with the word ‘product’. As I look through the principles, I note that Scrum has a strong connection to each of them. So much so, it is easier to call out those where the connection is, perhaps, not quite as so strong.
One example is that ‘business people and developers must work together daily throughout the project‘. In Scrum, the Product Owner represents the wishes of the stakeholders, which includes customers. This may give the perception that developers cannot work with customers directly, only through the Product Owner. This is erroneous. There is nothing to stop developers working directly with customers, though the construction of Scrum may not make that obvious.
Summary on the Agile Manifesto and Scrum
I have given a few examples of where I see the values of the agile manifesto being reflected in Scrum. There are many others. The Agile Manifesto values people and results and the Scrum of today still adheres to these values. The connection between the agile manifesto and Scrum is as strong as it’s ever been.
This article was originally published on the Turbo Scrum website