My journey to becoming a Scrum Master

In recent years Scrum, as an Agile method for developing software, has gained a lot of popularity. Like other software developers, I have been part of different Scrum teams, and I have seen good, bad, and ugly implementations/interpretations of it.

Two years ago I was asked to read and implement Scrum in one of the teams in our department. Here I try to summarize what I read to understand/implement Scrum. In addition, I try to summarize the challenges I have faced and point out weaknesses of Scrum.

Beginning

Like all previous days, I went to work. I am a senior software developer/technical researcher. That day I had a brief meeting with our project manager. He asked me if I am eager to learn about Scrum and implement it in our team? Well, I said yes. He handed me a book to start reading about Scrum: Essential Scrum: A practical guide to the most popular agile process by Kenneth Rubin. A long time before this day I have read Agile!: The Good, the Hype and the Ugly by Bertrand Meyer. Meyer’s criticism of Agile methods is truly brilliant.

My goal in this article is to show the path that I took to learn Scrum. I do not try to criticize it’s ideas; that is a goal for future articles. However, I highly recommend you to read Meyer’s book before or after reading the books that I recommend in here.

Requirement specification, estimation, and prioritization

To use Scrum you have to write down your requirements in some way. Scrum does not mandate any standard for requirement specification. However, most references suggest User Stories. To expand my knowledge of User Stories (beyond Rubin’s book) I read another reference: User Stories Applied by Mike Cohn. In this book, Cohn goes into the details of how to write good user stories. Based on what I have read in Cohn and Rubin’s books I decided to use a 4-level hierarchy system for requirement specification. At the top, there is the project. We break a project into a couple of coarse-grained stories (called epics). Each epic will be broken into finer-grained stories (we should be able to finish a story in a sprint). Each story will be broken into tasks.

After writing stories down, you have to prioritize and estimate them. To understand prioritization and estimation processes in Scrum I read two more references: Agile estimating and planning by Mike Cohn, and Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey. Based on what I have found in Cohn’s book I chose T-Shirt sizes for epics, story points for stories, and ideal hours for estimating tasks. Prioritization is another thing altogether. I think Tockey’s book is a very good starting point for this …

I have to admit that estimation using these units, specially story points, is not easy for software developers. Part of this, is due to the inherent uncertainty of estimates. However definition of story point itself is a little bit problematic. It even seems that well-known Agile authors also suffer from this problem. For example in page 87 of his 2004 book Cohn says:

My preference is to treat a story point as an ideal day of work

A year later in 2005 Cohn changes his opinion in his other book and completely separates story points from ideal days and after defining their meanings says (page 75):

My preference is for story points. The advantages of estimating in story
points are more compelling. If a team is struggling with the concept of estimating pure size, I will start them estimating in ideal days but will then convert them to story points

Other authors like Leffingwiell in his SAFe 5.0 Distilled book try to describe the meaning of story points in different terms and make it more clear. Authors like Vacanti point to the problem in a different context:

Part of the Agile Manifesto mentions “Customer Collaboration”. I fully support that notion that our work should involve close collaboration with the customer. However, to me, collaboration means speaking the language of the customer. And that language should extend to cover all the metrics and analytics that we use. Have you ever had to explain what a Story Point is to a customer?

I think all of these point to a problem in the concept of story points that might cause great confusion both in the estimation process and in defining “Agile” metrics. Anyway, you can read about the theory of Agile estimation in the above resources but, using it in practice is completely different.

How do we accomplish things in Scrum?

In general, Scrum assumes that software development is a complex process (for more information about the meaning of complex in this context refer to Cynefin framework). As a result, we can not specify all of our requirements and create a WBS (Work Breakdown Structure) and estimate them at the beginning of the project similar to the Waterfall model. Instead, Scrum’s method is similar to the Gradient Descent algorithm. It proposes you specify a goal, move toward the goal gradually and improve along the way. Let me clarify this method with an example:

