In zwei Tagen kann man sich zum SCRUM Master ausbilden und zertifizieren lassen – online, wohl bemerkt. Das verführt offenbar etliche Führungskräfte zu der irrigen Annahme, agile IT sei einfach und schnell realisierbar. Was die Methodik angeht, mag das stimmen. Doch die Entscheidung für agile IT ist eine Entscheidung für einen kulturellen Wandel, der von den vielen Führungskräften unterschätzt wird. Darum geht es in diesem Artikel.
Finden Sie agile IT und agiles Projektmanagement spannend und interessant? Dann geht es Ihnen wie mir! Ich sehe darin eine großartige Chance, flexibel und schnell Anforderungen umzusetzen, die an die IT Organisation gestellt werden. Aber nicht alles, was sich agil nennt, ist es auch – darum schauen Sie mir mir gemeinsam etwas genauer hin.
Echte agile IT - oder nur agil angestrichen?
Kommen wir gleich zur Sache. Wie können Sie eine agile IT von einer IT Organisation unterscheiden, die lediglich „agil angestrichen“ ist? Nach meiner Erfahrung gibt es hierfür zwei wesentliche Bedingungen, die ein Auftraggeber eines Projekts erfüllen muss.
Die erste ist: Mein einziger Ansprechpartner ist der Product Owner. Das bedeutet volles Vertrauen in das SCRUM Team, keine Berichts- und Kontrollbefugnisse und die regelmäßige Teilnahme an Planning- und Review Meetings. Wenn dies die gelebte oder angestrebte Projektkultur in Ihrer IT Organisation ist: Fein. Ansonsten können Sie davon ausgehen, dass das Projekt nur agil angestrichen ist.
Und die zweite Bedingung? Hier geht es um Geld – natürlich. Es ist essentiell, dass dem Auftraggeber eines bewusst ist: Es gibt keine Garantie dafür, für einen bestimmten eingesetzten Geldbetrag eine vorab definierte Leistung zu einem vorab definierten Termin zu bekommen. Wenn also beispielsweise die Rede davon ist, für Backlog Items Kosten zu kalkulieren und Termine festzulegen, können Sie getrost davon ausgehen, dass es der Auftraggeber ebenfalls nicht ernst meint mit agiler IT. Oder es schlichtweg nicht verstanden hat.
Agile IT heißt Nähe zum Business
Auch für agile geführte Projekte gilt, dass die Qualifizierung von Anforderungen maßgeblich darüber entscheidet, wie aufwändig die Realisierung ist und wie viele Iterationen gebraucht werden, um eine Anforderung umzusetzen. Je näher das Scrum Team an die Kompetenzteams in den Geschäftsbereichen rückt, desto besser. Meine persönliche Erfahrung ist, dass der direkte Austausch besonders wirksam ist. Und es ist nur eine minimale Methodenkompetenz notwendig.
Schlüsselwörter in diesem Zusammenhang sind Epics und User Stories. Dabei beschreibt ein Epic eine Geschäftsfähigkeit – also eine Leistung, die das Kompetenzteam aus dem Geschäftsbereich intern oder extern erbringt. Ein Epic wird in User Stories zerlegt. Diese beschreiben dann jeweils in sich abgeschlossene Einheiten, die vom Srum Team innerhalb eines Sprints von maximal 4 Wochen realisiert werden können. Ein Beispiel: Für ein Handelsunternehmen könnte ein Epic die Abwicklung von Bestellungen sein. Und die User Stories beschreiben dann die Unterstützung für die verschiedenen Kanäle, über die Bestellungen eingehen.
Der Vorteil: Am Ende eines Sprints kann dem Auftraggeber eine fertig entwickelte Funktionalität vorgestellt werden. Dadurch wird das Fortschreiten der Entwicklung für den Auftraggeber erlebbar. Und sollte es Missverständnisse in den Anforderungen gegeben haben, so werden sie im Sprint Review deutlich, so dass schnell nachjustiert werden kann.
Klingt gut? Ist es auch - doch wie erreichen Sie das?
Das wichtigste zuerst: Der kulturelle Wandel für eine agile IT muss vom IT Management gewollt sein und vollständig unterstützt werden. Das bedeutet konkret, dass das agile Manifest auf der Ebene der Geschäftsführung verstanden ist. In der Konsequenz müssen ggf. Kompetenzen neu verteilt werden.
Zweitens ist es erforderlich, dass die Finanzierung von Scrum Teams vollständig von der realisierten agilen Projekten entkoppelt wird. Konkret: Die Mitarbeiter mit notwendigen Skills müssen für einen fixen Zeitraum finanziert oder eingekauft werden. Und das hängt einzig und allein von den gewählten IT Architekturen und Standards des Unternehmens ab. In welchen agil geführten Projekten diese Mitarbeiter dann zum Einsatz kommen, ist von der Finanzierungsentscheidung vollkommen unabhängig.
Und last – but not least: Agile IT und agil geführte Projekte macht nur dann wirklich Sinn, wenn sichergestellt werden kann, dass fertige Entwicklungen auch schnell produktiv gesetzt werden können. Dies erfordert zum einen schlanke Prozesse und effizient organisierte Abnahmen, zum anderen automatisierte Test- und Build Prozesse. Das Stichwort in diesem Zusammenhang ist DevOps – das Thema ist einen eigenen Artikel wert.
Gedanken zum Schluß
Gerade in mittelständischen Unternehmen sind Flexibilität und Schnelligkeit ein entscheidender Wettbewerbsvorteil. Meine persönliche Meinung ist: Agile IT ist im KMU Segment Pflicht. Regulatorische Einschränkungen mag es geben – doch das steht einer agilen IT nicht im Weg. Es gilt auch hier: Wer will, sucht Wege – wer nicht will, sucht Gründe.
Gerne analysiere ich mit Ihnen gemeinsam die vorhandene Strategie. Wir finden heraus, was getan werden muss, um eine vollständig agile IT zu realisieren. Mit maßgeschneidertem Coaching für Führungskräfte und IT Teams helfe ich Ihnen bei der Umsetzung. Ich freue mich darauf, Ihr Unternehmen dabei unterstützen zu dürfen!
