15 mindset shifts an agile coach will need to pass the SAFe 5 SA certification

This is my second time around the SAFe SA certification, I’d previously obtained this certificate way back in SAFe 4. Since that time my perspective has grown and my mindset has continued to grow. My views around agility have simplified to a few basic tests (below) backed up with all of the fun stuff around people, motivations and engagement:

1. Are you able and willing to obtain feedback on actual solution implementation quickly? Yes “quickly” is a relative term but my view is fortnight downwards, where smaller is better.
2. Are you able and willing to use that feedback to make decisions on what is actually valuable?
3. Are you able and willing to use the feedback and decisions around value to change direction?

If you are doing then above then you are being fairly agile. To achieve this there is a whole bunch of complexity around humans and their interactions and motivations.

Photo by Luis Santoyo on Unsplash

If you have a similar mindset or have spent any time doing Scrum then lookout for these 15 hurdles that SAFe presents.

1. Towards the start of the workbook, you will be presented with some concepts around building networks of people around customer needs. You will then see a horrible assumption used to justify why hierarchies and command and control are not tackled by SAFe. We are told that hierarchy creates stability and efficiency and that is why SAFe exists. To allow the stability and efficiency that the existing hierarchy extols to map onto the customer-centricity and adaptability that networks of agile team members represent. My experience is that the most agile teams work fully autonomously when leadership becoming a supportive coaching function. To achieve that transition the existing hierarchies need to be considered in terms of the waste it creates and the ownership it tends to remove. I don’t think the base assumption for SAFe is sound. Hierarchies don’t create stability or efficiency, if they did then there would be no need for timeboxed work at a cadence in the first place.
2. I’ll paraphrase a quote from Edward Deming — managers, executives and leaders are the only people with the authority to change and continually improve the systems that govern how work is performed. Say what?? Deming did amazing things to transform how businesses operated, however, it was a long time ago now and things have moved on (or should have). The most agile teams I’ve worked with are unstoppable at shaping the system around them to best fit the value being delivered to the customer. They don’t need managers and executives to do it for them, they need managers and executive to support their efforts. What is even more confusing is further down the workbook SAFe also states that the workers (BTW: are managers, not workers as well?) are the best people to decide how the work is done. Note to SAFe, if you are going to grab quotes please make sure they align with your message.
3. Borrowed from Toyota, have a constant sense of danger. Supposedly this keeps you innovating, and it might well do. However, if we think about the greatest products out there I don’t think a single one was launched due to a constant sense of danger. They were launched due to an amazing vision and massive amounts of creativity. Creativity doesn’t work when you are pumped full of cortisol due to the stress of a constant sense of danger. This is where Lean manufacturing analogies tend to trip up a little. Making a manufacturing process more efficient isn’t the same as getting a bunch of creatives together to develop an amazing product be that software or otherwise. Yes, we need to keep a rate of change but constant danger, please no.
4. Another Deming quote butchered. “Systems left to themselves become selfish profit centres and thus destroy the system.” Sounds like a bad thing, especially when your business is set up around silos rather than value streams. However, when your business is set up around products aligned to customer value this can actually be a positive thing. There are countless books and articles about how creating sub-companies aligned with products where they have autonomy and ownership has been massively powerful. Don’t believe me, have a read of Re-inventing organisations by Frederic Laloux or check out the corporate rebel blog.
5. Right before an explanation of how product increments are 8–12 weeks in length, with the objectives are selected for the duration, there is a lovely graph showing how waterfall projects can’t adapt due to decisions being made up-front and then stuck too. Under the waterfall mess is a graph line section showing a team getting feedback on every iteration and adapting to it. The trouble is this graph compares waterfall to something akin to Scrum where feedback and the ability to change happens every iteration. Not waterfall to SAFe where although there are iterations the decision making happens in quarters. Embarrassingly the graph shows 5 iterations so half of a standard SAFe product increment and thus the SAFe graph would look the same as the waterfall one. For clarity, there is nothing wrong with a 3-month roadmap. What is wrong is not revisiting the objectives in that roadmap for 3 months.
6. Workers must be heard as they are the only ones capable of determining how best to do the work. I completely 100% agree with this. However, as you will see from point (2) SAFe does not. Well, it does. But it didn’t. Hell, it’s not sure what it believes because it’s been listening to too many great people and dipping into the pocket of too many successful theories. It hasn’t noticed that it’s arguing both sides of the coin.
7. “Agile teams deliver value every 2 weeks.” This is one of my chief gripes with SAFe, the workshops and workbooks define this stuff as if it’s fact. There is no differentiation between an Agile team and a SAFe Agile team. Considering many of the people doing these courses will be new to agile they’re going to get some crazy notions about agility. Great agile teams deliver value continuously. If you are new to agile thinking or Scrum please, please, please go and check with others on the how, what and why of agile teams, scrum masters, product owners. SAFe is selling as fact their own view of these things and this is dangerous as it limits true growth and understanding.
8. As per point (7), Product owners are essentially business analysts in SAFe. They do not own the product, they have no real authority over the product. Their main purpose seems to be to translate the product backlog into the team backlog and have authority over what stories are in the team backlog. Again this is not what the product owner role is about so don’t be fooled. The most egregious thing here is that although the product owner represents the customer, they don’t actually influence the product. That’s done at a portfolio or product level. The product owner is an implementor of someone else's decisions. What does good look like? A good product owner will own the product, self-evident I know. They will endeavour to understand, and put the team as close as they can to, the customer. They will take ownership of how to generate value for the customer.
9. As per point (7) & (8), The Scrum Master acts as a protector of the team to stop interference and removes impediments for them. Right, so the SM is effectively the protective parent. I’ve got nothing against protecting the team or removing impediments. The greatest Scrum Masters I’ve worked with have helped the team to protect themselves and enabled the teams to remove their own impediments. They help these things happen but in ways that enable rather than protect. The leader part in servant-leader rather than the protective parent.
10. Luckily, this one is SAFe’s own invention. The Release Train Engineer is a chief Scrum Master. Now a Scrum Master for the Scrum Masters isn’t a bad idea. Someone to help them hold up a mirror to how they’re working, help them reflect and improve. This would be positive. Unfortunately, the RTE isn’t described as this. Instead, they challenge them on the progress that the team has made. Because nothing builds trust faster than a Scrum Master who is checking on your performance and then going off to a Scrum of Scrum meeting to tell on you. This brings me to point 10.5, the Scrum of Scrum meeting was originally designed that the teams with dependencies could get together and talk about what they’re doing. They were attended by technical people to ensure alignment. What is the purpose of this being handed off to the Scrum Master who is non-technical to tell another non-technical Scrum Master who then has to tell his team, who will inevitably go and talk tech with the other team?
11. Product Managers define the priority of the program backlog. So where is the customer in this and what the hell do the product owners do when they’re being spoon-fed what to do by product management?
12. “Business Owners are the key stakeholders for the value stream.” Doesn’t sound very customer-centric this part. So somehow we’ve built a network of cross-function individuals into an agile team. We’ve aligned this with customer value. Then we’ve said that a business owner is the key stakeholder and regardless of the team's alignment they will do what the program managers have in their backlog (which in turn could be defined by the programme backlog). Now I’m sure with good intention someone in this massive hand-off hierarchy has spoken to the poor customer. However, it’s hard to justify the inclusion of Lean thinking around hand-offs, aligning teams with customer needs and then introducing a framework that encourages hand-offs and removes team autonomy.
13. Ok, this is a positive new story. On page 137 of the workbook, you get introduced to the customer that has been hastily (if my memory serves) inserted between version 4.0 and 5.0.
14. Design thinking is an interactive solutions development approach to delight the stakeholders. Great…..if your stakeholders are your customers. Unfortunately, our key stakeholders are the business owners. So we end the design thinking about what the business owner wants rather than what the customer needs. Yes, they should be the same thing but honestly, are they always? We’ve all worked on some vanity projects and products.
15. At the end of product increment planning the team will stay and plan until the business owner agrees that they’ve got it right. Sounds ridiculous and surely wouldn’t happen, right? Well, I’ve had the misfortune to be at one such event for a team that at the last minute was told that they had it all wrong. This was at 10 pm. It took them until 2 am before they got it right in the eyes of the business owner (who happened to work US hours, so wasn’t at all put out). This surely encourages the team to agree to whatever, just to get out of the session.

