We now use


  •     SAFe® [Scaled Agile Framework]
  •     LESS. [Lare Enterprise Scaled Scrum]

and then the company disappears into nirvana.
SAF€ or MOR€ would be in our opinion the better description.
Its all about - make money, make more money.
Maybe, maybe, make a lot more money.


The solution for everything - AGILE???

SAFe® and LESS are methods which are used as a solution to scale agility.
BUT ...   but...
one of the people who co-wrote the Agile Manifesto says:

There is only "agile work".

This means that what is currently being done with SAFe and LESS is not what it is all about!
There are indeed agile transformations from time to time, which work, but mostly

The moment you oppsose them there a reflex reaction of those who are responsible for the introduction and make money with the coaching state
that everything is agile and they are doing everything right.

Appropriate to this topic we present you here a lecture from 2015

Adjective instead of nominative


Adjective instead of nominative

Is one of the main points that Dave Thomas stresses in his lecture.
He shows several pictures in which he describes the way of implementation and calls SAFE® as WRONG.



Although large OEM's and Tier1 in the automotive industry are getting involved in these methods, this does not mean that these methods work.
Just because others do it, doesn't mean you have to do it too, does it?

And - as my colleague Nicole puts it so nicely

Just because we are "agile" we do not throw our common sense overboard.

Unfortunately, the introduction of agile software development or "company agility" often does just that: Common sense is thrown overboard.

Screenshots from above Video

Why we think SAFe® is stillborn

You don't have to believe us... but

Read the following sentences in sequence.

Built-in quality
- sounds great. Right?

9 years of development - 1 Head and further 7 luminaries.
There must have been something to it.

Page 339 SAFe® 4.0

The "Value Stream Level" (Whatever that means now) is "optional".


Page 443 SAFe® 4.0


    SAFe® delivers built-in quality
    An optional feature is the most basic construct of the?

I just imagine how it would be if a safety engineer imagined his concept in this way.
Safety Features == "MUST Haves" would be optional?

If you don't start using your own common sense here.
If you stop reading and follow follow the fuss, you will hit the wall.

How would you react if I were to give you such a statement
after 8-9 years of development? ..... ??? ...

What would you think of my quality?
And not only of mine, but also of the quality of my colleagues?

Yes SAFe is on everyone's lips and of course I/we have an extremely difficult position when we say that SAFe is not suitable for driving any meaningful changes.
You don't have to believe all this!

Small iterative correctable steps, that is agile. That is also a classic engineering approach.

It's called "Try and Error".
Small iterative steps which, if it turns out to be wrong, can be corrected.

Instead of doing exactly the same in the organization, we do the Big Bang and introduce SAFe/LESS.
Exactly at this point I ask myself in how far one has understood what agile means!

Do we really have to implement this?
It is more than obvious that such a big bang approach is not even remotely equivalent to what was called for in the agile manifesto and that by introducing such a huge chunk you are doing exactly the opposite of what agile is.

Fundamentally wrong assumptions in the development

LESS - did I understand??

Anyone who says..:
"sequential-lifecycle development doesn't work well"
has NEVER worked on a project like this before.
Likewise, the fact that almost everything that has been developed so far, has been developed according to exactly this sequential model, ....
Of course methods have weaknesses and if you look at the data.
 "Agile" is not the savior of everything.

"But we work agile"

agile development does not contradict the V-Modell!

Again and again I hear that you work agile and that you cannot work agile with the V-Model.
The answer to such a statement is:
You have no idea?
Please show me where the contradiction of the methods is.
What is mostly done is the justification " we work agile " to justify the own produced crap.


Just because you work agile you don't throw common sense overboard!


All experiences are sacrificed to the New Saviour.
Can be done that way - is then however is  ....


It was with these very words that I began this article.

And it is exactly with these words that I would like to close this article.

Can you imagine that somebody delivers a security concept to you, a concept on which the life of the people depends and this clearly is not so important and 2 pages later is rated as very important?

For me, what is said there is very uncertain.
And of course I took the € to point out that it is very much about making money with these methods, not necessarily about making something successful with these methods.

What is right for you or yor company, we can not judge. Only you can judge that.
But I'm sure that after presenting the above mentioned, the video, screenshots and explanations you will find that at least you should think about what you are doing.
I wish you all the best!

For religious followers

Yes, developmental methods have often become somewhat religiously degenerate in the meantime.

Whoever has the best method would simply make sure that he continues to work with exactly this method without making a big fuss about it. He would simply be happy that his company and his employees are successfully delivering products.

Last but not least there is a study below regarding the methods. The question was asked which method in software development (attention: it is not about hardware and not about mechanical development) the method is which

  •     fastest and
  •     most affordable
  •     is of the highest quality.

You will be surprised that exactly what you did not expect is the case and where our personal recommendation will go:

The Spiral Model with CMMI(Level5)

But please only if it really fits. It should never be fought for the sake of the method, it must be the result of the product and the satisfaction of the customer that determines the method.

Lets GO!

Evaluating Ten Software Development Methodologies

Download Request