Wir arbeiten doch agil – warum sind wir so langsam?

Twice the work in half the time. Diese Aussage haben viele vor Augen, wenn sie über agile Softwareentwicklung sprechen. Viele sind auch enttäuscht, wenn die Entwicklung im eigenen Unternehmen nicht schneller läuft als früher. In diesem Video gebe ich dir einen Gedankenanstoß, dass du beim Thema „Geschwindigkeit“ vielleicht in die falsche Ecke schaust.

Transskript

Ich habe mich in den letzten Tagen und Wochen mit meinen Trainingsteilnehmern ziemlich intensiv mit der Frage auseinandergesetzt, wie es eigentlich um Agilität in Unternehmen steht. Als Product Owner arbeiten wir vor uns hin. Wir wissen, was wir umsetzen wollen. Wir wissen, warum wir es umsetzen wollen. Und wir setzen es natürlich auch mit unserem Team um. Aber die Frage ist ja: Sind wir als Product Owner mit unserem Entwicklungsteam auf der Insel der Glückseligkeit? Oder sind wir in den Gesamtkontext des Unternehmens eingebunden? Wie wird dort das Thema Agilität bzw. agile Softwareentwicklung eigentlich gesehen?

Eine Frage, die in den Gesprächen immer wieder auftauchte, war: Wir arbeiten doch jetzt agil. Warum sind wir nicht schneller als früher?

Das ist eine gute und berechtigte Frage. Aber um sie zu beantworten, würde ich gerne einen Schritt zurückgehen und überlegen, an welcher Stelle wir Agilität eigentlich einsetzen. Auf 30.000 Fuß Flughöhe geht es eigentlich immer darum, mit einer neuen, großartigen, genialen Idee die eigenen Anwender glücklich machen. Mehr wollen wir eigentlich gar nicht.

Früher, zu der Zeit als Projekte plangetrieben umgesetzt wurden (Wasserfall & Co), sah dieser Prozess „Von Idee bis zufriedener Kunde“ ungefähr wie im Bild unten aus.

1. Eine gute Idee entsteht und wird rudimentär dokumentiert
2. Warten auf Vorgesetzten
3. Überarbeitung der Idee
4. Warten auf Vorgesetzten
5. Detaillierung Idee, Erstellung Business Case, Erstellung Vorstandsvorlage
6. Warten auf Vorstandssitzung
7. Beschluss zur Umsetzung
8. Warten auf Team
9. Umsetzung der Idee (Design, Build, Test)
10. Warten auf Release
11. Go-Live

Das ist der Prozess mit plangetriebener Softwareentwicklung. Vielleicht ahnst du schon, worauf ich hinauswill. Häufig erlebe ich, dass agile Softwareentwicklung (z.B. Scrum), in der IT eingeführt wird. In dem beschriebenen Prozess taucht die IT allerdings nur an zwei Stellen auf (Punkt 9 und 11). Und auch hier: Häufig beginnt man den ersten Schritt tatsächlich in der Entwicklung (Punkt 9). Und ja, ich glaube durchaus, dass wir mit einer agilen Entwicklung schneller sind als mit Design Build Test. Also lass uns den Block „Entwicklung“ verkürzen. Ja, du sparst ein wenig Zeit. Aber wenn du dir den Gesamtprozess ansiehst, dann ist das hier eine Optimierung im niedrigen Prozentbereich.

Die Frage „Warum sind wir denn eigentlich nicht schneller, jetzt, wo wir agil arbeiten“ ist durchaus berechtigt. Allerdings ist es bei der Beantwortung der Frage höchst gefährlich, nur auf das Thema Softwareentwicklung zu schauen. Es hilft ungemein, den Gesamtprozess von Idee bis Anwender zu betrachten und zu prüfen, an welcher Stelle die Zeit verloren geht. Ist es bei der Entwicklung? Ist es beim Release? Oder verliert man die Zeit am Anfang des Prozesses, um überhaupt das GO zu bekommen?
Schnapp dir mal deine Stakeholder, schnapp dir mal deine Kollegen passt gemeinsam das obige Bild an, so dass es für euer Unternehmen zutrifft. Einfach nur als Gedankenanstoß oder als Diskussionsgrundlage. Fangt an zu diskutieren. Ich bin gespannt auf die Resultate, die du mitbringst.

Aber in jedem Fall: Denk bitte immer daran, das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten.