Integrating as a Scrum Master in a new team and company

What has worked well for me in the past is to simply observe. You will alienate people if you come in with a prescriptive approach to how they should be doing things. Pick your moments to provide your suggestions or views, and be completely receptive to any feedback received. That will indicate whether to pursue the matter, or let it rest for a while.

Its about leading them to water, and hoping that they drink. If they don't, reflect on the situation, and look for the next opportunity to lead them to another pool of water.

As a SM, you should not be "addressing" anything. It is your job to make things as transparent and visible as possible to both the team and the organization, pointing out any poor practices and inefficiencies that you see, and backing those observations up with metrics, experiences, or examples that support your case. Ultimately, it is their decision to be receptive to it or not.

Good luck!

> It is your job to make things as transparent and visible as
> possible to both the team and the organization, pointing out
> any poor practices and inefficiencies that you see, and
> backing those observations up with metrics, experiences, or
> examples that support your case.

Correct. If you are not yet an influencer, that may be all you have control over.

> Ultimately, it is their decision to be receptive to it or not.

It's important to:

1) at any given stage know where sponsorship for change comes from, if any, and what its constraints might be
2) set clear expectations regarding how sponsorship must be evidenced, if the expected change is indeed to happen.

Hi there, let me share here with you site where there are various of short and degree courses to choose from. I hope this could help, good luck. http://www.premiumcourses.net/

this is useful,

thank you guys))

Where I am struggling right now, is that I was brought in as a Scrum Master and a sort of Agile Coach to a company that adopted Agile on the exact same day that I started. So pretty much everyone is looking to me to "show them how it's done". With management, however, I am getting conflicting signals. On the one hand, it was their idea to switch to Agile in the first place. On the other, I'm hearing of a lot of grumbling like, "Agile has too many meetings, people need to get back to work," and "We don't need Sprint Reviews, the Product Owners already know how things are going and there aren't any other stakeholders that matter. Anyone else who might want to offer an opinion in a Sprint Review, well, that's time they're wasting when they should get back to work, so let's just not have Sprint Reviews." Management seems to believe that if they just have each Scrum Team show off a 10-minute demo of their work, then that's enough.

So I'm kind of pondering how to deal with this. On the one hand, yes, I'm a new Scrum Master to the company. On the other, people are looking to me to "teach them proper Scrum". With management, they're clearly interested in trying something new (hence the switch to Agile), and I do have a line of communication to them, but they're really hating the "all these meetings" thing, since they see it as a waste of productive time.

How would other CSMs handle this? Try to be more of a Scrum evangelist (which is what I was hired to be), and work harder to persuade management to give Scrum a try, including Sprint Reviews? Or acknowledge that management may have other factors in mind that I do not since I'm so new to the company, and so acquiesce to their demands for now, but maybe try to push a bit more later? Or something else?

"they see it as a waste of productive time. "
Can they display any evidence of this "intuition" ?

What is the point of view of the Dev Teams ?
Are they seasoned enough to bypass the "Shu" level to the "Ri" level (any evidence ?) ?

You say that you were brought in as a Scrum Master and also as something of an Agile Coach, and that you were hired as a Scrum Evangelist. This suggests that your role is a fudge of various people's expectations. It's very hard to make progress under such conditions, as your role is likely to be constantly redefined and challenged.

In my experience, the best thing to do in this situation is to make your *own* expectations clear. I'd nail my colors to the Scrum Master role description mast, because that is clearly defined in the Scrum Guide and is not something that can be argued away. I'd make it clear that I expect the Scrum rules, as articulated in the Guide, to be observed. I'd make it clear what those rules are, but leave it up to others whether or not they follow them. If they are not followed I would explain the risks and possible consequences. I wouldn't see it as my job to evangelize anything. That's a different proposition as it requires a more mature and robust level of organizational sponsorship for enterprise change.

In my experience, getting valuable sprint Reviews is hard. Often they end up with just a 10-minute demo "we built technical features XYZ", and stakeholders can't connect, and stay away/complain. Telling them a story (this is where we were, we want to go there eventually, we took these steps this sprint, and coming up next are probably these steps) can keep them engaged, and may lead to valuable feedback.

Elonka, management thinks reviews are a waste of time. What do the other stakeholders think? Are they actively engaged?Can you show the management what important feedback would otherwise have been overlooked? If you are really lucky, you'll get feedback about an upcoming (or built) story "no that will not work, we need approach y instead". Then you can show the management: our meeting just gave us valuable feedback (and saved us building a story with marginal value).