Beim Tausch von Visitenkarten kommt es immer wieder mal vor: Stirnrunzeln oder Staunen, wenn sich das Gegenüber nicht als Diplom-Ingenieur, Senior Manager oder Abteilungsleiter ausweist, sondern als Product Owner. Der erkennbar ratlose Gesprächspartner bekommt dann auch schon mal den Hinweis: „Wir sind halt ein agiles Unternehmen.“

Agile Methoden sind nicht ganz neu in der Energiewirtschaft, aber bei weitem noch nicht alltäglich. Im Zuge der Digitalisierung der Branche hält der Ansatz jedoch mehr und mehr Einzug in die tägliche Projektarbeit. Die so genannte Scrum-Methode, die ursprünglich die Softwareentwicklung auf eine neue Grundlage stellen sollte, wird mittlerweile in allen möglichen Unternehmensbereichen eingesetzt.

Bei Prisma, der europäischen Handelsplattform für Gas-Transportkapazitäten, setzt man seit etwa einem Jahr auf Scrum bei der Weiterentwicklung der Bedienungsoberfläche, der Funktionen und der Stabilität des IT-Systems insgesamt. „Wir wollten unbedingt agiler werden, weil wir erkannt hatten, dass wir mit dem klassischen Projektmanagement viel zu langsam sind“, beschreibt Jan Wagebach die Ausgangslage. Ein Großprojekt, in dem die Plattform sozusagen vollständig „auf Links gekrempelt“ wurde, hatte sich mit Planungs-, Umsetzungs- und Testphase über fast eineinhalb Jahre hingezogen. „In einem so langen Zeitraum dreht sich die Welt ein gutes Stück weiter“, sagt der Teamleiter des Betreibers, der Prisma European Capacity Platform GmbH in Leipzig.

Regulatorische Vorgaben, die sich in den Funktionen der Plattform widerspiegeln müssen, können sich ändern, neue Netzbetreiber können den Nutzerkreis erheblich vergrößern und nicht zuletzt können auch die Anforderungen der Nutzer an die Navigation, den Funktionsumfang und die Leistungsfähigkeit der Plattform die Software-Entwickler herausfordern. In der Zwischenzeit nicht oder nur unzureichend darauf reagieren zu können, war für Wagebach und seine Kollegen eine höchst unbefriedigende Situation. Der Wechsel zu Scrum, mit dem die Leipziger vor 2016 noch nicht gearbeitet hatten, war deshalb fast schon eine logische Folge.
 
Wer sich das Konzept ansieht, dem dürfte kaum das Wort „revolutionär“ einfallen, eher der Begriff „gesunder Menschenverstand“. „Mir ging es ähnlich“, berichtet Wagebach. Aber es zeigt sich seiner Erfahrung nach immer wieder, dass letztlich die vermeintlich simplen Dinge zum Erfolg führen, die man aber aus irgendwelchen Gründen häufig aus den Augen verliere – warum auch immer. Scrum mit seinen einfachen Regeln gewährleiste, dass sich Kunde und Software-Entwickler jeweils ganz unmittelbar Rückmeldungen geben können und dass auf dem Weg zur Umsetzung des Projekts in regelmäßigen, kurzen Abständen bereits für den Kunden nutzbare Produktinkremente geliefert werden.

Die Idee ist in der App-Entwicklung wiederzufinden

Die Idee ist beispielsweise in der App-Entwicklung wiederzufinden. „User sind es gewohnt, dass immer wieder neue Versionen von Apps mit neuen oder erweiterten Funktionen herauskommen“, sagt Jessica Fellmann von BTC Business Technology Consulting AG, einer Tochtergesellschaft der Oldenburger EWE AG, die Prisma als IT-Partner bei der Weiterentwicklung der Plattform unterstützt. Der Vorteil aus Entwicklersicht: Man hat jeweils in kurzen Abständen, nach sogenannten Sprints, die zwei oder drei Wochen dauern können, ein nutzbares Produkt vorzuweisen. „Das kann von einem Button über Farbanpassungen bis hin zu neuen Funktionalitäten reichen, so Fellmann. Für den Kunden liegt der Vorteil darin, dass er seinen Nutzern ein neues Feature zur Verfügung stellen kann, noch bevor die Plattform insgesamt runderneuert ist. Dies habe bei der Entscheidung für die Scrum-Methode eine gewichtige Rolle gespielt, bestätigt Wagebach.

