Why AGILE is a false path

I know, now comes the outcry of the followers of the Agile.

The agile principles commented:

The demands of agile development are more than justified!
I respond to the demands and I comment on them:

  1. Individuals and interactions are more important than processes and tools
    But that does not mean:
    Processes and tools are irrelevant.
    1. Processes enable organizations to learn and improve over time, and the processes lead to reproducible results.
    2. Tools can fundamentally change the way a team identifies and responds to problems.
    3. Who as an executive or project manager has not understood, that is a capital for the people?
    4. Processes are interactions.
      If these processes do not work, the process is bad!
      1. Unfortunately, processes are created by those who are not affected by the process and then chiseled in stone. This is absolutely counterproductive.
      2. A good process helps all involved, or making a rescue route.
        If you drive in England or Australia, the process is different, the escape route remains!
      3. Decide that the result is achieved and is SUSTAINABLE!
    5. Tools / tools are important
      1. but only if they are good tools!
      2. Often tools are "ancient" and you align your process and the tool.
      3. Well then - throw away the tool and do it manually.
      4. A fool with a tool is still a fool!
      5. If you can not do it manually, no tool will help you!
      6. The tool has the purpose to serve and no human being the tool!
      7. Changing tools is often the hardest part - here we have religious fights
      8. Technical or logical reasons are rarely used in tool selection.
  2. Functioning software is more important than comprehensive documentation.
    What that does NOT mean:
    Documentation is old-fashioned / overrated.
    1. Without sufficient documentation of your requirements, it will be even more time consuming to create the software, not to mention a revision.
    2. If you do not know where you are, it is very hard to figure out how to get where you want, especially if it is not described properly.
    3. And do not forget that people get sick, get out and retire:
    4. You then need all your knowledge and the institutional knowledge required for the rest of the team.
    5. What is working?
      1. I have just so nicely today in March 2018 so beautiful
        It works / works! ....
      2. Did you test it? Yes!
      3. Where are the test cases ... uhhh - that was just here ....
      4. I still have to debug ... à Like now - I thought it worked!
    6. Functioning means in terms of quality: "meeting the requirements"
      1. It does not matter if I have an EPIC, a user story or a clearly defined requirement.
      2. These are all requirements, which were formulated in different detail.
      3. Documentation is a must, especially in a normative environment.
      4. However, there is never any evidence that you are documenting excessively - the documentation must be PURSUANT TO PURPOSE!
  3. Cooperation with the customer takes precedence over the contract negotiation
    What that does NOT mean:
    1. Contract terms are not important. They are.
    2. If both sides really work together then we should be happy in the end.
    3. Do not do business with people who want to establish a slave relationship with you!
      1. Customers demand - especially the big customers - often a request concert, of course, free of charge - NadaThere is nothing to cost - Nada
      2. There are still changes to be made (and validated) shortly before the show, without the schedule being postponed - Nada
  4. Responding to change is more important than following a plan
    What that does NOT mean:
    1. Planning is not needed.
    2. Plans are important, but they should not be carved in stone.
    3. Everyone who has worked with plans, does not know that no plan survives the first contact with reality.
  5. After all, the entire product is not made for its own sake - it is designed to meet the needs of the business.

  6. Any Project manager who is not able to split the work tasks of a large project into small "target groups", does not have anything to do either in management or in project management!

Why is Agile a wrong path?

The most important reason is:

  1. It is understood as religion
    - I am right - you are wrong!
    1. The behavior (I am in the right, you in the wrong) contradicts the fact of the
      law of Conway - the communication is cut off.
      This drastically reduces the product quality!
    2. Cut off communication "there (have no idea)" leads to tensions.
      The application of Agile principles is as well possible in the classic V-model or waterfall!
    3. Not every problem can be solved with a hammer, not all problems are called "nail"
      This means that, instead of the classical technical approach of a logical consideration, one always works with the same principle ....
      Working with the same methods under different conditions is not logically justifiable!
      We are then in the area of ​​hype or religion == of belief "== of evidence of independent knowledge.
    4. Without being "open on all sides" - then they would be "not very tight" - Align your eyes with the target, then it will be clear if the car, the tractor, the train or the plane is right
  2. AGILE is used to play chaos management
    1. I have often experienced management using the word "agile" to mask the inability of a structured approach.
    2. It is developed cheerfully, without "development" to connect with the other needs.
  3. Study results show that the method is NOT the cause of good and fast products
    1. Agile does not scale!
      1. Apart from the study results e.g. in the automotive sector, where they then turn back to the classic methods. (Kugler Maag)
      2. SAFE® and LESS are as well no solution - especially if the user is asked.
        "Yes, the management is excited, but it is worse than before" (statement of several Safety Engineers in a at a large German company)
        "We have to do that, but it will not work" (Tier 1)
    2. The key to success is - as evidenced in extensive study results:
If the method is not the cause of good and quick realization, you should simply choose the method as it suits the purpose!
It is a mistake to think that the method is the solution - no matter which method

Here again the hint from the Namecook study.

About the author:

Thomas Arends is Managing Director of "Deutscher Mittelstand Limited".
For years in the development of mechanics, hardware and software and still as a project, quality, task force, or interim manager on the way with customers worldwide.
He works in projects of the automotive or aviation industry, medical technology or industry.
He successfully accompanies companies in the field of normative applications in the o.a. Industries, whether V-model, SCRUM, Agile, SAFe®, LESS or waterfall.