Agile, Digital Uproar – or – New Robes for a New Emperor.

This is the title of an article Aebby (Dr. Eberhard Huber) published in his projekt (B)LOG. It is a censorious discussion of the current “agility hype“.

For me, “agile“ describes a quality that is excellently described in the agile manifesto. Unfortunately, agile (just like digital and innovative) has now become part of the Business Theatre instituted by the top managers of German Enterprises. They deal with all kinds of things, but they totally neglect the people working in the enterprise and the customers.

The Business Theatre is usually staged by the (top) management. It is a kind of self-portrayal practiced in enterprises and civil offices without any semblance of truth. As a consequence, you often get totally surreal decisions.

For our topic, this means: if agile is fashionable, then they decree the institution of agility. They pretend it is as easy as if you decree that the company cafeteria should get a new layer of paint.

Then they employ a few agile prophets in HR (Human Ressources) who are supposed to not only make the enterprise and its employees innovative, but also agile. And since the agilization of the enterprise must be just as measurable as its innovative potential (and everything else), a stupid counsellor gets the task of developing an agile KPI (Key Performance Indicator. Again and again, it is an exciting but mostly hilarious performance on the stage of the Business Theatre.

• Well, so be it. With his article, Aebby says what I feel about more than the following three topics:

• Agile has nothing to do with methods and/or technology.
• Successful projects have always been agile in the past.
• Self-organization is only one facet of agile work.

Well, I would like to put three exclamation marks behind every one of these sentences. Let me continue citing Aebby – on sprints:

Here is my favourite citing:
Sprints – that sounds nice and fast.
Sprint after sprint without guaranteed pauses will kill any human body.

All of this is beautifully and correctly expressed. I strongly recommend that you all read the article. In my own words and understanding, agility is something like the art and culture of life. Here are a few additions to Aebby’s article:

Fast sounds nice. But then, today, you have to be fast anyway. And fast has nothing in common with the term Sprint. After all, the agile manifesto was written by software developers, just like SCRUM was invented in software development. And they wanted to develop a better software.

What they meant in SCRUM when they said Sprint was the distance between two integrations. Initially, the developers programmed their modules separately. As soon as the modules had reached a certain level, everything was integrated and a new build was created.

If you had huge projects, the distances between two integration dates was sometimes half a year – often more. If the new build did not work properly, the error had to be found by means of regression if you wanted a running system. That meant you had to reset the entire development step-by-step as far back as the last step. This was an immense effort in work and time. I remember a project where, for more than half a year, we had no running system. Naturally that is fatal.

Consequently, a main reason for introducing short integration times was that you wanted a running system with the current development standard at all times. You never wanted to lose your feet. Consequently, you had to shorten the time between two builds considerably. That is what SPRINT means. It is misleading, because it is not about speed, but about stability. It is not about being fast. More often than not, you reach a goal more efficiently by taking small steps than with big ones.

Agile working certainly does not tolerate working without plan or concept. Mind you, instead of using the word ”planning“, I would prefer to call it a well-thought-through and diligent procedure. Agile is the ability to observe and learn. You absolutely need to be able to always follow what is going on and react to undesired developments with a level-headed reaction.

Sometimes, you do not really know the actual details of innovative projects with totally new functions at the outset. That is especially true if you want to utilize new technologies that might have disruptive effects and thus bring a high degree of research to the project. Then the only way to deal with the development is agile. This was often so in IT. In this case, it would be better to call it an iterative culture of trial and error, instead of agile. It means that you build roust prototypes, then test them, learn from it and improve them.

RMD
(Translated by EG)

P.S.
Aebby’s article was also part of the Blogparade by the Projekt Magazins.