Agil skalieren (Mit Giovanni Asproni von Zühlke Engineering Limited)

Lesen Sie das Transkript:

Wir versuchen, unsere Podcasts mithilfe eines Programms zu transkribieren. Bitte entschuldigen Sie etwaige Tippfehler – die Software ist nicht zu 100 % fehlerfrei.

Ben Aston:

Willkommen zum DPM-Podcast, in dem wir über Theorien hinausgehen und praxisnahe Ratschläge für ein besseres Führen digitaler Projekte geben. Danke, dass Sie eingeschaltet haben! Ich bin Ben Aston, der Gründer des Digital Project Manager. Alle sind begeistert von Agilität, aber wie setzt man sie über mehrere Teams oder Projekte hinweg ein? Wie kann man das beschleunigen, und wo kann es schiefgehen? Und wie verhindert man, dass es überhaupt erst schiefgeht? Bleiben Sie dran, um heute im Podcast zu erfahren, wie wir agile Prozesse skalieren und wie wir Agilität im großen Maßstab umsetzen können. Dieser Podcast wird präsentiert von Clarizen, dem führenden Anbieter für Projekt- und Portfoliomanagement-Software für Unternehmen. Besuchen Sie clarizen.com für weitere Informationen.

Heute habe ich Giovanni Asproni zu Gast. Er ist Principal Consultant bei Zühlke Engineering Limited. Ich habe das vermutlich falsch ausgesprochen, aber er sitzt in London. Er ist Softwarearchitekt, Programmierer, Coach und Berater mit umfangreicher Erfahrung in verschiedensten Branchen, u. a. Telekommunikation, Banken, Öl und Gas. Er hat zahlreiche Konferenzen besucht und zu verschiedenen Büchern beigetragen. Giovanni, vielen Dank, dass du heute dabei bist.

Giovanni:

Hallo. Danke für die Einladung.

Ben Aston:

Und wie spricht man den Namen deiner Firma richtig aus?

Giovanni:

Das ist tatsächlich ein schweizerischer Name, es heißt Zühlke.

Ben Aston:

Ah, jetzt wissen wir es! Ja, das hätte ich auch nicht richtig hinbekommen.

Giovanni:

Ich spreche es selbst ständig falsch aus, also keine Sorge.

Ben Aston:

Alles klar. Dann erzähl uns doch ein wenig darüber, woran du aktuell arbeitest. Wir haben vorhin schon kurz gesprochen – wie sieht für dich ein typischer Arbeitstag aus?

Giovanni:

Nun, mein typischer Tag ist momentan ziemlich voll, da ich seit Anfang Juni an einem neuen Projekt arbeite, in dem ich tatsächlich meine eigenen Ratschläge befolge – das ist sehr klug! Nach einer großen Bewertung bei einem Großkunden von Zühlke haben meine Kollegen und ich gemeinsam einen sehr groß angelegten Programm-Check durchgeführt – wir reden da von 500 Leuten, 57 bis 60 Teams, so in dem Dreh. Nun setzen wir einen Teil der Empfehlungen um. Das bedeutet im Wesentlichen, dass wir dem Kunden ein System bereitstellen, um Projektdaten und Programmmetriken zu erfassen, damit das gesamte Vorhaben besser gesteuert werden kann. Daher ist es ziemlich geschäftig; ich übernehme technische Leitung, Anforderungen, Berichterstattung auf allen Management-Ebenen beim Kunden und schreibe gelegentlich auch etwas Code.

Ben Aston:

Erzähl uns doch mehr über den Bewertungsprozess, den ihr durchführt. Es ist ja spannend, dass ihr nicht einfach reingeht und sagt: „Ihr müsst jetzt Scrum machen!“ und es einfach implementiert, sondern erstmal eine Analyse durchführt, richtig?

Giovanni:

Ja.

Ben Aston:

Wie läuft das ab?

Giovanni:

Bei einer Analyse versuchen wir eigentlich vor allem zu verstehen, was wirklich vor sich geht.

Ben Aston:

Ja.

Giovanni:

Wir sprechen mit Leuten, mit Vertretern aus den Teams, mit Führungskräften auf allen Ebenen und versuchen rauszufinden, wie die Situation vor Ort tatsächlich ist. Wir machen auch Code-Reviews, prüfen die Prozesse, denen die Teams folgen, bewerten, wie der Code eingebracht wird, und was sie zur Qualitätssicherung tun.

Ben Aston:

Ja.

