Forgotten basics of management.

one of the fundamentals in Logical Scaled business® is the law of Conway.
You never heard about it?
Maybe should apply it!

Communication.

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.

 

 

 

Sorry guys, if you have ever had any knowledge about requirements and if you would have applied it, this could have never happened in a book.

Miscommunication

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:

  1. Value Stream is optional.
  2. 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?)

 

Sorry guys.
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)

Wordings

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.

Why do I tell you that?

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")

AGILE

According to agilemanifesto the following are the main concerns of agile

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Now let's translate that into the typical project management.

  1. 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.
  2. 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!
  3. 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.
  4. 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 developmnet 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.

Requirements

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.

COMMUNICATION

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

Quality

is defined by

 

"Compliance with requirements."

 

Why should we be compliant?

The former CTO of IBM Germany, Prof Dueck, states in one of his essays.:

 

“regarding the finances, it always has to be an A Grade (very good), 
all the rest is accepted if being sufficient.”

 

Sorry guys, sorry management.

This is what drives anyone in development department crazy.

If you have to deliver products where you know that they are shitty, that kills any communication with those who demand it.
So any demand you have in the company:

  • is it from management,
  • the colleagues or
  • the user

can be considered as demand.
Whereas some of the people have the ability to define their needs in a technical manner, and some others (for example a baby crying) are not able to send out their needs/demands in a way that they are understandable and free of conflicts.

"Built in Quality"

is something any individual who has pride in himself, inherits.
You do not need to tell people to make quality.
For years, communication has been broken, and people are forced to deliver MVP's == Minimum Viable Products.
It is NOT A PRODUCT"!

So get in communication, talk to our colleagues.
(And do not be surprised that in the beginning, you will get all this piled up emotional charge.
You need to get emotions out first, before you can start to get in communication.)

Normative development

in any normative development, there is a mandatory statement regarding requirements.
These requirements, no matter where they have been generated, go through a review.
It has been understood that any requirement is the communication that you either receive or forward to the next level and that this one is making the quality of the product.

Conway law in the view of the company.

Any role in the company, of any unit in the company, has to receive something that is called "work product" in the sense of standards.
To the degree that this work product is communicated correctly, and is complete and fulfils all the criteria you need to work, the company will be able to run correctly.
(Imagine receiving a bill without bank data, our bill without the addressee and so forth.)

Ensure work products are complete and met the quality criteria!
(This is esp. true concerning Requirements and technical details.)
This will make communication running smooth.

Processes

are there to ensure a smooth and comfortable workflow of any kind of business object running through the company.
So taking the view set of agile development that people and individuals are superior to processes and tools, it only shows that the process in itself is insufficient.
So correct it, or are your processes and tools "carved in stone"?
A lot of tool decisions getting done are based on opinion of some superiors, not based on technical demands.
You wonder  why the tool is unimportant.
The tool and the process has to SERVE the one who use the tool.

How to communicate?

you can study communication at university.
you can study management at university
and even something called advanced management.

If you first have to study all those areas before you are able to work correctly in your job, you are lost.

Communication is not a one-directional flow, it is bi-directional flow, whereas on each site the receipt and understanding has to be verified.

What you find in the most companies is, that management, driven by an overloaded time schedule, is no longer able to receive communication from the areas of responsibility.

There is no better way to tell your colleagues that you don't like them, but by ignoring their communication.
(Try to do that with muscle ache or a flue, your bodys feedback will be accordingly, but there you do not wonder.)

If you do not develop a communication culture where the feedback of your colleagues is valued the same as the communication originally uttered by management, you are violating the Conway law and thus creating products of less quality, what is directly resulting in less income.

The heroes in the company!

A lot of people on management posts do not belong there.
They arrived on the post because beforehand they received a lot of attention. But Attention is not a work product!
I recently talked with one of my former colleagues who told me that by now there are nearly reaching the first level of SPICE® and I congratulated him and said him that he must be quite happy right now on that level as that would reduce task force significantly. (The company had about 60 to 80% of the projects running in task force mode before.)

He told me that it is even worse by now.
The reason: The team and department hats actively steer the project into a task force mode to get more attention.
Then, by handling the dangerous situation, can be attributed a hero, what will ease the path to higher management levels.

This is quite the opposite of what it should be.

Sadly enough, it's very often happening, as communication is not handled correctly.

The real heroes

Those who are the real heroes in the company are those who get the job executed without any further attention.

Long-term experience shows that those who create the most attention, later on, will be those chosen to be the leaders.
The real heroes, however, get not noticed.

Look up the real heroes! They can receive the communication, handle according to the job description and for what an excellent communication.

These people should be awarded the leadership posts!
If you do not, you tell your people.

 

"Hey if you do your job correctly, you are not a good guy.
You have to create shit, that needs management attention, and then you go up the career ladder."

 

Maybe you should send out another communication.

Hype Driven development

 look it up, here in this short essay it is shown, how people act on any hype in development.
If you think that is different in management, you are food.
As well there are some new and very high-end methods developed.

My method is the right one

Mybe you better start reading facts, if you have that mindset.

Look up the studies.

  1. There is no such thing as a best method.
    It is NOT TRUE THATT AGILE IS THE BEST
    The success is based on expertise. www.Namcook.com 
  2. There are things that stay - since 1987.
    Please see .
    Software Defect Reduction Top 10 List - study of the University of Maryland

 

Once again

Go back to the area of communication.
Communication is the most critical area of concern, that is making any methods you use working on not.
Today we focus on finances.
Yes, there are a lot of management trainings. However, the basics, the very basics, what is communication, are no longer valued to the degree they should.

If I talk about the forget management knowledge, I here refer only to communication.
Maybe you rethink what you are doing there.