Scrum Think big (eBook)

Großkonzerne und der deutsche Mittelstand führen Projekte in gigantischen Ausmaßen durch. Zehn Millionen Euro sind schnell ausgegeben und Dutzende Personen leisten ihren Beitrag. Aber da gibt es noch einige Besonderheiten: Diese Projekte werden im Rahmen des normalen Tagesgeschäfts durchgeführt, sie stören den üblichen Ablauf. Arbeiten Personen an mehreren Standorten am Projekt mit, ist die Projektsprache Englisch. Und als wäre das allein nicht schwierig genug, sind diese Unternehmen noch dazu in einem gigantischen Beschleunigungsrennen gefangen. „Digitalisierung“ lautet das Stichwort, täglich entstehen neue Technologien. Neue Optionen, neue Geschäftsfelder entwickeln sich über Nacht. Unternehmen, die auf dem internationalen Parkett weiter bestehen wollen, müssen damit umgehen können. Fehlentscheidungen und Selbstzufriedenheit führen schnell zum Desaster.

Organisationen sind völlig überlastet angesichts der Flut an Projekten, die sie bewältigen sollen. Die ursprüngliche Frage hat sich also nicht geändert: Wie gelingen große Projekte, speziell in der Hard- und Softwareentwicklung? Als „großes“ Projekt bezeichnen wir dabei eines, das folgende Bedingungen erfüllt: Es hat ein Budget von mehr als einer Million Euro, dauert mehr als sechs Monate und an der Durchführung sind mehr als sechs Personen beteiligt, die an verschiedenen Orten angesiedelt sein können.

Doch als wären die Umstände nicht schon schwierig genug, muss die Frage noch etwas anders gestellt werden: Wie gelingen solche Projekte in einer ansonsten traditionellen Ablauforganisation? In einer Organisation, die dem Urbild entspricht: mit hierarchischen Organigrammen, siloartigen Abteilungen und einer Matrixstruktur, die den klassischen Ablauf ständig mit viel zu vielen Projekten stört. Die Antwort ist einfach: Diese Organisationen werden scheitern. Punkt.

In diesem Buch zeigen wir daher, wie große Projekte gemanagt werden können. Aber wir beantworten gleichzeitig die Frage, wie Organisationen zu agilen Organisationen umgebaut werden können, denn ohne das geht es nicht. Der Unsinn von „hybriden“ Projekten oder agilem Arbeiten in klassischen Strukturen ist überholt, denn jede neue Technologie bringt eine Flut an neuen Möglichkeiten. Gleichzeitig rast eine Welle von Gesetzesänderungen auf die Unternehmen zu. Kontinuierlich müssen Organisationen ihre Prozesse und damit oft ihre IT-Infrastruktur anpassen. Kaum ist eine Prozessänderung beschlossen, steht sofort die nächste an. Vieles bleibt lange im Ungewissen, denn manchmal wissen nicht einmal die Behörden selbst, wie eine neue Vorschrift aussehen soll. Man weiß, dass sie kommen wird, aber nicht, wann genau und in welcher Form. Werden die entwickelten Lösungen die richtigen sein?

In diesem Spiel kann nur mitmischen, wer seine Managementmethoden den Umständen anpasst. Traditionelles Management muss in diesem Umfeld zwangsläufig scheitern, denn dessen Spielwiese wurde für einen anderen Kontext und andere Zeithorizonte entwickelt. Es hat gute Dienste geleistet, viele Unternehmen haben mit dem 120 Jahre alten Managementparadigma gute Erfahrungen gemacht. Aber immer wieder ist zu beobachten, dass kritische Projekte außerhalb der traditionellen Unternehmensstrukturen durchgeführt werden. Die Labs und Taskforces sind besonderen Bedingungen unterworfen: Dort dürfen die Kolleg:innen alles anders machen und werden nur daran gemessen, ob sie eine Lösung finden. Klassische Unternehmensprozesse werden ignoriert oder so geschickt ausgenutzt, dass sonst Undenkbares plötzlich möglich wird. Doch diese Ausnahmen, die noch in den 1990er-Jahren zum Erfolgsmodell viele Konzerne gehörten, sind heute die Regel. Jedes Projekt ist zu groß, jedes Projekt ist zu labil und gleichzeitig ist das Standardbusiness nicht mehr sicher. Alle Prozesse sind ständig unter Volllast.

Die Softwareentwicklung war der erste Industriezweig, in dem diese Entwicklung zu Beginn der 1990er-Jahre sichtbar wurde: Der traditionelle Weg der Projektdurchführung funktionierte nicht mehr. Also machten sich im Silicon Valley einige Manager:innen auf den Weg, suchten eine Lösung für die beschriebenen Probleme und (er-)fanden die agile Softwareentwicklung. Von den unterschiedlichen Modellen setzte sich weltweit eine Vorgehensweise durch: Scrum. Dieses Managementframework wurde entwickelt, um in einem komplexen Umfeld möglichst schnell etwas liefern zu können, von dem man oft nicht weiß, wie es aussehen soll und erreicht werden kann. Zunächst ging man davon aus, dass man gut ausgebildete Softwarespezialist:innen zusammenbringen müsse, um aus ihnen ein Team mit einer klar definierten Aufgabe zu formen. Das funktionierte sehr gut. Heute arbeiten viele Unternehmen in ihren IT-Abteilungen erfolgreich mit kleinen, sich selbst organisierenden Teams.