Giovanni:

Wir sprechen mit dem Management, um ihre Sichtweise kennenzulernen. Letztlich erstellen wir ein Gesamtbild der Lage, denn gerade große Projekte ähneln sich zwar in vielen Dingen, aber oft unterscheiden sich die Details sehr.

Ben Aston:

Und wie sehen deine Empfehlungen nach so einer Analyse aus? Sind sie jedes Mal unterschiedlich oder laufen sie meist auf dasselbe hinaus? Giovanni: Nein, das hängt davon ab, was wir finden. Es gibt schon Dinge, die sich wiederholen, weil—

Mm-hmm (bestätigend).

Giovanni:

Wir machen die Fehler eben oft auf dieselbe Art.

Ben Aston:

Ja.

Giovanni:

Ein wiederkehrendes Thema ist, dass Firmen, wenn sie auf groß angelegte Programme skalieren – z. B. von 100 auf 200, manchmal auf 500 oder sogar auf 1300 Leute in einem einzigen Produkt –, meist keine Instrumente haben, mit denen sie messen können, ob dieses Wachstum überhaupt einen Vorteil bringt.

Ben Aston:

Du sprichst von Instrumenten – welche Werkzeuge nutzt ihr, um zu prüfen, ob das Hochskalieren tatsächlich einen Nutzen bringt?

Giovanni:

Wir betrachten viele Aspekte. Ich habe in meinem Artikel über Voraussetzungen für Skalierung geschrieben – darauf achten wir besonders. Wir prüfen, ob jeder weiß, was er zu tun hat, ob alle an einem Strang ziehen. Sie wären überrascht, wie unterschiedlich die Zielvorstellungen manchmal sind.

Ben Aston:

Mm-hmm (bestätigend)

Giovanni:

Die ziehen in unterschiedliche Richtungen. Was ich aktuell mache: Wir schauen auf die Nutzung von Metriken – wie stellt man fest, dass sie tatsächlich schneller werden, und zwar anhand von echten Daten statt nur eines Bauchgefühls.

Ben Aston:

Mm-hmm (bestätigend) Ja.

Giovanni:

Wir analysieren das Systemdesign, die Architektur – passt sie zur Teamstruktur? Kommunikationskanäle sind ebenso ein Thema, denn bei großen Projekten neigen die Kommunikationswege dazu, zu erstarren, bis man Probleme kaum noch effizient lösen kann.

Ben Aston:

Ja, ja. Kommen wir jetzt mal zu deiner eigenen Erfahrung mit skalierter Agilität. Gibt es einen Fehler, den du gemacht hast, aus dem du besonders viel gelernt hast? Etwas, das andere vermeiden sollten?

Giovanni:

Ich habe tatsächlich kürzlich einen Fehler gemacht, der zwar nicht dramatisch war, aber doch in gewisser Weise. Ich wurde zu einem Kunden geschickt, um eine schwierige Situation zu lösen – es gab Schwierigkeiten mit einigen Teams, inklusive Kundenteams. Bei Zühlke arbeiten wir häufig direkt im Kundenteam.

Ben Aston:

Richtig.

Giovanni:

Vieles lief gut, aber letztlich gab es politische Verwicklungen beim Kunden, die aus den falschen Gründen das Projekt beendeten. Die Lektion daraus: Manchmal glaubt man zu wissen, was los ist, und übersieht dennoch bestimmte Dinge.

Ben Aston:

Ja.

Giovanni:

Da waren interne politische Spiele im Gange und wir standen mitten im Kreuzfeuer.

Ben Aston:

Mm-hmm (bestätigend).

Giovanni:

So ist das…

Ben Aston:

Politik spielt immer eine Rolle, auch wenn wir das nicht wollen.

Giovanni:

Das stimmt. Politik ist an sich weder gut noch schlecht, sie entsteht immer, wenn Menschen zusammenarbeiten. Entscheidend ist, wie man damit umgeht.

Ben Aston:

Definitiv. Und welchen Ratschlag würdest du jemandem geben, der „agil werden“ soll, aber wenig Erfahrung mit Agilität hat und nicht mal genau weiß, was das bedeutet? Viele unserer Hörer sind wahrscheinlich in dieser Lage und die Kunden verlangen „Agile“. Was wäre dein wichtigster Tipp?

Giovanni:

Der wichtigste Tipp ist, die Erwartungen zu verstehen und zu klären. Wenn Leute sagen: Wir möchten dieses Projekt agil machen – was meinen sie damit? Was ist das Bedürfnis, welches Problem soll gelöst werden?

