Well, everybody speaks about agile and with the understatement of a British
Lord I would say that most stuff I read and hear about is total bullshit. A
fundamental mistake most people do is neglected the boundary conditions of
agile - a mistake often done on data science and machine learning as well.

If we have a look at e.g. this talk here, then we’ll find out that most
applications it originates on are tasks that were well defined. Breaking
them down in chew-able pieces and iterate fast on small problems to find
solutions is easy.
The problem nowadays is that it is forced as a static type of organization (if you must use agile it is no longer dynamic) on top of any
problem of any size. Further, the whole process is dumped down to a level
where it becomes practically useless. If it is applied to stuff like online
marketing and other stuff that can’t cause real damage, then it is almost
irrelevant if it breaks more than once in a while. The risk (hazard *
damage) is simply super small.

Sometimes engineering projects like the Apollo program are presented as an example for agile development. Well, yes such stuff works only if the people working on the project are excellent and know what they are doing. Further, they had their 30+ years of experimentation and failures in rocket science already. Moreover, most physical fundamentals were described mathematically already. That is a completely different situation to developing a product e.g. in health care or everything else with more stakes on the line than online marketing. Further, we hardly find skilled teams ever. I don’t mean above average which is statistical non-sense. I simply mean people who understand what they are doing and not people clicking through lots of sub menus to come up with something that works sometimes and the underlying structure is hardly debugable. Considering how many people I met and worked with who hold some degree or did some course in something but are not able to understand what they are doing I foresee an interesting future - especially in Europe. But let’s get back to agile and focus software development:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Manifesto for Agile Software Development

  1. Enforcing agile on everything contradicts “Individuals and interactions over processes and tools” because it enforces tools and processes.

  2. “Working software over comprehensive documentation” does not mean sometimes working software with close to no documentation. The latter is the one I encounter at least on a weekly basis. The only thing worse than no documentation is wrong documentation which seems to be more and more common for many machine learning tools. Damn it! It’s not so difficult to write or generate proper documentation for a version 1.x product!

  3. “Customer collaboration over contract negotiation” seems to be moving into “let’s deliver something the customer can’t use and therefore they have to build the working product themselves”… . In ML/AI contract negotiations are relatively straight forward but in general software development it seems like contracts are getting worse and worse (payment per minute/second instead of daily rates with 100% surveillance - who in his right mind allows a customer to install spyware on hardware they are responsible for …).

  4. “Responding to change over following a plan” works only with excellent people. However, reality shows that it is more or less goal-less changing because the tool agile says “change”. Adapting to change works with skilled people only!

I want to point out that I don’t reject the agile manifesto but its enforced realization. It seems like it influences software development in a harmful way already.