A couple months ago I attended a local Agile user’s group meeting and sat in on the Scrum Master Birds of a Feather session. I created a bit of a stir when I first asked, “How many of you have full time Scrum Masters?” All the other organizations represented turned out to have full time Scrum Masters. So, I then asked my second question, “What do they do?” I guess I had asked the question in a way that implied that full time Scrum Masters was strange, because I was greeted by several moments of complete silence. Most of the people, other than those from my own organization, looked at me like I had three heads. Finally, they indulged the obviously under-educated member of the group, namely me, with explanations directly from The Scrum Guide as to what a Scrum Master does. I shocked them further when I said that we had moved beyond the need to have full time Scrum Masters. I didn’t bother telling them that we actually never had full time Scrum Masters.
The Scrum Guide generally describes the Scrum Master role as one of teaching, coaching, facilitating, and removing impediments. And when a Scrum team is new, these things take time. A team new to Scrum tries to follow Scrum by the book and needs someone that can do a lot of teaching, coaching, facilitating and removing impediments. But what happens when the delivery team matures? Teaching lessens. Coaching lessens, though there is still need for coaching around constant improvement. Facilitating is still necessary, though this takes up very little time. And impediments lessen as the team learns to deal with them on their own. If one of the team members’ full time job is teaching, coaching, facilitating, and removing impediments and all these things have lessened to where that person is only needed ten to twenty-five percent of their time, what do they do the rest of their time?
For us, we took the following path. We started with Scrum, though I wouldn’t say strictly by the book. We came from a world where we had project managers running multiple projects, thus working with multiple project teams. Our first step was to train our project managers in Agile. Several of them took advanced courses. A couple even became certified Scrum Masters and Agile Project Managers from the Project Management Institute. Thus, our project managers (PM) became our first Scrum Masters. Due to resourcing constraints (we had more teams than PM’s) and possibly due to a little foresight, we did not immediately dedicate a Scrum Master to a single team. Yes, that’s right, we violated one of the Scrum rules right from the start. Each of our PM’s generally had two teams they worked with as the Scrum Master. This kept them busy, but did not overwhelm them. Their role, as you might guess, was to teach and coach the teams in Scrum, to facilitate the Scrum ceremonies, and to remove team identified impediments. And this worked for the first nine months to a year.
Fortunately for us, our Scrum teams matured. It became apparent to me that our set up with using PM’s for Scrum Masters was starting to become a problem when during employee one to ones I kept getting asked just what value the PMs (notice they were not referred to as Scrum Masters by the team) were adding to their team. The delivery team members felt like they were being over-managed by multiple people. They had their own functional managers and they had Scrum Masters who were not really part of the delivery team.
We made our first change in the structure. Each team was allowed to select their own Scrum Master from among the delivery team members. The Scrum Master would still be responsible as a full time delivery team member, but they would also facilitate the Scrum ceremonies and be the first point of contact for impediments to the team. What did we do with the PM’s? At first we left them as PM’s – doing some project management stuff such as cross-team coordination. But we also left them as Agile coaches. And coaching became something a delivery team asked for, not something that we imposed on them. This worked well. Those teams that were more mature in their Agile approach and understanding didn’t feel over-managed. Those teams still coming up to speed had someone they could go to for coaching.
One more minor transformation occurred as we continued to mature. We elevated the PM’s to program managers rather than project managers. They now became responsible for cross-team initiatives. These are projects that transcend products and have tasks / stories in multiple delivery teams. We also rearranged our management reporting where we went from functional managers / supervisors to delivery team managers / supervisors, a role we call the delivery manager. And it is the delivery manager that is now responsible for the Agile coaching and mentoring. We’re still working the kinks out of this model, but the teams are delivering well, so it seems to be working.
For us, Scrum Masters started as positions and evolved to roles as we became more Agile mature. We took the responsibilities of a Scrum Master and divided out the coaching / teaching parts from the facilitation / impediment removing parts. This works well for us allowing the teams to feel self-managed and allowing them to mature at a sustainable pace, as coaching has become something asked for rather than imposed upon them. It also allows more team members to experience the role, as many of the teams will rotate Scrum Master at set time periods. And we’ve found that any type of delivery team member can be a Scrum Master. We have business analysts, developers, and QA testers all being Scrum Masters. We’ve also found that even the coaching / teaching is staying within the delivery teams with the Scrum Masters, as the ones that gravitate to that role are the ones interesting in learning Agile principles and imparting that learning upon their teams.
Finally, the bottom line that makes management happy is that we have less people doing the same amount of work. We have sixteen delivery teams. Without the need for dedicated Scrum Masters, we’ve saved the need to have sixteen more people and with a fixed budget, that really breaks down to being able to have sixteen delivery teams, rather than only having thirteen teams because we’d need those extra people to fill a position that’s really a role.
My concern and the reason for this article, is really a warning to all of you out there beginning your Agile journey. If you hire a slew of full time Scrum Masters, which is happening at least here in St. Louis, you need to have a contingent plan as to what you’ll do with them as your delivery teams mature. And at least here, most of the Scrum Masters being hired are coming out of a project management background. Nothing wrong with that, but again, be prepared to answer the question, “Okay, now what do we do with all these PM type people that used to be Scrum Masters?”
About the Author
Brian Lawrence is currently an IT Director at TriZetto Provider Solutions in St. Louis, MO, where he is responsible for several Agile and Kanban product development teams, as well as application architecture. He has been a process junky since the days of Edward Yourdan. During his career he’s taken development organizations through several methodology transformations, including Rational Unified Process, Essential Unified Process, and Agile. He loves process improvement and looking at ways of developing software better, faster, and cheaper. His current passion is looking at ways to manage within an Agile environment.