Scrum is Not Agile
Scrum is Not Agile
As a Scrum Master, I instinctively dislike this opinion. In an attempt to challenge my assumptions, I want to see if this could be true. Is Scrum an agile framework?
Join the DZone community and get the full member experience.Join For Free
Last week I was speaking with another Agile practitioner about forming some new teams. During our discussion, I was told that Kanban would be the only way to proceed, because “Scrum is not Agile.” This stance seems to be growing in popularity. I frequently see posters on LinkedIn sharing that they signed the “agile oath of non-allegiance” or talking about Scrum as if it were a rigid process that must be followed to the letter. As a Scrum Master, I instinctively dislike this opinion. In an attempt to challenge my assumptions, I want to see if this could be true. Is Scrum an agile framework?
To truly answer that question, I need to establish what Agile is. The inciting incident shows that there must be competing opinions. For the sake of this inspection, I will use the most incorruptible definition I can think of, the Agile Manifesto. In this post, I will compare Scrum to the first two of four key principles. Next week, I will finish out my investigation with the remaining two.
The Agile Manifesto
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on
the right, we value the items on the left more.”
Based on the Agile Manifesto I can assume that any process that meets the 4 key principles must be agile. For the sake of this dissection, I will ignore the fact that both Ken Schwaber and Jeff Sutherland are original signatories of the manifesto. This in-and-of-itself does not mean that their framework (Scrum) upholds the values listed.
Individuals and Interactions Over Processes and Tools
Does Scrum prescribe processes and tools? For this answer, I will go directly to the source: The Scrum Guide. According to the guide’s first page, “Scrum is a framework for developing and sustaining complex products.” It goes on to say “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.”
If we take the above statement at face value we can conclude that no, Scrum does not recommend a particular process or tool. Rather, Scrum gives us guidelines in which we can choose the best processes or techniques to use.
This seems to satisfy the first key statement in the Manifesto. Scrum is not giving us a process to follow; it sets the stage for us to select the processes and tools that suit us. This would imply that the individuals and interactions occurring in the framework are given a higher priority than simply following a prescribed process. For me, this is rather conclusive. Scrum seems to pass the first hurdle, but what about the others?
Working Software Over Comprehensive Documentation
Does Scrum put any undue focus on documentation? To answer this again we should go to the source. The guide lists only 3 required artifacts: The Product Backlog, the Sprint Backlog, and the Increment.
What are each of these items? The product backlog is a list of user stories that could be considered the definitive list of work that needs to be completed on the product. The Sprint Backlog is a list of work that the development team has agreed to complete during the current iteration and the plan for completing that work. The Increment is the newly created product functionality, plus all of the previous functionality built into the product.
From the three Scrum artifacts, one of them is literately working software. The other two are lists of work that needs to be completed to create the software that is created by the Product Owner and Developers working collaboratively. Inspection of the rest of the guide does not mention document or documentation (unless referring to itself).
As Scrum does not appear to require any specific documentation, and instead specifically requires a piece of functioning software be created during every iteration, I must conclude that it meets the second criteria. Scrum appears to value working software over documentation. Further, the requirement of collaboration between the PO and the dev team to create the backlogs seems to further illustrate the first principle, valuing an interaction over a tool such as a document.
So far, Scrum seems to be 2 for 2 on key principles from the Agile Manifesto.
Published at DZone with permission of Jade Stephen , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.