Ein Leben auch außerhalb der IT

Softwareentwicklung und Scrum passen zusammen. Das Frontend nicht ohne Backend entwickeln. Und nicht erst am Ende alles testen – das klingt einleuchtend. Scrum wird dabei aber oft als exklusive Methode für die IT wahrgenommen. Zeit den Irrtum aufzuklären.

Scrum ist längst nicht mehr nur Softwareentwicklern ein Begriff. In der Praxis scheitern allerdings viele Versuche, die Methode zu implementieren und der Begriff „Scrum“ ist schnell verbrannt. Oftmals beruhen die Vorbehalte gegen Scrum auf falschen Erwartungen, die dann zwangsläufig enttäuscht werden. Grund genug, sich die verschiedenen Irrtümer einmal anzuschauen.

„Drüben in der IT-Abteilung arbeiten sie agil. Wir können ihnen aber ganz normal unseren Auftrag geben.“ Solchen Aussagen begegne ich in Unternehmen häufiger. Die IT-Abteilung arbeitet mit agilen Methoden, die Mentalität in der Fachabteilung hat sich oftmals nicht geändert – es werden Aufträge erteilt, niemand spricht von Zusammenarbeit. Scrum wird ausschließlich als Arbeitsweise für die IT wahrgenommen, mit Modewörtern wie „Product Backlog“ oder „Product Owner“. Meist wissen die betreffenden Personen aber weder genau was „agil“ bedeutet, noch was Scrum eigentlich ist und wie die Begriffe im Verhältnis stehen. Und wie sie selber wirklich davon profitieren könnten.

Scrum und agile Denkweise sind nicht nur etwas für „die da drüben in der IT“, sondern für alle Unternehmensbereiche

Agil ist nicht gleich Scrum

Agilität ist eine geistige Haltung, die Unternehmen zum einen befähigt, flexibel auf Kundenbedürfnisse und Veränderungen zu reagieren und zum anderen die Arbeitsabläufe so umzugestalten, dass kreative Prozesse und Innovationen gefördert werden. Im sogenannten Manifest für agile Softwareentwicklung aus dem Jahr 2001 wurden vier Leitsätze formuliert, auf denen alle agilen Methoden beruhen:

Abbildung 1: Vier Leitsätze für agiles Vorgehen; Quelle: Manifest für agile Softwareentwicklung.

Diese Leitsätze liegen auch Scrum zugrunde – dort geht es aber eher darum, diese geistige Haltung als eine Art Projektmanagement in Unternehmen umzusetzen. Es ist ein Framework, das aus der Praxis heraus entwickelt wurde. Scrum ist dabei relativ simpel zu verstehen und hilft mit seinen Abläufen, Rollen und Regeln Unternehmen dabei, Projekte agil umzusetzen. Es hilft Teams, sich bei der Produktentwicklung auf das Wesentliche zu konzentrieren und ihre Ressourcen so einzusetzen, dass der Kundennutzen maximiert wird.

Die Komplexität ist entscheidend

Auch wenn agile Methoden in der Softwareentwicklung ihren Ursprung haben, kann Scrum, wie auch das klassische Projektmanagement, ebenso in jedem anderen Bereich angewandt werden. Scrum dient ganz allgemein der Entwicklung, Bereitstellung und Weiterentwicklung von komplexen Produkten aller Art.

Komplexität bedeutet, dass eine Vielzahl von Faktoren und Einzelkomponenten miteinander verwoben sind und sich gegenseitig beeinflussen oder deren Zielsetzungen sich sogar widersprechen. Natürlicherweise bestehen daher bei der Entwicklung von komplexen Produkte Unsicherheiten, Abhängigkeiten und eine gewisse Unberechenbarkeit.

Bei herkömmlichen Vorgehensweisen wird Komplexität mit einer ausführlichen Analyse- und Planungsphase begegnet, Arbeitspakete geschnürt und diese dann an die entsprechenden Teams und Abteilungen verteilt. So kann es passieren, dass Interdependenzen erst spät zu Tage treten und so zu großen Problemen und Verzögerungen führen. Durch die Teilung der Aufgaben arbeiten die verschiedenen Bereiche nicht zur selben Zeit an den gleichen Komponenten – so lassen sich Änderungen nicht mehr ohne großen Aufwand umsetzen.

Vertikale statt horizontale Teilung

Auch bei Scrum gibt es, wenn man so will, eine gewisse Analysephase. Denn auch dort wird das komplexe Problem in einzelne Komponenten zerlegt – allerdings nicht entlang der zu erfüllenden Aufgabe, sondern entlang des Endprodukts. Es wird ein sogenanntes Backlog erstellt und dort zwischen wichtigen (weit oben im Backlog) und weniger wichtigen Komponenten priorisiert. Die einzelnen Komponenten sind dabei umso detaillierter ausgearbeitet, je weiter oben sie im Backlog sind – weiter unten sind vielleicht zunächst nur grobe Ideen vorhanden.

Zur Detaillierung eines Elements im Backlog gehört es auch, den Aufwand für die Umsetzung zu schätzen, diese obliegt dem Team. Bei der Schätzung merkt das Team dann auch, ob die Komponente noch zu weit gefasst ist und sich eigentlich noch weiter unterteilen lässt – vielleicht sogar in eine wichtigere und weniger wichtige Komponente. Ein Beispiel wäre ein Bezahlprozess mit Kreditkarte. Hier könnte das Team das Element weiter unterteilen in die am weitesten verbreiteten Anbieter Visa und Mastercard und die Umsetzung von Bezahlung mit American Express weiter nach unten priorisieren.

