I can see that a Scrum Master has two important role out of many; namely building a self-organised Team and removing impediments.
Apart from teaching, mentoring and coaching, what else does one need to do to make a self-organised Team?
The question is general to management roles and speaks about "building people up".
Just Googling these 3 words lands countless views and advice — please avoid theoretical and commercial docs, focus on real-world blogs and talks by real people speaking in their own name or their company's (i.e. take advice from those who've already succeeded at what you seek). Or read actual books (a few links in this post).
I'd like to quickly brief, then frame for the SE domain. (Disclaiming, this is my personal/anecdotal exp., so take it with salt, sugar, pepper too, and maybe some vinegar.)
Building people up is sometimes termed the real value of management: the 'benefit' for all parties lasts longer than their involvement (you come back home with it; while the company keeps it too, as culture). It's also contagious by nature (someone 'built up' tends to build up others quite naturally).
You need to:
Remove limiting thoughts towards a "growth mindset", as Carol S. Dweck puts it (of all theories, I can confirm this one is true; reading this book literally changes lives). Basically the idea that success/failure is the result of work, effort, actions, and certainly not a judgement on ourselves: you wrote bad code today, doesn't mean you're a bad programmer, just that you botched that task and need to put more effort on this one.
Lead by example. Period. It's just the only sustainable form of leadership: you eat your own (manager)dog food. Your own advice, you don't preach it, you don't even voice it much, you simply do / apply it yourself, for yourself but for all to see, and let others observe and, if your ways are good, slowly convince themselves that they should imitate you.
Use only positive reinforcement (rewards) as feedback. Generally, everything else is moot or counterproductive (notably punishment, shaming, etc.), a necessary evil, last-resort can't-avoid-it kinda situation. Make your positive reinforcement "fair": praise always when it's "not bad" (positive even just above neutral), but moderate the intensity accordingly. The key concept is that others feel "recognized", "acknowledged" for their efforts (it's not about making them feeling like the best always, but more intimately feeling that they are seen, that they exist in the team. Like, "I know. I know that you show up and you really try. This has value for both of us, I see that." can't be said only once or in not-so-clear words).
As you've guessed by now, it's an empathic process much more than a technical task.
About the growth mindset: it's the one thing you wish to focus on, if you win this you win life, period. (grains of salt and everything)
Its beauty is to nurture a genuine appreciation — all the way up to love — for work and effort because these solve our problems. It's always very positive but never undeserved or entitled or random: we stick to the dumb facts and go from there each step of the way. But ultimately, step by step, you can really get there, wherever "there" is.
One take away is that you become able to "love what you do" (whatever you do) and not feel restricted to "(only) do what you love" (because that's unreal and out of your control anyway).
Most importantly, you cease to think or say things like "I am" (I am a good/bad programmer, I am a good/bad communicator) and become more factual, more "in the now" (I did a good/bad job on this programming task, I did or did not communicate my problems well). Hence, there's always room for improvement, next time.
You'll face the 3 demons:
Imposter syndrome or related lack of self-confidence.
This freezes initiative, offers to help, communication. It's worse for the team than the individual itself. A team that behaves as a whole like an imposter has lost before they even begin.
That's the toughest part, because spoiler: you can't change people. This is why we "hire a person, not a profile": you can always train someone to meet a job profile but you can't change a person unless they want to.
Honestly, my best shot at it is to have people read the book "Mindset" by Carol Dweck. That's what cured me of imposter syndrome and I think it works for many, maybe most people.
Silence. Lack of communication. Silos, sub-groups, divisions.
There is a great book on organizations called "Tribal Leadership" by Dave Logan, John King & Halee Fischer-Wright. I think it's a tremendous read for anyone looking to manage any kind and size of team(s).
In SE it's even worse than other fields for more or less obvious reasons. Be flexible with meetings but have at least 1 full team meeting per week (no longer than it should, show respect for people's time); one-on-one's also need to happen regularly and cannot be substituted. The spirit should always be that of transparency, and people be made certain that revealing their mistakes will not ever turn on them: you use everyone's mistakes as stepping stones to build the team, the culture.
How? Well here's a typical situation:
What you just did in this example is:
Note that it's long to write and properly explain, in real life such informal talks about mistake X can happen in all of 2-10 minutes. This approach is directly inspired from accidentology, the study of the causes of accidents, and subsequent elaboration of methods and processes to ensure safety e.g. in air transportation or medical care).
Other good tools are:
Basically anything in groups of 2-3 is great to reinforce communication. Lone wolves usually have their own way of dealing with it; don't force anyone, just be open and transparent about what you expect — like it's OK to pretty much reveal the whole "from making individual mistakes to growing stronger as a team" process, be totally transparent how that works, people can then own it and use it in whatever they do with whomever (like your pair progs hehe). [It's also great for educating children]
Lack of trust.
Now that's my way. It builds up on everything above and then some, of course. But basically in practice, day-to-day, it comes to this:
Be a servant leader of a servant team. Not 'boss' (petty) but 'How can I help you?' 'How can I facilitate whatever it is you have to do?' 'Can you help me help you rise higher or easier?' That's your job.
Then, only then will people talk to you: when they feel you're with them. Goes true against your hierarchy: you protect your guys, you don't throw blame at them, you suck it up and own the team's successes and failures all the same.
Because remember, even if someone's subpar and made more mistakes and eventually needs to go, it was the team's failure all along that we shipped buggy. Your team must trust you speak as one, and take the hits. Your best guy too needs to feel free to speak and admit their mistakes, especially your best, so it's not "oh it's OK now but I'll throw you under the HR bus next time though": it's OK forever or never).
And because you serve them, they'll reciprocate by serving you too and work to avoid more 'hits', to ship 'better', to succeed. Not for you, dear master, but with you, as one. Then can you claim 'mastery' at orchestration, organization.
The take away is that you want to break these damn walls that people — legitimately — erect around themselves to allow 'trust' to 'flow'. Like a river. Trust is a flow, it doesn't really stop, only grows or shrinks in time. Trust never burns, it heals: people want to trust but are afraid to, and by showing them real tangible examples of situations where they could trust you and each other, fear will subside.
Also, you hear stuff like "trust is earned, not given". It's a bit vague, forget about such pop-philo. Trust, according to psy studies, is built by sharing circumstances, i.e. being in the same boat enough with someone (implying they're on your side, did not turn on you). So don't fret it. It'll come, it's one of these genuine things of the heart than no 'system' can hurry. But you can see how it all contributes (the team meetings, the openness in a "safe zone" kind of setting, the pairs, the one-ness of you taking the shots outside this 'sanctuary')...
There's this book whose title says it all I think: "Sometimes We Win, Sometimes We
Fail Learn". If you can make someone genuinely agree to that, you'll do great at managing teams in Agile environments (the fundamental premise of Agile and streamlining such as DevOps is to take "a little hit on initial quality" to "massively increase total throughput"; so you really need at least resilient and at best anti-fragile mindsets, and systems, to work under such paradigms. Basically, get ready to make mistakes and fix stuff).
I get that's a lot to take in, honestly that's more like a plan for the next 5 years, you'll probably change jobs twice or more on the way to mastering these things. Which is why I included down-to-earth examples, simple things to do. Compound effect: you do a little here, a little there, but every single day, and it builds up to mountains in time.
Notice I didn't use much words like "self-organizing" and "initiative". That's because you can't really "require" or "suggest" these things — merely show by example but then again, it's part of a larger frame. You rather elicit, or nurture, such behaviors by
Once you get it, you can't really do "wrong" as a team lead but only learn/grow: making mistakes is also something you can do, and if you just reveal and fix them asap, as you go, and as a team too (maybe with your guys, maybe with your hierarchy too), you'll earn this even-higher level of trust called "respect" — for being fair as a leader who self-judges themselves, and behaves, according to the very standards they seek to promote onto others.
The Scrum Master is one of three roles defined within the Scrum methodology. As part of the Scrum Team and acting as a servant leader, its primary responsibility is to help the team follow the Scrum process.
Unlike a project manager in a waterfall approach, Scrum Master is not responsible for planning, it is done by the product owner and the team. Nor does it manage the team members, nor is it responsible for product quality, this is done by the team.
As you said and right, Scrum Master is responsible for ensuring that the team follows the process as well as being a facilitator who removes obstacles from the team. These responsibilities translate into:
The necessary dedication to the project
Some projects require a 100% dedicated Scrum Master. In other projects, he / she accumulates his / her role as team member. At first, this job tends to be full-time. However, after a few sprints the processes will tend to systematize. That way the workload will drop and he / she can actively contribute to Sprint Goal.
In all my work as a Scrum Master and Agile Coach the one thing that always always impedes teams from becoming self-organising is meddling third parties:
e.g. 1: a manager that wants to micro-manage individuals on the team - this totally blocks any self-organisation happening e.g. engineering manager, architect
e.g. 2: a command and control product owner that assigns work to team members and wants to control how the solution is engineered - self-organisation will be very slow if not impossible with this situation
What I would recommend is that you build strong relationships with all the people outside the team who are very close to the team and then start coaching them on how it is important that they don't meddle with the team.
e.g. 3: a command and control or micro-managing team leader or technical lead within the team - this is more of an internal role, but still has the same effect.
It should be continuous coaching process for the team, to transition and grow Product Mindset in all members of the team. Development team should share ownership of product and understand what is the most important for business at the moment and why. During Sprint planning it is a good idea just to setup the high level goal(what has to be achieved and why) and let the team to drive process of breaking tasks and defining what and how will be built. Ideally to define ownership during this event.