Scaled Agile: misconceptions from a Mechanical Engineer
Learning and applying Agile is not only for software teams, developers and productivity nerds like me

Last year, I became a Certified SAFe® 6 Agilist.
Before I attended the training sessions, I thought I would sharpen my skills in Scrum, DevOps, and how people work in those hyped Tech Companies. I am a Mechanical Engineer but over the years I have transitioned to Data Analytics and Software Development, so this seemed the perfect next step to move in that direction.
In reality, learning about SAFe® 6 helped me more in terms of career growth and big-picture vision. It doesn't turn people into gurus about all DevOps tools out there. It allows individuals and organizations to face the digital era more competitively, which is far more valuable.
Let me tell you why that is, while going over three misconceptions about Scaled Agile (and Agile in general) before learning more about it.
"Every business is a software business”. Watts S. Humphrey

Myth #1: Agile is for Tech Companies only and has nothing to do with Hardware-based businesses
If you develop hardware products, you surely understand how building mockups and functional prototypes early on can help you detect and solve problems that would be extremely expensive to fix if found close to the production date. This is essentially an Agile practice.
The truth is that companies and institutions in different sectors benefit from an Agile mindset, regardless of their core business (including Governments and HW manufacturers).
One example is reducing the size of work batches to reduce variability, obtain faster feedback loops and therefore shift learning to the left of the development timeline (where errors cost less). Those are some of the practices used to obtain Built-in Quality, which is encouraged by SAFe.
Think changing a CAD model and 3D printed fixture vs modifying (if possible) an injection mold and re-organizing the production line. That's peanuts and hours versus tons of money and weeks.
Myth #2: Using Scrum only means more meetings, steps, and overhead for developers, and tools to micro-manage
This is the most falsest, false thing you'll ever hear. Yet, I've heard this one from friends and colleagues, and people online.
They complain because the companies they work for "use Agile", and that means they have so many documents to fill, endless meetings to attend and they have to tell what they are working on every 5 minutes, which gets tracked on a fancy tool like Jira or Asana.
I've been there. I had to move tickets from one stage to another too, while writing long emails and preparing PowerPoints to justify what I was doing, and then having long meetings with my boss and other 20 people, to discuss minutiae for each one of the attendants and get micro-managed for not having attached the raw data file to the PowerPoint so it remains tracked.
The reality is: those companies think they work in Agile ways only because they use Jira and create "Epics". They simply don't understand how Agile works.
On the contrary, well-implemented Scrum (and SAFe®) aims at reducing delays, and inefficiencies, and letting dev teams work with autonomy without useless overload.
People need to understand that there are huge differences between Maker schedules and Manager schedules. The cost of having an interruption is HUGE for a developer. It's anti-economic. It increases delays, de-motivates, and lowers quality.
One of the principles of the Agile Manifesto is "Working software over processes and tools". Yes, it mentions software, but it applies to anything. The key is to make sure you are working on the right thing, at the right time. Agile focuses on demonstrating what you are doing, getting feedback fast, and therefore improving quickly.
Documentation is very important, but making sure you are achieving a working product is even more important.
Myth #3: Agile Is Just for Coders
This is also false, and if you read the previous two points it should be obvious why. SAFe® needs to be implemented at the Enterprise level to be effective, and Management training is the second step on SAFe® implementation roadmap.
Managers can't continue pushing project requirements and deadlines, and wait until the testing phase to realize the requirements were wrong all along. It's simply too slow.
One example: A meeting without a clear goal, with more than 10 people, lasting several hours in the morning simply doesn't work - yes, I'm talking to you, middle managers in every single Italian Automotive company (don't know about the rest of the world for now). They are strongly discouraged by SAFe.
At best, people don't pay attention, and if they are working remotely they do the laundry or something while they listen in the background - guilty! Or they don't pay attention at all, and work on a personal project during the meeting to avoid the waste of time (guilty as well!).
Repeat that, every week (even several times per week) and you get more than a quarter of the knowledge worker's time spent on useless meetings—no wonder the company can't keep up with the market.
Of course, I'm not an experienced manager or anything like that, this is just my two cents.
What makes it even worse: people also waste time before and after the meeting.
Before the meeting you don't commit to working on a large task that needs full concentration (you know, the ones that actually add value and demand Deep Work). You'll get interrupted anyways, so you do smaller tasks.
After the meeting, it takes you a considerable "ramp up" to concentrate again on what you need to do - between 20 and 40 minutes for most people!
Managers also need to understand why asynchronous communication exists.
SAFe is a framework: it's a cultural thing
SAFe® draws concepts from Lean Thinking and Agile and helps Enterprises apply them at scale. That's it.
But that's much easier said than done because of an ugly set of truths: large enterprises have completely inefficient and under-performing habits, because of outdated (internal) cultures and therefore are terribly slow at keeping up with rapid market changes.
In the book The Power of Habit, Charles Duhigg puts it this way: successful organizations simply have positive habits. Therefore, large enterprises failing to compete in a dynamic market often have strong habits that prevent them from changing quickly - The whole thing is a cultural problem.
As new technologies enable more innovative businesses to thrive, the question is not whether or not large companies will need to face disruptive business models enabled by technology that may take them out of the market. The question is when.
Those who fail to adapt and compete with disruptive businesses will become the next Blockbuster. In fact, 52% of the Fortune 500 companies have disappeared over the last two decades.
What SAFe does is implement core values and competencies at the Enterprise level, that let companies achieve Business Agility.
Personally, I think the concept is incredibly powerful, and can be adopted by any type of Enterprise. However, because of the nature of Software development, it becomes easier to implement in Software companies. Other types of businesses (for example large Automotive OEM's) face very different challenges, and while they necessarily need to move towards Agility, they are inevitably slow to do so, because developing large cyber-physical systems is complex on its own, and because many managers are too reactant to change the way they work.
The key part is: people (and therefore companies) really do need to change the way they think, in order to implement Agile practices. And this is very hard to do.
I am a pessimist, so I believe the transformation will become slightly more sustained as the generational change from Boomers to Generation X to Millenials progresses - when more people born in the digital era start to take more leadership within large enterprises.
Final thoughts
Large enterprises (of any type) that don't implement Business Agility Value Streams are not exactly doomed to fail, but will surely have a tough time succeeding nowadays. I keep coming back to the Blockbusters vs Netflix example, but there are other cases, like Blackberry, or HTC.
Learning about Agile was an eye-opener for me when starting my own business (which is completely different from what I do at work, so no Software!). It helped me understand the value of streamlining my work, and minimizing Work In Progress and To-Do lists (I was using Kanban board wrong all along!). The most important thing was getting quick and frequent feedback, and this is why I started doing with my products.