What is a Scrum master to do when management do not support Agile and Scrum?

Question

Scrum has come out of R&D. The organisation has scaled significantly. The organisation recruited more developers, Scrum masters and product owners (POs) and more managers.

All of the managers talk like they understand and back Agile and Scrum, however this is not true.

Scrum masters are all struggling to even coach POs to use a single backlog. POs are also project management and reporting incorrectly to management in order to look good.

What is a poor Scrum master to do?

I do know that this can be the norm, Agile coming from R&D, but not from the top down and senior management don't understand and don't support it.

This leaves the likes of developers and Scrum masters and some POs in a very difficult situation. The Scrum master, for example, is unable to convince the PO to use a single backlog, and management don't mind, so there it ends.

Answer 1

You have three options:

1. stay and fight for a change;
2. give up and just go with the flow;
3. leave and go join a company that embraces the principles and values you have.

From what you mention, it looks like you were in a smaller company that was nimble and using Agile. Then the company started growing and brought in people to support more structures within the company.

Bringing in managers is the usual approach. However, since these people are brought in to support the organization, they should have the right mindset to do so in a way that agrees with the "way things are done" inside the organization.

If an Agile company wants to remain Agile when growing, they need to bring in people with the Agile mindset. It seems you onboarded traditional managers, who will do what they know best, i.e. use traditional management techniques.

It also seems that you were Agile because "it happened", not because it was a method you wanted to embrace as a way of working and growing, otherwise you wouldn't have hired traditional managers.

So for upper management this looks like "using whatever it works". If you have Scrum, or a hybrid, or whatever you are doing and lying that you are doing something else, that all is nice and dandy for management.

Now back to the options you have:

1. You can stay and try to educate the people on Agile methods, principles and values, try to increase transparency, communicate clearly, and try to bring back collaboration in a company that is moving thowards a more rigid structure. This won't be easy. If management does not want this and doesn't support it, and gets annoyed when you try to suggest it, then you are fighting the fight alone. You need allies in this. Not understanding is one thing, but not caring or intentionally going the other direction is another. So if you preach something else than what people want to hear, you just place a big target on yourself to be fired.
2. if you can't beat them, join them. You just give up and support the existing work, and play the same game that they do. Work is work, so suck it up and do it! Without management support you can't change a company. And if the company does things a certain way, you need to fit in or... use the third option.
3. Search for another company where the working environment is more in tune with what you care about. This is probably the last resort, but if you can't educate them, and dislike joining the way things are done, then what option do you have?

I haven't seen many Agile companies, but I've seen many throwing the buzzwords around. Sometimes because they don't know any better, and sometimes because they just want to show a different facade to others, without putting in the work to make it real. If you can win people over with arguments, you are in a situation where people didn't know better. If you get flat out shut down when coming up with arguments and people care about the facade, office politics, and climbing the corporate ladder, then you won't be able to turn the ship around.

Answer 2

It can be hard coaching "upwards" to educate more senior people in your organisation. Many managers, especially those from traditional (less Agile) backgrounds, believe they know more about the development process than those doing the work. And even for agile development organisations, they tend to act as the interface to non-agile constraints such as manufacturing, marketing and training functions who expect a clear roadmap of planned upcoming features they can expect.

One strategy in this case is to cultivate a good relationship with more senior management than those you need to convince. It does sound counter-intuitive, but this level of management is likely to be more aware of the importance of the interfaces between groups of people.

When you have the support of a more senior manager, try to get an external trainer to run a course for the entire organisation (yes, including the development team who are already using agile methods). In my experience, the middle managers are more receptive to ideas from outside, as this gives them some sort of credibility than something that appears (to them) to be "home-grown".

There are advantages to having managers and developers in the same training course. This isn't an exhaustive list (and will depend on the nature of the training; I'm envisioning a course that has plenty of practical exercises in the content):

• Each group knows what the other has been taught, improving future communications because they now have a common language.
• Managers can get some experience of the nature of agile delivery, and developers can discover what kind of communication is useful to management.
• When the current practice differs from the course content, that can be discussed - find out why theory and practice differ, and whether the reasons are still valid.
• Personal interactions can be improved by all levels working together as equals for a short time, breaking down perceptions of hierarchy.

If you take this approach, be prepared to spend plenty of time selecting a trainer that you believe will be a good fit. Don't just pick the first one you find; explain clearly your own situation and ask them in detail about how the course content will be tailored to suit. Any reputable trainer will be willing to spend time to ensure they deliver the training you actually need.

Answer 3

