Forgotten basics of management.
one of the fundamentals in OTSM (Organisation, Technology and Service Management) == Logical Scaled business® is the law of Conway.
You never heard about it?
Maybe should apply it!
The law of Conway
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." — M. Conway (Wikipedia)
is something that even having been discovered already in 1967. It seems to be forgotten.
Even though it is one of the most fundamental laws to be applied in the company, people have forgotten it.
People think if you choose an email, and instant messenger, this is what communication is.
This is not what communication is about.
Communication means the exchange of ideas, and if you have ever been working as a project manager in a company, you will have found out that every conversation that relates to the need of more funding or the change of time/project runtime is getting ignored by management.
Keeping that in mind I tell you:
Why I don’t like SAFe®
I know, that might give me a lot of enemies if a state that I consider SAFE® inapplicable, however maybe you are willing to read a bit, as to why I’m so unhappy.
Yes, I know there is already 4.5 on the market, however, let me show you, what is happening.
Scaled Agile Framework is on the market since 2008 and has had several revisions.
Here you see a screenshot out of the SAFE® 4.0.
Here you see that it is stated, that the value stream level is an optional construct.
Now if you go four – YES, precisely 4 pages – further you see the following.
Yes – exactly 4 Pages Later!
Sorry guys, if you have ever had any knowledge about requirements, reviews and so forth and if you would have applied it, this could have never happened in a book.
There seems to be a significant error inside of that thinking.
Anybody reading that will find out that there is a huge, glaring error.*
If you translate the above:
- Value Stream is optional.
- Value Stream is the most valuable construct.
you can as well state the following.
“If you want to drive with high speed on the highway, you need a lot of horsepowers is in your car.
However, you can take as well a cow, as a motor is optional.”
* (Talking to those who are certified they tell you - yes we know there are contradictions in the book. You need to go to LA and get trained, then you understand. Sorry I will not! If someone can not even express himself in a way that it is free of contradictions ..... why should I pay him for training?)
I am doing reviews on the things I write myself, what is not a good review.
Feel free to communicate, and I will correct – esp as I am NOT native English!
But if you write a book with several people and you do not detect this gross error.
If you after years of work do not detect this gross errors, how can I trust you with the rest?
Scaling of Agile
Based on the fact that agile development doesn’t scale, there have been two (well known) developments to make Agile scaling.
One is called SAFE®, and the other one is called LESS.(Large Enterprise Scaled Scrum)
if you look into the methods of LESS and SAFE® you will find that there have been a lot of new artefacts being introduced, whereas the definitions of those artefacts are in my viewset insufficient and – even more problematic – they do not match current understanding.
This makes it very, very, very difficult to understand and even more difficult to realize.
- Taking the fact that „companies are constrained to produce designs which are copies of the communication structures of these organizations“.
- Then finding out that labelling the communication structure of those who originate SAFe® be labelled „marginal“ is still very benevolent.
- Those who receive that model must have (and they have) a lot of misunderstandings, how do you want to archive a good product.
How do you think that misunderstanding will reflect in the company.
It will add confusion.
If you read through the basic principles of Agile, there is no contradiction to the V-or Waterfall Method development method.
(Even right now I know there is a religious war uprising…., See as well „5 reasons Agile is like a cult„)
According to agilemanifesto the following are the main concerns of agile
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Now let’s translate that into the typical project management.
- If you have not cognized that individuals are more valuable than a process or a tool you should not be in any manager position anyhow.
- If you have read any normative environment, where as documentation is a key fact, I can understand that you do not document what you are doing.
(Please see the latter part regarding requirements.)
No plane will liftoff, without thorough documentation of what was needed and so forth – and I rather like that!
- As long as finances are the critical factors in success to a company, the number three ”customer collaboration over contract negotiation” will never happen.
This is however a management decision and has nothing to do with development.
- If you are unable to respond to change, you never understood project management.
Once again – communication
If you look into all those areas, you find out that apparently the basis of interaction, what is communication, has been dropped out to the fullest.
Even the development of Agile shows only one thing.
The „typical project management“ and the „typical management“ have been/are apparently unable to communicate.
This can be easily solved, but it is a long way to change the mindset.
no matter if they are uttered in a type of user story or a dedicated requirement.
It is something the User (whoever that is) needs.
Sadly enough, requirements engineering is still an issue that has not gotten management attention enough.
Just recently I read through the requirements of an UAV (Unmanned Aircraft Vehicle).
You think they are written well…. Instead, I guess I ask someone in Kindergarten – they utter their requirements better.
A requirement or a user story is the communication from your predecessor, or it is the successor, in the workflow.
- If you do not get those straight
- if you do not receive the communication from your predecessor
- HOW CAN YOU EVER PRODUCE SOMETHING OF VALUE?
- If you do not produce a real requirement
- If your colleagues are unable to read what you are doing
- HOW CAN THEY EVER MAKE A PRODUCT THAT SUITS YOUR NEEDS?
Make proper requirements – these are the communication elements that are needed to create something of Value