Scrum-Projekte wurden bald so erfolgreich, dass immer mehr Hardwareentwicklungsteams auf diese Arbeitsweise aufmerksam wurden. Die Softwareentwickler:innen lieferten ihre Produkte immer schneller ab, nutzten andere Formen des Reportings und wirkten alles in allem zufriedener mit ihrer Arbeit. So hielt Scrum auch Einzug in das traditionelle Projektmanagement für Hardwareprodukte. Und die Verbreitung von Scrum ist noch nicht abgeschlossen: Inzwischen gibt es selbst verwaltungsnahe agile Teams, etwa in Audit-Abteilungen von Banken.

Heute wissen wir: Das war nur der Anfang. Heute können wir das Erfolgsmodell Scrum dekonstruieren und genau benennen, welche Prinzipien dazu führen, dass Organisationen den Veränderungsdruck erfolgreich bewältigen können.

Teambasierte Organisationen

Ein kleines, sich selbst überlassenes Team kann bei einer klar umrissenen Aufgabe alle paar Wochen etwas vorzeigen – das ist auch mit klassischem Projektmanagement erfolgreich möglich. Scrum-Projektteams sahen sich aber schnell mit der Frage konfrontiert, wie sie denn große Projekte stemmen könnten, denn genau das war und ist die Herausforderung.

Auch unsere eigene Sicht der Dinge war lange Zeit einfach: Kleine Scrum-Teams aus gut ausgebildeten Mitarbeiter:innen sind um einiges effektiver als große behäbige Projektteams. Also, weshalb sollte es den Bedarf geben, Projekte möglichst groß aufzuziehen? Die Antwort lag doch auf der Hand: Man musste einfach die Projektteams verkleinern. Wir hatten selbst gesehen, dass ein zehnköpfiges Team in kurzer Zeit in der Softwareentwicklung Projekte ablieferte, an denen 150 Personen gescheitert waren. Alles sprach also dafür, dass große Projekte gar nicht gebraucht wurden.

Dass man sich mit dem Thema noch einmal ganz anders auseinandersetzen musste, wurde klar, als die Anfragen zu Scrum in der Hardwareentwicklung immer häufiger wurden. Plötzlich waren völlig andere Probleme zu lösen: In diesem Bereich arbeiten nicht zwangsläufig Menschen zusammen, die ähnlich denken. Manche „verstehen“ sich aufgrund ihrer Ausbildung überhaupt nicht. Chemiker:innen denken anders als Biolog:innen, die wiederum ganz anders an Probleme herangehen als Elektroingenieur:innen, die natürlich alles ganz anders machen als die Maschinenbauer:innen. Dazu kommt, dass diese unterschiedlichen Disziplinen oft gar nicht an einem Standort angesiedelt sind. Die wunderbare Idee, alle Kolleg:innen in einem Raum zu versammeln, ist oft gar nicht umsetzbar, denn die Spezialist:innen sind in der ganzen Welt verteilt und mitunter gehören sie nicht einmal zum eigenen Unternehmen. Aber das Internet lässt die Welt auch in diesem Punkt schrumpfen: Die besten Köpfe lassen sich leichter finden als je zuvor und sind oft kurzfristig buchbar. Ein befreundetes kleines Zwei-Mann-Unternehmen mit einem stark eingegrenzten Spezialgebiet arbeitet für einen kalifornischen Giganten. Die zwei nehmen Aufträge an, liefern die Ergebnisse ab und es scheint hervorragend zu funktionieren. Längst haben „New Brokers of Work“ daraus ein Geschäft gemacht: Sie vermitteln Aufgaben an Spezialist:innen, finden diese in weltweiten Netzwerken oder bauen selbst diese Netzwerke auf. Das ist auch Teil des sich abzeichnenden Trends zur Hyperspezialisierung: Arbeiten in Projekten werden kleinteilig auf diejenigen verteilt, die sich am besten für die Aufgabe eignen (vgl. Malone et al. 2011).

Wer genau hinsieht, macht eine erstaunliche Beobachtung: Wieder ist es die Softwareentwicklung, in der dieser Trend seinen Ausgang nimmt. Weltweit verteilte Softwareentwickler:innen arbeiten gemeinsam an Projekten, obwohl sie sich oft noch nie persönlich gesehen haben und manchmal nicht einmal die Namen der anderen kennen. Unternehmen wie Automattic (Wordpress) oder 37signals (Basecamp) wurden bewusst so konzipiert. Sie wollen mit Menschen auf der ganzen Welt zusammenarbeiten, die das benötigte Wissen haben. Microsoft baut viele seiner neuen Produkte konsequent in die Cloud, damit Menschen in jedem Winkel der Erde daran arbeiten können, auch Adobe setzt auf das gleiche Prinzip.

Es setzt sich also ein Prinzip der Zusammenarbeit durch: Teams arbeiten in Netzwerken zusammen. Was das Management von Organisationen dabei oftmals...