Get certified - Transform your world of work today


Scrum in Disguise

27 May 2014

Vandana Roy


We have come long way in Agile and Scrum. There are many organizations that have adopted Agile -- but are they really following it? The organization as a whole, yes; but there are parts of the organization that have not adopted Agile completely and are still resistant. Teams are following Waterfall disguised as Scrum and often complain that they are not succeeding. The most common signals of Scrum in disguise:
  • Teams rely on either ScrumMasters or functional managers to divide the tasks for them. In many cases the functional manager prefers him- or herself over the team for splitting tasks.
  • Key Agile ceremonies, such as release planning, grooming, and sprint planning meetings, are conducted without the entire team's involvement.
  • Functional managers are always present in retrospective meetings; this can hamper open input and candid feedback from team members.
So, as ScrumMasters, how do we handle these challenges? I faced this situation and I realized that if you resist and try to educate the team about Scrum, then the working environment just turned hostile. So I had to find a better solution to handle the situation. I could think of two approaches:
  1. Be observant; let the functional managers and team follow what is right according to them. Wait for the team to fail and then you can step in and coach the team on how following core Scrum principles would have prevented failure in the first place.

    This scenario needs lot of patience (to look for the wrong moves) and alertness (toward pointing out major mistakes). However, the major downside is that it will take a long time for the team to realize that their method is failing. Worse, there is the possibility that the team will never realize this and never agree that they are wrong, as they continue to strongly believe in their approach.
  2. Alternately, allow the team to follow their methods, which are not totally Scrum, and support them to an extent, but enable them to see the mistakes early. This one is my favorite, as it addresses all three challenges mentioned in the beginning.
To a certain extent, I would let the teams follow processes they believed to be correct, though they may seem wrong from an Agile perspective. This ensures that, as a team, they fail fast. I would also break the tasks down for the team myself and give highly challenging estimates that the team may not be able to meet. When they revert to stating that the estimations are not correct or that there are more tasks to be added, then I'd tell them that, in my opinion, the tasks break down properly and the estimations are accurate; and if the team gauges its work differently, then perhaps team members should have listed their tasks and given estimates. Eureka! The team realizes they should themselves have done tasking and estimation rather than my doing it for them. My objective is fulfilled.

When functional managers see that sprint goals are not met and that tasks are not being completed, they retrospect with team members and understand that tasks were not complete because estimates were inaccurate. Since this comes from the team, the functional managers are bound to give them a chance to do tasking and estimation. Hence the problem with functional managers not letting the team be involved in estimation and tasking is solved.

The team has now committed to doing estimation and tasking, but how do they do so without knowing about the story details? The team comes to me looking for a solution, and I explain the value of attending key ceremonies such as release planning and grooming and the sprint planning meeting. Eureka! The team realizes and agrees to go for all the ceremonial meetings and convinces functional managers. Another problem solved!

The functional managers always insist on attending retrospectives and they never agree with the fact that team members will not open up in their presence. Due to this, team members lose interest in retrospectives and think they are a waste of time. To solve this problem I asked the functional manager to do me a favor by not attending just one retrospective, and I promised to share the results. In one such retrospective I told the team that the functional manager would not be able to attend and that the day's retrospective was totally confidential. The result of the retrospective was that the team gave more feedback, shared more pain points, came up with action items, and agreed to act on those action items. After that I did a comparison between the retrospectives held in the presence of the functional manager and the one retrospective held without a functional manager, and shared the results. I was able to provide substantial evidence to the functional manager that his absence let the team improve on its own by identifying their mistakes and looking for improvements, and that overall it turned out to be productive for the team's performance.

In sum, conflicts are bound to happen when ScrumMasters and functional managers work together on a project. Their roles overlap a lot. Another sticking point is that ScrumMasters always support and want to implement Agile, whereas functional managers would not prefer any specific method; their primary concern is about team performance and deliverables. It is the ScrumMasters' utmost responsibility to convince the functional managers just how beneficial Scrum can be -- if followed correctly and passionately!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.9 (10 ratings)


Gurpreet Singh, CSP,CSM, 5/27/2014 8:08:49 AM
Agree with your thoughts! This is a continuos battle ... but we need to keep fighting...

Nice article!
Neeraj Malkoti, CSP,CSM, 5/29/2014 2:10:27 AM
Interesting observations, thanks for sharing.

These seem classic psychological reactions to change ( denial, confusion, anger) but with coaching & perseverance- will slowly lead to acceptance & confidence.

Functional Managers ( Assume you meant Product Owner?) have lived in command-control mode for all these years. It's very natural for them to have a Point of Contact & Scrum Masters become obvious choice (smell #1).

In addition to what you mentioned, would you also like to try below:-

1. Foremost, everyone should receive coaching on Agile & Scrum. Everyone ( including PO, Teams, Leadership group, business partners, stakeholders) must be aware on basic concepts (ceremonies etc) but more importantly WHY adopt Scrum/Agile?

- A well executed coaching (classroom training?) will lead to common understanding & break resistance.
- A buy-in (consensus) will reduce conflicts moving forward.
- Learning together ( classroom sessions) will enable face to face interaction.
- Any questions (there will be a lot!) could be answered by expert coaches, which reduces ambiguity.

IMHO, failing often & then understanding values, principles & ceremonies will only stretch "confusion/ chaos" phase. I could imagine this is discouraging for teams & may result in high attrition (as members find lack of direction/vision disturbing).

You may want to consider taking first few steps correctly. As teams are mature, they become more willing to experiment/ fail/ learn.

2. Scrum Master need to detach themselves from PM mode & instead focus on enabling direct communication between PO & teams. They can facilitate discussions & ceremonies.
They should coach PO & promote idea of " no special people" (including themselves).
If there anything PO wants from team- he should reach out to team directly.

3. Functional Manager (assume, PO?) & Scrum Master ( SM) rarely have any overlapping responsibilities.
- SM serves PO & team both. SM coaches team on agile/scrum principles.
- PO is the sponsor who gives team a vision to implement.

Scrum team includes PO, SM & Feature team.
It's one team bound by a common purpose. & it's Scrum Master who needs to drive agility (change mindset from confrontation to collaboration)

If there's any battle, then its between Team (PO+SM+FT) & business challenges.


Vandana Roy, CSP,CSM, 5/29/2014 11:54:46 AM
Hi Neeraj,
Functional Managers I was talking about was not PO's but the development managers and Dev managers do exist in almost all the companies, howmuch ever coaching you want to give and tell them that in reality only 3 people exist (SM PO and Team). Many organizations have dev managers and my article is all about convinving them about following SCRUM. Three suggestions you gave are really good but the work with team and PO, with dev managers we need additional steps and that is what I have mentioned.

I totally agree with your point "but with coaching & perseverance- will slowly lead to acceptance & confidence." with that we also need lots of patience and faith.

Neeraj Malkoti, CSP,CSM, 6/4/2014 10:02:09 PM
Hi Vandana,

My understanding is there are no Development managers in SCRUM.

Refer Agile principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Our department consciously eliminated Development manager role on Day 1 of adoption. So they do not exist in all companies.

I however feel that such roles may exist when you start your transition but they must be phased out asap else adoption will fail.

For model to succeed, power structures, first level managers, specialist roles must be made redundant & teams need to get empowered.
Easy said than done.

Good luck!


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up