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
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
Unfortunately, the introduction of agile software development or "company agility" often does just that: Common sense is thrown overboard.
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!
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.
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.
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!
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
You will be surprised that exactly what you did not expect is the case and where our personal recommendation will go:
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.