BTW: English version here/Englische Version hier.
Neue Methoden und Werkzeuge verändern die Zusammenarbeit von Anwendern und Entwicklern. Neue technische Möglichkeiten, veränderte Aufwandsrelationen für bestimmte Aufgaben eines Softwareentwicklungsprojektes schaffen neue Möglichkeiten oder gar Notwendigkeiten, ein Software-Projekt abzuwickeln.
Die Welt der Softwareentwicklung hat sich stark geändert
Solange es aufwendig war (und vielfach noch ist), ein Bildschirm- oder Listen-Layout zu verändern, mussten diese Vorgaben möglichst früh im Projekt festgeschrieben werden. Ist es hingegen auch in späten Projektphasen leicht möglich, 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 Entwicklungswerkzeuge 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 Softwareentwickler 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 benutzerfreundlichen, 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 zuerst die organisatorischen Fragen geklärt werden müssen, bevor die IT-Anwendung Sinn hat. Und es ist genauso wahr, dass in der Praxis regelmäßig versucht wird, über die IT organisatorische Probleme in den Griff zu bekommen. 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 werden. 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 Anforderungen 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 Organisation 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-Unterstützung mit welchem Grad an Komfort lohnt, kann aber wiederum nur der Anwender treffen und verantworten.
Gerade wenn man von einem streng phasenorientierten Vorgehensmodell abweicht, 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 Schnittstellen-, 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 Managements, die Gesamtverantwortung für den Erfolg und damit das Gesamt-Projektmanagement 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 zweiter Ordnung.
Betrachten wir eine IT-Anwendung als ein System von Funktionen und Daten, die zu Applikationen zusammengefasst und auf bestimmten Hardware- und Betriebssystemplattformen 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 durchdachten IT-Architektur, sie erleichtern jedoch entscheidend den Wandel erster Ordnung, nämlich die Systemoptimierung im Rahmen einer gegebenen Architektur.
Gute Architektur kommt nicht von Gelegenheitsarchitekten!
Softwareentwicklung ohne Programmierer? Softwareentwicklung durch die Anwender? 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 individuellen 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-Landschaft (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.
Webmentions
… [Trackback]
[…] Info on that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]
… [Trackback]
[…] Info to that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]
… [Trackback]
[…] Find More here on that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]
… [Trackback]
[…] Read More here to that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]
… [Trackback]
[…] Find More on that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]
… [Trackback]
[…] Here you can find 39781 additional Info on that Topic: it-governance.blog/wir-sind-so-flexibel-bei-uns-muss-sich-niemand-festlegen-oder-doch/ […]