First, we’d like to say that the purpose of this post is not to convince you to use Scrum, let alone have you buy it. In order to be convinced, one has to try it. David and I had an interesting discussion about it, and we believe that the topic is worth sharing because, during our mandates, we often hear the actual question: “Why Scrum?”
So, here is our exchange:
David: By the way, Nedjma, why Scrum?
Nedjma: And why not Scrum? (laughs)
David: Right! (laughs) I mean, why is this framework known as the Agile reference framework?
Nedjma: Scrum is a framework allowing to discover Agility. This framework is easy to understand and, through its artefacts, ceremonies, and rules, it conveys the values and principles of the Agile Manifesto.
David: OK! And?
Nedjma: There are few rules to follow, and the pace is steady with well-defined meetings in a specific order. Scrum is easy to explain; the Scrum guide only comprises 17 pages.
But simplicity is not the complete answer to the question. Scrum is a framework that has proved its worth in various contexts. It allows to rapidly produce value thanks to multidisciplinary and self-organizing teams. There are no fixed plans laid in advance. The Scrum team is constantly seeking the best way to produce the utmost value for the end user.
David: This is interesting, and I’d add two elements: the early delivery of value is possible given Scrum’s incremental and iterative approach, which allows to deliver working software at regular intervals. This approach maximizes the opportunity to receive feedback from stakeholders, which ensures to obtain a high-quality product.
Quality, the second element I wanted to talk about, is very important in Scrum. The Scrum team is indeed delivering a ready-to-release software increment at the end of each iteration.
Nedjma: Software development is complex, and Scrum allows to face this complexity.
David: Yep! Therefore, why Scrum?
Nedjma: You didn’t let me finish! Scrum allows to face this complexity through empiricism; one of the fundamentals of the Scrum framework.
An empirical process means that we make decisions based on experience, and to do so transparency is required. In Scrum, all important aspects must be visible in order to be able to inspect them and make decisions that mitigate risks.
For instance, the daily scrum: Based on the previous day’s work, we can adapt the plan of the day to get closer to the iteration’s goal. The sprint review allows to inspect the product increment developed, get feedback, and work with the stakeholders depending on the progress to determine work with the most value to be performed during the next cycle.
But this is not limited to software development. Scrum allows to address complex problems, it is written in the Scrum guide. Let me check the precise definition. Here it is:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
In the definition, I particularly like the “creatively” adverb because I think that software development is a creative activity requiring a creative way to perform it.
David: I agree with you; regarding the first element, it is true that it’s simpler to discover empiricism via Scrum’s practices. We can also see this through the sprint retrospectives; the Scrum team members find concrete ways to adjust their behaviours, communications, and practices based on what they learned during the iteration.
I believe that the most important is to develop an Agile spirit. The Shuhari concept describes this qui well; rules must be respected to be able to achieve the right state of mind, then transcend everything. The Scrum framework allows each and everyone to begin their Agile journey.
The creative aspect of software development is also meaningful to me; in my opinion, a developer is above all an artist.
Nedjma: Exactly! As you often say, there is a difference between doing Agile and being Agile. By the way, I’ve read your latest article on the subject… I found it quite interesting! I agree that one of the good ways to achieve an Agile state of mind is to begin to use Scrum.
David: Let’s go back to the first question. I think that one of the important answers is team motivation. Let me explain: Scrum encourages the implementation of self-organizing, cross-functional, and focused teams comprising less than 10 individuals. It could be a challenge for certain organizations to have a cross-functional team because it eventually requires to break down silos. However, it is a real source of motivation, since it gives the team members a better visibility of objectives as well as meaning to their work.
Scrum teams are empowered by the organization. They collaborate with the client or its representative in the execution of one product increment per iteration. They track their progress and make decisions on a daily basis in order to find the best way to achieve their goal. It’s the best way to get motivated and performing teams.
Nedjma: I see in what you’re saying the way the first value of the Agile Manifesto is stated in Scrum. The success of Scrum projects is clearly linked to commitment, communication, and collaboration between the various roles and facilitated by the rules of the approach.
David: Speaking about the Agile Manifesto, we can easily associate most of its values and principles to the various elements of Scrum. It is a typically Agile framework. It could be the topic of our next discussion and article.
Nedjma: I’ll be more than happy to discuss it with you…
Now, let’s try to summarize our different answers to the question. We choose Scrum because:
- It is lightweight and easy to understand, which allows to quickly start with Agility.
- Its rules allow to face complexity.
- It is based on an iterative and incremental approach and it allows to rapidly produce high-quality software increments by focusing on one clear objective per iteration.
- The Scrum team is an empowered, focused, and committed team who relies on the rules of the approach to collaborate.
- In addition to learning how to do Agile, Scrum helps to be Agile. It’s above all a matter of continuous improvement to respond to change.
Did I forget anything? Are these all the points that we raised?
David: Absolutely! However, despite all the good points that we mentioned, we can’t always use Scrum.
There are circumstances when we can’t benefit from Scrum. I’m thinking of any team who works in a continuous flow (e.g., support teams). In that case, I believe that methods such as Kanban or Agile-Lean are more effective. On the other hand, these methods provide less guidance than Scrum and require more rigour and accountability during their implementation.
Nedjma: I agree that Scrum is not adapted to all situations. It also makes me think of a few interesting combinations between Agile methods such as Scrum and XP. I find that using XP practices in Scrum (in software development) adds real value to the team’s work. For example, TDD, refactoring, pair programming and continuous integration.
David: Thus, if we are able to define a framework in an Agile way, we don’t need Scrum?
Nedjma: Not necessarily, as long as the new framework is Agile…