Scrum is Not Agile (Part 1 of 2)

Iterative Agile Process Image similar to scrum

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 Process 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 are 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. Check back next week for my conclusion. Thanks for reading!

Sharing is caring!

5 thoughts on “Scrum is Not Agile (Part 1 of 2)

  1. One key things that a lot of people miss (those people who try to be inflexible in their approach) is that Ken’s book Agile Project Management with Scrum – he says “apply and adapt”.

    So you can be Agile with Scrum.

  2. I could argue that Scrum is indeed a process, depending on how you want to define process. If you take the most simplistic definition “A process is a set of activities that interact to achieve a result.” (wikipedia) then Scrum I would argue that Scrum is indeed a process. Lightweight and general yes, but still a process. Semantics maybe…

    1. Hi Frederic,

      Thanks for the comment Fredrik! I can definitely see your point, and I always say semantics matter.

      I would say that Scrum is a set of roles, events, artifacts, and the rules that bind them together. Scrum may contain some elements of process such as a description of activities, but is loose and incomplete. To me this makes the framework definition more accurate.

  3. If you take a look at the history of scrum, it’s basically based on the Toyota Production System. I have read a couple of books on TPS and even taken a tour of a plant. They way Toyota works is that cars are built in the order that customer orders come in. Using Australian car models as an example, as I am an Aussie, the order could be…
    Red Camry
    Blue Aurion
    White Camry
    Beige Camry Hybrid etc
    The cars are manufactured in that order.
    This allows Toyota to respond to changes in orders very quickly. In other words, they are able to respond to orders in an “agile” fashion.
    Prior to TPS other manufacturers would make a certain car model for several days, then another car model now the same with Scrum as I see it, ignoring the agile manifesto, Scrum tries to remove the “batching” of work by specifying increments of one month or less to get something through the pipeline. In the waterfall world where projects go on for months or years it’s not until the end that you see something. Given this comparison, scrum is “agile” in the fact that it responds to the change of work quicker than waterfall. Can it still be considered “agile” 16 years after the agile manifesto, I think yes. But that is my opinion given that waterfall is still alive and well in 2017. Can it be considered agile compared to other methodologies such as Kanban? Maybe, maybe not. It’s all a case of perspective. I look sway to determine if something is agile or not. It’s based on how the work is done, not what is done to do the work. If the work is done in such a way as it responds to change quickly, and stuff is completed in such a way you never have to touch it again once it is “done” it is agile. If you are doing work in batches and not completing (i.e. You need to touch the job again for testing) which is done after another piece of work is done, it is not agile.
    That is just my view.

Leave a Reply

Your email address will not be published. Required fields are marked *