Ben Aston:

Ja.

Giovanni:

Agilität ist kein Ziel an sich, sondern ein Mittel zum Zweck. Oft beschließen Menschen, agil zu werden, weil andere das machen und sie glauben, dadurch schneller und erfolgreicher zu sein – dabei wird der eigentliche Kern verfehlt.

Ben Aston:

Mm-hmm (bestätigend)

Giovanni:

Deshalb geht es vor allem um Erwartungsmanagement und Klarheit.

Ben Aston:

Das gefällt mir. Das Ziel ist nicht der Prozess selbst, sondern der Wert, den wir liefern – effizienter und mit einem klaren Ergebnis. Der Weg ist Mittel, nicht Selbstzweck.

Giovanni:

Ganz genau.

Ben Aston:

Was ist in deiner Werkzeugkiste – ob Software oder analog – um Teams zu beurteilen und in der Umsetzung zu unterstützen?

Giovanni:

Eines meiner wichtigsten analogen Werkzeuge ist mein Moleskin-Notizbuch. Beim Gespräch ohne Laptop, nur mit Notizbuch, entsteht eine andere Atmosphäre, das Gespräch ist offener.

Ben Aston:

Ja, das kenne ich auch.

Giovanni:

Die Notizen übertrage ich später mit einer Software namens Scapple – dort kann ich Gedanken miteinander verbinden, aber alles ist freier als bei einer Baumstruktur. Das Ganze ist eher ein Busch oder Wald, was mir hilft.

Ben Aston:

Genau

Giovanni:

Ein weiterer Punkt: Beim Bewertungsgespräch mit Teammitgliedern ist nicht nur wichtig, was gesagt wird, sondern auch, wie die Stimmung im Raum ist. Wir müssen auch Körpersprache und Atmosphäre mit einbeziehen.

Ben Aston:

Mm-hmm (bestätigend)

Giovanni:

Die Gespräche müssen in sicherer Umgebung stattfinden – z.B. spreche ich mit Entwicklern nur ohne Manager im Raum. Das Gleiche gilt für Gespräche mit Führungskräften.

Ben Aston:

Richtig.

Giovanni:

Auch wenn alle sagen, sie seien offen – die Realität ist meist komplexer. Sicherheit ist daher essenziell.

Ben Aston:

Zurück zu Software: Hast du eine bevorzugte Projektmanagement-Software für agile Projekte?

Giovanni:

Das hängt tatsächlich vom Kontext ab. Wenn alle im Büro sind, reicht oft ein Whiteboard. Arbeitet das Team verteilt, ist ein elektronisches Tool besser geeignet. Jira ist weitverbreitet – ich mag es nicht besonders, weil es langsam ist, aber es ist besser als ein Whiteboard mit verteilten Teams.

Ben Aston:

Verstehe.

Giovanni:

Es kommt immer auf den Kontext an.

Ben Aston:

Neben deinem Moleskin und Scapple – gibt es neue Tools, die du entdeckt hast?

Giovanni:

Eigentlich nicht. Ich bin in einer Lebensphase, in der ich nicht nach neuen Tools suche. Oft ist es am besten, es einfach zu halten.

Ben Aston:

Auf jeden Fall. Aber gehen wir zurück zu deinem Artikel – alles dreht sich um agile Skalierung. Es ist bekannt, dass mehr Leute im Projekt nicht gleich mehr Produktivität bedeuten, im Gegenteil: Oft sinkt die Produktivität, wenn die Verwirrung wächst. Es muss also einen besseren Weg geben, mehr zu erreichen. Giovanni hat dazu einen großartigen Artikel geschrieben – mit Faustregeln, Gesetzen der Skalierung und Überlegungen zur Teamstruktur. Wer den Artikel noch nicht gelesen hat, sollte unbedingt auf thedigitalprojectmanager.com vorbeischauen.

Lass uns klären: Warum sollten sich Unternehmen überhaupt für agile Skalierung interessieren?

Giovanni:

