Do You Need a Scrum Master or a Coach?

I was talking with a former collegue the other day about his desire to bring in a Scrum Master to help with their move to Agile.   They had a pilot team running using a home-grown implementation and he felt it was time to bring in some outside help.

As I collected more data, it became clear he was looking at a larger transformation effort.  This particular organization was large and complex (~300 people in the IT department alone) and the nature of their industry breeds more conservative and political culture which would make transitioning less about “Agile” per se and more about Lean.  Arguing about what is Agile and what is Lean isn’t the focus of this post, it’s simply a matter of what approach to take for the transition.

So what is a coach going to give you compared to a Scrum Master?  Scrum talks about a Scrum Master as the team facilitator, someone who is there to protect the team, remove obstacles and help the team function better.  Essentially the scope of a Scrum Master is local optimization for the team.  Once the team is optimized other business problems are going to be exposed and depending on the expectations that have been set, this can be a good thing or enough to kill your adoption.  

A coach, on the other hand, will be focused on optimization of the organization.  Often they are working and thinking on multiple levels and deeper when team output is exposing other organizational dysfunctions.  Team symptoms such as bad estimates, missed commitments and poor quality are indicators there are larger organizational nuts to crack.

You’re Looking the Wrong Way

A client I’m working with had asked for me to put together a session on splitting stories and backlog grooming because they couldn’t figure out how to make their stories small enough to get done in a sprint.  Management’s perspective was that the team couldn’t estimate properly and kept missing their commitments.  I suspected this wasn’t really the problem and it was a great opportunity to help the team become aware of what the issues likely were.

After the session, I talked with one of the BA’s to collect more data about a particular story that ‘was impossible to split’.  She explained to me that this story had about 30 different scenarios (it was a billing application with complex billing rules per state) and they couldn’t split it up since all the work had to get done for all states for the release.   First I suggested the usual way of splitting, implement the changes for a company that has one facility in one state and go from there.

She said it wasn’t possible because there was so much effort to fully regress the application that they would have to make each change, manually regress the changes for all scenarios and then fix whatever got broken.  Then I asked her about how they test the application and she mentioned that it’s all manual and very complex.   I said it sounded like a case of 5% “programming work” and 95% “testing work” and she agreed.   This problem was compounded by not wanting programmers to be idle since there so much testing effort, so they would make the changes, the testers would test the changes and the programmers would move on to the next batch of changes.

New issues would be tossed back into development while they were working on the next set of changes and this created a vicious snowball effect that was raising frustrations for the team and management as the release date got closer and closer.

The System is the Problem, Not the Team

To summarize, the team asked for help on splitting stories and the problems exposed were much more severe:

  • Silos on the team: they felt they had no other option, the SM on the team promoted this behaviour
  • Lack of testing automation: automation doesn’t solve everything but no unit tests and no automated regression resulted in extremely long regression periods
  • Complex code: talking to the programmers revealed extremely complex and tightly coupled code which made even making changes difficult let alone testing and regressing. Ever hear programmers say the code isn’t testable?  That was there reality in this case.
  • Management frustration: desire to clamp down on the team more since management didn’t trust their estimates.
  • Un-realistic release dates: releases were missed frequently all the while ‘gotta get done by this date’ attitude was still very much alive and well.

In this particular scenario a Scrum Master will focus more on local optimization yet the impediments the team is facing  are organizational problems typically outside the scope of what a Scrum Master is.  A Scrum Master will help the team optimize their process while a coach will be operating on multiple levels to figure out the root cause.

Another advantage a coach will have is that the scope of their engagement will extend beyond the team.  To be blunt, the people with the power and influence to help with change are more likely to listen to a coach than a Scrum Master as the intent of hiring a coach is bigger picture thinking than hiring a Scrum Master.

Tips and Conditions for Being Successful with a Scrum Master:

  • you’re starting with a pilot project and the scope is the team
  • you have a tight budget to experiment with agile
  • your organization is small(er)
  • politics aren’t a factor
  • flatter organizational hierarchy

