Are ScrumMasters the new bottleneck?

Posted on December 3rd, 2009 in Agile by siddharta || 13 Comments

In the “old world” there was a certain flow that information would take.

Say you are a developer and you had a question regarding the testing. You would bring up the issue with the development manager. The dev manager would bring it up with the test manager in the next meeting (you, of course, were not invited). The test manager would ask a tester. Then the information would flow back in reverse until you got your answer.

You <-> Dev Manager <-> Test Manager <-> Tester

What if you had a question for the customer? Then it would be something like this

You <-> Dev Manager <-> Analyst <-> Customer

There are rather obvious sources of waste here. The Dev Manager is a bottleneck to the the entire conversation. Not surprisingly Agile processes disbanded the middlemen. So it is encouraged that the information flow is like this instead

You <-> Tester

You <-> Customer

All well and good. Conversations are better and waste is eliminated.

However, I’m noticing a pattern emerging, especially between onshore-offshore teams that have adopted agile recently.

Lets say you have a blocker that needs an input from a team member in another team. The information flow is like this – You’re stuck on something, so you raise an impediment. The ScrumMaster takes the impediment along to the Scrum of Scrums where it is passed on to the other ScrumMaster. The other ScrumMaster gets the answer from the team member and passes it back. Impediment closed. In other words

You <-> Your ScrumMaster <-> (Scrum of Scrums) <->  Other ScrumMaster <-> Team Member

Look familiar?

Similarly, 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

Hmm. Anyone see the parallels?

You <-> Dev Manager <-> Test Manager <-> Tester

You <-> Your ScrumMaster <-> (Scrum of Scrums) <->  Other ScrumMaster <-> Team Member


You <-> Dev Manager <-> Analyst <-> Customer

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

Are ScrumMasters the new bottleneck?

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

