Finding your place as an SPC

Time to take yet another jab at the SPC. The SPC role is massive, and as I mentioned before - people can't be good at everything the role suggests. That's simply because there are too many different things you might be doing.

DISCLAIMER: Proceed with caution. This model needs refinement.

So, I've created this simple model as a brain dump on what an SPC could spend their time with.
If you're an SPC and/or Agile Coach, you can try checking the boxes and see where that lands you.

How-To-Use

• If you're an organization looking for an SPC, let them make their check marks.
  This gives you an impression of what you're hiring for.
• If you're an SPC as part of a company's SPC community, this gives you a reflection opportunity to see if what you do is what you want to be doing.
• If you meet as an SPC community, you may want to compare your results with your peers - it's a great discussion starter!

Notes

• I would like to say, "There are no rights and no wrongs" - but that wouldn't be entirely true. A few combinations would be pretty insane. If you can't figure out which ones, ... I have bad news.
• Not all combinations are consistent - I hope that's not what you're doing.
• As the dividing line is, "where you spend more than 10% of your time" - there shouldn't be more than 10 checks.
• I would assume that an average SPC shouldn't have more than 5 or 6.
• Being a non-average SPC means you're probably spreading yourself too thin.

Feedback welcome. I would like to improve this so it can be the most useful tool for others.

SPC Competency - what companies can do

In a recent post, I gave my opinion about the condition of the SPC. I have received some pushback, in multiple directions:

1.  I'm being too negative.
2.  The problem isn't limited to SAFe or the SPC.
3.  What's the solution?

Let me address these points quickly before digging in.
First, I made this post because I care. Not to place blame, but to spark a discussion. And I did.
Second, I agree. The growing problem of ersatz agile coaches would still be getting worse even if SAFe didn't exist. But I don't give a hoot about the ever-growing number of pointless certing schemes out there. I would prefer if we could improve the SPC community.
Third, I don't know. But I have ideas based from what I have seen.

So - let's make this article about point three.

Getting out of the dilemma
I base these ideas on personal observations (in italics) made from one client - they know who they are.
This article is a kind of action-item list for things you may want to do in your organization to maximize the likelihood of having "good" SPCs.

The certificate is nothing - what matters is the person who bears it!

Dismiss Ersatz SPCs fast

When you identify Ersatz SPCs in your organization, you should let them go quickly. Preferably, you don't give an external SPC a prolonged contract to begin with - start with monthly contracts that you can simply choose to not prolong.
When you hire SPCs as internal staff, use a probation period to see if they're worth their salt.
The challenge is that you need further mechanisms to determine where prolonging makes sense.

My contracts are often limited to supporting ART launches. Although I believe that this isn't how you build up a sustainable Lean-Agile enterprise, I am currently considering to offer fixed price services like ART ramp-up support with success clause.

Check your metrics

By looking at the wrong metrics, you run a huge risk of ditching the right people and relying on the wrong people. Metrics such as numbers of ARTs launched (fewer is better), amounts of people trained (irrelevant) or teams converted to "Agile" create effort and trouble without value. Success metrics should be business relevant figures, and success should be measured in terms of how your organization creates value.

Transformation metrics like customer satisfaction, time-to-market and product quality are much harder to game and let you know whether your SPC is making show or progress.

Avoid wholesale packages

This one is key - because too often, organizations look to a single large consultancy to take care of the entire staffing question.

When you ask an agency to bring in droves of SPCs to do an Enterprise transformation, you're going to get a few good ones and a lot of bad apples. It's inevitable. Don't hire SPCs by-the-dozen. Create a process where you, as a client, are in control of every single SPC so that you can decide to terminate Ersatz SPCs without getting contractual problems.

I see Business Owners interview every SPC individually, and being from one specific agency can't be a success guarantee to be placed. Steer clear of "bargain bins" here - if Agency A allows you to place a second candidate at a discount, that's probably not to your advantage!

Rely on Expert opinion