Tips and Conditions for Being Successful With a Coach:

  • you have no idea what to expect by ‘going agile’
  • you’ve heard the good things about agile and want to see if you’re ready
  • large(er) organization with taller hierarchy
  • you desire training at all levels (organization, management and team)
  • suspicion you’ll need to ‘sell agile’ to management
  • organizational politics are an issue

In short, it’s really easy to under-estimate the time, effort and complexity of transitioning to Agile.  A coach is going to help you understand the impact of the transition and help figure out a plan that will work for your organization.  There are many tools and practices available in a coach’s toolbox that a Scrum Master might not have.

When you’re ready to try Agile, take a bit of time to figure out what skillset you need and talk to people otherwise you can end up just making the hill a whole lot harder to climb later on.

  • http://www.lookforwardconsulting.com Carlton Nettleton

    I like your article, but I feel you are misrepresenting the role of ScrumMaster. When I teach Scrum, I explain the role of the ScrumMaster is to both look in to help the Team and look out to help the organization remove impediments. In the beginning, SM spend a lot of time helping Teams. Over time, as the Team becomes more self-organizing, SM spend more time with the organization. However, if an SM spends too much time with the Team, then the organization will not see the benefits of Scrum. Too much time with the organization, an the Team will not know how to make the transition to self-organiztion.

    IMO, strictly speaking what you call a coach is more accurately described as a consultant – someone who has specialized knowledge who is hired to fix a problem.

  • Jason

    Thanks for the comment Carlton. That’s the rub right? My CSM training talked about the role of the SM being a team focus. Through experience I found that not to be the case from my personal perspective but I have often experienced the SM seen as just another PM who happens to know about Agile. Perceptions can be hard to change.

    As far as consultant vs coach, personally I don’t see much of a difference. Coach is just a fancy sounding name for a consultant that specializes in agile practices. In any case, when I go into an organization, I’m there to help them improve as an organization.

  • http://www.lookforwardconsulting.com Carlton Nettleton

    I have met many of the PM turned CSM and they are what you describe. In fact, I have met two PM who were CSM that I would NEVER let near a Scrum Team. IMO, Scrum was just a means for them to drive the Team to THEIR goals and outcomes. There are good PM out there who care about the people, they just need good mentoring on what Scrum really is about.

    It is a shame the practice of Scrum is quite weak and the education of many SM is so poor.

  • Jason

    I think the education is so customized that it’s difficult to convey a consistent message. Plus it’s only 2 days, can’t expect much out of that. I really had no idea what Scrum really meant until working in the field after the training for a while.

    Having said that, a coach is more of a business consultant in my opinion. I don’t think the people with influence to change are going to listen to just a Scrum Master in most cases, especially in larger organizations.

  • http://noncomplexstuff.com Vincent Tencé

    I agree with Carlton. See my comment on my blog http://noncomplexstuff.com/2010/10/07/the-scrummaster-role.html.

    It’s sad that your CSM training talked about the role of the SM being a team focused. As you figured out by yourself, it is much more than that. In my CSM classes, I make sure people understand that change is the role of the ScrumMaster. Let’s carry on transforming the world of software development!

  • Jason

    I would agree for small, flat organizations with a single team that a Scrum Master is sufficient. In more complex organizations a Scrum Master in the sense of what CSM courses teaches isn’t likely to have the skills, power or influence to change the organization. If the intent of the CSM training to prepare candidates for organizational change why do they offer CSC?

    While I don’t want this to be yet another certification debate, a 2 day training course is no where near sufficient to build a toolkit for organizational change.

    While it may have been Ken’s intent for a Scrum Master to be an organizational change agent, it doesn’t fly in the real world when you’re dealing with larger companies and complex structures. It would be great if it was that simple but having worked in small (15-ish people) and large enterprise (30,000+ people) organizations I’ve experienced first hand that it isn’t.

  • Pingback: non complex stuff | You need a ScrumMaster to change the old style()

  • http://agileyammering.wordpress.com/ Lilysonherway

    Be careful of the person who calls themselves a coach though.  More and more I’m seeing “coaches” who I wouldn’t let near a team as a Scrum Master.  An org may need a coach, hire a coach and end up getting a chucklehead who messes it all up.