Wir sind agil, bei uns muss sich niemand auf irgendetwas festlegen! Oder doch?

BTW: English version here/Englische Version hier.

Neue Methoden und Werkzeuge verändern die Zusammenarbeit von Anwen­dern und Entwicklern. Neue technische Möglichkeiten, veränderte Aufwands­relationen für bestimmte Aufgaben eines Softwareentwicklungsprojektes schaffen neue Möglichkeiten oder gar Notwendigkeiten, ein Software-Projekt abzu­wickeln.

Die Welt der Softwareentwicklung hat sich stark geändert

Solange es aufwendig war (und vielfach noch ist), ein Bildschirm- oder Li­sten-Layout zu verändern, mussten diese Vorgaben möglichst früh im Projekt fest­geschrieben werden. Ist es hingegen auch in späten Projektphasen leicht mög­lich, sogar neue Felder in die Datenbank einzufügen, muss man sich mit diesen Vorgaben weniger Mühe geben. Der Anwender muss nicht mehr detaillierte Pflichtenhefte erstellen und dann unterschreiben, damit er nur mehr bei Strafe beträchtlicher Mehrkosten Änderungswünsche geltend machen kann. Kommt zwar immer noch vor, aber das ist mehr eine Art Gehorsamkeitsprüfung als eine echte Notwendigkeit.

Geht es aber in diesen Punkten sozusagen etwas lockerer zu, wo noch kann man auf harte Arbeit und Verbindlichkeit in frühen Projektphasen verzichten? Braucht man überhaupt noch ein Architekturkonzept, ein Datenmodell, Use-Cases etc. Arbeiten wir einfach wieder nach dem Motto HIG (Hirn ins Gerät), wie es in den Anfangszeiten der IT üblich war. Damals erfolgte Softwareentwicklung von Entwicklern für Entwickler und niemand war da, der Ansprüche an das Ergebnis stellte, ohne die Technik zu verstehen und zu beherrschen? Das einzige was stört, ist der Anwender, so denken wohl im Stillen viele Entwickler.

Spontan oder strukturiert?

Kann es sich vielleicht der Anwender angesichts der neuen Entwicklungswerk­zeuge und -plattformen überhaupt bequem machen, sich mit Informationen über seine Anforderungen in freier Prosa sowie kritischen Anmerkungen zu den ihm vorgestellten Prototypen begnügen, darauf warten, dass die Soft­wareentwickler früher oder später das erträumte Informationssystem liefern?
Oder gilt umgekehrt für die Softwareentwickler, dass sie nur noch dem Anwender ein Werkzeug in die Hand geben und es ihm erklären müssen, ihn damit einige Zeit arbeiten lassen und zum Schluss die abgelieferten Teile zu einem benutzer­freundlichen, fachlich optimalen und kostengünstigen Informationssystem zusammenfügen?

Natürlich wissen wir alle, dass beide Extreme nicht realisierbar sind und natürlich gibt es niemanden, der ernsthaft ein solches Szenario vertritt. Aber doch ist einiges in Fluss geraten und damit verbunden gibt es Verunsicherung bei allen Beteiligten.

Ich meine, dass auch in agilen Projekten einiges an Pflichten bleibt, diese betreffen alle Beteiligten. Flexibel sein ist nicht gleichbedeutend mit oberflächlich, sprunghaft und unverbindlich.

Die Pflichten der Anwender in agilen Projekten sind erheblich

Die Anwender (gemeint ist damit sowohl das Management als auch die Anwender im engeren Sinne) müssen eine klare Vorstellung davon entwickeln, welche Beiträge ein IT-System zum Erfolg des Unternehmens insgesamt und zur Verbesserung der adressierten Geschäftsprozesse im Besonderen leisten soll. Ein iteratives Vorgehen begünstigt die Entwicklung kreativer Lösungen, da strategische, organisatorische und technische Phantasie besser zusammenwirken können als im Rahmen eines klassischen, streng phasenorientierten Vorgehens nach dem Wasserfall-Modell. Aber es kommt auch hier der Zeitpunkt, wo man sich festlegen muss und das heißt immer auch, auf etwas zu verzichten, zumindest vorläufig.

Es gehört zu den Stehsätzen der IT-Strategie, dass zu­erst die organisatorischen Fragen geklärt werden müssen, bevor die  IT-An­wendung Sinn hat. Und es ist genauso wahr, dass in der Praxis regelmäßig versucht wird, über die IT organisatorische Probleme in den Griff zu bekom­men. Wenn eine Regel so oft ignoriert wird, besteht der Verdacht, dass sie entweder falsch oder zumindest in der Praxis nicht umsetzbar ist; gemäß einem pragmatischen Begriff von Richtigkeit ist sie damit aber auch im zweiten Fall falsch.

Organisation und IT-Systeme können natürlich separat und nacheinander optimiert wer­den. Dass dabei regelmäßig nur ein Suboptimum erreicht wird, steht für mich aber außer Zweifel: Wüsste der Anwender, welche Möglichkeiten ihm die IT bieten könnte, würde er sich vielleicht anders organisieren. Wüsste der Softwareentwickler, welche An­forderungen der Anwender nicht genannt hat, weil er sie für nicht realisierbar hält oder sich nicht vorstellen konnte, würde er manches anders lösen.

Alles ist möglich, nichts ist fix?