Assume you are on top of a hill and it is dark out there. So, you can only see a couple of meters away. In addition, assume that you want to climb down the hill. What do you do? Well, you know that to climb down you have to move in the direction of a downward slope. Consequently, you have to find a downward slope, and move in that direction one step at a time. In addition, at some points along the way you stop and assess your situation to see how you are doing. You might change the course slightly based on your assessment.

This is exactly how Scrum works. First, you start with a product vision. You break your vision into a bunch of coarse-grained epics. Now you prioritize and estimate these epics (very rough estimates). Then you start working on some of them. You break them into finer-grained user stories as you move on. Each sprint you finish a couple of these stories and attend a review meeting to see if you are moving in the right direction or not. In addition, each sprint you attend a retrospective meeting to improve the process of doing the work.

Notice that Scrum has two improvement mechanisms:

1. Review meetings for improving and correcting the output
2. Retrospective meetings to improve the process that you use to generate output

Scrum meetings and their challenges

Based on different resources Scrum has the following meetings:

• Planning meetings to specify what we want to do in the upcoming sprint
• Daily meetings at each day of sprint for planning the day
• Review meetings at the end of each sprint to review the potentially shippable product increment and change development direction based on stakeholder feedback
• Retrospective meetings to improve the process of doing work

Most Scrum references mention these events and describe them to some degree. However, none of them properly describe how these meetings should be held. For example, in theory, the idea of daily meetings is great! However, when you want to gather people for daily meetings you might face different challenges (specifically in remote teams). To solve some of these challenges some people use asynchronous daily standups. For more information about sync/async daily meetings refer to this article.

Planning and review meetings have their challenges, but the most obscure meeting is the retrospective. For learning about this meeting I had to read a separate reference: Agile Retrospectives: Making Good Teams Great by Esther Derby et al. This is a great resource to learn about structure and activities that you can use in retrospective meetings.

Theory vs practice

After reading all of the references, I had no problem implementing the Scrum process. However, after some time I noticed a huge gap in my knowledge that none of the above reference’s address (except a shallow discussion in Derby’s book). The gap was about how to deal with “bad apples”?

Scrum books and most other resources on management assume that people always behave nicely. However, in practice sometimes this is not the case. For some time these questions haunted my mind:

• What can be done about the so-called “bad apples”?
• The only solution is to remove them from the team and organization?
• What about people that can not work in teams?

To find answers for these questions I studied ethics (Exploring Ethics by Steven Cahn), decision theory (An introduction to decision theory by Martin Peterson), economics (Mankiw’s micro and macroeconomics), and psychology(different resources). I have to admit sometimes as a Scrum Master you are facing a decision problem that is similar to Trolley’s Problem. These so-called wicked problems do not have solutions; they have resolutions. The resolutions might not make everyone happy …

Disadvantages of Scrum

After being a Scrum Master for two years I have to admit that Scrum is not perfect and has its disadvantages. Here are some of them from my point of view:

• Agile literature is sometimes inconsistent, confusing and dogmatic. I think before applying any Agile method you must read it’s criticism. A very good book in this line is Bertrand Meyer’s Agile!: The Good, the Hype and the Ugly
• Scrum assumes that people love teamwork. This assumption does not always hold (my observation!). Consequently, people that do not love teamwork will be left-out
• Scrum assumes that you have a team of qualified experts. This is not always the case
• I think, the notion of the team itself is one of Scrum’s weaknesses; because a team is very sensitive to stress, shock, etc
• In the long-term Scrum in combination with design thinking will result in a Tayloristic-style kind of management. You can read about this problem here
• Scrum has too many meetings that make people tired (I agree that these meetings are necessary)

Conclusion

In this article, I tried to introduce the references I have read in my journey to become a Scrum master. In addition, I tried to describe some of the challenges that I have faced along the way.

In the end, I have to say to be a good Scrum Master you must be empathetic, eager to learn, and always be prepared to deal with difficult situations.