Do not rely solely on Business Owner or RTE opinion as to what makes a good SPC, as the art of snake oil selling includes deceiving the Ignorant. You don't want Snake Oil.
When a Business Owner has a bad feeling, they should immediately turn to an SPC for advice.
Create a stream of communication between Business Owners and SPCs who aren't invested in the ART.

I have been invited to observe PIP's and offer feedback to the Business Owners. This approach strengthens well-meaning SPCs and exposes Ersatz SPCs.

Give SPCs a role in strategy

SAFe isn't just about lumping development teams together in ARTs, The key to Enterprise Agility is bringing different parts and layers of the organization together in transparent alignment. Experienced SPCs can help there, if you let them. Especially, don't determine what the SAFe organization should look like and then just delegate it to SPCs. This attracts Ersatz SPCs who will act as willing execution agents for poor strategy.

Include external SPCs in your Transformation team, while avoiding to delegate the Transformation entirely to external SPCs. Offer the SPCs transparency into the Transformation - and figure out ways to let them contribute beyond ART level.

Avoid One Man Shows

It looks tempting to put a single SPC in charge of a single ART launch - which creates two major risks: First, if that single SPC is a washout, you'll discover that after the PIP failed. Second, if that single SPC gets stressed out, you stand empty handed. Try distributing the load.

Involving multiple SPC's with each ART increases transformation quality and decreases risks. It's good to at least have other SPCs check in on a new ART occasionally, to see if the lead SPC requires support. Ideally, don't save on SPC capacity. 1-2 SPC per 50 people isn't too much.

Separate concerns

SAFe is a huge topic. For starters, we have the domains of strategy, training, value streams and technical aptitude.

Consulting isn't coaching isn't counseling. Process change, teaching people new practices and structural reorganization are different pairs of shoes. Managers have other needs than developers than product people. 

Few people can take care of all of that. Most excel in one area, some in two or three. Even if someone could do everything, they'd spread themselves too thin if they would do all of it at once.

Hence, allow people to play out their strengths. Let SPCs determine how they can contribute - and let them do exactly that.

Always involve multiple SPCs to launch an ART. Not everyone needs to be around full-time, as long as you ensure that people do the thing they're good at, not the things that are really not their strength.

Pair and Shadow

Once you have identified some competent SPC's, ensure that they are present at key SAFe events, such as the Value Stream Workshop and the PIP. An hour of observation and a short conversation between them and the other SPC will be very revealing.

I have very much enjoyed the conversations with a senior SPC who critically probed the dysfunctions he observed during my ART launch PIP.

Build an SPC Community

When skilled SPCs talk, discussions get interesting. By having a community of peers, you will quickly see:

1. Who contributes and who doesn't.
2. Whose contribution adds value and who blathers.

The SPC's you want in your organization are those who care to make a difference. Observe those who don't want to join the SPC community as a vehicle to have a bigger impact - they might have something to hide!

I enjoy every session of my client's SPC community, because it's a great way to look at the big picture and avoid local optimization. Personally, what I like most is the ability to draw attention to enterprise-wide issues.

Create a Central SPC Work Backlog

Nobody is Superman. We all have strengths and weaknesses and nobody can do everything. We should focus on the things we're good at. There's a lot of SPC work, starting with awareness sessions, Value Stream Workshops, going over trainings, program backlog workshops, PIP support, Inspect+Adapt events and many more. The SPC community should have a backlog where all known work can be made visible, so that SPCs can pull the items where they're confident to add value.

I have been "One Man Army" Coach before. It's terrible. Being able to access an SPC activity backlog where one can get items covered that one isn't good at and pull items that make the organization successful is a quantum leap.

Identify Organizational Antipatterns

Current Culture has an impact on Agile Transformation. No single SPC sees the big picture, it becomes visible when we put our individual perspectives together. This helps us identify systemic change potential and levers going much beyond the scope of a single ART. Ersatz SPCs might reveal themselves by claiming antipatterns that aren't, or claiming clear antipatterns are fine.

When we had the idea in the SPC community to collect antipatterns, I had a hundred things on my mind. It was fascinating to learn where I was victim of my own bias and where others shared my observations.

Meet. Face to Face.

