Scrum 101 from the Trenches (1). What no Training Teaches You

Scrum is currently the most popular product development framework. It’s also the framework I used the most and I am most comfortable using. It’s a simple framework, but not easy to implement.

I am going to write a Scrum series, where each post will tackle a part of Scrum, with information on its purpose and definition, to which I will add the interesting part: what Scrum training doesn’t teach you, and what you will learn the hard way, by using Scrum to build software.

What is Scrum?

Scrum started as a project management framework.

As the Agile community is moving towards dropping projects and focusing on building products, the Scrum Guide defines Scrum as “a framework for developing, delivering, and sustaining complex products“.

That’s it: Scrum is a way of building products. It is over 20 years old, dating back from 1993, when Jeff Sutherland used a very early form of Scrum for Easel Corporation, while the term Scrum was coined in 1995, by Sutherland and Ken Schwaber.

The name Scrum is inspired by an article written by Hirotaka Takeuchi & Ikujiro Nonaka wrote an article in HBR (1986) – The New New Product Development Game – which presented a “rugby approach” to product development: “where a team tries to go the whole distance as a unit, passing the ball back and forth.”, with an emphasis on speed and flexibility.

The Scrum Guide

Scrum is entirely described in the Scrum Guide. As mentioned, the framework is as simple that a 12-page guide is enough to describe it. But don’t be fooled by its simplicity, many a new Scrum aficionados take its simplicity too lightly and they run into numerous issues come implementation.

Underneath the lightweight attribute of Scrum there is deep complexity, learning from various domains (software engineering practices, team performance, organisational transformation, product development, product management, etc.) that will influence the implementation of the framework.

In Schwaber’s words: “Ken Schwaber correctly points out that Scrum is hard. It’s not hard because of the things you do; it’s hard because of the things you don’t do”. Excerpt from Agile Project Management with Scrum (2004), by Ken Schwaber.

So, no matter how much “you got” Scrum, you have a long journey to have a successful Scrum implementation in your organisation. According to Schwaber, it might take you between 1-3 years to reach a successful agile transformation with Scrum (Agile Project Management with Scrum (2004), by Ken Schwaber).

A short description of the framework

Scrum as a framework is quite easy to understand (hard to master, so don’t get fooled by its lightweightness):

There are only 3 roles: Product Owner (PO), Development Team (Dev Team), and Scrum Master (SM).
The teams works in iterations, called Sprints, that are not larger than 30 days.
The work that needs done on the product is all comprised in the Product Backlog (PB; which is owned and maintained by the Product Owner).
The entire Scrum Team (PO, Dev Team, SM) meet regularly (maximum every month; the most common sprint duration is 2 weeks) to plan work for the following iteration; the meeting is called Sprint Planning.
After the PO and the Dev Team agree on the PB items to be worked on during the sprint and on a common sprint goal (releasable increment), the Dev Team creates the Sprint Backlog (SB). The SB comprises all items, tasks, research that need to be done during the sprint to fulfill the sprint goal agreed with the PO.
The Dev Team starts working on their tasks. They communicate and collaborate with the PO, other teams, stakeholders to get everything done to fulfill the sprint goal. They also meet daily during the Daily Huddle to discuss the sprint progress and if there are any impediments they need to remove.
At the end of the iteration, the Dev Team, the PO and stakeholders meet for Sprint Review, to inspect the increment, give feedback and decide what the team will be work on next (update the PB also).
The sprint ends with the Retrospective, where the entire Scrum Team meets to discuss how they work, what they need to learn to continuously improve and agree on actions or experiments to run during the next sprint.

The apparent simplicity of Scrum made it the most popular framework to date. But, as you will see in following posts, this simplicity hides a lot of complexity. When you start working with Scrum, plenty of questions arise that the Scrum Guide doesn’t cover.

I used to be bothered by the fact that Scrum doesn’t cover everything and doesn’t have answers for everything, especially when I first started working with it. I learned that these knowledge gaps are there for a reason: there is space for you to experiment and create your own learning and practices. So, if you feel a lot of pain when you start implementing Scrum, enjoy it, it means that you’re learning.

The Scrum Values

Every time I did a new training on an Agile framework, the trainers always dive into principles first. Eager to learn about the framework, I found it makes it harder for me to learn about the framework. But the principles are a great space to start, they are the answer of every question, they guide you when you run into issues and problems and they give you an indication about where you are on your implementation scale.

Mastering the principles means mastering the framework. The issue is that mastering the principles is the hardest part of a framework implementation.

Let’s take a look into the Scrum principles and see how you can use them; check out their description in the image above, before jumping into understanding how they can be used:

Courage: is your team speaking up when they have problems? Are they choosing the harder option, with a long term effect, rather than the easy fixes that would have them deliver fast and please management? Is the retrospective a safe space where everyone contributes and shares ideas honestly and openly? This principle is helping you create teams that can become self-organised and will build the right thing.
Focus: is your team reaching their sprint goals? Are they delivering a releasable increment every sprint? Or are they working on too many projects and they release late? This principle helps push your team getting things done and releasing often (which is the condition for fast feedback and iteration).
Commitment: does your team feel responsible and accountable to reach the sprint goal? Do they do their best to make the sprint goal happen? Is your team delivering technical excellence and are committed to deliver their best work? This principle guides you to figure out how to get the work done, at best quality.
Respect: how do your team members interact with each other? Are they being caring? Do they give each other improvement feedback in a caring way? Did they create rules on how to work with each other? This principle helps you build a strong team, with people that respect each other but also push each other to deliver their best work.
Openness: does your team inform the SM/PO immediately if they find an impediment that would stop them from reaching their goal? Are they contacting the PO if they are not clear about the backlog item? Are they being open for not being able to fulfill their commitment and work on solutions and alternative together with the PO? This principle ensures transparency within the team and between the team and stakeholders.

Scrum Alliance or Scrum.org?

If you’re interested to learn more or get training on Scrum, there are two officials bodies of training: Scrum.org, that offers Professional Scrum certifications and Scrum Alliance, which over Certified Scrum certifications. There is a little history behind them, so maybe this will help you choose a certification.

Ken Schwaber and Jeff Sutherland, the creators of Scrum, founded Scrum Alliance together, with the intention to train and teach Scrum. For a period of time it was very easy to get Scrum certified, there was no exam, and a lot of unqualified people got certified and became trainers.

Schwaber wasn’t too happy with the situation, so he created Scrum.org, where getting certified is quite complex (the class training is not mandatory, but if you are new to Scrum, the exam is not easy to pass; the minimum score is 85%).

Sutherland went ahead and founded Scrum.inc.

It’s not relevant which one of the Scrum houses you are going to learn from or get certified with. What is essential is the trainer that will run your class. You have to maximize your learning from that training and having a good trainer is essential. So focus on the best trainer you can get in your area, maybe also research ideal companies you would work for and see what their requests are.