Große agile Projekte

Sichern Sie SPEED in Ihren großen agilen Projekten

   AgilSPEED

Agile Software-Entwicklung bringt schnell neue Funktionen live. Startups und Pilotprojekte machen es vor: Das Scrum-Team entwickelt und testet in zweiwöchigen Sprints Inkremente, die sofort live gehen. Wachsen Startup oder Projekt, kommen neue Scrum-Teams dazu. Und plötzlich wird das agile Vorgehen ganz schön schwerfällig. Teams blockieren sich, weil sie gegenseitig auf Arbeitsergebnisse angewiesen sind, der Product Owner kann nicht mehr alle Teams bedienen und die einheitliche Architektur geht verloren. Lesen Sie, wie Sie die sieben häufigsten Stolperstellen in großen Scrum-Projekten meistern. 

Bilden Sie Feature-Teams

In großen Projekten werden Scrum-Teams oft nach Funktion aufgeteilt: Backend, Datenbank, Frontend werden von unterschiedlichen Teams betreut. Ist ein Team auf Inkremente eines anderen Teams angewiesen, ist es schnell blockiert. Unser Gegenrezept: Schneiden Sie Ihre Teams nach Produkt-Features und besetzen Sie in jedem Team alle Rollen – Business Analyst, Software-Entwickler und Tester. So bearbeitet jedes Team sein Feature eigenverantwortlich und übernimmt die Verantwortung. Die Produktverantwortung bleibt weiterhin beim Produkt-Owner: Er entscheidet, ob ein Feature ins Produkt übernommen wird. 

Halten Sie das gemeinsame Architekturverständnis lebendig

Arbeiten mehrere Teams an einem Produkt, driftet das Verständnis der Architekturvorgaben schnell auseinander. Mit der Praxis-Community und dem Tiger-Team gibt es zwei praktikable Ansätze für ein gemeinsames Architekturverständnis: Ein Tiger-Team gibt die für alle verbindliche Architektur vor. Es arbeitet in den ersten Sprints alleine, beispielsweise am Anfang der Produktentwicklung oder in einem Startup. Dabei festigt es die Architektur. Werden weitere Scrum-Teams aufgebaut, teilt sich das Tiger-Team auf. Jeder Ex-Tiger trägt die Architektur in sein neues Team. In größeren Projekten mit vielen Teams steuert eine Praxis-Community das gemeinsame Verständnis: Jedes einzelne Team entscheidet autonom über Architekturprinzipien seines Features. Architektur-Fans tauschen sich in der Praxis-Community über vielversprechende Beispiele und über Fehlschläge aus, legen gemeinsame Leitplanken fest und tragen das Wissen in ihre Teams zurück. Durch den Austausch bleibt das Wissen über die Architektur im Bewusstsein. 

Verteilen Sie die Aufgaben des Product Owner 

Ein einzelner Product Owner wird mehreren Teams in der Regel nicht mehr gerecht – er muss zu viele User Stories ausarbeiten. Der Ausweg: Lassen Sie die User Stories vom Team formulieren. Der PO gibt Überschriften und einige Stichworte vor. Das Team-Mitglied, das die User-Story ausformuliert, klärt Fragen direkt mit dem Kunden oder der Fachabteilung. Auch Business-Analysten können bei der Ausarbeitung helfen. Sie profitieren davon, eine verantwortliche Person für die Abnahme der Sprint-Ergebnisse zu haben. Ab sieben Teams bietet es sich an, Product Owner für einzelne Bereiche zu ernennen. Darüber gibt es einen Chef-PO. Er behält den Überblick und ist letzte Entscheidungsinstanz. Die Bereichs-POs verantworten Teilbereiche des Backlog. 

Sprint Reviews auf dem Marktplatz

Gemeinsame Sprint Reviews über ein von mehreren Teams bereitgestelltes Inkrement werden uferlos. Stattdessen bietet sich ein Bazar-Review an: Jedes Team zeigt seinen Anteil an seinem Stand, der PO und Interessierte aus anderen Teams oder der Fachabteilung wandern von Stand zu Stand und lassen sich die Veränderungen zeigen. 

Räumen Sie Hindernisse Team-übergreifend aus

In seinen Retrospektiven identifiziert das Scrum-Team Impediments; Hemmschuhe, die mehrere Teams betreffen, werden vom einzelnen Team nicht erkannt. Ein übergreifendes Impediment-Board, das alle Scrum-Master gemeinsam führen, schafft Klarheit. Alternativ erkennen die Teams gemeinsame Schwierigkeiten bei einer gemeinsamen Retrospektive, zusätzlich zur Team-Retro. 

Produkt-Backlog statt Team-Backlog

Arbeiten mehrere Teams an einem Produkt, entstehen schnell mehrere Produkt-Backlogs. Damit geht der Überblick verloren, wie das Produkt sich entwickelt. Funktionen werden doppelt entwickelt oder gar nicht. Besser ist es, wenn ein zentrales Backlog die Stories des Produktes im Ganzen erzählt. Im Planning zu Beginn des Sprints zieht jedes Team die relevanten Stories in sein Sprint-Backlog. 

Austausch beim Scrum of Scrums

Der Wissensaustausch zwischen vielen Beteiligten in unterschiedlichen Teams wird schnell unsystematisch und aufwändig. Bei Scrum-of-Scrums-Treffen tauschen sich Vertreter der Teams regelmäßig aus. Timeboxing diszipliniert die Teilnehmer, das Treffen ufert nicht aus. Idealerweise rotieren Teammitglieder durch, dann bleibt das Wissen im Team verteilt. Doch Achtung: Scrum of Scrums wird schnell als Statusmeeting in Richtung Management interpretiert. Ein festgelegter Fragenkatalog hilft, das Wissen systematisch zu teilen und teamübergreifende Anliegen zu diskutieren. 

Sprechen Sie mit uns

Martin Sturzenhecker, Bereichsleiter ACE

Rufen Sie Martin Sturzenhecker in München an unter 0151 54422083

Rufen Sie Alexander Hofmann in München an unter 089 544 253 013