Scrum Master or Scrum Coach

A first jump into trying to get teams to behave in the Scrum framework

Our organization has a new VP and on day 1 his words were we will make this an agile organization. This was big and important news to me because it gave foundation for my ongoing goal of going ahead and getting my CSM (but on the company's dime). I recently achieved that and working day 2 since that was a test. I was thrown into a team meeting where their existing Scrum master was not present (and to clarify not trained or certified in Scrum either) and I was asked to come sit in on a sprint planning meeting to advocate Scrum philosophy. In many ways one could say I was sitting in more as a coach for this meeting than as an actual Scrum master. This works for me as my long term goal in Scrum aligns more with that position.

So let's set the backdrop of what was going on in this sprint planning meeting when I came in as a picture of just what kind of Scrum fall it was in. Let us start with the attendees: 3 developers (2 of which also recently made CSMs with me), a person whose role was not clear and left, a documentation specialist, a project manager (who does not hold a PMI-PMP), and 2 product owners*

* let's tackle the product owner thing now since I starred it. The 2 product owners were there because they are under the actual product owner who has limited availability and they assigned these 2 to cover in their stead. The person they are covering for, and themselves, really fall more into the spectrum of stakeholders than product owners.

As I said they were in the process of sprint planning, but the steps leading to this planning of their second sprint were as follows:

1. a sprint review meeting had occurred, however people were still working right now on items from that sprint that had not been completed.
2. a sprint had occurred but nothing in the sprint had been sized
3. there had been no sprint retrospective

So as you can see right from the bat there is a whole lot of mess and bad interpretations of how Scrum is to work going on here.

After hearing all this I had to just stop the meeting to try to right this boat into something someone could at least say was a best effort towards following Scrum. So here became the plan:

1. First we went over everything that happened in the first sprint (which turned out to be in a time block that couldn't be described but was between 3-4 weeks)
2. We took the list of what was deemed done and inversely applied a sizing to them, which actually required creating a sizing to even begin with. (we went for shirt sizes and applied Fibonacci afterwards to score)
3. We used the points from 2 to at least figure a velocity for the first sprint.
4. We then sized what remained of the pieces not completed.
5. After that we added items from the top of the backlog, having to check the whole time that they were right to be on top priority wise, and then sizing till we got to a number that the team was comfortable with for the coming 2 week sprint.

As we got into 5 we also realized that there the priority order of the product backlog was still off so we broke the meeting then, while the product owner(s) on their own worked to refine the backlog into a more accurate priority order. If anything changed that would affect what was grabbed for the sprint the sprint review meeting would be redone but that it should not take too long unless the whole world changed. While they did that the developers brook off to work on splitting the user stories so far in the sprint backlog into tasks. At the end the product owner had not changed what was in the sprint but had reordered 2 items in the sprint. I said that was enough to redo the sprint planning meeting but with what we have already learned it should be a fairly quick sprint "re-plan".

Throughout this whole time I tried to stay to the letter of what is Scrum and what is not, granted some things had to be tweaked as we were retroactively applying it. The interesting thing is that, although we started with a little bit of some consternation on taking these steps back, I feel we ended with everybody appreciating it. I think the product owners understood the importance of always making sure we had the most important items first and how they own that list. Also the developers appreciated my comments that failure is always an option and failures in a sprint help us to improve with each iteration.

I think the one very non-Scrum thing added is color coding to the backlog. The product in question has regulatory concerns that have hard deadlines. What I suggested to track that is that if an item had a hard regulatory date to color code it red, and if it was a soft regulatory date to color code it yellow. It was the best I could come up with. I still stressed that color coding or not the backlog must be sorted in priority order.

As a first test coming in cold this proved two things to me. Presenting Scrum with well reasoned discussions as to why we do things certain ways really can help all parties. Also that once the parties grasp these pieces they have more confidence moving forward. The roles help people take ownership where they need to take ownership.

In the end I chose to approach this meeting not as just a replacement Scrum master but as a Scrum coach. I find at least in this particular circumstance with this organization that was the right call.