Eine Profession auf der Suche nach sich selbst Bringen wir Agilität wieder ins Gleichgewicht!

Bringen wir Agilität wieder ins Gleichgewicht!

Das Agile Manifest ist weit mehr als die vielzitierten vier Wertepaare. Timm Richter plädiert für ein neues Verständnis der Software-Entwicklung, für eine sachgerechte Balance der Werte und gegen Ideologie.

Management Summary

Download PDFDownload PDF

Eine Profession auf der Suche nach sich selbst Bringen wir Agilität wieder ins Gleichgewicht!

Bringen wir Agilität wieder ins Gleichgewicht!

Das Agile Manifest ist weit mehr als die vielzitierten vier Wertepaare. Timm Richter plädiert für ein neues Verständnis der Software-Entwicklung, für eine sachgerechte Balance der Werte und gegen Ideologie.

Management Summary

Wir empfehlen zum Thema Organisationsentwicklung
4 Stunden
07.11.2024
425,00,-
KI im Projektmanagement: Revolutionieren Sie Ihre Arbeitsweise

In diesem Seminar lernen Sie, wie KI Ihr Projektmanagement revolutionieren kann. Sie erhalten Einblicke in verschiedene KI-Methoden und deren Anwendung in Datenanalyse, Risikoeinschätzung und Entscheidungsfindung. Der Kurs vermittelt tiefgehende Kenntnisse zur Steigerung von Effizienz und Effektivität und befähigt Sie, KI-basierte Lösungen in Ihre Projekte zu integrieren. Mehr Infos

Während Unternehmen auf der ganzen Welt noch versuchen, agiler zu werden, wächst in der Software-Entwicklungsbranche bereits ein Unbehagen mit Agilität. Die Autoren des Agilen Manifests (Beck e.a., 2001) äußern sich durchaus kritisch und es wird darüber diskutiert, was den "Kern von Agilität" ausmache. In seinem lesenswerten Blogbeitrag: "The Agile Crisis — a Primer" gibt Jan Wischweh einen Überblick der aktuellen Diskussion darüber, welche Fehlentwicklungen bei dem grundsätzlich nützlichen Ansatz von Agilität zu beobachten sind (Wischweh, 2019).

Auch wenn Sie kein Software-Entwickler sind, und selbst wenn Sie Agilität nur für einen Hype halten, lohnt es sich, das Agile Manifest, das Gründungsdokument der agilen Idee, genauer anzuschauen und vollständig zu lesen. Dann werden Sie sehen, dass die Rezeption des Agilen Manifests den ursprünglichen Gedanken der Autoren nicht gerecht wird – woran diese nicht ganz unschuldig sind. Die Problematiken in der Software-Entwicklung, mit denen sich die Autoren des Manifests 2001 auseinandersetzten, sind genau diejenigen, die Unternehmen heute bei der Einführung von agilen Methoden im Geschäftskontext erleben, wie z.B. ein zum Selbstzweck verkommenes Reporting oder zu träge Entscheidungswege. Hier können Sie also von der Erfahrung der Software-Entwickler profitieren, um nicht in dieselben Fallen zu laufen, welche die Autoren des Agilen Manifests unzufrieden machen.

Haben Sie das Agile Manifest wirklich gelesen?

Die Autoren des "Agile Manifesto" trafen sich im Jahr 2001, weil sie über das Selbstverständnis ihrer noch sehr jungen Profession der Software-Entwicklung sprechen wollten. Die Leitfrage war: Was macht gute Software-Entwicklung aus? So heißt es im ersten Satz des Manifests: "We are uncovering better ways of developing software by doing it and helping others do it" (Beck e.a., 2001).

Das Agile Manifest ist weit mehr als 4 Werte und 12 Prinzipien!

Wenn überhaupt, dann ist die Startseite des Agilen Manifests bekannt. Es finden sich jedoch ganz viele erhellende Informationen auf der Website (die folgenden englischsprachigen Zitate sind von dieser Site, siehe Beck e.a., 2001), auf der die Autoren über die Entstehungsgeschichte des Manifests berichten. Dabei wird deutlich, wie grundlegend sie ihre Profession hinterfragen.

Es dreht sich nicht einfach nur um eine bessere Art der Programmierung, sondern um das Selbstverständnis einer Profession. Die Autoren machen deutlich, dass sie sich als der Schrecken von Unternehmensbürokraten sehen, die offensichtlich keine agilen Ansätze mögen ("the Agile approaches scare corporate bureaucrats"). Sie möchten sich von denen unterscheiden, die Prozesse wegen der Prozesse mögen ("those that are happy pushing process for process’ sake"). Die Autoren wünschen sich eine Entwicklergemeinschaft, die von der Last der "dilbertesken" Unternehmen befreit ist ("developer community freed from the baggage of Dilbertesque corporations"). Wenn Ihnen der Begriff "dilbertesk" nichts sagt: "Dilbert" ist die Hauptfigur einer Cartoon-Serie von Scott Adams. Er ist Software-Entwickler in einem großen Unternehmen und beständig den Widrigkeiten sowohl einer überbordenden Bürokratie als auch unfähiger Vorgesetzter ausgesetzt.

Werteorientierte Zusammenarbeit als Ideal

Das Ideal der Autoren sind Organisationsmodelle, die den Menschen in den Mittelpunkt stellen, und eine werteorientierte Zusammenarbeit auf der Basis von Vertrauen und Respekt fördern, sodass ein Arbeitsumfeld entsteht, in dem sie gerne arbeiten wollen. Sie schreiben über ihr Treffen:

"We all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work."

