So gelingt der Umbau
Agile IT-Organisation – darauf kommt es an
Die Treffen der Innovation-Boards sind an die jeweilige Sprintdauer anzupassen beziehungsweise es muss sichergestellt werden, dass immer ausreichend Themen für die Sprints aller Teams vorhanden sind. Sofern dies erfolgt ist, sind sämtliche Requirements im Backlog des Teams wiederzufinden. Im Rahmen der Sprint-Planung wird dann priorisiert und die Aufwände werden beispielsweise mithilfe des Planungspokers geschätzt.
Es sei noch erwähnt, dass im Kontext der agilen Zusammenarbeit verschiedene Ansätze der Aufwandsschätzung zur Verfügung stehen. Je erfahrener die Teams sind, desto besser werden die Ergebnisse ihrer Schätzungen. Im Anschluss an die Aufwandsschätzung erfolgt die Entwicklung der Services, bis diese fertig und releasefähig sind. Damit die agilen Teams nicht blockiert werden, sollten so viele Prozesse und Workflows etc. wie möglich automatisiert werden.
Das betrifft auch die Bereitstellung von Entwicklungsumgebung, Testsystemen und Testdaten. So kommt es in der Software-Entwicklung nicht zu Verzögerungen und der Service gelangt schnell in den agilen Release-Management-Prozess. Dessen Laufzeiten betragen für den Release-Typen 'Minor' ein bis zwei Tage, für 'Major' ein bis vier Tage, für 'Hotfix' sechs bis 24 Stunden und für 'Emergency' ein bis sechs Stunden. Eine genaue Definition aller Change-Aktivitäten muss erfolgen, kann an dieser Stelle allerdings nicht explizit beschrieben werden. Nach Release-Freigabe kann der Service in der Produktion deployed werden. Im Anschluss befindet sich das digitale Produkt in der Verantwortung des Betriebs und wurde dem Kunden bestenfalls bereits automatisiert bereitgestellt.
Wann eine IT-Organisation agil ist
Auf Basis der Ausführungen in diesem Artikel sollten folgende Kriterien erfüllt sein, damit eine Organisation als agil betrachtet werden kann:
Es existiert ein TOM und eine agile Governance, die organisationsweit gültig ist und regelmäßig überprüft und gegebenenfalls angepasst wird.
Alle Mitarbeiter verfügen über ausreichende agile Kompetenzen und sind für die Arbeitsweise mitverantwortlich.
Alle sind gemeinsam für die definierten Ziele verantwortlich, das heißt für alle Aufgaben und Ergebnisse sämtlicher Iterationen.
Die Mitarbeiter dürfen Risiken eingehen und im Team schnelle Entscheidungen herbeiführen.
Sie sind dafür verantwortlich, dass Anforderungen von Kunden erfasst, verstanden und berücksichtigt werden.
Experimente sind erwünscht, mögliches Scheitern wird akzeptiert und in Kauf genommen.
Alle Mitarbeiter dürfen Fehler machen, doch sie sind dafür verantwortlich, daraus zu lernen.
Transparenz und demokratische Entscheidungen im Team werden eingefordert und gefördert.
Die Zusammenarbeit im Team wird unterstützt, die Kompetenzen diesbezüglich werden kontinuierlich weiterentwickelt.
Es wird zu jeder Zeit offen und ehrlich über Problemstellungen diskutiert.
Ergänzend dazu ist es ein guter Ansatz, ITSM-Prozesse und Wertströme mittels TOM zu überprüfen und zu bewerten, was die Agilität bremst. Nachfolgend die vereinfachte Darstellung eines TOM und ein Beispiel, wie es zur Prüfung der Agilität eingesetzt werden kann.