In large corporations, it's easy to remain anonymous. This creates a hiding place for Ersatz SPCs. When you meet for a day in a setting like Open Space Technology or Liberating Structures Workshops, you can learn about who you're dealing with. Many minds breed new ideas.

The best you can do is create an Open Community Meetup in your company's location. This creates a time and space where you can meet your own peers. It can likewise become a mechanism to learn about one's own organizational bias and be a vehicle for recruiting interested outsiders who could make a valuable contribution.

Fuckup Nights

Talking about where "you dun goofd" isn't easy, but we all do. I do. All the time. Maybe my last article was a goof - I'll let you determine that. Provide a forum where people can talk about their mistakes openly. We can help each other out, and we can learn from others' mistakes as well.

The Agile Academy

I've taken two barrel loads of shots against the Agile Academy - and it might appear as I am totally against this idea. I am not. Indeed, I mentioned before that I believe that a properly set up Agile Academy is an essential instrument in sustaining and nurturing Enterprise Agility. I am against using this approach too early, exclusively or as a false dichotomy.

Use Neutral Trainers

An Agile Academy is very dangerous when it relies on people with local bias as trainers, who in their worst case have built their own curriculum based on their personal understanding and then proliferate this in the organization. Bringing in a mix of reputable external trainers to conduct trainings on Lean/Agile basics irrespective of your local context is more costly, but it provides a balancing instrument in the organization.

The client who is running a quite successful "Agile Academy" has a number of training partners who are not part of their organizational culture. This ensures the trainers get neutral market feedback and do not adapt to cater to your current status quo.

Trainers must be Doers

A very common mistake in Corporate Agile Academies is that you raise fulltime Inhouse Trainers who lose touch with organizational reality. 

My heart jumps when I hear that people who are doing the work in the trenches are giving trainings and feeding back their learnings from the training into their daily work, and vice versa.

Every ART SPC must take a role in training

When the Agile Academy creates a disjoint between trainer and the ART SPCs, that may be efficient from an organizational perspective, but it's terribly inefficient from a learning perspective. The Lead SPC of an ART must be in the training room, ideally as a trainer or at least as co-trainer. This strengthens the bond between them and the people they work with on a day-to-day basis. They can link training content to their daily work - and see from the training questions where further support after the training is required.

Ideally, the Academy relies on SPCs who also work in the trenches and has a standard process where the ART SPC is part of the training process.

My client didn't do this initially, and this created negative feedback swiftly as Agile Academy processes weren't synchronized to ART launch processes.

Choose candidates wisely

SPCs are multiplicators either way. A good SPC spreads a good culture. A bad apple spreads a bad culture. Is it better to err on the side of caution? I don't know. But what do you do if you have an internal SPC with an anti-agile attitude? Do your processes accommodate for that? Maybe they will use their accreditation to wreak havoc elsewhere. Although that may not be your problem - it affects the global SPC community.

Wait before you train inhouse SPCs

Being an SPC is a high responsibility. I believe that training people without agile experience as SPC is setting them up to fail. Especially if you have no Agile history in your organization, you will be challenged to find people who have enough background to succeed as an SPC. Wait before moving the SPC role "in-house". Give people time to collect experience as Scrum Masters or Release Train Enegineers before you move them into an SPC role.

My client went through an Agile Transformation years ago. There are Scrum Masters with vast experience on their back, and they have the battle scars to prove it. Such people make great SPC candidates.

Avoid role poker or favors

Internal SPCs will carry the burden and responsibility of fostering and sustaining Lean-Agile Practice long after the Externals are gone. They need to be the people who care to do this. If you select Internal SPCs by means of favoritism or to appease political demands, that's a signal that you're preserving a status quo where power play beats performance.

I have participated in deep discussions with Business Owners over the implications, pros and cons of nominating SPC candidates for the Agile Academy. As part of my coaching, I also had 1:1 conversations with the candidate to see if this is how they personally felt they could add most benefit to the organization.

Be picky

There should be no guarantee that a candidate nominated as SPC becomes an SPC. Let some time pass between nomination and training. Peer interviews by SPCs and collaboration with SPCs who are outside the line responsibility of the nominating Business Owner are a good way to do this.

