Endlich agil!

Wir leben in einer Zeit, in der es „nor­mal ist, dass vie­les anders ist und immer schnel­ler anders wird“, wie der Zeit­for­scher Karl-Heinz Geiß­ler tref­fend fest­stell­te. Für die­ses Phä­no­men der Beschleu­ni­gung, der Kom­ple­xi­tät und der damit ein­her­ge­hen­den Unsi­cher­heit hat sich in letz­ter Zeit das Akro­nym VUCA (kurz für vola­ti­li­ty, uncer­tain­ty, com­ple­xi­ty und ambi­gui­ty) eta­bliert. An die Stel­le von Sta­bi­li­tät und Effi­zi­enz tre­ten Agi­li­tät und Effek­ti­vi­tät. Ver­än­de­rung wird die Regel. Pro­jek­te, als Kon­strukt zur Über­füh­rung eines sta­bi­len Zustands in den nächs­ten, haben ausgedient.

Intel­li­gence is the abili­ty to adapt to change.
Ste­phen Hawking

IT-Sys­te­me wer­den in den meis­ten Orga­ni­sa­tio­nen behan­delt wie Maschi­nen: Sie wer­den beschafft oder gebaut und dann betrie­ben und gewar­tet. Sowohl die initia­le Bereit­stel­lung als auch jede grö­ße­re Ver­än­de­rung wird als Pro­jekt durch­ge­führt. Die­se Umbau­maß­nah­men stö­ren den sta­bi­len Regel­be­trieb und müs­sen mini­miert wer­den. Einer­seits. Ande­rer­seits sichern die­se Umbau­ten die Wett­be­werbs­fä­hig­keit der Orga­ni­sa­ti­on, weil sie Geschäfts­pro­zes­se opti­mie­ren und im Zuge der Digi­ta­li­sie­rung immer mehr auch völ­lig neue Geschäfts­mo­del­le ermög­li­chen.

Je mehr „VUCA“ also das Umfeld einer Orga­ni­sa­ti­on ist, des­to wich­ti­ger wer­den time-to-mar­ket und cost-of-delay neben einem sta­bi­len Betrieb. Des­to weni­ger passt aber auch die­se eta­blier­te Sicht auf IT-Syte­me und Sys­tem­land­schaf­ten. Die zugrun­de­lie­gen­de Annah­me, dass IT-Sys­te­me wie Maschi­nen beschafft, betrie­ben und gewar­tet wer­den müs­sen, ist zwar nicht falsch, igno­riert aber die prin­zi­pi­ell viel höhe­re Fle­xi­bi­li­tät von Soft­ware. Solan­ge das alle so machen und solan­ge die Märk­te trä­ge und weit sind ist das auch kein Pro­blem. Es wird aber schnell zum Pro­blem, wenn neue agi­le­re Wett­be­wer­ber in die inzwi­schen gesät­tig­ten Märk­te ein­tre­ten, wie das im Moment bei­spiels­wei­se im Auto­markt der Fall ist. Und dann nutzt es auch wenig, wie in dem Comic von Geek&Poke (ver­öf­fent­licht unter einer Crea­ti­ve Com­mons CC BY 3.0 Lizenz) oben, einen Teil der Pro­jek­te agil zu machen.

Wir arbei­ten in Struk­tu­ren von Ges­tern mit Metho­den von heu­te an Stra­te­gien für Mor­gen vor­wie­gend mit Men­schen, die die Struk­tu­ren von ges­tern geschaf­fen haben und das Über­mor­gen in der Unter­neh­mung nicht mehr erle­ben werden.
Knut Blei­cher

Der eigent­li­che Wan­del in der agi­len Trans­for­ma­ti­on ist es also, nicht Pro­jek­te jetzt nach ande­rer Metho­de durch­zu­füh­ren, son­dern die Ver­än­de­rung als gewünsch­ten Nor­mal­zu­stand zu begrei­fen, frei­lich ohne Sta­bi­li­tät zu ver­lie­ren. Nicht ohne Grund ist Scrum eine Metho­de zur Pro­dukt­ent­wick­lung und nicht ohne Grund heißt eine der zen­tra­len Rol­len im Scrum Pro­duct-Owner und eben nicht Pro­ject-Owner. IT-Pro­jek­te sind Aus­lauf­mo­del­le. Sie wer­den abge­löst durch Pro­duk­te mit zuge­hö­ri­gen fes­ten Teams, die ihren Aus­schnitt der IT-Sys­tem­land­schaft per­ma­nent an die Anfor­de­run­gen der Märk­te und der Orga­ni­sa­ti­on anpas­sen und gleich­zei­tig sta­bil betreiben.