How do you influence without authority?

What transparency have you been able to put in place over the various issues, their effect on outcomes, and the gap which will need to be closed if Scrum is to be implemented?

Transparency - We use confluence and all teams are aware and have agreed to Rules of Engagement.  Definitions of Roles are also posted for all to see.  I have personally experimented with different forms of communication with developers and management and both elements are aware of my communication.

effect on outcomes - I have attempted to communicate the value of clear artifacts and purposeful events.

Gap - Apparently, I need management to do the influencing if management is unwilling to give me the authority. This particular team only seems to respond to authority in the organization and does not respect the roles in Scrum.

Management cannot abdicate their responsibility to influence change and to communicate a sense of urgency for it. They may respond better if the transparency you give includes metrics or KPIs (burn rates, planned vs completed, undone work etc).

Management is fully aware of the KPIs.

I am not asking anyone to abdicate authority or responsibility.  I am asking how I can influence without authority because I currently have no authority in the organization.

I'm going to go a slightly different way.  Who is being held accountable for the team's results and by whom?  Since you are not authorized (and as a Scrum Master you shouldn't be I might add) to tell the team how to work, then you will have to depend on the individual(s) that are holding the team accountable.  In Scrum theory the team should be holding themselves accountable but in real life situations there is usually some management entity that is going to be doing that as well.  That is where the transparency of the KPIs come into play.  If there is a level of expectations from those in authority then making it apparent where the team is delivering to those levels is crucial.  That is what will drive management to "figure it out".  You do not do this lightly though.  You discuss with the team what KPIs you will be surfacing.  Explain to the team and authority figures what each KPI shows and the purpose behind the KPI.  Also explain to them what is "good" vs "bad" for each KPI.  I also encourage finding a way to sculpt a KPI to indicate the value being delivered to the stakeholder (I have used something as simple as a "star rating" on each increment) as that is the ultimate measure of success in Scrum.  As you see "bad", you should work with the team and authority figures to address it.  As you see "good" you should work with the team and authority figures to recognize it. 

Your influence will come by being totally transparent.  You don't tell anyone what to do.  You don't tell them they are doing bad or good.  You help the people in authority and those involved in the work to understand how to assess this on their own. 

While all of this is happening, you will help all of the parties understand how the Scrum framework is structured to enable better results, to provide opportunities for inspection and improvement.  

Yeah, I can write all of that down in words but doing it is not as easy.  Scrum is based on servant-leadership, not authoritative leadership.  In the servant-leader model no one has authority but everyone has accountability.  Getting people to recognize and appreciate the difference is not easy.

Daniel and Ian,

Thank you for taking time to comment.  I appreciate your input.

 Brian Gooder, Under similar circumstances what worked BEST For me is the RETROSPECTIVE ! When done correctly you can put the ball in their court  :)

There are several nice ways to make it fun and engaging for collocated teams. Now, in your case the team is remote. That is a BIG drawback  as some of these methods like spider web or sailboat and speed car are not as fun anymore but can still be implemented. If you learn you will understand that basically they all work on the principles of allowing the team identify the problems in innovative ways using the anchors (process impediments) stopping the sailboat from moving forward (team progress); marking the value of each concern (each spider web leg) to identify the scope of the impediments that need to be corrected so we can focus on the longest (most impeding) ef first. 

Below is my Special method that worked for my remote team (currently testing on another mixed team, local + remote !)

Buy a Problem. (This is basically a modified version of Buy a Feature game which is a good technique for a PO collecting Stakeholder priorities)

Once you understand how Buy a feature game is played, the difference here is that instead of buying a feature, the users will bet on buying a solution for the process problem :) I don't know if it's my team composition or my style but it worked pretty well for us. Each team member gets to spend only 100 (or whatever amount you choose, it does not really matter as the key is the cap). Unlike features the problems are not valued. The value is whatever you are willing to pay ! Like I said it's a bid now. You can place all your bets on just one problem that you think is most worry some according to you. If none of the problems are your concern you can add yours to the list (we used a simple excel file). using these values we can generate a radar graph that looks just like a spider web (dynamic!). All you need is to find the one that the team bet most on and come up with an action plan. 

Now you may wonder, how this helps induce Scrum to teams?

Here is one real life example. The team placed bets against various factors like testing, defects, requirements, being remote (communication and other), code quality, documentation, management, time availability etc and eventually the clarity of requirements evolved as the most betted problem that needs solution. It's the team that seeking solution now. So I asked them for their suggestions after helping them agree on a schedule of dedicated events to clarify, prioritize and add enough details to the requirements, while carefully introducing them to Acceptance Criteria (I held back DoD at this time, half step at a time !!) and then I told them let us call this Backlog Refinement. Now they are doing one of the Scrum practices without knowing !

I advise you to check other nice methods to make retrospectives fun here. There are several other tools softwares and videos which I  would advice you to follow. Retrospective is your best avenue to make them do the work for you, but you need to be carefull, delicate and nudge them to talk instead of you dictating. Good luck !