Agilität - Die häufigsten Missverständnisse, Teil 2

Falsch: "agil" und "ingenieurmäßig" sind gegensätzliche Vorgehensweisen

Niklas Schlimm

Kennen Sie das? Sie lesen einen Artikel und ärgern sich ein wenig über die Behauptungen, die in dem Beitrag aufgestellt werden? Ich finde, man sollte Behauptungen immer ein bisschen untermauern, indem man zum Beispiel auf Aussagen anderer Experten Bezug nimmt. Diese kann man dann diskutieren und am Ende „seinen eigenen Senf“ dazu geben. Dann hat der Leser den Eindruck, dass der Autor nicht denkt, er alleine hätte „die Weisheit mit Löffeln gegessen“ und das ganze wirkt objektiver. Man kann natürlich auch bewusst von seinen eigenen Erfahrungen berichten. Das kann man dann entsprechend formulieren, also konkret beschreiben, was man selbst gemacht hat. In diesem Fall leitet man aber auch keine allgemeinen Gesetzmäßigkeiten oder Handlungsempfehlungen ab (oder nur mit größter Vorsicht).

Warum schreibe ich das? Dies ist der zweite Teil in der Artikelserie zu den häufigsten Missverständnissen rund um Agilität. Es geht diesmal um einen Standpunkt, den ich vor kurzem in einem Artikel gelesen habe. Dort werden „agile“ Verfahren und ingenieurmäßiges Vorgehen als gegensätzliche Denkphilosophien beschrieben. Folgende Zitate aus dem Artikel verdeutlichen, was ich meine:

Sie fragen sich, ob es nicht sinnvoller wäre, die Softwareentwicklung vernünftig ingenieurmäßig aufzubereiten, um deterministisch eine Produktionsqualität, wie z. B. im Fahrzeug- oder im Hausbau, zu erzielen, anstatt sich auf Behelfslösungen wie agile Vorgehensmodelle zu verlassen.

Ein ausschließlich ingenieurmäßiges Vorgehen funktioniert nicht in komplexen Umgebungen, mit denen wir bei der Softwareentwicklung häufig konfrontiert sind.

Die Aussagen interpretiere ich so, dass nach Meinung des Autors ein ingenieurmäßiges Vorgehen im Kontrast steht zum agilen Vorgehen. Der Autor lässt allerdings weitgehend offen, was genau er mit „ingenieurmäßig“ meint. Das habe ich zum Anlass genommen, und auf dem deutschen Wikipedia die Einträge zu Ingenieur und Ingenieurwissenschaften gelesen.

Ich breite die Inhalte der Wikipedia-Einträge hier nicht aus. Den Einträgen kann ich aber nichts entnehmen, was gegen agile Vorgehensweisen zur Umsetzung von Software-Projekten spricht. Meinte der Autor mit „ingenieurmäßig“ vielleicht „Software Engineering“? Software Engineering wird gerne als Teil der Ingenieurwissenschaften verstanden, erfasst aber alle Bereiche der Software-Technik und damit auch die agilen Vorgehensweisen. Der Begriff „ingenieurmäßig“ ist also zumindest irreführend und etwas unglücklich gewählt.

Später im Artikel wird aber klar, dass der Autor eigentlich gar nicht „ingenieurmäßig“ meinte. Der Autor wollte vielmehr sagen, dass agile Verfahren im Kontrast stehen zu formalen, stark prozessorientierten Vorgehensweisen. Letztere haben die Eigenschaft, dem Team sehr fein aufzugliedern, wer, was, wann tun soll. Das „wie“ wird also nicht dem Individuum (Entwickler, Analyst etc.) überlassen, sondern klar vorgegeben. Folgende Wikipedia-Zitate zu „Agile Software Developement“ machen eigentlich ganz gut die Gegensätze zwischen agilen und prozessorientierten Vorgehensmodellen klar:

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