Während zuvor im klassischen Wasserfall-Modell ein Projekt quasi in die Entwicklerteams, die üblicherweise aus fünf bis zehn Spezialisten bestehen, hineingekippt wurde, gehen jetzt die direkt an der Software-Entwicklung Beteiligten auf der Seite des IT-Dienstleisters und auf der Seite des Kunden kleine Schritte miteinander.

Transparenz, die der Scrum-Ansatz fordert, ist nach Jessica Fellmanns Überzeugung ein ganz wesentlicher Erfolgsfaktor für die Zusammenarbeit. „Es wird transparent, wenn ein Team sein Sprintziel nicht erreicht, oder wenn das Entwicklungsteam durch Einflüsse von außen in seinem Arbeitsprozess gestört wird “, sagt Fellmann, die als Scrum Master zum Beispiel dafür verantwortlich ist, dass die Methode konsequent umgesetzt wird und das Team sich auf seine Arbeit fokussieren kann mit dem Ziel, stetig die Produktivität zu erhöhen. Das Offenlegen von Fehlern soll fester Bestandteil der Kultur werden. „Um daraus zu lernen und besser zu werden“, so die BTC-Managerin. Dies könne so weit gehen, dass man einen „Fehler des Sprints“ als Team analysiert und nach einer Lösung sucht, die man dann gemeinsam „feiert“.

Die Stärken des Scrum-Ansatzes kommen vor allem dann zum Tragen, wenn die Problemstellung komplex ist und wenn man noch keine absolut exakte Vorstellung von einer Lösung hat, wenn noch nicht klar ist, welche Daten genau erfasst und verarbeitet und welche Prozesse abgebildet werden sollen. Früher wurden häufig Pflichtenhefte geschrieben, die den Beteiligten wie ein Klotz am Bein hingen und ihnen die Flexibilität nahmen – wenn sie überhaupt gelesen wurden. Und nach einem Jahr Entwicklungszeit waren viele der Annahmen schon überholt. Urte Rieken, bei BTC für den Bereich Projekt- und Qualitätsmanagement verantwortlich, kann sich noch gut an solche Zeiten erinnern, auch wenn sie mittlerweile bereits seit fast sechs Jahren Kunden bei der Einführung agiler Methoden in der IT-Entwicklung berät: „Das Ergebnis entsprach dann zwar den Beschreibungen im Pflichtenheft, war aber nur in den seltensten Fällen das, was man zum Zeitpunkt der Fertigstellung wirklich gebrauchen konnte.“

Pflichtenhefte mit Hunderten von Seiten gibt es nicht mehr. Stattdessen wird das Vorhaben in überschaubare Anforderungen gegliedert, nachdem der Product Owner seine „Vision“ formuliert hat, was am Ende herauskommen soll. Wobei sich das Ziel der gemeinsamen Anstrengungen im Laufe des Prozesses durchaus verändern kann, genauso, wie sich die Rahmenbedingungen für den Einsatz der Software-Lösung verändern können. Aus der Vision gehen dann „Stories“ hervor, die in eine Rangliste gebracht werden. Jessica Fellmann, die als Scrum Master für die Anwendung der Methode und des Coachings der Teams zur Selbstorganisation verantwortlich ist, gibt ein Beispiel, wie eine solche Story lauten könnte: „Als Anwender dieses Systems möchte ich einen Nachtmodus verfügbar haben, so dass die Kollegen, die nachts arbeiten, nicht vor einem allzu grellen Bildschirm sitzen müssen.“ So banal kann das sein. Es geht natürlich auch komplexer. Doch die Umsetzung der Geschichte in die Realität darf nicht mehr Zeit, als für einen Sprint zur Verfügung steht, in Anspruch nehmen. Ansonsten müsste die Story noch weiter in ihre Bestandteile heruntergebrochen werden.