The first SPC candidate I mentored for my client was probably at least as capable to meet this responsibility as I am. He shadowed me and asked questions. I coached him for a few months. This was part of his onboarding process before he went for training.

Provide ongoing support

An SPC training is nothing more than basic awareness. It doesn't make an SPC, and it doesn't equip an SPC to bear their responsibility within the organization.

SPC Candidates should ...

1. join the company's SPC Community as early as possible.
2. have a mentor/coach even before their SPC training.
3. be able to rely on their mentor/coach after their SPC training.

I have observed others becoming SPC in a slow process, where seasoned SPCs were always present to support one in growing into the role. Combined with the above items from the community, this keeps weird outcrops under control.

Don't cut ties with external SPCs too quickly

I have mentioned the Dunning-Kruger Effect in the original post: how do you know what you don't know? And how do you know when you're ready to move on alone?

Fading out external support slowly is, in my opinion, imperative. Don't throw out your Externals on the day after PIP launch. Consider a prolonged period before the SPC moves on. I'm talking about months, potentially years before the last External finally moves on.

Why? Otherwise, you reward SPC's who create fire+forget show effects.

Make sure that an external SPC is responsible for a first successful PI with valuable outcomes, and give them the opportunity to make this happen.

I have seen ARTs reduce the involvement of external SPCs to I+A event attendance, PIP coaching, call-on-demand and many other means of slowly breaking dependency without cutting ties.

Plan the future for external SPCs

Some organizations rashly and harshly cut ties with External SPCs after the ramp-up phase. 

Even after the SAFe rollout is over, I strongly suggest to keep some brains close for collecting feedback, new impulses and ideas.

Part of the phase-out process needs to be creating a strategy for sustaining an influx of valuable external knowledge without falling for dependencies. And here, I'm not talking about maintaining external trainers for the Agile Academy - I'm talking about people who stand where the rubber meets the road, that is: in the trenches.

That's it.

I hope this is a more positive outlook on how I envision corporations contributing to a better SPC community in the future.

Plans are useless - really?

Sparked by a recent thread on LinkedIn, I would like to dig a little bit into the idea of planning in an agile environment.

Useless, worthless, pointless plans

These three terms are often conflated, even though they do not mean the same thing.

Utility

Let's start with a metaphor.
Sand may be considered to be useless in a desert.
Then again, sand is very useful when making transistor chips from the silicon.
We need sand to sustain our production of computers, which in turn sustains our modern lifestyle. While sand (as an intermediary input) is useless, the results created by the sand are highly useful.

Such are plans.
A plan's usefulness is the extent in which it is used.
A plan is only useless if it isn't used at all.

Calling plans "useless" is misleading - more interesting is the question which aspects of the plan are being used and which aren't.

Value

Again, let's go to a metaphor.
Water has no value to a person living on a lakeshore, and even negative value to a person who is drowining. It's precious to people living in an arid environment. It's the same water - only in a different context.

Value depends on market forces - supply and demand.

A plan's value lies in how far it is actually demanded.
A plan is worthless when nobody wants it. It is also worthless when it leads us to places we don't want to go.

Calling plans "worthless" is an oversimplification. More interesting is the question how to maximize the value of planning.

Return on Invest (ROI)

An extension of value is the Return on Invest - that is, the investment into the plan. Irrespective whether you calculate cost by creation effort or TCO, it does affect the net value of the plan.
Note: A plan may have a negative ROI even though it does have value!

Purpose

Let's skip the metaphor.
A plan in and of itself has no purpose. The purpose of a plan lies in achieving a goal.

A plan has a purpose if it helps us reach our goal better than we would otherwise.
A plan is pointless if it either doesn't help us reach our goal or distracts us from our goal.

Calling plans "pointless" is a hasty generalization. More interesting is the question how to ensure our plan serves its purpose.

Consequences

The best plans maximizes all three attributes: utility, value and purpose.

A plan is ...

• beneficial, if it helps make better choices.
• worthwhile, if it results in more benefit than it did cost.

The plan is, however ...