Man sollte das wissen, denn früher oder später trifft man auf das Thema. Besonders in größeren Unternehmen wachsen Projekte von alleine. Mein genereller Tipp: Versuche nach Möglichkeit gar nicht erst zu skalieren. Erstmal das eigene Problem klären. Warum willst du skalieren? Bist du sicher, dass es sein muss? Im Artikel nenne ich Voraussetzungen – fehlen die, wird aus einer kleinen Unordnung nur eine große. Es ist erstaunlich: Bei allen wirklich großen Projekten, teilweise mit dreizehnhundert Leuten und tausenden Repositories, braucht es am Ende auch nicht mehr als zwanzig, dreißig richtig gute Leute. Wie ein Freund es sagte: Die Teamgröße ist das Minimum aus verfügbaren Leuten und (verfügbarer) Zeit.

Ben Aston:

Richtig, ja.

Giovanni:

Es ist entscheidend, erst effektiv und effizient zu arbeiten, bevor man aufstockt.

Ben Aston:

Wenn wir über agile Skalierung sprechen, ist das wichtigste also: So klein und schlank wie möglich bleiben. Aber auf Prozessebene: Gibt es einen Ansatz, der für alle funktioniert? Oder müssen Teams individuell geführt werden?

Giovanni:

Ein Ansatz für alle funktioniert eigentlich nie, besonders bei großen Teams. Du hast einfach zu viele verschiedene Präferenzen und Arbeitsweisen. Allerdings braucht es bei aller Individualität dennoch eine gewisse einheitliche Schnittstelle, vor allem im Berichtswesen, damit das Management überhaupt verstehen kann, was vor sich geht. Den Teams sollte weitgehende Freiheit gewährt werden, aber beim Reporting sollte einheitliche Transparenz herrschen.

Ben Aston:

Wie sieht ein solches Reporting dann aus, wenn Teams unterschiedlich arbeiten?

Giovanni:

Es gibt viele Wege. Man sollte zum Beispiel nicht allen Teams Scrum aufzwingen. Für Support orientierte Teams ist ein Flow-basiertes Board oft sinnvoller. Aber man kann sich bei der Messung dann auf Stories, Features oder Epics konzentrieren – egal, ob Teams in Sprints, Kanban etc. arbeiten. So lassen sich übergreifende Analysen und auch Code-Strukturen auswerten, was ich in meinem aktuellen Projekt tue – etwa: Wie arbeiten die Teams wirklich zusammen? Oder behindern sie sich gegenseitig?

Ben Aston:

Stichwort skalieren: Wie sieht schlechte und wie gute Skalierung aus?

Giovanni:

Schlechte Skalierung passiert typischerweise, wenn das Management von oben einfach mehr Leute ins Projekt wirft, weil es schneller gehen soll. Dahinter steckt meist klassische Kapazitätsplanung („wir stellen 100 Leute ein und sind in einem Jahr fertig“), die so einfach nicht funktioniert. Essenziell ist, erfahrene Experten gleichmäßig über die Teams zu verteilen. Teams müssen sich auch äußern dürfen, wenn sie Verstärkung brauchen, statt unabhängig davon einfach neue Leute zuzuweisen.

Ben Aston:

Das heißt, es geht auch um Bewusstsein.

Giovanni:

Ja, Bewusstsein ist wichtig. Etwas, das vielleicht provoziert: In Softwareprojekten sind einzig die Programmierer und Nutzer wirklich unverzichtbar. Projektleiter, Berater, ja sogar Tester – hilfreich, aber nicht zwingend erforderlich. Ihre Aufgabe ist, die Entwickler effektiver zu machen. Wer das als Projektmanager begreift, stellt andere Fragen: Nicht „Was sollen die Teams tun?“, sondern „Was brauchen sie, um bessere Arbeit zu machen?“.

Ben Aston:

Was war das Beste, das du je beim skalieren gesehen hast?

Giovanni:

So richtig gut habe ich das nur ein- oder zweimal erlebt, in mittelgroßen Settings: etwa fünf Teams, 50 Entwickler. Dort kannte jeder seine Rolle, wusste, wen er fragen musste, und es gab neben formaler viele informelle Kommunikationswege. Sehr große Projekte hatten alle massive Probleme, oft weil einfach zu viele Leute dabei waren, ohne dass dies aus verstandenen Gründen geschah.

Ben Aston:

Was hältst du von Standard-Frameworks zur Skalierung wie SAFe oder Large Scale Scrum?

Giovanni:

In wenigen Einzelfällen funktionieren die, wenn der Kontext exakt passt. Grundsätzlich mag ich diese Frameworks aber nicht, da sie darauf ausgelegt sind, Projekte in ihre Form zu pressen. Sie fokussieren sich auf Struktur, aber zu wenig auf das tägliche Tun der Beteiligten. Besonders an SAFe stört mich, dass es dem Management ein Gefühl von Kontrolle gibt, aber am Arbeitsalltag wenig nützt.

