Agile – That sounds fresh, that sounds dynamic: Somehow word has got around that this must be the ultimate in development philosophy. Even people who have not yet developed anything in their lives except perhaps a healthy appetite, like to ask if they would also “develop agile”. It’s probably one of the buzzwords of recent years. But is Agile always the right approach? Does it automatically guarantee a usable or customer-oriented product?
The answer, especially to the second question, is a clear no, but it is precisely this supposed promise that makes Agile the Holy Grail for many.
The agile approach as “lip service” is rather dangerous. Or as my favorite Agile coach says, “Real Agile means being brave.” However, very few people are aware of this. They think it would be easier and simpler by itself. However, the principles of Agile are generally not observed: In many larger organisations, decisions are still made very hierarchically. The project employee then reports to the subproject manager, the project manager and the latter to steering and steering committees, who in case of doubt have to reinsure themselves again in the line organization. This has nothing to do with Agile. “Set up projects around motivated individuals. Give them the environment and support they need and trust them to do the job.” Those who are not honest with themselves and still work in traditional structures, but like to pretend to be “agile” will be shipwrecked.
The principles of Agile are often ignored
In addition to the decision-making ability of the project team, the involvement of the customer also plays a central role. And as long as it is not possible to integrate the (right) customer (or the customer correctly) into the development process, it does not matter according to which paradigm the customer is not involved in the development. Often enough it happens both when writing a specification in the non-agile approach and when writing sprint appointments in the agile approach that the right customer (e.g. the actual user) is not involved at all or is present. He is often the employee who has other important things to do, such as taking care of day-to-day business. The seconded deputy who is currently available knows about it, has seen it before, or at least has spoken about it to someone who should know.
It’s like the joke about the drunk who desperately looks for his key under the street lamp, on the grounds that he can see better there than in the dark bushes where he actually lost the key. Unfortunately, some abbreviations are not. The disappointment of the customer is inevitable in these cases.
But even if the customer gets the job done right, is Agile better in any case? Here, too, I mean no. Agile is a good choice and may even be necessary and helpful for particularly complex projects, with distributed roles and long runtimes, where not all dependencies can be identified in advance and cannot be controlled at all (Thorsten Wolf wrote (only german) a nice explanation of what is “complex” and what is “complicated” – and how to handle it – on agile4work.de).
In these cases, fixed planning at the beginning is sometimes not possible. Agile in these cases is a kind of “lesser evil” that has to be accepted in an increasingly complex and networked world in order to reach its goal at all. For this I need the courage to focus on the “motivated individuals” and the confidence “that they will do the job”. Each specification is otherwise obsolete in terms of content before it has been agreed and released.
Especially with architectural decisions, the goal must not be completely unclear at the beginning.
However, even in such complex projects, Agile does not mean that the goal must be completely unclear at the beginning, or at most the way to get there. Architectural decisions in particular may otherwise be made completely wrongly and practically irreversibly. Such dependencies must be explained to the customer as early as possible and the goal discussed with him. Because if a builder does not know whether to end up with a detached house or an underground car park and is not even rudimentarily familiarised with which construction technique is better suited for which project, neither the prefabricated house nor the stone-on-stone method will achieve the desired result.
After several “agile” voltes during the construction phase, it ends up either in a much too expensive family house or in a rather ugly underground garage.
User Review
( votes)