• useless, if it doesn't get used or in a way that doesn't produce benefits.
• worthless, if it isn't needed.
• pointless, if it doesn't lead us to our goal.

Better plans

A plan is always made within a context.
As we gain more information, we need to integrate this into our plan.
As information changes, we need to update our plan.

All these activities are part of planning.

Planning

There are two types of planning - the initial plan creation, and replanning, i.e. updating the plan.

Spending more time on planning is...

• a benefit if it increases utility, value and purpose of the plan.
• worthwhile if the benfit outweighs the cost.

Spending more time on planning is...

• useless, if it doesn't add further utility.
• worthless, if it doesn't add further value.
• pointless, if it doesn't help us reach our goal better.

Replanning

The best plan isn't the plan with highest accuracy, but the plan which maximizes utility, value and purpose while minimizing cost. It is optimzed for cost both during initial creation and future changes. It therefore likewise minimizes the deterioration in utility, value and purpose while simultaneously minimizing cost in each step. 

The easiest way to achieve this is by not planning things that do not need to be planned yet, as this implicitly reduces the risk of sinking money into re-planning.

An agile planning strategy

Agile plans are extremely context sensitive. 

Depending on how fast your environment changes, your planning horizon can be longer or shorter.

Depending on how much information of a plan helps in achieving your goal, your planning scope may be bigger or smaller.

Conclusion

Both planning and plans can be useful, worhwhile and purposeful. And each can be neither of these three things.

Avoid conflating or generalizing these issues. Instead, when you think that your plan is useless, inspect and adapt on this. Likewise, when you think your plans are worthless or pointless.

Why the SPC will destroy SAFe

SAFe is a massively successful Enterprise Agile Framework, and irrespective of how one thinks about SAFe, it's impossible to think away from today's enterprise world. Part of the huge impact SAFe has made was due to its - undoubtedly extremely smart and well calculated - move of quickly training a large number of SPC's and letting them spread SAFe in organizations. 
I believe that the SPC will ultimately become SAFe's downfall - let me explain.

Dwindling Requirements

When I became an SPC in 2016, the requirement was "five years of agile experience at various levels, in various roles, in various organizations." Although at that time, I already saw some SPC's who didn't meet this requirement, I was excited to join a community of very seasoned agilists who were serious of moving beyond team-level agility.

Today, we see no such constraint. The main constraint seems to be who (or whose organization) is willing to invest the training fee - growing hordes of ersatz agilists are competing for an SPC role.

While most early adopter SPCs and SPCTs are massive bundles of competence, today's average SPC  brings only a fraction of the competence of the early adopters.

Organizations hiring such SPC's, unfortunately, lack the discernment to figure out the difference between a washout and true competence. This alone will ultimately undermine trust in SAFe.

Skipped examinations

The SPC exam is undoubtedly hard. Much harder than, for example, the CSM exam and still a tad harder than Scrum.org's PSM-II.  Unfortunately, this doesn't help when it's already fairly common practice to get together in groups with one single experienced person who helps everyone pass their exams - even to the point where some consultants earn some extra bucks by offering taking exams for others. As such, this form of quality assurance isn't worth anything, either.

Ersatz Consulting

The worst development I am currently witnessing are the SPC "premium agile coaches" who ask for four-digit daily rates, even though they lack every single dimension required to succeed in the role. Not only do they have extremely shallow understanding of agility - they have no experience of the makes or breaks of an agile organization and rely solely on the standard slide decks to get by.

One SPC literally told me, "It's too much work, and reinventing the wheel, to figure out what the customer needs. I just copy+paste SAFe by the Book." - talk about even basic understanding. 

This level of expertise nets us ART's with 2 teams, Large Solutions of 40 People and Value Streams that start with a fully budgeted project or even a "Testing ART", and it's no wonder this eventually flies in people's face.

I predict that as more organizations get in touch with such Ersatz SPC's, fewer and fewer will take the gambit, until eventually the entire thing collapses. Give it a few years - if the current trend continues, it will come to pass.

Ersatz Agility