„So-called „lightweight“ software development methods evolved in the mid-1990s as a reaction against „heavyweight“ methods, which were characterized by their critics as a heavily regulated, regimented, micromanaged, waterfall model of development. Proponents of lightweight methods (and now „agile“ methods) contend that they are a return to development practices from early in the history of software development.“

Aus den Zitaten finde ich folgende Begriffe wichtig:

„heavyweight“ vs. „leightweight“: Wenig vs. viel Dokumentation speziell über Prozess und Kommunikation.

„micromanaged“ vs. „self-organizing“: Wenig Freiraum vs. viel Freiraum für das Team und das Individuum.

Weiterhin möchte ich noch folgende nennenswerte Gegensätze zwischen traditionellen und agilen Verfahren vorschlagen:

„funktionsübergreifend“ vs. „prozessorientiert“: Das muss ich ein wenig erklären. Schon im Regelkreis (siehe erster Artikel) habe ich explizit ein funktionsübergreifendes Team eingezeichnet. Es ist wichtig in agilen Projekten, dass alle notwendigen fachlichen und technischen Kompetenzen in einem Team vertreten sind, d.h. es gibt fachliche und technische Experten in einem Team. So kommt etwas zu Stande, das ich in meinem Blog schon als Continuous Feedback beschrieben habe. Ein Projekt hingegen nach Analyse, Entwicklung und Test zu trennen, entspricht nach meiner Auffassung nicht dem agilen Gedanken.

„developercentric“ vs. „managementcenric“: Wenn man sich die agilen Verfahren anschaut, dann sieht man schnell, dass alles auf den Entwickler zugeschnitten ist. Die allermeisten agilen Methoden und Techniken sind Techniken direkt für den Entwickler, oder erfordern seine Beteiligung. Der Entwickler – also der, der es tut – steht im Mittelpunkt. Herkömmliche Vorgehensweisen zielen dagegen eher darauf ab, dass das Projektmanagement kontrollieren und messen kann.

Das sind meines Erachtens wichtige Gegensätze, die „agil“ von „prozessorientiert“ unterscheiden. Weil wir oben den Entwickler als Mittelpunkt des Universums definiert haben, sei an dieser Stelle der Fairness halber auf ein wichtiges Problem agiler Vorgehensweisen hingewiesen: Angelehnt an die X-Y-Theorie von Douglas McGregor (Theorie X: der Mensch ist unwillig, Theorie Y: der Mensch ist engagiert) wird bei agilen Projekten wohl eher die Theorie Y angenommen – „der Mensch ist engagiert“. Denn „self-organizing“ setzt Dinge wie Identifikation mit dem Produkt, Verantwortungsgefühl und Interesse voraus – typische Eigenschaften richtig motivierter Mitarbeiter. Aber sind alle Mitarbeiter immer so richtig motiviert? IT als Job oder als Passion? Dieses Thema möchte ich in einem Artikel dieser Serie noch einmal detaillierter aufgreifen und auch genauer beschreiben, was es mit der X-Y-Theorie auf sich hat.

Und jetzt kommt ein zusammenfassendes „Outro“ in Kurzform:

Ingenieurmäßig = Software-Engineering = Software-Technik = Obermenge aller Vorgehensweisen inkl. „Agile Software-Entwicklung“

Daraus folgt, dass „agil“ auch „ingenieurmäßig“ ist.

Ich habe in diesem Beitrag bewusst ein bisschen polarisiert. Bis zum nächsten Mal!

Niklas Schlimm ist seit über 15 Jahren als Software-Entwickler und Architekt in unterschiedlich großen Projekten tätig. Zurzeit arbeitet er als Gruppenleiter eines Architektur-Teams bei der Provinzial Rheinland Versicherung AG. Seine Schwerpunkte dort liegen im Bereich Agile Software-Entwicklung, Java-EE-Architekturen mit Hostanbindung und Application-Lifecycle-Management.
Geschrieben von
Niklas Schlimm
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.