Learnings from The Professional Scrum Master (PSM) Course

My takeaways from the 2-day PSM Course.

Rahul Pulikkot Nath
Rahul Pulikkot Nath

Table of Contents

Last month I attended the Professional Scrum Master (PSM) training. Richard Banks was the training instructor who also happens to be my colleague at Readify. It is a two days training and was a great experience for me. It changed my perception towards Scrum. Before the training, I was not that fascinated about Scrum and often argued against it citing that it's development practices that we need to uphold more and not Scrum. After the training, I have still not changed on the latter part but have changed my perception towards Scrum. Here are some of the key takeaways for me from the training.

TLDR;
  • Stick to the Process
  • Make Daily Scrum (a.k.a Standup) effective by setting mini goals
  • Understand the different Roles and imbibe the responsibilities
  • Have a well-defined Definition for Done
  • Deliver value in every sprint
  • Foster team collaboration and openness
  • Scrum is not the Silver Bullet. Other development practices must be followed in parallel.

If you are completely new to Scrum or not so familiar with the different terms used I recommend that you read The Scrum Guide. Don't refrain from clicking that link thinking it is a long book. It is a short one, and you can finish it in less than an hour. It is an hour well spent!

Scrum Framework

Sticking to the Process

Everyone who was attending the training was already using Scrum, but.. This is one of the common things with mostly everything and specifically with Scrum. People take parts of it and change the system to suit their needs. This is fine as long as you have tried the original process long enough to understand the pros and cons of it.

*Tweaking the process to suit existing practices as soon as you start with a new process is just resistance to change*

Like Uncle Bob Martin says in clean code, dedicate yourself to the process and follow it religiously until you have mastered the process. You can start modifying the process or finding new ways once you have reached that state. But till then follow it religiously if you want to see any benefit.

Martial artists do not all agree about the best martial art, or the best technique within a martial art. Often master martial artists will form their own schools of thought and gather students to learn from them. So we see Gracie Jiu Jistu, founded and taught by the Gracie family in Brazil. We see Hakkoryu Jiu Jistu, founded and taught by Okuyama Ryuho in Tokyo. We see Jeet Kune Do, founded and taught by Bruce Lee in the United States.
Students of these approaches immerse themselves in the teachings of the founder.They dedicate themselves to learn what that particular master teaches, often to the exclusion of any other master’s teaching. Later, as the students grow in their art, they may become the student of a different master so they can broaden their knowledge and practice. Some eventually go on to refine their skills, discovering new techniques and founding their own schools. None of these different schools is absolutely right. Yet within a particular school we act as though the teachings and techniques are right. After all, there is a right way to practice Hakkoryu Jiu Jitsu, or Jeet Kune Do. But this rightness within a school does not invalidate the teachings of a different school.
-Uncle Bob Martin, Clean Code

Effectiveness of Daily Scrum

Daily Scrum or otherwise popular as Standup meetings are not about standing up to give status updates. The intent of the Daily Scrum is for the development team to get together and work out whatever is required to get closer to the goal set for the sprint. Standing up improves your activity levels and interaction levels. So it's recommended to stand up. The primary intent of the fifteen minutes time-boxed event (it can take no more than the allotted time) is to look at how we tracked on with our 'mini goals' from last daily scrum and setting new 'mini goals' till next stand up. Also, capture any impediments or blockers and make sure that there are assigned people following up on it. The daily scrum necessarily needs not be the first thing in the morning but is usually preferred. Currently, I am on an evening 4 pm daily scrum.

Roles and Their Importance

Understanding of the different roles in Scrum is necessary. A scrum team consists of

  • The Product Owner
  • Scrum Master
  • Development team
Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Most important is to understand the responsibilities of each role and adhere to it as much as possible. Remember Sticking to the Process is important. Each of the roles must have the courage and openness to act according to their role responsibilities.

Definition of Done

Having a prior agreed on Definition of Done is important to decide when a piece of work is done. Having a common understanding of the definition of done ensures that we do not ship half-baked features. It also provides a guide for non-functional features, which often gets sidelined or missed and later becomes a show-stopper.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

Delivering Value

One of the golden rules is that every sprint must produce an increment that adds some business value. It need not be released to production, but it must be production ready. The Product Owner makes release decisions.

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints

This hints that having sprints solely for handling Technical debts, Refactoring, Project setup, Infrastructure setup, etc. are not recommended.

Team collaboration and Effectiveness

The process heavily depends on the people encompassing The Scrum Team. So it is important to have a good rapport amongst the team members. The team members should be comfortable and open with each other. The team needs to be self-organizing. When starting with Scrum, this might not be the case, and the team must recognize this and work towards self-organizing. The Scrum Master must encourage and guide the team to reach that state of independence.

When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
Scrum Values

The Scrum Guide calls out the above five core values that a team should demonstrate for the effectiveness of the framework. The Scrum team should constantly try to demonstrate these core values and try to improve on this.

Not the Silver Bullet for Development

There's a mess I've heard about with quite a few projects recently. It works out like this:
  • They want to use an agile process, and pick Scrum
  • They adopt the Scrum practices, and maybe even the principles
  • After a while progress is slow because the code base is a mess
-Martin Fowler, Flaccid Scrum

If you are looking up to Scrum to solve the problems with the quality of code you are delivering, you are with the wrong process. Scrum does not talk anything specific about software development and related practices. Extreme Programming is one process that is specific to coding and software development and is also a type of agile software development. It talks about the various development practices lays down strict rules related to software development. Again if you decide to follow this do that religiously - Sticking to the Process matters. Picking up only certain aspects of different school of thoughts might not provide the desired output always. Code Coverage if one such practice that is picked up in isolation and seen to produce not much value.

Given these new insights, I now feel that following a proven process framework, like Scrum will help a team achieve its goals. The core values that Scrum lays down is important for any team. From my personal experience, the reason why I used to look down upon Scrum is that it was not practiced the way it was laid out. Like in software development premature optimization of the process is likely to give less value. The training provided a lot of new insights and helped me to have a better understanding of the Scrum process framework. I did the PSM I and PSPO I (I had attended this training last year but never took the test until now) assessment and got certified. Are you using Scrum, what are your experiences?

Thoughts