Wollte man grundsätzlich beide Teilsysteme gleichzeitig optimieren, würde man schnell die Grenzen der bewältigbaren Komplexität, der Beweglichkeit der Or­ganisation und der Geduld der Anwender überschreiten. Genau hier ist die mit modernen Entwicklungsplattformen gegebene Möglichkeit höchst nützlich, die Phantasie des Anwenders in frühen Phasen mit rasch entwickelbaren Prototypen zu stimulieren. Die letzte Entscheidung, bei welchen Aufgaben sich welche Art von IT-Unter­stützung mit welchem Grad an Komfort lohnt, kann aber wiederum nur der An­wender treffen und verantworten.

Gerade wenn man von einem streng phasenorientierten Vorgehensmodell ab­weicht, besteht die Gefahr, dass die Präzision der Projektplanung reduziert und das Projektmanagement lax wird. Es ist jedoch eine der Paradoxien, die wir aus den Projekten zur partizipativen Organisationsgestaltung gelernt haben, dass nicht nur mit zunehmender Zahl an Beteiligten sondern auch mit zunehmendem Grad an Partizipation das Projektmanagement umso straffer sein muss. Je mehr Gestaltungsspielraum man den Beteiligten einräumt, umso häufiger kommt es zu Veränderungen, die Auswirkungen in anderen Bereichen haben. Das Schnittstel­len-, Kommunikations- und Stakeholdermanagement müssen daher in agilen Projekten mit höchster Professionalität wahrgenommen werden, deutlich mehr als in Projekten nach einem mehr oder minder strengen Wasserfallmodell. Es müssen die Meilensteintermine aufeinander abgestimmt werden und der regelmäßige, proaktive Informationsaustausch gesichert werden.

Schriftliche und von allen Beteiligten verstandene und anerkannte Projektaufträ­ge, eine klar definierte Projektorganisation, insbesondere  Projektleiter mit ausreichenden Entscheidungsbefugnissen und Ressourcen sind einige weitere Elemente, die gutes Projektmanagement immer schon auszeichnen und unter den komplexeren Bedingungen des agilen Vorgehens umso wichtiger sind.

Es ist die nicht delegierbare Pflicht des Anwenders, insbesondere des Manage­ments, die Gesamtverantwortung für den Erfolg und damit das Gesamt-Projekt­management zu übernehmen.

Veränderung ist wichtig und möglich – aber welche Art der Veränderung?

Agile Vorgehensmodelle erlauben es, IT-Systeme im Verlaufe ihrer Entwicklung zu ändern. Watzlawick u.a. unterscheiden zwei Formen der Veränderung: „die eine findet innerhalb eines bestimmten Systems statt, das selbst unverändert bleibt, während das Eintreten der anderen das System selbst verändert“ (S. 29). Sie sprechen von einem Wandel erster Ordnung bzw. einem Wandel zwei­ter Ordnung.

Betrachten wir eine IT-Anwendung als ein System von Funktionen und Daten, die zu Applikationen zusammengefasst und auf bestimmten Hardware- und Be­triebssystemplattformen implementiert werden, so erleichtern agile Vorgehensmodelle den Wandel erster Ordnung. Ist es jedoch erforderlich, den Charakter des Systems insgesamt zu ändern, erleichtern dies agile Vorgehensmodelle nur noch marginal. Agilität erspart uns also nicht die Ausarbeitung einer durchdach­ten IT-Architektur, sie erleichtern jedoch entscheidend den Wandel erster Or­dnung, nämlich die Systemoptimierung im Rahmen einer gegebenen Architektur.

Gute Architektur kommt nicht von Gelegenheitsarchitekten!

Softwareentwicklung ohne Programmierer? Softwareentwicklung durch die An­wender? Mag sein, es kommt aber auch darauf an, wen man als Programmierer und wen man als Anwender bezeichnet. Und es kommt sicher auch darauf an, wie komplex ein Softwaresystem ist. Wenn wir uns darauf einigen, dass jemand der z.B. in Excel Makros schreibt oder vergleichbare Leistungen in anderen Systemen erbringt, kein Programmierer ist, kann man den oben zitierten Verheißungen nicht zustimmen. Wenn wir eine Analogie zum Bauen herstellen, so sehen wir, dass im Zeitalter der Fertighäuser sehr viele Bauherren keinen Architekten mehr brauchen. Allerdings sind die Fertighäuser von Architekten entworfen worden und die mehr oder minder hohe Qualität des Entwurfes erkennt jeder, der ein Fertighaus seinen indi­viduellen Bedürfnissen anpassen will. Wenn wir noch einen Schritt weiter zur Städteplanung gehen, so sehen wir die Grenzen der Eigenplanung deutlich an den städtebaulichen Fleckerlteppichen mancher Gemeinden. Wenn wir also einer „Verhüttelung“ der IT-Land­schaft (also einer Ansammlung von Insellösungen mit komplexen Schnittstellen) entgehen wollen, so kommen wir nicht umhin, die Anwender auch im Zeitalter von Scrum und XP durch Profis zu betreuen und manchmal auch zu führen.

Nicht zu vergessen: Es gibt auch Pflichten der IT in agilen Projekten

Die Pflichten des Anwenders enden also dort, wo es um die Gesamtarchitektur und die optimale technische Gestaltung des IT-Systems geht, sie gelten aber umso mehr, wenn es um die Klärung der strategischen, wirtschaftlichen und organisatorischen Voraussetzungen und Rahmenbedingungen des IT-Einsatzes geht. Aber dort wird der Erfolg des IT-Einsatzes zum Großteil entschieden, egal ob wir agil arbeiten oder nicht.

Das erfolgreiche Zusammenwirken von vielen Stakeholdern funktioniert nicht ohne stabile Strukturen und disziplinierte Zusammenarbeit. Flexibilität erfordert viel Arbeit, nicht nur, wenn es um Yoga geht.