Agility relies on empiricism, a lot of it is situational awareness and context sensitivity. The idea that "SAFe by the book is Industry Best Practice" is contrary to the very idea of agility, and what would you expect as a result when your consultant dumps a number of structures, patterns and practices on your organization? Agility isn't one of the things you should expect.

Ersatz Coaches

The SPC community is also facing an increased membership of people who bear the title "SAFe Coach (SPC)" and lack any form of coaching background.
Also note that an SPC is a SAFe Program CONSULTANT, not a coach. Consultancy has its benefits - not everyone needs to be a coach! And the SPC training program doesn't even claim to make you one, either.

Many "SAFe Coaches" confuse "Coaching" with telling other people what to do or selling them solutions. In a worst case scenario, I have seen an SPC "Coach" complain that they lacked a mandate to impose their own (very poor) understanding of SAFe  on the organization without resistance.

Such Ersatz Coaches are running rampant, to use the words of a friend of mine, "causing a nuclear fallout in their wake" - and their numbers are rising, whereas the number of truly competent agilists who work as SAFe Program Consultants isn't really increasing.

As such, the odds of SAFe-oriented coaching being worth its cost diminish rapidly.

Ersatz Trainers

SAFe allows people to get a sanctioned license to train Scrum Masters, Product Owners, teams and even managers without any relevant trainer qualification .

SAFe Trainings contain a lot of learning objectives and even provide standardized trainings. But these trainings aren't worth even the time of attending if the trainer doesn't understand the learning objectives themselves and has no personal experience to contribute.