If you already understand agility or have come from a Scrum background there are lots of things in SAFe that will trip you up. Especially if you are a sadist like me and put yourself through the SA exam twice in a decade to see if things have changed. When doing the exam you can’t always answer the questions with the outcome that would provide agility because this isn’t just about agility. This is about maintaining a balance between agility and the hierarchy (which adds stability and efficiency). It makes SAFe extremely attractive to corporations that don’t want to think about transforming how they operate. It makes SAFe very popular. If this is the first toe in the water and leads to greater things then “huzzah” to that. If this is the final resting place of your agile journey then it is a potential distraction from what really needs to change.

As you can see from my 3 basic rules at the top of this article, SAFe has some problems.

Yes, they suggest deploying on cadence and releasing on demand, however, that cadence is every 8–12 weeks after a system demo. Is that fast feedback?

If you do manage to get some feedback can you use it to make a decision? Well yes, but not until you reach PI planning and not if you are a lowly worker or product owner. That kind of decision making power resides with the executive and managers, the real key stakeholders.

I like to think I’ve got a growth mindset. I understand that the fixed-ness of our thinking is on a scale depending on the subject matter and possible current mood. I’m 100% sure that SAFe can be delivered in such a way to improve large corporations that have historically implemented waterfall. It may even be a stepping stone to real organisational change. However, I’ve worked with 2 organisations that have supposedly implemented SAFe. One an insurance provider and the other an extremely large American bank. In the first instance, I helped the team focus on the basics of agile and it worked a treat. There was no need to scale what was being done and so although they were supposedly doing SAFe they largely left what was working, working. The second I walked away from as there was nothing agile for me to do.

BTW: I passed my example with +90% so I am now proudly SAFe 5.0 Leading SAFe certified. Give the guy a badge why don’t you.

About the author:

Chris Davey works at understanding people and how they interact with one another. This has caused him to explore life coaching, CBT, NLP and in a very large part himself. He spends his days helping people work together, often with-in the software industry. In his spare time, he likes to create, playing and writing about games (http://awaitingmaturity.blogspot.com/), snowboards, travels and now and again just sits and thinks. You can keep up with the adventures on www.steelcurve.com, Medium @chrisjsdavey, LinkedIn https://www.linkedin.com/in/chrisjsdavey/ , Twitter @Kemlock and www.steelcurve.com. If you are really determined you can catch me on most PC gaming platforms as “Chemlock” or “AwaitingMaturity”.