“Agiles Projektmanagement beginnt bei den Basics. Wir beginnen bei der sozialen Kompetenz der Mitarbeiter und fokussieren so u.a. auf die Einhaltung der getroffenen Vereinbarungen”
Michael Nauditt, Geschäftsführer der moguru GmbH
Agiles Projektmanagement mit Scrum
Scrum im Jahre 2020 ist ein weltweit erfolgreiches Framework für agiles Projektmanagement, welches für Sie ein Set von Methoden und Best Practices bereitstellt, um Projekte mit folgenden Werkzeugen erfolgreich zu machen:
Agiles Projektmanagement basiert auf Empowerment
In funktionsübergreifenden Teams werden Ihre fachlichen Vorgaben (was) eigenverantwortlich umgesetzt (wie). Ihre Teams planen ihre Arbeit selbstbestimmt und legen ebenso teamintern Lösungsmöglichkeiten fest. Dabei werden natürlich Ihre Coding Guidelines und andere Qualitätsansprüche berücksichtigt.
Kurze Zyklen geben im agilen Projektmanagement Sicherheit
Kurze Entwicklungszyklen (Sprints) von zwei bis vier Wochen bilden die Grundlage für Ihr schnelles Feedback. Dabei fokussiert sich das Team auf die Erstellung fertiger Software Inkremente (Fokus auf Done Done). Darüber hinaus geben kurze Zyklen die Möglichkeit schnell die Vorgehensweisen in der Entwicklung anzupassen.
Überprüfung und Anpassung
Das Prinzip “Inspect and Adapt” ist der Kern von Scrum und Ihrem Projekterfolg. Kurze Entwicklungszyklen ermöglichen mit unmittelbaren Feedbackschleifen durch frühe Releases, Sprint Reviews und Sprint Retrospektiven, die Selbstoptimierung der Teams und marktorientierte Produktentwicklung.
Timeboxing und Disziplin
Agiles arbeiten erfordert Disziplin und das Einhalten der zeitlichen Vorgaben. Jede Aktivität im Rahmen von Scrum hat eine festgelegte Dauer (z.B. Daily 15 Minuten) welche nicht überschritten werden darf. Für die Disziplin im Team und die Einhaltung der Zeitvorgaben ist der Scrum Master verantwortlich.
Agiles Projektmanagement basiert auf Transparenz
Das Team informiert Sie tagesaktuell über den Projektfortschritt (z.B. via Burndownchart und Sprint Backlog) und teilt Wissen im Team z.B. im Daily oder im Rahmen von Code Reviews und Pair Programming.
Im einzelnen besteht Scrum aus folgenden Rollen, Aktivitäten, Enablern und Artefakten sowie zu treffenden Vereinbarungen:
Rollen
Der Product Owner (PO) ist für die Ausgestaltung und somit den wirtschaftlichen Erfolg (ROI) des Produktes verantwortlich. Der Product Owner schützt das Entwicklungsteam durch seine Funktion (neben dem Scrum Master) gegenüber störenden Eingriffen weiterer Stakeholder.
Der PO ist bevollmächtigt endgültige Entscheidungen über das Produkt, seine Merkmale und die Reihenfolge der Implementierung zu treffen.
Der PO ist somit der Ansprechpartner für das Entwicklungsteam bei der Frage, welche Produkteigenschaften in welcher Reihenfolge entwickelt werden sollen. Um diese Funktion optimal wahrzunehmen, arbeitet der PO co-located beim Scrum Team und plant mindestens 60% seiner Zeit für die Arbeit am Produkt ein.
Zu diesem Zweck erstellt, priorisiert und managt er die Anforderungen im Product Backlog.
Der Product Owner überprüft, ob die Arbeiten des Teams der Definition of Done entsprechen und somit als erledigt betrachtet werden können.
Stakeholder sind zum Beispiel Kunden, Investoren, Anwender, Partner, Aktionäre, andere Mitarbeiter oder das Management. Die Stakeholder sind direkt oder indirekt von den Projektergebnissen betroffen und haben ein (wirtschaftliches) Interesse an dem Produkt. Sie sind jedoch nicht Teil eines Scrum-Teams. Die Stakeholder teilen dem Product Owner ihre Anforderungen und Wünsche an das Produkt mit und beeinflussen auf diese Weise die Produktentwicklung. Der Kontakt mit dem Scrum-Team während eines Sprints erfolgt ausschließlich über den Product Owner.
Die Verantwortlichkeit für die Integration der Scrum Arbeitsweisen und Verfahren liegt beim Scrum Master. Er coacht dafür sowohl die Organisation, den Product Owner als auch die Team Mitglieder.
Der Scrum Master achtet auf die Durchführung der Aktivitäten im Rahmen der vereinbarten Zeiten (Timeboxing). Er stellt sicher, dass sich alle Team Mitglieder an die selbst getroffen Vereinbarungen halten. Er hilft dem Team erkannte Hindernisse zu beseitigen.
Der Scrum Master ist der Coach am Spielfeldrand. Er ist weder Mitspieler noch gibt er konkrete Vorgaben wie und welche Arbeiten erledigt werden sollen.
Er coacht die Team Mitglieder, verantwortet die Dokumentation des Fortschritts (Burn Down Chart) und hilft so dem Team qualitativ hochwertige Produkte zu erstellen.
"Ein Scrum Team besteht optimalerweise aus 4,6 Personen."
– Jeff Sutherland, in seinem Buch “SCRUM, The Art of Doing Twice the Work in Half the Time”
Ein Scrum Entwicklungsteam besteht heute dennoch meist aus 6-9 selbstorganisiert arbeitenden Personen.
Die Mitglieder eines Entwicklungsteams haben gemeinsam das Know-how, alle Aufgaben zur Produkterstellung durchzuführen. Dabei achten die Teammitglieder darauf, dass sich die jeweiligen Spezialisten (z.B. Frontend Entwickler) sich auch in anderen Bereichen (z.B. Test und Backend Entwicklung) mindestens oberflächlich auskennen (T Shape).
Aktivitäten
Das Backlog Refinement ist neben dem Planning 1 und dem Sprint Review die wichtigste Schnittstelle zwischen Entwicklungsteam und Product Owner. Im Product Backlog Refinement werden vom Product Owner regelmäßig (z.B. jede Woche mindestens eine Stunde) neue User Stories vorgestellt, Fragen des Teams beantwortet und wenn möglich vom Team geschätzt. Ist eine Schätzung nicht möglich (Definition of Ready nicht erfüllt), klärt der Product Owner offene Fragen und stellt die Story im nächsten Refinement erneut vor.
Im Rahmen des Planning 1 (Sprint Planung) werden die priorisierten Backlog Einträge geschätzt und die im nächsten Sprint zu bearbeitenden Items ausgewählt.
Je nachdem wie häufig ein Backlog Refinement stattfindet, kann eine Sprint Planung für einen zweiwöchigen Sprint zwei bis sechs Stunden als angemessen betrachtet werden.
Im Planning 2 werden die User Stories vom Entwicklungsteam in Tasks zur Entwicklung und zur Erfüllung der Definition of Done zerlegt.
Durch das Daily wird der kontinuierliche Informationsaustausch zwischen den Teammitgliedern gefördert. Ziel des Dailys ist es, vorrangig einen Überblick darüber zu erhalten was die Teammitglieder am vorigen Tag getan haben, woran sie heute arbeiten werden und was sie in ihrer Arbeit behindert. So sorgt das Daily für Transparenz und die Möglichkeit für die Teammitglieder sich optimal zu unterstützen und Abhängigkeiten zu erkennen. Das Daily ist insbesondere kein Statusmeeting für den Product Owner oder gar den Scrum Master. Es ist streng darauf zu achten, dass Dailys die vereinbarte Zeit, optimalerweise 15 Minuten, nicht überschreiten.
Im Sprint Review, welches am Ende eines jeden Sprints stattfindet, präsentiert das Entwicklungsteam das fertiggestellte Produkt Inkrement.
Das Ziel des Sprint Reviews ist die Synchronisation aller Beteiligten über den aktuellen Stand der Arbeiten. Somit wird eine Entscheidungsgrundlage über die folgenden Produkterweiterungen für das Planning 1 gelegt.
Der Sprint Review kann für einen zweiwöchigen Sprint innerhalb von 30-60 Minuten durchgeführt werden. Eine detaillierte Vorbereitung und Abstimmung im Entwicklungsteam von maximal einer Stunde ist dabei angeraten.
Im Rahmen der Sprint Retrospektive identifiziert das Team die Stellschrauben zur Optimierung des nächsten Sprints. Unter Anleitung des Scrum Masters deckt das Team positive und negative Aspekte der Arbeit im letzten Sprint auf. Aus dieser Diskussion werden Maßnahmen zur Verbesserung der Zusammenarbeit für den nächsten Sprint definiert. Die Ergebnisse finden Eingang in das Impediment- oder Improvementbacklog.
Enabler und Artefakte
Die Vision ist eine ganzheitliche Betrachtung der Projektziele oder des Produkts und wird vom Product Owner entwickelt. Er erzeugt (ggf. zusammen mit dem Scrum-Team, Stakeholdern, Marketing) ein Zukunftsbild der Idee / des Projekts. Die Vision soll die Stakeholder und das Team von dem Produkt überzeugen, sie motivieren und begeistern.
User Stories sind eine umgangssprachliche Beschreibung der vom Markt gewünschten Funktionen. Die vom Product Owner zu schreibenden und zu priorisierenden User Stories sind üblicherweise in folgender Form geschrieben:
Als <Nutzer Rolle> will ich <gewünschtes Ziel> damit <Nutzen/Grund>
Beispiel einer User Story eines fiktiven Online Shops:
Als Kunde möchte ich in meiner Rechnung alle die von mir bestellten Produkte sehen, so dass ich eine Quittung über den Kauf zur möglichen Regulierung von Garantiefällen habe.
Neben dieser Beschreibung brauchen User Stories sogenannte Akzeptanzkriterien. Hier am Beispiel des Online Shops:
- Rechnungen sind internationalisiert (Sprachen sind zunächst Deutsch und Englisch)
- Die Rechnung enthält die Rechnungsnummer
- Die Rechnung wird als PDF bereitgestellt
- ...
Beim schreiben guter User Stories kann man sich an das Wort INVEST anlehnen. Gute User Stories sind Independent, Negotiable, Valueable, Estimable, Small and Testable.
Im Product Backlog werden alle Anforderungen an das Produkt vom Product Owner in Form von User Stories aufgelistet und priorisiert. Durch kontinuierliche Weiterentwicklung dieser Stories und aufgrund neuer Erkenntnisse bleibt das entwickelte Produkt stets nahe an den Anforderungen des Marktes.
Im Sprint Backlog befinden sich die im aktuellen oder kommenden Sprint zu bearbeitenden User Stories und Aufgaben. Die Lieferung der im Sprint Backlog befindlichen User Stories im Sprint wurde vom Team prognostiziert. Ziel eines Sprints ist die Fertigstellung eines nutzbaren und releasefähigen Inkrements.
Das Improvement Backlog ist eine nach Priorität geordnete Liste mit Maßnahmen zur Verbesserung der Zusammenarbeit. Die Improvements sind Ergebnisse der Sprint Retrospektiven und werden im Improvement Backlog als Stories abgebildet und zusammengefasst. Für die Pflege des Improvement Backlog ist nicht der PO sondern das Team verantwortlich.
Das Burndown Chart veranschaulicht den Fortschritt eines Sprints. Ein Burndown Chart stellt die noch zu bearbeitenden Items, z.B. als Story Points, im Verhältnis zur Zeit grafisch dar. Die Story Points sind dabei normalerweise auf der Y-Achse und die Zeit auf der X-Achse aufgetragen (siehe auch Burn-up Chart). Mit Hilfe des Burndown Charts lassen sich Abweichungen im Verlauf eines Sprints frühzeitig erkennen und angemessene Lösungsmaßnahmen können rechtzeitig begonnen werden.
Das Produktinkrement besteht aus allen bisher fertig gestellt Backlog-Einträgen (frühere und aktueller Sprint), die der Definition of Done entsprechen.
Vereinbarungen
In der Definition of Ready (DoR) werden all die Kriterien gesammelt, die erfüllt sein müssen damit eine Story in den Sprint aufgenommen werden kann. In der DoR werden zum Beispiel folgende Punkte geprüft:
- Die Story ist klar und verständlich geschrieben
- Alle Teilaspekte der Story wurden mit dem Team besprochen und von diesem verstanden
- Der Product Owner hat eine Priorisierung der Story vorgenommen
- Das Team hat eine Schätzung abgegeben
- Es wurden Akzeptanzkriterien (z.B. mindestens drei) genannt
- Externe Abhängigkeiten wurden diskutiert
Storypoint Estimation ist eine Technik zur "Größenabschätzung" von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning I Anwendung findet.
Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Storypoint Estimation führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.
Bereits nach ca. 4-5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.
Sprints (Kurze Entwicklungszyklen von zwei bis vier Wochen) bilden die Grundlage für schnelles Feedback und Anpassungen am Produkt. Während des Sprints fokussiert sich das Entwicklungsteam auf die Erstellung fertiger Software Inkremente. So wie alle regelmäßigen Aktivitäten verändern Sprints ihre Dauer optimalerweise nicht.
Die Definition of Done ist eine Auflistung von Vorbedingungen welche erfüllt sein müssen, damit ein Backlog Item als fertig bezeichnet werden darf. Mit wachsender Erfahrung des Teams verändert sie sich im Laufe der Zeit. Die Definition of Done enthält unter anderen:
- funktionale Anforderungen (“Die bereitgestellten Funktionen arbeiten wie gewünscht”)
- nicht funktionale Anforderungen (“Die Antwortzeit muss unter einer Sekunde liegen”)
- Prozessuale Bestandteile (“Freigabe durch den Product Owner ist erfolgt”)
- Qualitätskriterien (“Code Review wurde durchgeführt”, “Test wurde erfolgreich durchgeführt” etc.)
Was brauche ich für meine App?
Wir haben typische Elemente einer App für Sie zusammengestellt.
Damit können Sie schnell und unkompliziert den Aufwand für Ihre App-Idee abschätzen.
Agiles Projektmanagement mit Scrum im Detail – Infografik
Erfahren Sie detaillierte Informationen per Klick auf die Info-Punkte.
Download-Link versenden:
Susann Käßbohrer
Manager Project Onboarding
Scrum skalieren für agiles Projektmanagement
Mit seinen klar definierten Rollen, Aktivitäten und Artefakten ist Scrum eine leicht verständliche und schnell zugängliche Methode, um die Vorteile der agilen Vorgehensweise produktiv einzusetzen. Gleichzeitig liegt darin aber auch ein limitierender Faktor des Frameworks: Scrum ist aufgrund seiner Struktur ideal für Teams von drei bis maximal neun Personen geeignet. Softwareprojekte sind jedoch häufig so komplex, dass die Anzahl der daran beteiligten EntwicklerInnen mitunter sehr viel höher ausfällt.
Agiles Projektmanagement mit mehreren Teams
Das führt in der Anwendung von Scrum bei größeren Teams zu ganz praktischen Problemen: Face-to-Face-Kommunikation ist nach wie vor die beste Möglichkeit, um Informationen auszutauschen. Doch die benötigte Anzahl der direkten Gespräche steigt quadratisch mit der Anzahl der beteiligten Personen. Dies wird ab einer bestimmten Teamgröße zur organisatorischen Herausforderung.
Große Projekte werden außerdem meist von mehreren Teams bearbeitet, die sich arbeitsteilig um bestimmte Features und Funktionen kümmern. Dies führt zu cross functional dependencies, also wechselseitigen Abhängigkeiten zwischen den Teams, die erkannt, kommuniziert und behoben werden müssen. Halten alle beteiligten Teams ihre eigenen Sprints ab, muss zudem sichergestellt werden, dass die darin entwickelten increments auch integrierbar sind, das heißt als Ganzes funktionieren (integrated increment).
Frameworks ermöglichen Skalierung auf unterschiedliche Teamgrößen
Damit stößt das „klassische“ Scrum-Framework in der Praxis schnell an seine Grenzen. Für viele Teams stellt sich deshalb die Frage, wie Scrum auf die benötigte Teamgröße skaliert werden kann. Möglich wird dies über eine Reihe von Frameworks, die allesamt auf Scrum basieren. Vier der bekanntesten stellen wir in unserer Blog-Serie vor: Scrum of Scrums, Nexus, LeSS und SAFe. Diese Reihenfolge ist dabei nicht zufällig gewählt. Sie spiegelt vielmehr die zunehmende Komplexität der Frameworks wider, die sich unter anderem in der Anzahl an zusätzlichen Rollen, Aktivitäten und Artefakten niederschlägt.
Alle genannten Frameworks verfügen über nützliche Erweiterungen, um die durch den Skalierungsprozess auftretenden Probleme zu adressieren und zu kontrollieren. Unterschiede bestehen sowohl hinsichtlich der Vorgehensweise als auch der Komplexität der Frameworks: Während Scrum of Scrums lediglich ein übergeordnetes Meeting zur Koordinierung mehrerer Einzelteams darstellt, bietet SAFe ein umfassendes Framework zur Agilisierung kompletter Unternehmen.
Teil 1: Scrum of Scrums
Bei Scrum of Scrums handelt es sich nicht um ein vollständiges Framework, sondern vielmehr um ein übergeordnetes Treffen, eine Art “Meta-Scrum”. Die Idee: Mehrere Scrum-Teams arbeiten an ihrem eigenen Sprint Backlog...
Weiterlesen
Teil 2: Nexus
Nexus – lateinisch für „das Zusammenknüpfen“ – ist ein Framework, das drei bis neun Scrum Teams integriert. Scrum dient dabei als Basis-Rahmenwerk und wird um neue Rollen, Artefakte und Methoden erweitert. Dies ermöglicht...
Weiterlesen
Teil 3: LeSS
Das Large Scale Scrum (LeSS) Framework vereinfacht die Entwicklung von Produkten mit mehreren nach Scrum arbeitenden Teams. Es ermöglicht eine schlanke und effektive Synchronisation der einzelnen Scrum Teams...
Weiterlesen
Teil 4: SAFe
Das Scaled Agile Framework – kurz SAFe – ist das komplexeste Rahmenwerk, das wir Ihnen in unserer Blogserie zur Scrum-Skalierung vorstellen möchten. Es zielt auf die Agilisierung kompletter Unternehmen...
Weiterlesen