I once got a message from a disillusioned member of a corporate LACe who complained that she had just sat through a mind-numbing training with an SPC trainer who responded to a remark, "But that's Waterfall practice!" (after having explained that allegedly SAFe's Product Management requires Big Upfront Planning) with the serious question, "What's wrong with Waterfall?" and who for the heck of it couldn't figure out why Command and Control structures don't help in knowledge work.

 What learnings would you expect from such a training? Significant agility probably won't be one.
The more organizations get exposed to such training, the less likely they will see SAFe delivering any benefits.


But wait, those are just the SPC's on the market - with an ever-growing number of snake oil sellers who are just out for a quick buck. So let's talk about the alternative.

The Inhouse-SPC

Large organizations going the SAFe route quickly shift to raising up inhouse SPC's from the ranks of their own Project Managers and Line Managers. Many of them get sent to an SPC training without ever having experienced agility first-hand, and even if they have, it was only a kind of Scream. They have been in a middle manager role for a long time, oftentimes in the same corporation since they graduated. And now they take responsibility for helping their organization "become Agile". I will grant that they are motivated and keen to make a difference - they just lack experience to compare situations and the depth to predict future outcomes.
Consequently, they often implement things which look like a good idea but will have adverse effects months or even years in the future: How can they know?

Training is not Practice

The Inhouse SPC raised by an Inhouse "Agile Academy" under the tutelage of Inhouse trainers who are also very limited in Agile breadth and depth, although a great cost-saving factor, lack the background to avoid even elementary pitfalls. Even if the organization has the foresight of combining the training with on-the-job experience, we're still talking about people who basically "do organizational surgery after having read a book on the subject".

Agile Incest

The Inhouse SPC and SPCT lead to a phenomenon I would call "Agile Incest" where people from the same company define what is "Agile" based on what the company itself is doing - the benchmark becomes the current reality instead of the true potential.

Proliferating Bad Practice

Combining the two items, that is, extremely limited agile experience as well as no exposure to alternate viewpoints, will make the Inhouse SPC believe that they have reached the culmination of Agile Excellence - which is in reality Dunning-Kruger's Peak of Ignorance.
They then proceed to spread their "excellent" ideas by moving on to better paid roles in other organizations or giving talks on conferences, where the name of their organization has a more impressive sound than the actual achievement.

Just to give one example of where this leads - I was interviewed by one such SPC who had become "Head of Agile Practice" in a corporation, who called on my incompetence for making the claim that a Product Owner actually gets to decide what gets built! They patiently took their time to explain to me in detail the mandatory half-year process across five layers of an "Agile Enterprise" where others will decide on what gets built by whom and when - before the Product Owner ever gets to see a requirement or talk to a stakeholder.

tl;dr:

A massive influx and growing army of SPC's who have no background in agility are spreading dysfunctional practices. Organizations care more for SPC price and quantity than results and quality. Combined, this will eventually lead to the downfall and marginalization of SAFe.

I will leave it up to the reader to determine whether the currently visible acceleration of this process is for better or for worse.

Ten dysfunctional Scrum Master patterns

There's a lot of material out there on what a Scrum Master allegedly is and does, although many of the tips are indeed antipatterns that will keep the team from ever reaching top performance. So let's take a look at what a Scrum Master is NOT. Here are ten dysfunctions in the Scrum Master role - and better alternatives!

The nurturing parent

A recurring theme with Scrum Masters who think they're doing a good job while actually achieving the opposite is that they take the role of a parent for the development team. The term "Scrum Mom" has been coined as an antipattern, although the issue goes much further and deeper.

Brief detour into psychology
Let me refer the unaware reader to Eric Berne's book, "Games People Play" for the full mechanics of Parent-Child dynamics. For brevity sake:

Eric Berne suggests that people are always in one of three so-called "ego states" - Parent, Adult or Child. Transactions among adults or between parent and child are "stable". Others are "crossed" (i.e. broken / unstable). Consequently, by assuming a "parent" role, one pushes others into a "child" role and vice versa.
The more frequent this happens, the stronger a parenting Scrum Master will instill childish behaviour and attitude within the organization!

The blue transaction among adults is "stable".
The crossed brown transaction is unstable - the trigger doesn't match to the response!

The Pamperer

To paraphrase Atlassian, the Scrum Master may want to do any kind of thing that's required to get the team to hum - fixing hardware, changing room temperature, bringing coffee and whatnotever.
This brings us into the "I'm only trying to help" game described by Berne: Team members get used to absolving themselves of taking care of their own basic necessities.
This eventually brings the Scrum Master in a defensive position: They constantly have to guess what other people need, and if anything goes wrong, developers might turn against the Scrum Master with blame.

Adults find taking care of their basic needs part of their own identity, and will enjoy an environment where they can do this by themselves: It instills a sense of autonomy and control.
The Scrum Master should get NEAR to the team, help them become aware of their own needs and build an environment where people can meet their own need with little effort.

The Protector

A common misconception is that the Scrum Master should cotton-wrap the team in a cozy little bubble, safely protected from "the mean outside world" so that developers can focus on writing software. This creates two separate issues: First, developers lack the interactions and understanding to figure out what's going on around them. Second, it creates another unhealthy mechanic: Dependency. Developers become unable to cope with the surrounding organization, relying on the Scrum Master.
Again, the Scrum Master ends up fighting a losing battle: If they do a perfect job, everyone will push organizational issues on them - and if they make the slightest mistake, they will be blamed for inadequacy.

The Scrum Master's responsibility is to educate people - both within the team and around - which interactions are helpful and which aren't. Avoid the trap of buffering these interactions. Unhelpful interactions cause conflict, and defusing this conflict is part of the growth process. Learn conflict resolution techniques.

The Facilitator

Yet another common misconception is that the Scrum Master has to organize things for the team - such as, when meetings take place, who is invited and what the agenda is, then to facilitate the show. This is just a specific form of pampering - developers assume that the Scrum Master knows best (sly "Tangled" reference) about meetings.  Continuously organizing or facilitating meetings is not a Scrum Master responsibility, lest we fall into the "TAGAWI" game where meetings won't be held if not for the Scrum Master. Especially new Scrum Masters will not realize that they're falling for a game and thus are very likely to lose.

The Scrum Master's responsibility is educating developers initially why and how to conduct Scrum events like a Retrospective, so that they can learn the importance of these meetings and how to make them valuable. Instead of organizing meetings, the Scrum Master is well advised to let developers take this responsibility and help them sustain this practice.

The decision maker

In many organizations, a Scrum Master may make decisions either as a surrogate manager, a spokesperson or as representative of the team. While it's valid that the Scrum Master represents a decision that has already been made, the Scrum Master is not a decision maker!

The Surrogate Manager

When teams move to self-organization, they may occasionally feel lost, because decisions that were made by others for them now lie with the team. As such, they might look to the Scrum Master to fill this decision gap. It does provide a sense of safety and comfort to let others make decisions in times of turmoil - even if that decision is wrong, the responsibility rests elsewhere. Long story short, if the Scrum Master caves in, they fall for a parent role, stopping the team from becoming truly self-organized.

The Scrum Master might want to explore with the team "Why" the team wants the Scrum Master to make this decision and "What" will happen as an outcome. By facilitating the right discussions, the Scrum Master empowers the team to make their own decisions and live up to it - propelling self-organization!

The Spokesperson

Developers may also ask the Scrum Master to fetch a decision that rests elsewhere in the organization. Terrible Scrum Masters will assume that they can make a decision instead, which will put them into the worst possible position: if they get it right, they still usurped another person's position, if they get it wrong, everyone will blame them.
Bad Scrum Masters will run off diligently to find out from the decision maker. They just fell for a game: the team plays the "helpless child" and looks to the Scrum Master for a solution.

Rather than acting as an intermediary, the Scrum Master should build networks of people, connecting others directly. If needed, the Scrum Master may need to act as a facilitator in meetings so that a mutually acceptable solution can be worked out.

The representative

In a video by Atlassian, they suggest that the Scrum Master should represent the team in backlog refinement. While it's okay for the Scrum Master to represent a specific decision the team has already made, the Scrum Master lacks the understanding of content and technical background to communicate details on behalf of the team. As such, the Scrum Master is always guessing and still likely to make mistakes.
It's very misguided to believe that a non-technical person can decide on technical details, and the details are what makes or breaks the outcome. This sacrifices effectiveness in the name of "efficiency", turning teams into "delivery factories" (another parent-child dynamic).

When teams keep out of meetings which provide an opportunity to acquire essential information and provide essential feedback, there is probably a strong parent-child dynamic at work - either developers are being pressed into a "child mould", or they are themselves in child mode and press others (for example, management or the Product Owner) into a "parent mould".

The Scrum Master should carefully examine why this is happening - oftentimes due to fear or negative organizational culture.

The bouncer

I cringe whenever I hear that a Scrum Master should act as bouncer, shooing people away from the team. Why? Because people have needs. When others feel the need to interact with the team and get called off, this will most likely trigger resentment and other negative emotions which will eventually have a backlash. Acting as a bouncer, the Scrum Master creates two separate parent-child dynamics: Towards the team (sheltering) and towards the outsider (controlling communication).

The Scrum Master should get NEAR to the approaching person, then learn why this need exists and how it can be met. One-on-one interaction can build a more positive working environment and may lead to different solutions than what the approaching person originally intended.

It's incredibly important for the Scrum Master to help others, irrespective of whether within or outside the team, to find ways to meet their needs on an "Adult" level.

The Ambassador

Occasionally, the Scrum Master may be asked or feel tempted to represent the team towards outsiders, so that the team doesn't get interrupted. This makes the Scrum Master a filter of information and a translator, both of which can become incredibly dangerous.

What a Scrum Master may do is have first discussions to see if the interaction is indeed helpful for the team and the organization, and if this is the case, they should bring people together directly in the most effective way.

Further reading

I have hinted at the book "Games people play" by Eric Berne.

Other books in this context are:

• TA Today by Ian Stewart and Vann Joines.
• Transactional Analysis in Psychotherapy by Eric Berne.
• I'm OK, You're OK by Thomas Harris.

Note that the reading of these books will not make you a professional therapist or psychoanalyst, and I strongly encourage you to stay out of trying to do therapy or wielding this knowledge as a tool - although understanding these things gives you a much better understanding of what's going on. 
Do NOT, and I can't emphasize this enough, do not start calling out transactional dynamics within your team or use TA interventions loosely. You're going to leave a trail of devastation.
Much rather, I invite you to silently reflect on how you are contributing to the situation and what you yourself can do to improve.