I am about to change my job for an automotive embedded software company, doing ASIL D development. Such a company put a highlight in their SAFe framework. Now, given my little experience, when working with "official" Scrum managements or "official" Agile methodologies in development, in couple of companies (the two last big ones where I worked) I found it was introduced frustration and acceptance in coworkers, as they lost the initiative, lost product innovation while working for years on the same project. Other engineer friends had similar opinions and "they live with it".

Either this was normal or not, only once I worked with constant enthusiasm, and that was fitting how I think. We were following the Kanban method, with small tickets, and implementing changes as required, turning out to be something like Extreme Programming. No complex tools for tracking, no coworkers paid to do only that, meetings were done only if there was a problem, everyone was feeling useful, and delivery estimation check was done with close contact with each other - and experience. We had relatively fast deliveries, enthusiasm and the like. But the company was also smaller.

As I am about to decide on this new job, I wonder: do you have any suggestions about which question I could ask their managers at the interview to check if SAFe is compatible with how I work? I am passionate about technology, electronics and reliability applied through it, not about management and confining creativity and engineering knowledge. I really feel clueless about how to discover this in advance, instead of discovering this after I start to work.

As you might imagine, I am not an expert in such management things, but I think that if something works, it should go smoothly for an engineer without spending weeks to study such methodologies and not working. So I am also searching for a way to look at these things with the right perspective.

  • Wikipedfia says: The Scaled Agile Framework (abbreviated as SAFe) Commented Jan 22, 2020 at 12:19
  • 2
    Please note that the disadvantages you mention for Scrum are actually not inherent to scrum, but frequently encountered in organizations claiming to be agile without understanding the basics of it, or understanding it a wrong way.
    – Laurent S.
    Commented Jan 22, 2020 at 13:01
  • 2
    I don't really get the downvotes on this one.
    – undefined
    Commented Jan 22, 2020 at 15:44
  • @undefined Me neither, must be from the SAFe consultants.
    – thexeno
    Commented Jan 22, 2020 at 18:18
  • @BernhardDöbler Yes, isn't what I wrote?
    – thexeno
    Commented Jan 22, 2020 at 18:20

4 Answers 4


This has absolutely nothing to do with SAFe or Scrum or Kanban or Extreme Programming.

To start with, lots of companies claim to be using one or more of these methods, but you see a couple of things. One is that they are frameworks and there are multiple ways to do them within the bounds of the framework. Another thing that you see is that the intent of the framework isn't understood and the organization does them wrong. Just the fact that they claim to do them, whether it's in person or in a job description or elsewhere, doesn't really mean that much.

You know how you have worked in the past and have been effective. You can ask questions about how these organizations work - is work pushed or pulled, how much time is allocated to innovation or R&D work, what tools are used and how do they fit into the development process, how much time is spent in meetings on a regular basis, how often is work delivered and integrated, and so on.

Just don't worry about what process models or methods or frameworks that they claim to use. Focus on what's important to you and ask these types of questions to everyone, from the hiring manager to the leads to the individual contributors that interview you. Maybe even ask the same questions to multiple people, especially if they are on different teams to get a feel for how different teams in the same organization may be structured or go about their daily work.

  • Thanks for the answer. What do you mean by "work pushed or pulled"?
    – thexeno
    Commented Jan 23, 2020 at 11:33
  • 1
    @thexeno Work can either be pulled by the person doing it at the appropriate time or pushed by an external entity, such as a manager or team lead. Commented Jan 23, 2020 at 12:01

Out of point: My opinion on SAFe is that it is not "agile" but something that tries to reconcile management and product management with agile team.

On the point: The issue is that like for any methodology the company can say "we're doing X" or "we're working with Y" and when you join you understand that they don't understand either X or Y and are just buzzwording (intentionally or not).

Start by researching about SAFe to better understand what problems it tries to solve and how it works. Then when interviewing, don't ask about SAFe, but how they effectively work with specific questions:

How much planning is done on project, is it long term planning (>1y), mid term planning (3~6 month) or short term/scrum planning (1~4w)?

How are deliveries done? Which system is used? What tools? How long does it takes once a task is finished to be delivered?

With this you'll know two things: If they want to use SAFe do you want to work with it. Are the process effectively in place what you seek.

  • I agree with you, the only thing Agile in sAfe is the name. All the rest is just turning big waterfall in smaller waterfalls. But as people choosing methodologies most of the time don't understand the concepts and as "Agile" is still a trendy methodology, putting "Agile" in that name was probably done in order to sell it better.
    – Laurent S.
    Commented Jan 22, 2020 at 13:05
  • What do you mean by deliveries? And when you suggest asking for systems and tools, you mean to accomplish what?
    – thexeno
    Commented Jan 23, 2020 at 10:59
  • Also, I don't get how the time between a finished task and a delivered one, relates to me, as a potential developer?
    – thexeno
    Commented Jan 23, 2020 at 11:22
  • 1
    You said "We had relatively fast deliveries, enthusiasm and the like." I supposed deliveries are something you care about so I suggested you ask how they do it. Now it depends what you mean by deliveries. I thought you meant code delivery. In some organisation you code, you commit, someone test, it's delivered. In others, you code, you wait for approval, you commit, you wait for merge, you wait for test, etc. far from fast deliveries.
    – JayZ
    Commented Jan 23, 2020 at 12:29
  • @JayZ thanks for the clarification. I meant what you understood
    – thexeno
    Commented Jan 24, 2020 at 13:49

SAFe is a framework, not a proscription. That said, there are some fundamental things which, if you're not doing them (correctly), you're not doing Agile.

I understand your frustrations with an Agile process, especially if done badly, but if you work with it, a lot of the pain is removed (the "big bang" approach to delivery, weeks of forced "death march" overtime, the screaming and blamestorming when things go wrong, management hiding behind "you didn't tell us it would be late", etc).

It's not perfect of course; It can be really frustrating to be pulled out of an intensive, head-down code session for some seemingly trivial ceremony (an Agile term for a regular meeting). And when the "open and transparent" is used by management to gather info for bashing the team....

I understand where you're coming from, but I've also over the years worked with some really stubborn people who cannot, will not, start properly using source control, an IDE (software development environment) or some other tool or process (testing?) that we, as a profession, now consider de rigeur.

Do you like the job? Is the money good? Other aspects? Take it or don't based on those.


My company rolled out SAFe based on the success of a grassroots agile movement.

The good thing about it was bringing more of management into feeding us work in a more agile way. i.e. by maintaining a prioritized backlog and at least trying to do small features with more frequent feedback.

The bad thing about it was it had a tendency to centralize decision making and added a lot of bureaucracy/overhead. When I was a scrum master during the grassroots phase it mostly meant leading the meetings. Our scrum master now is doing administrative work at least half time and often full time. Our day to day is mostly the same, but our month by month feels a lot less efficient. For example, we are asked to produce 10 week plans when they almost never last past 5 weeks. I think a lot of our day to day is helped by the fact we did grassroots first, and still insist on a lot of the autonomy that provided.

Were I interviewing for a job at any "agile" company, whether SAFe or not, I would ask about their planning process from when someone has an idea to when it is deployed to production. That will give you an idea of how much teams are autonomously executing in small increments to a well-communicated shared vision, versus being top-down managed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .