Reagieren auf Veränderung mehr als Befolgen eines Plans

Wie schon im 10-Minuten-Artikel zum dritten Wertepaar aus dem agilen Manifest „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“ erwähnt, ist es aus verschiedensten Gründen sehr wichtig auf Änderungen reagieren zu können. Ich selbst habe mal bei einem Softwareprojekt mitgearbeitet, welches ursprünglich über einen Zeitraum von 5 Jahren geplant war. Aufgrund des großen Erfolgs war nach ein paar Jahren schon klar, dass die Projektlaufzeit auch noch verlängert wird. In diesem Zeitraum wird sich der Markt des Kunden, der dieses Projekt in Auftrag gegeben hat ändern. Das Projektteam hätte zu Beginn des Projekts nicht sinnvoll planen können, was genau gemacht werden muss und wie das fertige Endprodukt aussieht, weil sich über den Zeitverlauf einfach Änderungen und Wünsche ergeben werden. Wenn die Benutzer das erste mal die Software nutzen, wird sich auch erst noch herausstellen, was wirklich so funktioniert wie geplant und wo vielleicht noch optimiert werden kann.

Ein Projektplan hat grundsätzlich die Vorannahme, dass ich den gesamten Projektverlauf prognostizieren kann. Das ist in dieser komplexen Welt einfach nicht möglich. Das Wort „komplex“ ist dabei eine bewusste Abgrenzung gegenüber kompliziert im Sinne des Cynefin-Frameworks, über das ich hier im Blog auch unbedingt noch schreiben möchte. Darüber hinaus gibt es zahlreiche Untersuchungen die belegen, dass Schätzungen in Projekten einfach unglaublich schlecht sind. Mehr dazu findest du unter dem Stichwort „Cone of Uncertainty“, über den ich auch noch schreiben will.

Wenn ich also Pläne nutze, muss ich bereit sein diese fortlaufend anzupassen. Alternativ hilft es nur noch sehr kurze Zeitabschnitte zu beplanen. Dann kann ich leichter umplanen, wenn es Änderungen gibt oder einfach den Plan ganz verwerfen ohne viel verschwendet zu haben. Das ist sinngemäß z.B. der Ansatz der bei Scrum genutzt wird. Natürlich können auch Pläne im klassischen Sinne einfach über Board geworfen werden, wie es sinngemäß bei Kanban gemacht wird.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Das dritte Wertepaar aus dem agilen Manifest fokussiert auf den Kunden. Durch die vielen Probleme mit klassischen Wasserfallansätzen und dem Versuch die Zukunft in Projekten vorherzusehen (vertragliche Festlegung von Zeit, Kosten und Umfang), entstanden immer mehr Konflikte zwischen der IT und ihren Kunden. Das wurde über einen langen Zeitraum durch immer härtere und detaillierte Verträge geregelt, mit denen beide Seiten versucht haben sich abzusichern. Im Kern kann das natürlich gar nicht funktionieren, da in komplexen Umgebungen einfach nicht vorherzusagen ist, wie sich alles entwickeln wird. Der agile Ansatz ist deshalb ganz klar: Bei Problemen wird miteinander geredet und die beste Lösung für alle Beteiligten gefunden.

In der Theorie ist das natürlich leicht gesagt, in der Praxis braucht es da viel Vertrauen. Schließlich geht es auch um eine Menge Geld. Nur in der Praxis habe ich als Kunde nichts davon, wenn ich mir ein exaktes Endprodukt vertraglich absichern lasse zu einem festen Preis, wenn sich z.B. auf dem Weg dahin herausstellt, dass dies so nicht zu realisieren ist oder der Markt sich während des Projektverlaufs so stark ändert, dass das Produkt nicht mehr für die aktuelle Marktsituation passt. Andersrum bringt es mir als IT nichts, mir das Budget (und damit den potenziellen Gewinn) vertraglich zusichern zu lassen und den Umfang zu fixieren, um z.B. der schleichenden Vergrößerung von Projekten entgegenzuwirken, wenn danach zwar der Gewinn da ist, nur das Produkt nicht oder nicht richtig genutzt werden kann und der Kunde entsprechend unzufrieden ist. Deshalb gilt grundsätzlich: Erzeuge Win-Win Situationen. Agil sein bedeutet, die Komplexität anzunehmen und damit umzugehen. Damit wird ein ganz wesentlicher Marktvorteil geschaffen, da die Konkurrenten noch mit vertraglichen Streitereien beschäftigt sind, während in der agilen Welt einfach das Beste aus der aktuellen Situation gemacht wird.

Es muss möglich sein, fortlaufend während eines Projekts Änderungen an den geplanten und bereits umgesetzten Anforderungen zu machen, um schnell am Markt reagieren zu können. Dazu ist auch eine direkte Einbindung des Kunden (und insbesondere den echten Nutzern) wichtig, um direkt Feedback einzuholen. Lasten- und Pflichtenheft sind da völlig untauglich, weil sie nie die Realität wirklich widerspiegeln. Deshalb müssen IT und Kunden sich als Partner betrachten und gemeinschaftlich sich fortlaufend darauf konzentrieren stets den bestmöglichen Nutzen für alle Beteiligten zu schaffen.

Funktionierende Software mehr als umfassende Dokumentation

Das klassische Projektmanagement, bzw. das wasserfallartige Projektvorgehen ist Dokumentgetrieben. Es werden Lasten- und Pflichtenhefte erstellt und über den Fortschritt wird in Form von Statusberichten in diversen Gremien berichtet. Im agilen Kontext wertschätzen wir dagegen den echten Fortschritt der Software. Dieser wird präsentiert und es wird nichts gezeigt, was nicht wirklich fertig ist. Keine Mockups, Dokumente die Konzepte beschreiben, isoliert fertiggestellte (nicht integrierte) Module, …

Die agile Entwicklung fokussiert grundlegend auf den Nutzen von Software und dessen Weiterentwicklung. Der Fortschritt der Produktentwicklung wird deshalb in „Nutzen der funktionierenden Software“ gemessen. Da es fortlaufend funktionierende Software gibt, kann zu dieser auch kontinuierlich und schnell Feedback eingeholt werden, was wiederum die Priorisierung und damit Fokussierung auf die wichtigsten Funktionen unterstützt.

Meine Erfahrung ist allerdings nicht, dass in agilen Projekten deshalb nicht dokumentiert wird. Im Gegenteil. Da in agilen Projekten kontinuierlich funktionierende Software produziert und ausgeliefert wird, wird auch die Dokumentation kontinuierlich gepflegt, da diese ja auch für die Entwicklung, den Betrieb und die Benutzer benötigt wird. Wo ich bei klassischen Projekten eher erlebe, dass die Dokumentation vernachlässigt wird und hinten runterfällt. Selbstverständlich müssen auch die Anforderungen an die Dokumentation im Zusammenhang mit der Compliance erfüllt werden. Allen Beteiligten fällt es leichter, die Dokumentation kontinuierlich aktuell zu halten und als Unterstützung der gemeinsamen Entwicklung zu nutzen, als das lästige übel, was zum Schluss noch erstellt werden muss – oder angepasst werden muss, weil das Endprodukt nichts mehr mit der vorher geplanten Dokumentation zu tun hat.

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

An meinem ersten Arbeitstag bei einem meiner Arbeitgeber, hatte ich Probleme mit der mir zur Verfügung gestellten Tastatur. Ich habe sofort vorgeschlagen, dass ich meine eigene Tastatur mitbringe. Leider wurde mir mitgeteilt, dass dies nicht möglich sei – aus Sicherheits- und was auch immer für komischen Gründen. Es sei auch nicht möglich mir eine neue oder andere Tastatur bereitzustellen, weil ich ja bereits eine habe und überhaupt sei man ja so stolz darauf, dass es nur einen Tastaturtyp gibt. Alles in der IT ist schön standardisiert. Dieser Problemfall war im Prozess einfach nicht vorgesehen und es hat viel Mühe gekostet jemand zu finden, der mir in dem Fall helfen konnte. Du kannst dir vorstellen, wie begeistert ich war, was für Probleme ich wegen einer Tastatur hatte.

Das erste Wertepaar im Manifest für agile Softwareentwicklung ist „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“. Hier kann man gut sehen, dass das agile Manifest auch als Gegenbewegung zu den Effizienz- und Optimierungsversuchen im Bereich der IT in den 90ern entstanden ist. Damit eben so Fälle wie der oben geschilderte gar nicht erst entstehen. Der Kunde, Benutzer und andere beteiligte Personen sollten immer wichtiger sein, als irgendwelche Tools. Die Prozesse sollen eine Unterstützung sein, nicht etwas, um das man herumarbeiten muss. Bitte nicht falsch verstehen – das ist kein Plädoyer für das Entfallen von Prozessen und jeder macht was er will. Stattdessen brauchen wir Prozesse für die Standardfälle und Prozesse zur Unterstützung aller Beteiligten mit gleichzeitiger Möglichkeit, bewusst aus den Prozessen ausbrechen zu können, wenn dies notwendig ist.

In der heutigen Zeit ist das natürlich nicht so einfach, schließlich müssen auch Dinge wie Compliance berücksichtigt werden. Dementsprechend wichtig wird die Dokumentation der Prozesse, so dass jeder nachvollziehen kann, welchen Zweck der Prozess erfüllt und was alles berücksichtigt werden muss, so dass auch in einem Sonderfall alle Rahmenbedingungen überblickt werden können. Die vorhandenen Tools und Prozesse können dann als Angebot genutzt werden, so dass die Beteiligten bestmöglich unterstützt werden. Wenn das jedoch nicht auf den Anwendungsfall passt, sind alle Informationen parat, um eine bessere Lösung zu finden. Das fördert die kontinuierliche Verbesserung, bietet ein passendes Umfeld für Innovation und spricht die intrinsische Motivation der Mitarbeiter an.

Was ist Agile?

Der Begriff Agile kommt vom Manifest für agile Softwareentwicklung aus dem Jahr 2001 und wurde seitdem in den verschiedensten Kontexten verwendet und ausgedehnt. Er wird weit über die Softwareentwicklung hinaus verwendet. Dazu werden die im Manifest beschriebenen Werte allgemein auf die Produktentwicklung übertragen.

Im Kern ist Agile ein normatives Wertesystem, da es 4 Wertepaare und 12 Prinzipien beschriebt. Man kann Agile also nicht machen, sondern es hat einen Bezug zur Kultur und zum Verhalten. Es ist eine im Vergleich zur Arbeitsweise der 90er Jahre veränderte Betrachtungsweise von Arbeit, Projekten und Produkten. Hier gibt es auch einen direkten Zusammenhang zur Betrachtung der IT als Ressource – wie Strom.

Als sich die Projekte immer mehr nach den agilen Werten ausgerichtet haben, wurde immer deutlicher, dass diese neue Art zu Arbeiten auch Auswirkungen auf die ganze Organisation hat. Nicht nur die Projektarbeit ändert sich. Dementsprechend wird heute viel über agile Transformation gesprochen. Die ganze Organisation soll agil werden – was auch immer das dann heißt.

Für mich ist dieser Teil besonders spannend, da es dann ja auch um Führung geht. Wie wird eine Organisation geführt, in der Projekte agil sind? Wie wird eine Organisation an sich agil? Braucht es überhaupt noch die Führungskräfte im klassischen Sinne oder ändert sich das alles? – Im Manifest ist die Rede von Servant Leadership, also der dienenden Führung. Ist das die Zukunft von Führung?

Das sind viele interessante Fragen über die ich in nächster Zeit schreiben werde. Bleib dran!

Ist IT wie Strom?

In den 50er Jahren führte die Erfindung des Transistors zur Entwicklung der ersten Großrechner. Diese waren sehr teuer und auf Hardwareebene anfällig. Deshalb stand der Betrieb im Vordergrund. Der Einsatz lohnte sich für Unternehmen, weil die Rechner schneller rechneten als Menschen und keine Rechenfehler gemacht haben.

In den 60ern gab es dann eine breite Verfügbarkeit von Großrechnern als Standardprodukt. Die Software wurde komplizierter und so steigen die Entwicklungskosten und erste Ansätze von Projektmanagement entstehen. Weiterhin ist die Nutzung von Rechnern teuer und gleichzeitig ein enormer Wettbewerbsvorteil, weshalb sich Investitionen hier lohnen.

In den 70ern und 80ern kam dann noch der PC dazu, so dass die Effektivität der Mitarbeiter direkt gesteigert werden konnte. Trotz der zusätzlichen Kosten zum Großrechner und all den neuen Problemen mit PCs, waren Investitionen deshalb lohnenswert.

In den 90ern dann waren IT-Systeme in den Unternehmen allgegenwärtig, so dass allein das Vorhandensein von IT kein Wettbewerbsvorteil mehr war. Die IT wird deshalb als Ressource betrachtet, die auch Effizient eingesetzt werden muss – wie Strom. Jetzt bekommen IT-Service-Management, Projektmanagement und Controlling eine äußerst wichtige Rolle und prägen das IT-Management nachhaltig.

Jetzt sehen wir jedoch die Probleme von der Betrachtung der IT als Ressource. Immer mehr Unternehmen erkennen, dass die IT Unternehmen die Zukunft sind. Alles wird getrieben durch die Digitalisierung und wer nicht selbst schnell genug zum IT Unternehmen wird, der findet sich plötzlich einer ungeahnten Konkurrenz ausgesetzt.

IT ist also nicht wie Strom. IT ist ein treibender Faktor und bildet mindestens das Rückgrat eines jeden Unternehmens. Langfristig wird nur überleben, wer das versteht und die Chancen ergreift, statt an der Ressource IT zu sparen.

Cynefin Lego Game – LeanIng Hochschulgruppe

Letztes Jahr habe ich die LeanIng Hochschulgruppe an der TU Dortmund kennengelernt. Das ist eine studentische Initiative die das Thema Lean Management an der Universität etabliert und über Kontakte in die Wirtschaft die Brücke zwischen Theorie und Praxis bildet.

Auch die Gruppe guckt natürlich über den Tellerrand hinaus. Nachdem sie sich letztes Jahr mit Scrum beschäftigt haben, habe ich für die Studenten einen Vortrag über das Agile Manifest und dessen Entwicklung gehalten.

Dieses Semester wurde ich gefragt, ob ich kurzfristig einen weiteren Vortrag dieser Art für die Studenten machen kann. Da kam mir die Idee das Cynefin Framework mit dem Lego Spiel von agile42 vorzustellen.

Interessant ist, dass die meisten Mitglieder von LeanIng im produzierenden Gewerbe unterwegs sind, wo Prozessketten mit Lean Management und Kanban optimiert werden. Das wird häufig in Complicated einsortiert und hat schnell mal Ausreißer nach Complex. Mit dem Cynefin Framework können sie das besser zuordnen und zu den passenden Tools (z.B. Experimente statt Analyse) greifen.

Mit Hilfe des Cynefin Spiels konnten die Teilnehmer über die Theorie hinaus auch ein Gefühl für die einzelnen Domänen bekommen. Es passt auch sehr gut zur Hochschulgruppe, weil deren Fortbildungen zum Thema Lean auch auf Serious Gaming aufbauen. Naja und generell ist spielen natürlich eh gut zum lernen 😉.

Den Teilnehmern habe ich versprochen den Foliensatz zu veröffentlichen. Guckt euch ruhig auch die Originalquelle an. Hier der Foliensatz zum Cynefin Lego Game.

Willkommen

Diese Webseite befindet sich noch im Aufbau – eigentlich ist es eher ein Minimum Viable Product (MVP), das jetzt weiter ausgebaut wird. Oder eben eher MVH – Minimum Viable Homepage.

Für Informationen zur Vorlesung IT-Management, steht der Bereich „Dozent“ schon bereit.