Direkter Austausch mit den Entwicklerteams

Das agile Konzept entledigt sich relativ vieler und vor allem der althergebrachten Managementebenen, die man üblicherweise in einem IT-Projekt findet. „Als Kunde haben wir einen sehr direkten Austausch mit den Entwicklerteams“, sagt Wagebach. Den klassischen Projektleiter gibt es nicht mehr und Business Analysten kommen nur noch selten zum Einsatz.

Wer sich an Stille-Post-Spiele beim Kindergeburtstag noch erinnert, kann sich leicht vorstellen, welche Vorteile der direkte Draht gegenüber einer Informationskette hat, die über mehrere Personen führt.

Die Erfolge der Scrum-Methode bei der Weiterentwicklung der Prisma-Plattform haben die Betreiber so überzeugt, dass gerade die gesamte Organisation des Unternehmens auf diesen Ansatz umgestellt wird. „Das Produkt von Prisma ist die Plattform. Warum soll man da nicht das Unternehmen am Produkt ausrichten“, fragt Wagebach rhetorisch. Schließlich sei das Unternehmensziel der Betrieb, die Aufrechterhaltung sowie die kontinuierliche Weiterentwicklung der Plattform. Deshalb gebe es derzeit auch keine Pläne, von Scrum wieder abzurücken. Allerdings, davon geht Wagebach aus, müsse man wohl genau wie die Plattform auch, die Methodik der Zusammenarbeit mit BTC immer wieder etwas nachjustieren. Letztlich drehe sich die Welt ja weiter.


Scrum-Glossar
Scrum bedeutet so viel wie „Gedränge“. Der Begriff stammt aus dem Rugby-Sport. Dort besprechen sich die Spieler kurz vor einem Spielzug, bevor das Gedränge um das ovale Spielgerät beginnt. Wesentlicher Bezugspunkt dabei ist die Selbstorganisation des Teams.
So englisch wie die Bezeichnung der agilen Projektmanagementmethode selbst, sind auch die einzelnen Elemente eines Entwicklungsprozesses und die verschiedenen Rollen der Beteiligten. Hier die wichtigsten:

Product Vision: Eine kurze Beschreibung des Ziels, das mit der Erstellung des Produkts erreicht werden soll.

Product Backlog: Die Liste mit Anforderungen in der Reihenfolge ihrer Priorität, die den Funktionsumfang eines Produkts beschreiben.

Sprint: Ein Zeitraum von meist ein, zwei oder drei Wochen, in dem das Team sein Sprint-Ziel erreichen muss.

Sprintziel: Dieses ist das Ergebnis, das das zwischen Product Owner und Entwicklerteam vereinbart wird und in einem Sprint erreicht werden soll. Das Sprint-Ziel wird auf der Grundlage der Product-Backlog-Einträge formuliert.

Sprint Backlog: Eine Liste von konkreten Aufgaben im Entwicklungsprozess, die erfüllt werden müssen, um das Sprintziel zu erreichen.

Development Team: Eine sich selbst organisierende Gruppe von Spezialisten, die für die Umsetzung des Projekts verantwortlich ist und am Ende eines Sprints ein sogenanntes Inkrement übergibt.

Increment: Es ist eine in sich abgeschlossene Produktfunktionalität, die während eines Sprints vom Team entwickelt und nach Abschluss des Sprints „geliefert“ wird.

Scrum Master: Die Person, die für die Umsetzung der Scrum-Methode verantwortlich ist. Sie sorgt dafür, dass das Team sich auf seine Arbeit fokussieren und der maximale Nutzen aus der Anwendung der agilen Methode gezogen werden kann. Sie hat nicht die Funktion des klassischen Projektleiters, sondern eher die eines Vermittlers und Unterstützers, der mögliche Hindernisse für das Team aus dem Weg räumt.

Product Owner: Er vertritt die Auftraggeberseite und ist dafür verantwortlich, den Business Value des Produkts zu maximieren. Er beschreibt beispielsweise die Anforderungen und priorisiert sie im Product Backlog.