Für die Autoren definiert also das Agile Manifest dieses Ideal, wer sie sein wollen und wie sie arbeiten wollen.

Prozesse und Methoden sind für die Menschen da – nicht umgekehrt!

Sie weisen auch darauf hin, dass sie nicht gegen Methodik sind. So schreiben sie: "The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology." Diese Behauptung wird dadurch unterstrichen, dass die Autoren alle prozessorientiert und Verfechter unterschiedlicher Prozessmethoden sind, z.B. Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Sie suchen eine Alternative zu dokumentationsgetriebenen, schwergewichtigen Software-Entwicklungsprozessen. Das ist ein sehr wichtiger Teil ihrer Identität: Prozesse und Methodik sind natürlich notwendig. Aber auf eine Art und Weise, die Menschen respektiert und hilfreich anstatt belastend ist. Ihr Ziel ist die (Wieder)herstellung eines Gleichgewichts:

"We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment."

Diese Idee des Gleichgewichts wird in ihrer ursprünglichen Benennung besser deutlich, da sie von "Lightweight Processes" und noch nicht von "Agilität" sprachen.

Der Konflikt zwischen Mensch und Maschine

Ich sehe diese Balance, die die Autoren für ihre Profession wünschen, als Ausdruck des folgenden allgemeineren Ringens zwischen zwei Polen, die man gut mit "Mensch vs. Maschine" metaphorisch beschreiben kann.

Das könnte Sie auch interessieren

Alle Kommentare (3)

Profile picture for user rainer@lingmann.de
Rainer
Lingmann

Danke für den guten Artikel, dem ich fast zu 100% zustimmen kann. Ich habe nur zwei Anmerkungen:

- Dem Hinweis darauf, Ideologie zu vermeiden, kann ich gerade als großer Befürworter agiler Ansätze nur zustimmen. Doch obwohl das so ist, darf man sich andererseits vom Ideologie-Vorwurf auch nicht zu schnell ins Bockshorn jagen lassen. Denn er wird oft gerade gegen diejenigen Veränderungsvorschläge vorgebracht, die sehr wirksam wären, aber weh tun. Siehe Punkt 3 von Larman's Laws:
https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Org…

- Der zentrale Punkt des Artikels, dass die rechte und die linke Seite des Manifests (wieder) ins Gleichgewicht gebracht werden müssen, steht auf Seite 1 des Manifests, direkt unter den Wertepaaren: "While there is value in the items on the right". Man muss aber auch dazu sagen, dass er eingeschränkt ist, denn "we value the items on the left more". Es geht also nicht um eine echte Ausgewogenheit, sondern schon darum, dass Organisationen, wenn sie sich zwischen zwei Werten eines Paars entscheiden müssen, auf die linke Seite fallen sollen. Die Punkte der rechten Seite dürfen die linke nicht behindern. Vertragsverhandlungen sind bspw. total sinnvoll und notwendig, aber sie dürfen Zusammenarbeit mit dem Kunden nicht ersetzen oder behindern.

Und zum Schluss noch ein Dank für den Hinweis auf die "About"-Seite des Manifests, der ich bislang tatsächlich viel zu wenig Aufmerksamkeit gewidmet hatte.

Lieber Herr Lingmann,
es freut mich, dass Ihnen der Artikel gefallen hat.

Zu Ihren beiden Punkten:
Ich stimme Ihnen zu, dass es auch nicht richtig wäre, Ideologie zu unterstellen wo keine ist. Sinnvoll erscheint mir, jenseits von Glauben- und Haltungsfragen immer gemeinsam zu schauen, welche konkreten Probleme denn gelöst werden sollen - und auszuprobieren, ob eine Änderung in der Balance der vier Themenbereiche des Manifestes hilft.

Sie schreiben "Wenn sie sich zwischen zwei Werten eines Paars entscheiden müssen" - genau, das ist des Pudels Kern, eine Entscheidungsfrage, ein Konflikt zwischen zwei im Grundsatz sinnvollen Verhaltensweisen. Ich würde nicht empfehlen, dass man sich in JEDEM Konflikt für die linke Seite entscheiden muss. Mit einer derartigen Regel hätte man sich festgelegt und müsste nichts mehr entscheiden. Die spannende Frage ist, wenn man natürlich mit dem Kunden gut zusammenarbeiten möchte und gleichzeitig auch einen Vertrag verhandeln muss, wie geht man mit so einem Konflikt um? Und dann könnte es (in manchen Fällen) ja durchaus auch eine Möglichkeit sein, gar nicht mit dem Kunden zu arbeiten oder aber unter dem Potenzial zu bleiben, das man dem Kunden bestmöglich bieten könnte, schlicht deswegen, weil ein Kunde sich nicht mehr leisten kann.

Hallo, ich finde die Botschaft dieses Artikels auch sehr gut. Dogmatismus, Fundamentalismus etc. ist immer ein Problem. Projekte sind einmalige Vorhaben, wäre ja seltsam, wenn man alle nach einem Schema abhandeln könnte. Ich sehe die Standards als wertvolle Quellen, man sollte auch danach streben, diese nicht aus Bequemlichkeit oder falsch verstandener Flexibilität zu ignorieren oder zu variieren. Aber letztlich muss ich in jedem Projekt den für dieses Projekt besten Weg suchen und gehen. Wer sich von Anfang an oder gar immer auf eine bestimmte Methodenlehre festlegt, hat schon verloren. Leider gibt es manchmal "Qualitätssicherer" oder Controller, die nur die Übereinstimmung mit einem Standard pedantisch prüfen und nicht bereit oder in der Lage sind, die Gründe für gut begründete Abweichungen zu akzeptieren.