Die Priorität richtet sich dabei nach dem größten „value“– die Bezahlmöglichkeit mit Visa hätte hier einen deutlich größeren value als American Express, weil mehr Kunden davon profitieren. Das Backlog bleibt über den gesamten Verlauf lebendig. Das Team kann neu priorisieren, Komponenten hinzufügen oder Komponenten wieder verwerfen. Für das Backlog ist der Product Owner zuständig und ihr/ihm obliegt auch die finale Priorisierung.

Vorteile nicht nur in der IT

Diese Vorgehensweise ermöglicht zum einen auch im fortgeschrittenen Projektstadium noch auf Veränderungen zu reagieren – das Backlog kann jederzeit neu priorisiert werden. Zum anderen senkt sie das Risiko komplexer Vorhaben, Budget oder Zeitplan zu reißen, da im Zweifel weniger wichtige Komponenten eingespart werden können – die variable Größe sind die Funktionen, nicht Zeit und Budget.

Abbildung 2: Plan-Driven vs Value-Driven approach; Bei agilen Vorgehensweisen wie Scrum wird angestrebt, den Nutzen bei fixen Kosten und Zeitplan zu maximieren, während klassische Herangehensweisen danach streben fix definierte Anforderungen umzusetzen.

Diese Vorteile können Unternehmen nicht nur bei IT-Projekten für sich nutzen. Nehmen wir beispielsweise an, ein Logistikunternehmen sucht nach Möglichkeiten, Energie zu sparen. Ein Vorhaben, das viele Unternehmensbereiche betrifft und wo viele Interdependenzen zu anderen Zielen wie etwa Pünktlichkeit bestehen. Hier funktioniert die Arbeit in crossfunktionalen Scrum-Teams, sei es unter Einbezug von Technik, Planung, Betrieb oder Hersteller, schon bei der Ideenfindung besser. Auch bei der Umsetzung von Maßnahmen können die verschiedenen Bereiche und Abhängigkeiten berücksichtigt werden. Die Energiesparideen, die sonst punktuell im Unternehmen aufkommen, können gesammelt und nach ihrem Energiesparpotenzial bewertet werden und in einem Backlog von Ideen geordnet. Die vielversprechendsten Themen werden im Team gemeinschaftlich vorangetrieben und umgesetzt. Bei jeder Maßnahme gewinnt das Team an Erfahrung, die es bei der nächsten Maßnahme miteinbringen kann.

Auch bei der Neugestaltung von Prozessen kann das Vorgehen nach Scrum hilfreich sein. Ein Beispiel wäre die Neugestaltung von Vertriebsprozessen. Klassischerweise würden wir die Tätigkeit von Kundenberatern analysieren, die Produkte untersuchen, die Kunden in Segmente unterteilen und ihre Bedürfnisse analysieren, um Anforderungen an die neue Vertriebsstrategie zu definieren. Stattdessen würden wir mit Scrum überlegen, welcher Vertriebsprozess uns den größten Nutzen bringt – welches Produkt wird stark nachgefragt, welches bringt uns den größten Umsatz? In unserem Scrum-Team sind von Anfang an auch Kundenbetreuer und Mitarbeiter aus dem Marketing. Der fertige Prozess wird nicht am Ende übergeben, sondern gemeinsam entwickelt. Der Prozess selbst ist zunächst gerade so ausführlich, dass er funktioniert. Alle Besonderheiten und Ausnahmefälle sind von niedrigerer Priorität und werden erst nach und nach ausgestaltet.
Beide Beispiele profitieren insbesondere von crossfunktionaler Zusammenarbeit und davon, dass das Team sich bei jedem Sprint überprüfen und verbessern kann. Verantwortlichkeiten können nicht zwischen den Bereichen hin und her geschoben werden, das gesamte Team ist verantwortlich. Es herrscht bei allen Beteiligten zu jeder Zeit Transparenz darüber, wo das Projekt steht. Zwischenergebnisse werden nach jedem Sprint überprüft und es gibt die Möglichkeit jederzeit die Prioritäten und die Agenda zu ändern, da alle zur selben Zeit am Gleichen arbeiten.

Aller Anfang ist schwer

Es ist sicherlich kein Zufall, dass agiles Management in der IT schon sehr viel verbreiteter ist als in anderen Bereichen. In der Softwareentwicklung wurde es schon in den 90ern als Reaktion auf immer kürzerer Produktlebenszyklen angewandt. Durch die mittlerweile weite Verbreitung haben Fach- und Führungskräfte im IT-Bereich daher grundsätzlich mehr Erfahrung mit agilen Methoden.

Die vertikale Teilung von Projekten in Komponenten statt einer horizontalen Teilung in Aufgabenbereiche erfordert eine andere Zusammenarbeit der spezialisierten Abteilungen und Bereiche. Vor allem einen ständigen Austausch und viel Kommunikation – so kommen die agilen Grundsätze der Zusammenarbeit zum Tragen.

Egal in welchem Bereich – es lohnt, Silodenken aufzubrechen und bereichsübergreifend Themen zu bearbeiten. Es lohnt, komplexe Projekte entlang des Produktes in Einzelkomponenten aufzuteilen, regelmäßig Zwischenergebnisse zu liefern und zu bewerten und ständig genau zu hinterfragen, ob das bearbeitete Thema das mit der höchsten Priorität ist. Scrum ist ein erprobter Rahmen um komplexe Produkte erfolgreich umzusetzen – in allen Unternehmensbereichen.