Für das Projekt zum Relaunch unserer Website betrat unsere Geschäftsführerin Petra Berleb Neuland: Erstmals fungierte sie als Product Ownerin. Dabei lernte sie nicht nur viel über agiles Arbeiten mit Scrum, sondern auch über die Tücken interkultureller Zusammenarbeit.
An Amazon-Kindle übertragen
Melden Sie sich bei Ihrem Amazon Konto an und folgen Sie den Anweisungen, um Ihre Datei hochzuladen und auf Ihr Kindle-Gerät zu übertragen. Unter diesem Link können Sie Ihre Amazon-Geräte und Dateien verwalten. Feedback oder Fragen?
Für das Projekt zum Relaunch unserer Website betrat unsere Geschäftsführerin Petra Berleb Neuland: Erstmals fungierte sie als Product Ownerin. Dabei lernte sie nicht nur viel über agiles Arbeiten mit Scrum, sondern auch über die Tücken interkultureller Zusammenarbeit.
"Für 150.000 Euro entwickeln wir eine schöne neue Website und sind in vier Monaten damit live."
Das waren die blumigen Aussagen des Vertrieblers unserer neuen Software-Agentur, die wir für den Relaunch unserer Website projektmagazin.de engagiert hatten.
Es war mein erstes agiles Projekt in der Rolle des Product Owners und ich war skeptisch. Die Projektdauer von vier Monaten kam mir mehr als unrealistisch vor. Aber auch nach mehrmaligem Nachhaken bestätigten uns der Vertriebsleiter und der Scrum Master den Zeitraum als absolut valide. Nun gut, dachten wir, schließlich deckte das System in Drupal ja bereits in seiner Standardversion viele Anforderungen ab, die wir nur noch an unsere Voraussetzungen anpassen mussten.
Nach einem knappen Jahr Konzeption, Layout-Entwicklung und der mühsamen Suche nach einem geeigneten Entwicklungspartner ging es endlich los. Die Suche nach der passenden Software-Agentur hatte den Projektstart um ein halbes Jahr verzögert. Wir waren überrascht, dass es so schwierig war, eine kompetente, vertrauenswürdige Agentur zu finden. Doch endlich hatten wir unseren perfekten Partner: Die deutsche Niederlassung befand sich in München, das Headquarter in Lettland.
Das Team bestand zu Beginn aus einem Scrum Master, einem Tech Lead, zwei Entwicklern, mir als Product-Owner-Newbie und Tobias, unserem Online Marketing Manager, der mich bei der Erstellung der Epics und User Storys stark unterstützte.
Die Velocity war anfangs erschreckend schlecht. Das sei normal, versicherte mir der Scrum Master, denn die Entwickler müssten sich ja erst einmal mit dem System vertraut machen. Das Team wurde bald um zwei Entwickler erweitert und das Projekt nahm allmählich Fahrt auf.
Dank meines theoretischen Vorwissens in Scrum wuchs ich bald in meine Rolle als Product Owner hinein und fühlte mich durch die Dailys gut informiert. Im Gegensatz zu unserem letzten Website-Entwicklungsprojekt, das wir klassisch mit 100 Seiten Lastenheft durchgeführt hatten, wusste ich zu jeder Zeit, woran die Entwickler arbeiteten und mit welchen Herausforderungen sie konfrontiert waren.
Um für das Projekt, dessen Probleme und das Team ein Gefühl zu entwickeln, war ich als Product Owner täglich beim Daily dabei. Es war zu Beginn sehr ungewohnt für mich, dass die Entwickler erzählten, woran sie gerade arbeiteten, welche Probleme sie hatten und wo sie Unterstützung brauchten. Dennoch fand ich schnell Gefallen an der Offenheit und der wertschätzenden Art des Teams. Was sich anfangs als Rechtfertigung angefühlt hatte, wurde für mich bald zur Normalität.
Projektstatus nach drei Monaten: 30 Prozent des Projektumfangs geschafft, ein Monat Restlaufzeit und 80 Prozent des Projektbudgets verbraucht.
Dass das prognostizierte Budget von 150.000 Euro nicht ganz reichen würde, war schon früh absehbar, denn wir hatten uns im Projektverlauf dazu entschlossen, unsere Kundendatenbank und unser Abrechnungssystem durch SaaS-Software zu ersetzen. Die Anbindung an die neuen Systeme, so die Argumentation des Tech Leads, wäre dadurch viel einfacher und schneller als die Schnittstellenentwicklung an das bestehende, individuell entwickelte Datenbanksystem.
Dennoch war das Missverhältnis "Projektergebnis zu verbrauchtem Budget" zu groß. Es war Zeit für klare Worte! In einem Eskalationsgespräch rückte der Tech Lead nach mehrmaligem Nachhaken zögerlich damit heraus, dass er sich im Vorfeld nur oberflächlich mit dem Projektumfang und den Anforderungen beschäftigt hatte. Er hatte die Komplexität unserer Website völlig unterschätzt. Auch der Vertriebler gab kleinlaut zu, die Sache falsch eingeschätzt zu haben. Nur der Scrum Master meinte lapidar: "Wir müssen uns endlich auf die wichtigsten Funktionalitäten konzentrieren, der Rest muss raus!"
Es herrschte ratloses Schweigen. Nach einer kurzen Kaffeepause einigten wir uns auf die Halbierung des Stundensatzes für die restliche Projektdauer – unter der Voraussetzung, dass ich als Product Owner den Umfang nochmals drastisch reduzierte und alles aus dem Projektumfang nahm, was nicht absolut zwingend für den Betrieb der Website in der Startversion war. Für das bestehende, kostenpflichtige Angebot von projektmagazin.de war das eine schwierige Gratwanderung. Welchen Service, welche Leistung konnte ich – wenn auch vorübergehend – streichen, obwohl unsere Abonnenten und Werbekunden (vermeintlich) dafür bezahlten?
Nach weiteren zwei Wochen der große Knall: Unser Entwicklungspartner eröffnete uns, dass er Insolvenz anmelden musste. Leider würde die Agentur die Website nicht mehr fertigstellen können, da sie die Entwickler nur noch bis zum Monatsende bezahlen konnte. Bumms! Da saßen wir und überlegten fieberhaft, was wir jetzt tun könnten.
Das Geld war fast komplett ausgegeben, aber von einer funktionierenden Website waren wir meilenweit entfernt.
Glücklicherweise hatten wir in der Zwischenzeit den Kontakt zu einer weiteren Drupal-Agentur aus der Ukraine vertieft, die sofort in das Projekt einsteigen konnte. Und wieder ging die Velocity in den Keller, da der Fokus nun auf der Projektübergabe und Einarbeitung der neuen Agentur lag.
Die Verzögerung brachte uns in eine kritische Situation: Unsere Werbekunden legten ihre anstehenden Buchungen für das Folgejahr auf Eis, da wir – bedingt durch die Insolvenz – den Termin für den Relaunch wiederholt verschieben mussten. Zusätzlich begann mit Hochdruck die Vermarktung unseres jährlichen Events, der PM Welt. Genau das wollten wir ursprünglich unbedingt vermeiden. Zusätzlich zum Tagesgeschäft wurde das Team also mit zwei großen Projekten doppelt belastet. Die Stimmung war entsprechend angespannt.
Nach zehn Monaten harter Arbeit und einer emotionalen Achterbahnfahrt gingen wir mit unserer neuen, modernen Website erfolgreich online. Die Projektdauer hatten wir um sechs Monate überschritten, das Projektbudget hatte sich verdreifacht und ein Drittel des ursprünglichen Umfangs war noch gar nicht umgesetzt.
Und dennoch: Viele Leser und Kunden waren vom neuen Layout und der Benutzerführung begeistert. Die Arbeit hat sich gelohnt, denn wir haben damit eine moderne und stabile Basis für die Zukunft geschaffen.
Dieses Projekt war durch die Turbulenzen extrem anstrengend und zeitaufwendig. In die Rolle des Product Owners in einem internationalen Team mit Kollegen aus Deutschland, England, Lettland und der Ukraine musste ich erst mühsam hineinwachsen. Ich verstand zu Beginn meist nur Bahnhof, wenn die Techies mit ihren Software-Fachtermini in Englisch loslegten und war sehr froh, meinen Kollegen Tobias an meiner Seite zu haben. Ohne ihn und seine technische Expertise hätte ich das Projekt nicht in diesem Umfang stemmen können.
Ich habe in keinem Projekt so viel gelernt wie in diesem. Inzwischen wende ich agile Vorgehensweisen und Methoden, die ich zuvor zwar ausprobiert, aber nicht regelmäßig eingesetzt hatte, konsequent auch in anderen Arbeitsbereichen an: In der Produktentwicklung arbeite ich mit MVPs und Meetings werden durch eine strikte Time Box begrenzt. Ohne Time Box gehe ich in kein Meeting mehr – damit wir uns auf das Thema konzentrieren und nicht in Detaildiskussionen abschweifen.
Sehr interessant war für mich, als Scrum-Newbie, der kulturelle Unterschied in der Zusammenarbeit: von der lockeren Offenheit und Direktheit des deutsch-lettischen Teams hin zur zurückhaltenden, eher hierarchisch geprägten Denkweise der Ukrainer. Um ein Beispiel zu nennen: Das deutsch-lettische Team adressierte offen und schnell, wenn es bei einem Problem nicht vorankam und fragte nach Unterstützung. Für das Team aus der Ukraine war dies zu Beginn unvorstellbar und hätte einen totalen Gesichtsverlust bedeutet. Da kam es schon einmal vor, dass ganze Personentage mit Überlegen, Recherchen usw. verstrichen, weil sich ein Entwickler nicht zuzugeben traute, dass er nicht weiter wusste. Mit wachsender Sicherheit, zunehmendem Vertrauen und viel Humor wurden die ukrainischen Kollegen aber immer lockerer und entspannter und hatten richtig Spaß an der Zusammenarbeit. Das zu beobachten, war eine schöne Erfahrung.
Die Arbeitsbelastung eines Product Owners ist – projektabhängig – immens. Für mich war es ein Vollzeitjob – und das bei der zusätzlichen Arbeitsbelastung als Geschäftsführerin. Andere Aufgaben außerhalb des Projekts waren in dieser Zeit nur schwer zu bewältigen, und diese mangelnde Aufmerksamkeit wirkte sich negativ auf die Stimmung im projektmagazin-Team aus. Gleichzeitig half mir die Arbeitslast sehr bei der Priorisierung von Aufgaben. Das Neinsagen fiel mir plötzlich leicht und ich delegierte Aufgaben, die ich früher ohne nachzudenken selbst gemacht hätte.
Meine Geschäftspartnerin und ich versuchten, den immensen Druck, der auf uns lastete, so gut wie möglich von unseren Mitarbeitern fernzuhalten. Dadurch fielen wir in alte Verhaltensmuster zurück. Wir verstärkten unseren Tunnelblick und verloren dadurch unsere Mitarbeiter ein Stück weit aus den Augen. Den wachsenden Unmut bemerkten wir deshalb erst, als die Stimmung schon hochkochte. Unsere Kolleginnen und Kollegen fühlten sich nicht ausreichend informiert und eingebunden. Heute würde ich mein Team in einer vergleichbaren Situation früher und stärker einbeziehen, auch wenn nicht alle direkt in das Projekt involviert sind.
Die konsequente Frage nach dem "Wozu?" ist mein größtes Learning, das ich aus diesem Projekt gezogen habe: Ist diese Anforderung wirklich nützlich, ist diese Detaillierung wirklich notwendig, kommen dadurch mehr Besucher auf die Website, verkaufen wir damit mehr Abos, sind die Leser damit glücklicher? Das hat meinen Blick geschärft und dafür bin ich sehr dankbar. Es ist jedoch ein Lernprozess und es fällt mir zunehmend leichter, mich von vermeintlich wichtigen Anforderungen oder liebgewonnenen Funktionalitäten zu verabschieden. Durch dieses Projekt habe ich diese Denkweise verinnerlicht und ich versuche auch, sie in meinem Team zu verankern.
Auch wenn das Projekt länger gedauert und mehr gekostet hat als prognostiziert, bin ich überzeugt, dass wir das Projekt mit einer klassischen Vorgehensweise nicht in der kurzen Zeit gestemmt hätten. Wir haben innerhalb von zehn Monaten unsere komplette IT-Infrastruktur ausgewechselt und damit die technische Voraussetzung geschaffen, um allen unseren Mitarbeitern flexibles Arbeiten im Flexwork zu ermöglichen. Das hat die Mitarbeiterzufriedenheit spürbar gesteigert.
Unser Mindset war schon immer agil, jetzt haben wir mit diesem Projekt unsere Methodenkompetenz erweitert und die agile Arbeitsweise stärker strukturiert und verbessert. Das fühlt sich für uns stimmig an, deshalb werden wir den Weg zum selbstorganisierten und agilen Unternehmen konsequent weitergehen. Eine andere Arbeitsweise ist für mich nicht mehr denkbar, denn wir haben noch viel vor.
 |
Agile Short StoriesWeitere 48 agile Kurzgeschichten finden Sie in dem Buch "Agile Short Stories", herausgegeben von Miriam Sasse und Joachim Pfeffer. Der Gewinn fließt an die Hilfsorganisation "Flying Hope". |
