As a consultant, I often find myself doing work outside my comfort zone. When my director called to ask whether I wanted to be a scrum master for a team working on a mobile point-of-sale application, my gut reaction was, “Hell no; I’ve never done that before! I’m a project manager; how would I translate that to scrum?” When I thought about it longer, however, I began to change my mind. After all, I had taken the certification course a year earlier, and I shouldn’t let that go completely to waste, right? Plus, it might be a good challenge for me, I told myself.
Six months later, I can look back with some degree of objectivity. Although there are some things that went well right away, there are many more that I would do differently. Being a scrum master is different than being a project manager, and there were many times I had to make a conscious effort to go against my natural tendencies. I had to unlearn some behaviors and put in place new ones that aren’t utilized in project management. There are four things I wish someone had told me before I started – and that’s what I aim to share here.
Don’t always follow your gut.
Being a project manager for more than 10 years instills habits such as detailed planning, ownership, making hard decisions, and documenting the heck of out everything. Within a few weeks as a scrum master, I noticed something was wrong. The team was becoming disengaged and they didn’t seem like a unified group.
I took my tech lead aside and asked him how he thought things were going and why he thought the team was less engaged. Luckily, he was open with me and shared that the team no longer felt that they owned the work. I was making all the decisions.
I looked back on some of my recent actions. One that stood out was a time when a developer came to me asking if she could pull work into the sprint. We were only a few days into the sprint, so I thought it would be okay. It made sense to get the work done sooner rather than later, and my project manager voice was telling me I had all the information I needed to make a good decision.
To my team, however, it appeared as though I was simply piling on the work without giving them the opportunity to discuss it and determine how they would handle the increased workload. Instead of being excited to get more work done for our product owner, they were resentful and felt put-upon due to the extra work.
After this discussion with the tech lead, I learned to take a breath and pause whenever my decision-owning project manager self started to rise up. Instead, I let the team own their decisions, with me serving as a facilitator who removes barriers rather than controlling the outcome of the discussion.
Value prioritization over scope.
This was one of the hardest aspects of transitioning to a scrum master. The project I was assigned to was true scrum but worked with waterfall deadlines set by a larger program. We had dates that we had to hit with high-level scope commitments. Each release had three to five sprints.
During my first few planning sessions, I reminded the team of our end goal and made sure they understood how much we had left to do. This was all wrong. They innately knew where we needed to be in three to five sprints, and my planning sessions only served to stress them out. A few times, this pressure caused them to take on too much and roll story points over to the next sprint.
Instead of focusing on the entire “big picture view,” what they needed to do was accurately assess what they could commit to finishing in the next two weeks. I was lucky enough to have a full-time project manager who was in charge of worrying about scope and hitting the release dates.
I realized I needed to move into a true scrum master role: supporting my team, accurately calculating our velocity, removing blockers and barriers, and projecting how many story points our team could accomplish by the dates set by the project manager. It was our project manager’s responsibility to escalate any concerns about scope and make sure stakeholders understood the effect that working in a scrum environment would have on the deliverables, timeline and other governance. This allowed me to focus inward and help the team focus. In the end, we met our original scope projections and the team was proud of the work.
Define, define, define.
We rolled over a significant number of story points each of my first few sprints as a scrum master. After talking to some fellow scrum masters and prompting the team during our retrospectives, I realized that the team didn’t clearly know when a story was ready to be developed – they had no “definition of ready”. When I asked about a “definition of ready,” my team responded, “we’ve never had this defined and we’ve done fine.” At this stage, planning sessions were also very painful. Tickets were missing visuals or acceptance criteria, and we spent hours together to complete them. It was clear that we needed to make a change.
I quickly set up a working session with the entire team. Each person made a list of the things he or she wanted to see in a complete ticket. When discussing these lists as a group, it was impressive to see how many team members came up with the same five or six components.
After much discussion, we agreed upon nine points, and I had each of the team members commit to saying “no” if any of the nine points were not present at sprint planning. As a result, the next sprint was amazing. Not only were our tickets more fleshed out, but the team said “no” three times (see lesson #4, Stick to your Scrum Guns, below) when saying “yes” would have jeopardized our progress.
Now, the team has the definition of ready in plain sight at each planning session, and we use it as a checklist for each ticket. We then quickly followed with a revamping of our definition of done!
Stick to your “scrum guns”.
We had a lively product owner who was very passionate about the product she owned. She also was very hard to say no to. Once the team defined ready, it was my job as scrum master to make sure the team stuck to this. When they didn’t want to pull in a piece of work, I had to back them up. That meant saying “no” to our product owner. It only took one time of sticking to our “scrum guns” before she made sure she planned earlier and had all of her ducks in a row before coming to planning.
We saw a similar effect when I adopted another common scrum practice: only allowing work to be brought in during the sprint if the entire team agreed. When asked by another manager or team to complete work we didn’t commit to, I informed that person that if the request met the definition of ready, I would take it to the team for a decision as to whether we could commit to the new work. Several times the process itself discouraged the person making the request. However, when the work was truly needed urgently, the team was able to assess the work quickly and move other work around to get it all done. It was impressive.
My time as a scrum master has been one of my favorite roles to date. Six months ago, I would never have believed that it could be so challenging and that I would learn so much that is applicable in so many settings. Moving into my next, more traditional project management role, I will incorporate many things I learned from my time as scrum master. I will empower my team more and will step up as the “enforcer” as needed while protecting them.
I’m looking forward to that next call from my director asking if I’ll be a scrum master again. The answer this time will be, “Hell yes!”