Imagine this, you are watching your favorite basketball team in the championship game. There is 1 second left on the clock. Your team is down by 2 points and has the ball. They move towards their basket and your favorite player takes a 3-point shot. IT GOES IN!!! Your team has won and the coach has Gatorade poured on them.
After the game the team celebrates and the coach gives an interview. They say that the team put forth a great effort and truly deserved the win. They take no credit for the success. The coach does not brag about how their coaching made the team what it is. They point to the team and say “That is who you should be celebrating”.
Now, I am a fan of the Minnesota Timberwolves basketball team so the above scenario has not really played out. I recently read an article (found here) on their head coach Chris Finch though. He has been with the team for roughly two seasons. In that time the team has had its ups and downs. To the fan base, the downs are reason to call for his firing.
You may be wondering why I am bringing up a professional basketball coach. In the article in question, the columnist took an interesting perspective on how people judge a coach’s effectiveness. I found there to be many parallels between being the coach of a basketball team and being a Scrum Master.
Parallel 1: Calls plays but is not the one to run them
In a perfect situation, the coach calls a play, the team executes, and they score. As with Agile, there are many different nuances that a basketball play has to take into account. What is the defense running? Which players are on the floor? How much time is left in the game? The list goes on.
Even with all that taken into account, the coach is not on the court passing the ball or taking the shot. If the defense decides to switch things up or does something unexpected, the team needs to adapt. This goes for the Scrum Master and engineers as well. The Scrum Master can coach the team to their heart’s content but the engineering team executes the play. If a sprint does not go according to plan, the Scrum Master can help remove impediments, but in the end, the team needs to be able to adapt.
Parallel 2: Does not construct the team but works to bring out their strengths
In the example with coach Finch, he inherited a team that did not have anyone to protect the basket at close range. He does not make the final call on who makes the team either. Rather than roll over and see the season go down the drain, he worked with what he had and found their strengths. He started coaching the team to play a faster defensive style to make up for the lack of rim protection.
Like a coach, the Scrum Master needs to help the team adapt to different situations. If a situation comes up that the team is ill-equipped to handle the Scrum Master can help the team adapt. For instance, let us say that during a sprint a bug comes to the team that is high severity. This team is full of newer engineers and the most senior engineer has their hands full. This bug will take the effort of multiple engineers. The team does not want to say “no”. The Scrum Master helps the team determine the importance of the issue and works with the Product Owner to determine if this is worth interrupting the sprint. The Scrum Master helps the team adapt.
Parallel 3: Has a style of “play” they like to run (not always a great fit for the team)
Most, if not all, professional basketball coaches have their own style of play they like to implement with a team. Truly great coaches can adapt and change their style based on different scenarios. Scrum Masters must be able to do the same. Each team a Scrum Master works with is different. Even if they only work with one team, there is a chance that the team does not remain the same over time. A great Scrum Master can change their style.
Parallel 4: If the team does well, the team looks great. If they do badly, the coach can take a big hit
As seen in the Timberwolves article, coach finch gets a lot of flack for the team’s underperforming. Remember he has been with the team for roughly 2 years. In terms of NBA teams that may be going through a rebuild (I think the Timberwolves are doing some form of rebuild), 2 years is not enough time to know if the changes made are successful.
Agile journeys take time. Picking up Scrum takes time. These are not drag-and-drop philosophies that will instantly fix your problems. Agile is a shift in mindset and behavior. Scrum, shows you the issues and you have to change them. Being quick to blame Agile and Scrum for failures can be catastrophic for a team. They may have been on the verge of turning the corner to great things but were stopped short.
Be patient, adapt, learn, and grow. And maybe you and your team will win the championship.
(I have no idea what an Agile or Scrum championship would be… maybe releasing a successful product?)
Additional resources:
https://conceptsandbeyond.com/product-owner-case-studies/
https://conceptsandbeyond.com/what-is-your-agile-sound/
https://conceptsandbeyond.com/utilizing-your-scrum-masters-to-the-max/