13 Responses to “Are ScrumMasters the new bottleneck?”

  1. Olga Kouzina Says:

    I wouldn’t say Scrum Master or even Dev Manager is a bottleneck. Peer-to-peer on the level of tester-customer will lack the overall view for the whole project and other underlying issues, not related to this particular one, of which you might be unaware of – and Scrum Master knows them all. So, it’s not waste and bottleneck. It’s value – not obvious at a glance – but value.

  2. siddharta Says:

    Olga, I think most people will ask the appropriate person. Sometimes the ScrumMaster has the information you want, then you ask the SM. If its something to do with story definition, you may want to ask the PO or customer. The SM may not be the right person to ask here. So why should the SM sit in the middle when they are just going to forward the information to the PO?

  3. David Bland Says:

    You Your ScrumMaster (Scrum of Scrums) Other ScrumMaster Team Member

    Add 9 1/2 hours of time difference, and it is like pouring molasses all over your velocity.

  4. Tobias Mayer Says:

    You misunderstand the nature of the Scrum-of-Scrums meeting. So do many others. This is not a meeting for ScrumMasters, it is a meeting for team members. Representatives of each team meet together to solve problems at an integration level. No middleman there.

    If the team has no access to the PO you are not doing Scrum. Simple. Calling someone “PO doesn’t make it so, and if the person doesn’t collaborate with the team you lose all possibility of creating the right software.

    The only potential bottleneck when Scrum is done well is between the PO and the real customer (if they are not the same person). When a PO is not empowered to make decisions this can cause a bottleneck — and it also causes a disempowered state for the whole team. PO’s MUST be empowered to act on behalf of the customer/s and not be a go-between.

    The ScrumMaster is not a go-between of any kind. He is an agent of change within the organization, supporting his team and educating and socializing Scrum outward towards other parts of the org. Doing his job well he has no time to be in the way of the team and any person or group they need to talk to.

  5. siddharta Says:

    Tobias, I’m not saying anything about the theory of Scrum of Scrums. Just because its not supposed to happen doesn’t mean it does not happen in the real world. Being in India, many of the agile folks I talk to tend to be part of offshore development teams. I’m just pointing out a pattern that I’ve observed.

    Whether you call it Scrum or not, it is rare to see a junior developer have direct access to the PO who is often an executive from the parent/client company abroad. Invariably information flows through the ScrumMaster, simply because the SM is usually the seniormost person who is local to the team.

    What has been your experience with companies in this situation?

  6. Alan Dayley Says:

    Very interesting observations! Thanks for publishing them.

    I have to echo Tobias’s assessment that if a developer on the team does not have access to the empowered Product Owner, it’s not Scrum. Doesn’t matter if the PO is halfway around the world and the developer is an un-degreed intern. The PO and any team member need to have direct communication.

    It’s great of you to voice what you are seeing. More and more ScrumMasters and companies are dealing with distributed teams. And some teams have politics in the way of communication even in the same building. The trick is to find a way to solve the disconnect so the bottle neck is not present.

  7. SmittyScrumMaster Says:

    @siddharta What you are observing is an offshore company injecting their management style because they believe they need to do this. It’s a common practice for them try to translate a low-context world to a high-context world. In no way does this = Agile or fit the SCRUM methodology.

    Still there’s no easy way to stop it as long as you live in a high-context world. In the past, I’ve managed this by hiring a local off-shore coordinator that speaks to the off-shore team and accepts work from them in the form of CVS patches. The off-shore team may be run as it’s own SCRUM team or not, but the off-shore team still has it’s own velocity and that velocity is taken into account when planning new iterations. The overhead management is still there, and is still a challenge, but it’s planned for.

    Hope this helps.

  8. Tobias Mayer Says:

    Siddharta, as you describe this “real life” you are describing 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. Remember, Scrum is about continuous improvement. If what you are seeing feels wrong, reflect on it with the team and make a decision to change. And then take action towards that change. Small steps. You have to begin by understanding the true roles of the SM, the PO and the Team, and also to understand the mechanisms of the ceremonies, including the Scrum of Scrums. Only in understanding can you guide your team towards improvement.

  9. siddharta Says:

    Hi Tobias, this isn’t my team. We are colocated :) It’s just something that I noticed when talking to folks here. You’ve been to India a few times. Have you seen any offshore teams that allow direct communication between a junior dev and a PO who is abroad?

  10. David Harvey Says:

    Hi Siddartha, Tobias:

    “Have you seen any offshore teams that allow direct communication between a junior dev and a PO who is abroad?” I’ve seen plenty of organisations where that’s not prohibited, yet just isn’t done, for cultural or sometimes personal reasons. It’s a coaching responsibility (which a Scrum Master may want to take on) to give teams and individuals permission to break out of dysfunctional self-or-culture-imposed patterns, and it’s a team member’s responsibility to rise to this challenge.

  11. Jaibeer Malik Says:

    Hi Siddharta, I may agree that I have seen the pattern but do not agree on the point that SM being the bottleneck, the problem may be with the emerging pattern (some may say it is new distributed agile pattern, I would say it is not at all Agile).

    >>”However, I’m noticing a pattern emerging, especially between onshore-offshore teams that have adopted agile recently.”

    Some time back, I posted thoughts on the similar topic “Story of Scrum: More of a selling point than actually doing it right”

    Definitely the distributed agile has its own challenges and different organizations handle those in different ways. Some put few experienced people to hide the state of team agility, like you said use SM as single point of contact and some organizations do it the right way.

    The problem itself may be somewhat/somewhere else:

    -Team not much aware of the true spirit of Agile
    -Management not yet ready to change the old mindset of projecting SM as Manager and hiding team progress from client/PO
    -Team not using scrums of Scrum properly (removing impediments across teams etc.) and intra-team collaboration being minimum.
    -Communication is backbone of distributed-agile, whether junior or senior member. Either equip junior members to handle that or you don’t have the right people on board, the organization do not the strategy in place to do the distributed agile or all the concerned parties are just happy with what is just working).

    I also mentioned the similar problems in the above post link. For some teams the new pattern works fine which may be because either they do not know the right way, have not experienced it yet or may be it will take some more time for them to learn themselves and understand it.

  12. siddharta Says:

    Jaibeer, thanks for the link to the blog post and your points. Completely agree with them.

  13. Anonymous Says:


    Pretty interesting point!

    I think we are two focused on what Scum is and how it is implemented\adopted within a particular team. Regardless of term you prefer to use – Scrum Master, Dev Manager, or some stuff like this – it is important to realize that the offshore teams usually doesn’t exists on its own account. They belong to organizations which in turn has its own rules on how to make the business. And the most important one is to keep the communication channel under the control. If they don’t, organizations itself might become the impediment. From this perspective, it is doubtful that the offshore teams would ever be able to implement “pure” Scrum since there is always be a person who decides who of the teammates is allowed to talk to the client and who aren’t.

Leave a Reply