'Scaring' my audience by being unrealistic

Hello - I've been a scrum master for several years now and have commonly been referred to as unrealistic or as an idealist.

Welcome to the club.

This feedback is largely coming from the person sponsoring the adoption of Scrum and an agile way of working. I don't know any other method to influence change other than increasing transparency over waste - but I'm confident this will only lead to the same thing, where resolution must be a scary vision.  

Has the sponsor clearly articulated his or her own vision for agile change? Why is it wanted? What improved outcomes are expected? This vision needs to be owned by whoever is accountable for organizational value. Often it is a CEO. A Scrum Master should be in a position to help managers elicit a vision, but clearly that's a different matter.

What you appear to be observing is not organizational gravity per se, but rather one of its effects. This is the delegation of change ever downwards. It seems it must always happen elsewhere...until it lands at a Scrum Master's feet. The key thing to bear in mind is that whoever really owns the transformational vision, and is accountable for it, must create a sense of urgency for change. That's how sponsorship will be evidenced.

Hello - I've been a scrum master for several years now and have commonly been referred to as unrealistic or as an idealist.

Someone should put this on a t-shirt and hand it out with every Scrum Master certification because it happens to all of us at some point.

@Ian is correct in that someone has to own the vision/goal of the transformation.  It is very much like an Epic.  Then the Epic is broken into smaller incremental deliveries.  A Scrum Team should do the work to support and satisfy the Epic definition.  In this case it is mostly organizational or process modifications instead of code changes. 

This feedback is largely coming from the person sponsoring the adoption of Scrum and an agile way of working. 

If this person is sponsoring the adoption of Scrum, then they should understand the difficulties of doing so.  Have them give you a goal (Epic) that defines the intended value delivery. That person then becomes the Product Owner for the goals and should then share the goals with the Scrum Team and make it clear that you will be offering guidance/suggestions on how to achieve the goals but it is the responsibility of the entire Scrum Team to reach the goals.  Retrospectives are made for this type of activity. You will see much better success if the entire team is involved in the solution. 

Definitely, the next time someone asks me what I do for a living, I'm going to reply "Some people call me unrealistic or an idealist."

You want them to learn a different way of working that may indeed be much better than how they're currently working, which is fine.   But while your observations seem to be accurate, it is difficult (to borrow from a common phrase) to both lead a horse to water, and then have them drink.

What has worked well for me in the past, and what you hinted at as well, is to always make things as visible and transparent as possible.   Always be ready to pose difficult and powerful questions around how they are working, and what they might want to change if given the chance.   

Just an opinion, but it very well may be that your "vision" is indeed scaring them.   People are rarely receptive to someone advising them that what they're doing is wrong, and that you have the answer.   Try to simply make your observations known, over and over and over again, without proposing any type of solution.   

Help them to see all of the ways they may not be working effectively, and only when they also see it, should you ever offer a "suggestion" on what they might do differently, and always ask for permission first to make such a suggestion. 

Good luck!

One quote has always stuck with me regarding these situations.   From Lyssa Adkins:

"The team's bumbling is better than your perfect plan."

Thanks everyone.

I like Timothy's idea of postponing/hesitating on providing a solution - until requested.

As a follow up question, when a Scrum Master is requested to do something, which contradicts the Scrum Guide, how can one best handle that situation without appearing unrealistic or dare I say it, lazy? For example, "Mr. Scrum Master, please ensure all developers attend the Daily Scrum, assign them their tasks for the day, and check at the end of the day to make sure they've done it."

As a Scrum Master, I'd be letting the team down, the framework down, and myself down by falling into this managerial role.  Although I can/should demonstrate the courage to challenge it, what techniques will best avoid the problem described in the original post?

I agree with the comments above by Timothy. It is good to ask difficult questions about improving way of working, even if uncomfortable.

"I'd love our Product Owners to actually use empiricism to drive the product's direction.  Again, the feedback is that the management levels do not really understand what this means, that it will scare them" - I would avoid the E word, and instead focus on communication of intention of doing experiments that would provide data to drive business decisions. Same meaning, less scary :)

As a follow up question, when a Scrum Master is requested to do something, which contradicts the Scrum Guide, how can one best handle that situation without appearing unrealistic or dare I say it, lazy? 

Look at the Scrum Guide section about the Scrum Master.  https://scrumguides.org/scrum-guide.html#team-sm.  Pay close attention to the services the Scrum Master provides.  There is a lot about helping people understand and appreciate Scrum.  In this case, I would take this as an opportunity to coach those asking these questions. I'd explain to them that you will coach the team on effective ways to work as a team and to appreciate the communication needed to meet the goals and forecasts that they define.  Explain to the people asking the question how letting a team make their own decisions and hold each other accountable will result in better results than having someone micromanage their activities.  

Having said that, as a servant-leader sometimes you may have to take a little more of the leader stance at the beginning in order for everyone to learn.  Be a little more directive at the beginning gradually reducing the amount you do and let the team pick up the slack you are providing. Help them understand that by their making decisions and communicating the reasons for their decisions will lead to their being able to self-organize and self-manage their work. As you are "managing down" you will also need to "manage up" to help the people outside of the Scrum Team understand how their actions can negatively or positively impact the teams ability to produce consistent value.

As always make sure that everything you are doing and the reasons behind your actions are very transparent. Lead by example with your own goal of minimizing your leader activities and increase your servant activities. I know this isn't a "how-to" answer and more theoretical but I really have no straight forward answer for you. 

As a follow up question, when a Scrum Master is requested to do something, which contradicts the Scrum Guide, how can one best handle that situation

I think I’d express a genuine curiosity about the request, since it would mean that the benefits of implementing Scrum could no longer be expected to accrue.

I agree with Ian - express a sincere curiosity about the request.

... please ensure all developers attend the Daily Scrum, assign them their tasks for the day, and check at the end of the day to make sure they've done it

Since micromanagement is a clear sign of mistrust, one of my favorite replies to these types of requests is to simply ask the requester "Why do you not trust the team to manage their work?"   Usually, they will deny that they don't trust the team, at which point you can leverage the opportunity to coach and educate (as @Daniel so clearly laid out).   If they readily admit that they don't trust the team, it simply leads to a different discussion, but a similar coaching opportunity.

My advice is to spend some time thinking about how you would respond to such non-Scrum requests, both real and hypothetical.   Be prepared to respond with powerful questions that both promote discussion and make things as transparent as possible. 

Good luck!