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.