Communicate, convince those that you need to work with that something needs to change if the agile process is expected to actually bring fruit. If that does not work, leave for a job where you can be a Scrum Master not only by title. (Of course, this isn't meant as hard advice but as an option that you should consider.)

Scrum and other agile approaches depend on collaboration and shared understanding of the processes. If the organization refuses to embrace agile values from its core it is bound to fail (or somehow stay alive with its old methods and some thin coat of agile paint.)

Answer 4

You are assuming "they" are the problem for not supporting your ideas, affecting your ability to deliver. They likely feel your ideas do not support them, affecting their ability to deliver. Recognize that what matters to you and what matters to them are not the same. Recognize that there are reasons why they are resistant, seek to understand what their needs are, and deliver solutions that work for everybody. Right now it looks like you are only trying to deliver a solution that works for you.

As an example, "reporting incorrectly to management in order to look good"... everybody wants to look good of course. Ask yourself "Why do they need to report incorrectly to look good?" "Why would reporting correctly not make them look good?" You may find that reporting incorrectly is an intentional strategy to protect the team because the team is not performing well. If the team performance is raised to meet expectations, then reporting incorrectly may no longer be required. They may think that this is helping the team by avoiding criticism for poor performance.

Since you mention having a single backlog twice, this seems to be a sore spot. Ask yourself "Why this is so important to me?" Is it because multiple backlogs are creating issues for your team? or is it because you learned Scrum dogma says you should only have one backlog per product? If it is creating issues for your team, why do they feel multiple backlogs work better? If it is for dogma, why are you so attached to it and are there alternatives? Is the team shared across multiple products, does your version of "product" match their version of "product", are they working from a different version of Scrum?

In this particular case I'd suggest learning more about scaling Scrum. In particular there are legitimate cases for multiple backlogs, hierarchical backlogs, combined backlogs, and other variations that add depth to the One Product=One Backlog rule. It may be that they are working from one of the scaled Scrum methodologies. It may also be that studying the challenges of scaling Scrum highlights the real issue such as silos becoming entrenched rather than cross-functional teams, or "product" not being defined well based on the number of products and number of teams, or just a general lack of collaboration (which Scrum will not fix by itself). Executives often don't have time or visibility into this level of detail, and often don't have the ability to change small things without using overly big controls. Individuals often can make these changes by simple collaboration.

Answer 5

The official role of Scrum Master ends before the PO's reporting of results to upper management. If they are misrepresenting above that line, the official role of Scrum Master can do nothing to help.

Of course, we all know how important the unofficial roles are. Your job is to make the Scrum work smoothly. That can be thought of in a very narrow way or a very wide way.

Your POs and Scrum Masters should be a team (even above and beyond what the literal reading of the Scrum guide suggests). The serve different roles in the effort and one falls without the other. If you feel the POs aren't on your team, then that would be the first thing to resolve. This is unrelated to Scrum. This is normal team management sort of stuff. Once you feel you are a team, the next step is merely to make the team succeed. But you have a choice in how it succeeds. You've mentioned struggling to convince the POs to change their ways. Continue to struggle. But pick your battles wisely. If you truly believe in Agile, then the best thing you can do to make the team succeed is to demonstrate why leadership needs to actually think agile. Focus more on the POs (or sections of the POs requests) that are most amenable to being made more agile, and create examples of success that the POs can share with the leadership. Raise up those that do it well. Merely don't push down those who have chosen a track that must fail. (Help them too, of course... but this is written from a "how do I fix this problem" perspective not an overall "how do I do my job in the company," which is a much wider topic).

As an overly simplistic example, I ran into a situation where a PO (with whom I already had the strong team relationship established) strongly directed one of the team members to work multiple stories simultaneously. In fact, nearly all of the team member's stories were active at one point during the sprint! This ran afoul of how I felt agile was best implemented. I'm a fan of the idea of working one task at a time (with allowance for exceptions) because it makes the team's work more transparent. With a glance, the sprint backlog can tell you a lot about how things are going!

I talked with the PO and the team member about the situation. They debated a bit, and the decision was that this multiple active story approach was indeed the right approach for this situation. So, as Scrum Master, what I told them was that this practice ruins the transparency that comes from monitoring the sprint backlog, so it was on them to make sure they communicated transparently between each other, and that they should make sure to communicate more often than usual. The transparency is the important part, not the means that transparency is achieved nor the buzzwords associated with it!

This takes resources. Both of them had to spend more of their time on the overhead of maintaining transparency. So there's an encouragement to do future stories "by the book." It got what the PO needed. And, for the rest of the sprint, I got to more or less ignore that set of stories and focus on doing Scrum better with the remaining parts of that sprint.

I like to think there's several takeaways here, but the one that I think stands out is that the message of "This isn't Agile, but we'll let you make the product you need to make" sells better than "This isn't Agile, so we need to fix it." In the end, business is not Agile. Business is business, whatever that happens to entail that day. I'd rather explain to a PO that they're not being agile, and what the consequences of that activity will be as opposed to trying to force them to be agile. Often the PO can understand the consequences and make a business decision about it. That's their job.

And, if you are constantly having to tell them that they're leaving agile behind, and the consequences of that, at some point they'll be in a position to start the discussion about how they are talking agile but not walking the walk. If they're succeeding, maybe Agile isn't right for the company (heresy!). If they're faltering, maybe that set of communications can form a backdrop for suggesting how to resolve it.

Answer 6

Keeping the development methodology out of it, any type of change in an organization requires strong leadership sponsorship. If you do not have that, maturing the change, whether it is the use of an Agile method or anything else, will be slow-moving or abandoned, likely the latter.

I would find it a huge waste of money to continue moving this forward until you have leadership support and someone at that level will assume the sponsorship role. That person needs to be trained, truly understand the benefits compared to the costs and risks, and own it with full accountability.

Agile is not special nor any different than any other organizational change. The principles of organizational change management should prevail here. Research OCM methods and deploy them.

Answer 7

We have been there. Done that. We lost a few battles and won others. The ones we lost, we could live with.

(I am intentionally leaving out what's already been covered in the other answers and only focusing on the "juicy details", in brief.)

When we were introducing agile to our organisation, they said they understood it, but they completely underestimated the effort it took to actually work that way.

We argued for 25% time of one of the developers on the team who wish to learn about all things process (or had a solid understanding and volunteered). This additional time is the "agile management overhead" i.e., the duties of a Scrum master that can take time away from engineering tasks.

The working agreement that was created by the team was that work items must exist in Jira (which we were using, but product managers were still adapting to it at the time). If something is not in Jira it won't get done and all teams would hold their ground on this.

Managers were notorious for backdoor favors, so making developers as Scrum masters solved that problem since no one wanted to argue with the developers!

The first step was to actually restrict all agile practices at the team level and capture as many metrics as we could regarding the process efficiency. Things like throughput, interruption time, average ticket size, number of bugs being reported, number of last minute tickets, etc. The information produced was eye-opening for senior management (although they didn't believe it).

Some rules of thumb/assumptions that helped start things out:

1. Assumed an "ideal day" size of 5-6 hours. That is, the team members should have 5-6 hours of productive time per day with 2 hours for other overheads, lunch, etc. This was the baseline assumption we started with.
2. Work was estimated against the "ideal day" benchmark, with a "range". So if something was 1 point, it was assumed to take 5-12 hours of work (1-2 ideal days). Same for other ranges.
3. Capacity was simply multiplied by the number of engineers on the team and we would fill up 75% upfront if possible. If we were more efficient, we'd pull in more work; else something would fall off. A five-person team was between (5*5*10 = 250 to 360 hours)
4. Carry over was strictly measured - tasks that we thought we could do but couldn't
5. Work was measured; rough start and end times so that we can calibrate if the 5-6 hours assumption was valid. So if something was logged at, say, 25 hours, it implied it was 5 points, and if we estimated it at 2 points we could see errors in estimations and discuss this in retrospectives. The average of all work gave us the ideal day size.
6. All measures of backlog size, current burn-down, iteration/release, etc., ticket throughput from backlog to delivery were all captured.

As you can see, these were done by Scrum masters and hence the ask for 20-25% time cutoff from their duties.

Most agilists dislike the notion of "hours"; but since the company had a more traditional management mindset, it was much easier to see hours than abstract "points" which lacked meaning outside the development team.

Some findings:

1. The ideal day for each team was actually 3-3.5 hours with a team having only 2 hours! Team members were called in for too many meetings and asked to jump on too many tasks and firefighting.
2. Carry over rate was about 20%! There were "live" bug fixes that would fill up about 30-40% of the queue (hence the 75% capacity limit).
3. Team throughput was strictly okay around 3-5 ideal days per ticket. The tickets had missing acceptance criteria, or were too big in scope or had missing information
4. ...you get the gist.

This allowed us to empower the teams and force others to work with them via an backlog interface to get work done. It was only rolled out to 3-5 teams each with about 3-5 members.

I left the place not long after (for other reasons; one was that they'd actually look to see how many hours were being logged for work items for everyone. Many worked over time and had a huge log and others were compared with that horrible benchmark).

However, the last I heard, the company is "mostly agile" with about 50-60% of the teams adopting it and they slowly tweaking it. However, the initial "metric oriented Scrum tied to hours" was highly beneficial to showcase feedback/efficiency. Something that the higher-ups always seem to value.

Answer 8

I've only seen one reference to retrospectives. Disclaimer: I acted as scrum master on one project; our company had been merged, and the new owners wanted our management to consider scrum. Our company had a strong culture of conducting "lessons learned" sessions projects, and disseminating the learnings to all teams, so I found it east to sell the idea of retrospectives. We were religious about asking the 3 Questions: what worked well? what didn't work so well? what can we try next time? I wonder whether OP could get more benefit from retrospectives, by helping the Team see the impact of the PO's behaviour on the schedule?

Answer 9

I can't agree with the phrase that management does not support agile/scrum. If that is true, why is scrum master employed in the first place.

As a scrum master, you are a leader and a coach. A scrum master can engage with the stakeholders on how to integrate scrum practice into the day-to-day operations of the company. Doing this by deploying some professional tactics will go a long way.

Well, if that doesn't work, you can either continue in that uncomfortable policy or you move ahead to a new job that will embrace your essence of profession.

Hope this helps.