InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

When ScrumMaster Becomes the Impediment ...

Posted by Vikas Hazrati on Dec 16, 2009

Sections
Process & Practices
Topics
Agile ,
Agile in the Enterprise
Tags
Scrum Master

A ScrumMaster as the name suggests is the guardian of the scrum process. He is a change agent supporting his team besides educating and socializing Scrum throughout the organization. He ensures smooth functioning of the team by eradicating impediments and keeping the team shielded from external distractions. However, in certain scenarios, Agile teams feel that the Scrum Master is the biggest impediment.

Siddharta described a scenario, that he finds prevalent in the offshore teams due to cultural hierarchy and traditional communication strategy. Here, the ScrumMaster ends up becoming a bottleneck between the team and the customer.

He suggested,

Many teams are touchy about giving the team member access to the customer or even the Product Owner (especially if they are remote). So the information flow is like

You <-> ScrumMaster <-> Product Owner <-> Customer

Tobias Mayer reacted to this by suggesting that if the ScrumMaster is becoming a go-between for the teams then the root cause of the issue is elsewhere.

[This is] a simple command and control management style. Calling someone a ScrumMaster doesn’t make him one, especially if he is deeply ingrained in “old thinking” and is not being coached away from that.

Jaibeer Malik ,echoed Tobias when he mentioned that the cause seemed to be the way Agile is being implemented and followed. He stressed on communication being the cornerstone of an Agile process and all members of the team should be equipped to communicate with anyone on the team without going through the ScrumMaster.

Roberto Fasciolo, however pointed out other reasons where the ScrumMasters were falling into the trap of traditional ways of working. He observed the following pitfalls,

  • Scrummaster committing to the sprint backlog – This is particularly prevalent when the ScrumMaster is also the team member. The team simply agrees to what he has to say.
  • Scrummaster telling the team what to do instead of coaching - This happens many times when the scrummaster is a former project manager. The effect is that the team might become completely dependent on its scrummaster.
  • Scrummaster acting as proxy between the team and the product owner – This is similar to the situation that Siddharta described and is prevalent in distributed offshore teams.

Mike Cottmeyer added that if the ScrumMaster is just keeping track of impediments then he is the impediment. A good ScrumMaster should not only be able to track and remove impediments but also be an Anticipator who could anticipate problems and work with the team to ferret out things which could go wrong.

Cesario Ramos described an interesting situation in which the ScrumMaster is so involved with the team apart from his ScrumMaster tasks that he becomes an impediment by being on the critical path.

The catch here is that the Scrum master is doing “valuable” project tasks. He or she is trying to do work which other team members might depend on to do their tasks. It can even go so far that the Scrum Master gets the feeling that they can’t get the Sprint done without him/her pitching in and picking up those all important / difficult tasks.

Boris Gloger, also had a similar story to say when he suggested that ScrumMaster (SM) does not mean (S)uper (M)an. A scrum master who is not doing his role properly or is trying to do multiple roles apart from his main role is actually an impediment to the team.

Hence, there are many situations in which a ScrumMaster, knowingly or unknowingly would impede the performance of the team. The key lies in identifying these situations early and take corrective action while there is still hope.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

I have worked with that ScrumMaster! by Selena Delesie Posted
Re: I have worked with that ScrumMaster! by Ben Liew Posted
Re: I have worked with that ScrumMaster! by Vikas Hazrati Posted
  1. Back to top

    I have worked with that ScrumMaster!

    by Selena Delesie

    You stole the image from my mind of a ScrumMaster I have worked with who was an impediment in all of these ways. So much harm is done to the team when behaviours like this occur; the environment created is hard to recover from (particularly if it is a team new to agile - they have no idea how much better things could be for them). I recently posted on my situation, looking more in-depth at how to discern if a ScrumMaster was helping a team or not (selenadelesie.com/2009/11/15/is-my-scrum-master...).

    Thank you for talking about this!

    - Selena

  2. Back to top

    Re: I have worked with that ScrumMaster!

    by Ben Liew

    Unfortunately, I've worked with a Scrum Master like that too. As a result of his unwillingness to listen to others, we have absolutely no meaningful delivery in the 6 months duration we've worked using Scrum. Since this is my first (and hopefully last) time I've worked with Scrum, I've developed strong stigmatism towards the methodology.

  3. Back to top

    Re: I have worked with that ScrumMaster!

    by Vikas Hazrati


    I've worked with Scrum, I've developed strong stigmatism towards the methodology.
    <blocklquote></blocklquote>

    ouch! that sounds a bit harsh and more like attacking the symptom than the root cause. I guess it would be better to do a retrospective on what is not going well and take corrective action. After all the methodology is also executed by people. If the people are executing it the wrong way then there is a bigger concern with the people than the methodology.

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.