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:
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.
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!