Ben Aston:

Das sehe ich ähnlich, auch bei Scrum. Jede Methode setzt bestimmte Kontexte voraus – stimmt der nicht, wird's schnell problematisch. Und oft verlieren sich Teams dann im Prozess und nicht im Ergebnis.

Giovanni:

Genau so ist es. Vor Jahren habe ich Extreme Programming eingeführt – aber nicht alle 13 Praktiken auf einmal, sondern wir haben klein angefangen, erst die hilfreichsten Praktiken eingeführt, dann langsam erweitert. Je umfangreicher ein Framework, desto schwieriger erlernt es sich.

Ben Aston:

Man kann nicht zu viel auf einmal lernen. Wird ein Framework einfach „übergestülpt“, machen die Leute oft nur noch „Dienst nach Vorschrift“, ohne Sinn dahinter.

Giovanni:

Das sehe ich laufend als Berater: Jeder macht Standups, aber keiner hört zu. Oder Retrospektiven sind nur noch Jammer-Ecken ohne Ergebnisse. Viele Unternehmen sprechen vom „Spotify-Modell“, aber wie ich höre, nutzt selbst Spotify dieses inzwischen gar nicht mehr so, sondern passt seine Prozesse laufend an.

Ben Aston:

Das Video zum Spotify-Modell wirkt schlüssig und zeigt, wie es funktionieren könnte, aber der Schlüssel ist der Kontext. Jedes Team, jedes Projekt ist anders – das müssen wir akzeptieren. Nur so wird es effektiv.

Giovanni:

Genau. Ein Buch, das ich sehr empfehle, heißt „Six Simple Rules“. Die erste Regel: Bevor du etwas änderst, sieh dir an, was die Leute tatsächlich tun. Erst dann kannst du passende Lösungen entwerfen.

Ben Aston:

Für Projektmanager und Rollen außerhalb der Entwicklung: Was ist aus deiner Sicht die wichtigste Erkenntnis, wie sie Teams am besten unterstützen?

Giovanni:

Das wichtigste ist, zu fragen: Wie kann ich euch unterstützen? Und: Davon ausgehen, dass das Team vor Ort sein Bestes gibt. Nicht hinterfragen, sondern gemeinsam herausfinden, wie man helfen kann. Viele Entwickler möchten sich gar nicht um Budget, Zeitplan, oder Papierkram kümmern – das ist die Domäne des Projektmanagers.

Ben Aston:

Niemand will letzten Endes für Budget oder SOW verantwortlich sein. Dennoch sind diese Dinge im agilen Umfeld zentral, auch wenn gern darüber hinweggegangen wird.

Giovanni:

Das sind essenzielle Themen. Deshalb bin ich skeptisch gegenüber den „No Estimate“-Diskussionen. Kunden wollen Prognosen – und Projektmanager sollten die Teams die Schätzung machen lassen. Ist sie zu lang oder zu teuer, ist es keine Schätzung mehr, sondern ein Commitment. Dann sollte man fragen: Warum dauert das so lange? Und, falls die Schätzung die beste ist, das Team auch gegenüber dem Kunden verteidigen. Das belohnt mit Loyalität und Offenheit.

Ben Aston:

Gerade die Kommunikation rund um Schätzungen ist entscheidend. Man sollte transparent sein, warum wie viel Zeit kalkuliert wurde, und die Teams unterstützen. Projektmanagement bedeutet v.a. Kommunikation – als Schnittstelle zwischen Teams, Kunden und Stakeholdern sorgen wir für Klarheit und Orientierung.

Giovanni, vielen Dank, dass du heute dabei warst!

Giovanni:

Sehr gerne, es war mir ein Vergnügen.

Ben Aston:

Und wir sind gespannt auf eure Erfahrungen: Habt ihr versucht, agile Methoden zu skalieren? Was hat funktioniert, was nicht? Hinterlasst uns eure Kommentare. Und wer mehr erfahren oder vorankommen möchte, kann Teil unserer DPM-Community werden – mit Zugang zu Slack-Gruppe, Vorlagen, Workshops, Office Hours, eBooks und mehr. Meldet euch an unter thedigitalprojectmanager.com/membership. Und wenn euch diese Folge gefallen hat, abonniert uns und lasst eine ehrliche Bewertung bei Apple Podcasts da. Bis zum nächsten Mal, danke fürs Zuhören.