Heute lesen Sie einen Beitrag, zu dem mich die Blogparade des Projektmagazins und ihr Redakteur Daniel Vienken mit vielen guten Fragen inspiriert haben. Das Thema lautet: „Wir arbeiten jetzt agil / digital / selbst organisiert!“ – Mehr Erfolg durch neue Freiheiten im Projekt oder viel Wirbel um nichts?
Hier möchte ich Ihnen meine Gedanken dazu vorstellen:
Als IT-Projektleiter bei BMW interessiere ich mich besonders für neue, wirksame Methoden und agiles Arbeiten. Ausschlaggebend dafür ist die Einschätzung, dass heutiges Wissen für die Anforderungen von morgen nicht mehr ausreicht. Es ist uns allen klar, dass wir etwas verändern müssen. Doch was?
Für mich sind nicht nur innovative Ideen spannend, sondern vor allem die Umsetzung in die Praxis. Denn erst daraus ergeben sich Erfahrungen, die zu nachhaltigen Veränderungen führen können. Das sind aber keine Lösungen, die von oben verordnet werden oder fix und fertig von der Stange kommen. Ganz im Gegenteil: Hier sind die Mitarbeiter selbst mit ihrer intrinsischen Motivation gefordert – unterstützt vom Management, das eigene Positionen und eigene Arbeitsweisen überdenken muss.
Zu meiner Situation: Ich bin in einem agilen Projekt mit zwei Teilprojekten und fünf Teams. Diese kommen aus vier unterschiedlichen Bereichen, zwei externe Entwickler-Teams, die Product Owner aus dem Fachbereich und die internen IT-Kollegen. Wir arbeiten nach Scrum, in zweiwöchigen Sprints. Dabei erhalten wir zu Beginn unsere Aufgaben und liefern nach 14 Tagen. Die Product Owner sichten nicht nur die Ergebnisse. Zum neuen Konzept gehört, dass sie auch für die erforderlichen Tests qualifiziert werden. Das bedeutet einen enormen Zeitgewinn und bessere Qualität, weil Anforderung und Umsetzung viel enger verzahnt sind.
Nicht alles Gold, was glänzt
Klingt, als ob „agil“ die Lösung für alle Projekte wäre. Das stimmt meiner Erfahrung nach so nicht. Wenn das „Was“ und das „Wie“ klar sind oder eingespielte Arbeitsabläufe vorliegen, macht der Aufwand einer agilen Veränderung von Arbeitsabläufen keinen Sinn. Beispiel: Eine Kollegin aus dem Infrastrukturbetrieb kam zu mir. Sie ist für die Organisation und Abwicklung der Installation von Verkabelungen für die Telekommunikation von außen zuständig. Das funktioniert seit Jahren einwandfrei. Jetzt bekam sie die Anweisung, Ihr Projekt auf agil umzustellen, was streng genommen keinen Sinn macht. Meine Empfehlung ist, bei der Einführung agiler Methoden mit Augenmaß vorzugehen.
Ein anderes Thema ist die Tendenz des Cherrypickings. Wenn schon agil, dann bitte alle ins Boot, die mit am Projekt arbeiten, und bitte alle Aufgaben erledigen, auch die, die wenig bis keinen Spaß machen. Da müssen sich traditionell Orientierte ins Neuland wagen und Digital Natives nach herkömmlichen Tugenden liefern. Wenn dies nicht gelingt, scheitert agiles Arbeiten.
Agiles Arbeiten – Trends und Managementansätze
Ich habe mir aus dem agilen Manifest einzelne Prinzipien herausgegriffen, anhand derer ich weitere Erfahrungen teilen möchte.
Kunden zufriedenstellen
Die Amerikaner bezeichnen ein Unternehmen oft als „Happy Customer Factory“ – der Ansatz gefällt mir sehr gut und so verstehe ich auch unsere Aufgabe hier bei BMW. Damit die Kunden glücklich sind, müssen es zunächst auch die Mitarbeiter sein. Das erreicht man mit agilen Methoden und Konzepten wie Working Out Loud (WOL ist eine Peer-Coaching Methode, bei der bis zu fünf Personen in einem gemeinsamen Circle innerhalb von 12 Wochen agile Werte trainieren, um für die neue Arbeitswelt gerüstet zu sein). Bricht man es noch weiter herunter, gehört auch mein Fachbereichskollege als mein interner Kunde dazu. Er sollte zufrieden sein mit meiner Leistung. Da bin ich als Projektleiter bei der Projektvorbereitung und dem Test der Ergebnisse ebenso gefordert wie als Teamkollege während der gemeinsamen Scrum-Zyklen oder als IT-Experte mit Blick auf die Betriebsreife, für die ich das Produkt gut dokumentiere und auch finanziell in die Zukunft denke. Denn die Aufgabe endet nicht mit der Inbetriebnahme, sondern setzt sich in der Wartung fort. Das musste einer unserer Product Owner akzeptieren, der das Entwicklerteam unter Zeitdruck setzen und auf Dokumentationen wie Benutzerhandbuch oder Beschreibung der IT Architektur verzichten wollte. Das habe er alles im Kopf. Genau damit hätte er vielleicht ein schnelles, aber keinesfalls ein gutes Ergebnis erzielt, denn erst im langfristigen Einsatz entscheidet sich, ob das Projektergebnis den hohen Erwartungen gerecht werden kann.
Änderungen willkommen heißen
Während eines vierzehntägigen Scrum-Zyklus‘ treffen wir uns täglich zu sogenannten Dailys, fünfzehnminütigen Kurzmeetings, bei denen wir den Projektfortschritt und die Bedarfe der Entwickler diskutieren. Als IT Projektleiter ist es dabei meine Aufgabe, zuzuhören, zu unterstützen und bei Problemen rechtzeitig einzugreifen. Funktioniert die Performance nicht, entstehen unüberwindbare Hindernisse, wird eine neue Software benötigt oder gibt es Kommunikationsschwierigkeiten mit anderen Abteilungen? Dann greife ich ein, indem ich andere Experten hinzuziehe, den kurzen Dienstweg mit meinen internen Kollegen vom Infrastrukturbetrieb nutze oder einfach nur mal die richtigen Fragen stelle, zuhöre und Wertschätzung zeige.
Das Besondere am agilen Arbeiten ist, dass man zu Beginn bei einem Sprintmeeting die Themenpriorisierung festlegt. Wir haben eine Vision, auch klare Vorstellungen dazu, wie das Produkt aussehen wird. Es kann aber schnell passieren, dass andere Aufgaben in den Fokus geraten – dann müssen das Entwicklerteam und wir von der IT auch dafür offen sein. Diese Neupriorisierung birgt Konfliktpotenzial, das man ausgleichen muss. Dailys helfen Konflikte zeitnah zu erkennen, das ist damit einer der Erfolgsfaktoren agiler Projektarbeit.
Häufige Auslieferung
Mein Projektalltag hat sich im Vergleich zu früheren Wasserfall-Zeiten deutlich verändert. Damals haben wir die Projektaufgabe und das Ergebnis beschrieben, die Entwickler sind in medias res gegangen und wir haben sie nicht wieder zu Gesicht bekommen, bis die Ergebnisse vorlagen. Dann haben wir getestet – und hatten ein Outcome, mit dem wir mehr oder weniger zufrieden waren. Das hat sich gründlich geändert.
Heute sind wir viel näher dran. Wir hören täglich, wo der Entwickler gerade ist. Der Product Owner erhält regelmäßig Testmaterial und Änderungswünsche fließen direkt wieder in den Prozess ein. Das sorgt für Flexibilität und weniger Aufwand – wenn, ja wenn sich alle an das agile Framework mit seinen Meetings, Priorisierungen und Regeln halten. Bricht jemand aus, gibt es Unordnung, die den Projekterfolg gefährdet.
So geschehen bei einem Product Owner, der sich und dem Team die agilen Meetings sparen wollte. Sein Wunsch: Wir machen Workshops on Demand und auf Zuruf, dazwischen wollte er selber einen Blick auf die Ergebnisse werfen. Ein klarer Fall von Micromanagement und Kontrollwunsch. Ich habe ihn zunächst aus strategischen Überlegungen heraus gewähren lassen: Der Kollege war als Product Owner neu und agil lässt sich meiner Meinung nicht von oben anordnen, sondern muss auch ein Stück weit gefunden werden. Zudem lebte unser zweites Teilprojekt die agilen Prinzipien vorbildlich und hätte damit ein gutes Beispiel auch für diesen Kollegen abgegeben. Nach einem Monat musste ich allerdings eingreifen, denn das Chaos hatte sich ausgebreitet. Es war nicht mehr klar, welche Aufgaben erfüllt sind und welche nicht. Der Product Owner war ebenso unzufrieden wie die Mitarbeiter, statt Fokus herrschten Turbulenzen. Durch diesen Schmerz, den alle Beteiligten wahrnahmen, war es für mich leichter, die agile Struktur wieder einzuführen, die das zweite Teilprojekt so erfolgreich machte.
Crossfunktionale Zusammenarbeit
Die Abteilungsgrenzen hinter sich zu lassen und dabei ganz neue Synergien zu entwickeln, gehört zu den Grundprinzipien von Working Out Loud und dem agilen Arbeiten gleichermaßen. Ein neues Gefühl des kontinuierlichen Miteinanders und der Verbundenheit wecken das Potenzial in den Menschen: Wenn jeder Einzelne sich gebraucht und geschätzt fühlt, dann „schafft“ er auch. Working Out Loud zielt zudem darauf ab, dem Einzelnen in der Praxis agile Werte zu vermitteln. Dabei haben wir diese Werte nicht nur an Wänden und auf Plakaten, nein, wir üben diese in den 12 Wochen anhand von Aufgaben. Einzelkämpfer und Individualisten lernen mehr Vernetzung und Vertrauen in das Team. Das führt zu einer effizienteren Teamkommunikation, Synergien von anderen Projekten und nachweislich besseren Ergebnissen in kürzerer Zeit. Ich wende Working Out Loud nicht formal im Projekt an, sondern rege durch Information und mein eigenes Vorbild dazu an, die Methode für sich zumindest auszuprobieren.
Unterstützung leisten, Vertrauen schenken
Als Projektverantwortliche habe ich weite Gestaltungsmöglichkeiten und Freiräume für meine Entscheidungen. Ich genieße Vertrauen. Dabei werde ich vom Management mit Schulungen, Coaching, Filmen, Vorträgen und Best Practice Austausch intensiv unterstützt. Unterstützung und Vertrauen ziehen sich wie ein roter Faden durch das agile Arbeiten bei BMW.
Wir waren ja ein klassisches Unternehmen, in dem es keine agile Projekte gab. In meinem Projekt hatten wir beispielsweise am Anfang eine Workshopreihe zur Theorie des agilen Vorgehens absolviert. Mitarbeiter, die noch keine Vorstellung von „agil“ hatten, wurden eingebunden. Sie arbeiteten sich in die Projektbeschreibung und das Testen der Projektergebnisse ein. Dafür hatte ich Coaches zur Verfügung und konnte die zuständigen Manager direkt mit einbinden.
Aber auch gegenüber meinem Team gilt dieses Prinzip von Vertrauen und Unterstützung. Ein Beispiel dafür ist die Schätzung im Team. Das ist bei uns im Projekt eine ganz erfolgreiche und bewährte Methode: Die Gruppe soll abschätzen, wie lange eine bestimmte Aufgabe braucht. Dazu ist es nötig, die Aufgabe zu verstehen, der Entwickler muss also kommunizieren, das Team und bei uns auch die Product Owner geben Schätzungen ab – dabei wächst ganz nebenbei das Team zusammen. Ich bleibe im Hintergrund und sorge dafür, dass ich bei Unsicherheiten rechtzeitig unterstützen kann.
Zusammenfassend möchte ich sagen: Der Umstieg hin zum agilen Arbeiten funktioniert nicht, indem man den Schalter umlegt und sagt: „Ab jetzt sind wir agil“. Meist stehen dem Unternehmenskulturen und Verantwortliche entgegen, die noch auf ein klassisches Mindset, auf Silodenken und Wettbewerb setzen. Aus jahrelanger Erfahrung im Management komplexer Projekte kann ich sagen: Das funktioniert nicht. Es braucht eine neue Haltung, ja, eine neue Kultur, die Kommunikation und Eigenverantwortung fördert. Dabei gilt: kein Cherrypicking, also agiles Arbeiten nur so lange, wie’s Spaß macht. Man muss auch dranbleiben, wenn es Konflikte gibt und unterschiedliche Einschätzungen lösen. Wir haben viel ausprobiert und oft gegen Widerstände gearbeitet, letztlich aber doch die Unterstützung des Managements gewonnen. Dranzubleiben lohnt sich für alle, denn dann können wir die Früchte ernten, die uns agiles Arbeiten bietet: bessere Performance, stärkere wirtschaftliche Position und vor allem: mehr Freude im Job.
