Agiles Projekt- Management / Scrum

Transkript

1 Agiles Projekt- Management / Scrum Visionen in Realität umsetzen 1

2 Lektion 1: Was ist agiles Projektmanagement? Entwicklungen vorantreiben, Neues entwerfen, gestalten, Nutzern zur Verfügung stellen: Das sind faszinierende Aufgaben mit unglaublich grossen Möglichkeiten. Diese Aufgaben sind allerdings auch schwierig. Meist wissen weder Nutzer noch Auftragnehmer zu Beginn genau, wie das Endergebnis aussehen soll, welche Features es braucht, was es können soll. Und noch weniger genau wissen wir, in welchen Schritten wir es realisieren können. Es gibt festen Grund, von dem wir ausgehen können, aber vieles lernen wir erst unterwegs. Das ist ein wenig wie der Bau einer Brücke: Auch hier geht es von festem Grund in Neuland hinein. Aber sicher ist: Agiles Projektmanagement hat sich in Tausenden von Anwendungen hervorragend bewährt 2

3 Wofür brauchen wir agiles Projektmanagement? Entwicklung und Verbesserung von Produkten wie z.b. leistungsfähiger Software können wir nur mit einer hervorragend organisierten Zusammenarbeit realisieren. Sicherheit bei der Terminplanung, Kontrolle von Risiken, effiziente Arbeit und höchste Qualität sind die Kriterien einer solchen Zusammenarbeit. Wir alle verwenden agiles Projektmanagement bereits, ohne darüber nachgedacht zu haben. Am besten kann man das anhand einer Ferienreise darstellen: Wir haben einen bestimmten Zeitraum und ein bestimmtes Budget zur Verfügung und wollen dafür maximalen Genuss. Wir legen vielleicht die ersten beiden Nächte am Ankunftsort fest und orientieren uns dann weiter. Wir erfragen besondere Restaurants oder Sehenswürdigkeiten und planen die Feinstruktur jedes Tages situativ. Am Abend bewerten wir den Tag und legen die Aktionen des nächsten Tages fest. Um erfolgreich zu sein, muss für alle Beteiligten grösstmögliche Transparenz geschaffen werden. Abläufe und Ergebnisse müssen für diejenigen sichtbar sein, die für das Ergebnis verantwortlich sind. Alle Schritte sollten nach gemeinsamen Standards definiert sein, damit man zu einem gemeinsamen Verständnis der Situation kommt und Abweichungen so gering wie möglich hält. Transparenz, Überprüfung und Anpassung sind drei Grundprinzipien des agilen Projektmanagements 3

4 Lektion 2: Das Produkt Bei Projekten muss am Ende immer ein Projekt-Produkt herauskommen. Oft ist es so, dass ein Kunde (der Produkt- Owner) eine Vision, aber keine klare Vorstellungen davon hat, wie das Produkt am Ende aussehen soll. Aber für die Arbeit an den Lösungen sollten alle Beteiligten wissen, welche Anforderungen das Endprodukt erfüllen muss. Viele Informationen zur Präzisierung des Produkts müssen erst eingeholt bzw. erarbeitet werden. Alle Anforderungen werden in einem Anforderungs-Katalog (Product- Backlog) festgehalten?? 4

5 Product Backlog Produkte können immer weiter verbessert werden. Denken wir nur an die Entwicklung der Automobile in den letzten Jahrzehnten. Die Anforderungen steigen ständig, deshalb ist ein Product-Backlog niemals vollständig bzw. endgültig. Am Anfang sind meist nur die bekannten und am besten verstandenen Anforderungen enthalten, aber es entwickelt sich mit dem Produkt und dessen Einsatz weiter. Produkte müssen sich konstant anpassen und verändern, um im Wettbewerb bestehen und den erforderlichen Nutzen bieten zu können. Product Backlogs bestehen so lange wie das Produkt. Wir geben Produkte für die weitere Verwendung als Release frei, wenn wir glauben, dass sich das rechnet. Aber wir arbeiten bereits am nächsten Release. Das Product Backlog ist eine Liste aller Features bzw. Anforderungen eines Produkts. Diese Liste ist nach Nutzen (Geschäftswert) der Features priorisiert. Das Product Backlog ist die einzige Quelle für Anforderungen, hier werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet Inhalt: Beschreibung der Features Reihenfolge der Features Schätzung Wert 5

6 Product Backlog (Beispiel) 1 Ich als Möchte So dass. Notizen Priorität Status 2 (Done) Product-Backlogs sind eine Mischung aus Story-Telling und präzisen, messbar definierten Anforderungen. Wir brauchen umgangssprachliche Beschreibungen, weil wir die am besten verstehen, aber wir brauchen auch die genauen Daten. Am besten, man trägt alles in eine Excel-Liste ein (die das Team nach eigenen Vorstellungen stricken kann)

7 Lektion 3: Das Produkt bzw. Increment erarbeiten Zielsetzung für das Entwicklungsteams ist, ein neues Produkt bzw. Verbesserungen an einem vorhandenen Produkt (Increment) zu entwickeln. Das Ziel eins Entwicklungs-Abschnitts ( Sprint ) besteht darin, eine potenziell auslieferbare Version des Produkts zu erstellen. Durch diese Vorgabe wird verhindert, dass die in Projekten häufigen Provisorien für Verwirrung sorgen. Und es ist ständig eine fertige Version vorhanden. Leitlinien: Jedes Inkrement muss zum Abschluss eines Sprints in einen verwendbaren Zustand zur Verfügung stehen, so dass der Product-Owner sich jederzeit dafür entscheiden könnten, es für die Verwendung freizugeben Das Team muss eine gemeinsame Definition dafür entwickeln, wann ein Inkrement diese Voraussetzung erfüllt, also fertig ist ( Done ) Jedes Produkt(-Inkrement) ist gründlich getestet, so dass das Funktionieren des Systems als Ganzes sichergestellt ist 7

8 Lektion 4: Vorgehen zur Erarbeitung von Increments Das Vorgehen zur Erstellung von Produkten / Increments besteht aus fünf Schritten. Die Arbeit wird in Sprints. Eingeteilt. Ein Sprint kann gesehen werden als Teilprojekt mit einem maximalen Zeithorizont von einem Monat. Transparenz, Kontrolle, Sicherheit und Schnelligkeit sind die Grundprinzipien. Nach Beendigung eines Sprints folgt das Sprint-Planning für den nächsten Sprint 1. Sprint-Planning Sprint Backlog. Definition des Leistungs-Umfangs 2. Bearbeitung Aufwands- Schätzung Arbeit an Tasks 3. Daily Meeting Soll-Ist-Vergleiche Burndown-Chart 4. Sprint Review Präsentation der Ergebnisse Überprüfung Ausblick 5. Sprint Retrospektive Learnings für das Team festhalten 8

9 Sprint-Planung Bei Entwicklungsarbeiten gibt es viele Unbekannte: Welche Produkte / Entwicklungsstände wollen wir erreichen? Sind diese Entwicklungen realistisch? Wie lange werden sie dauern? Hier schafft Scrum festen Grund. Die Arbeit am Produkt wird in Sprints von maximal einem Monat eingeteilt. Diese Zeitbeschränkung ist sinnvoll, um das Risiko einer Sackgasse zu begrenzen. Die genaue Dauer eines Sprints wird zu seinem Beginn festgelegt und darf weder verkürzt noch verlängert werden. Der Arbeitsplan für den Sprint wird gemeinschaftlich vom gesamten Scrum Team erstellt. Das Ergebnis des Planungs-Prozesses ist das Sprint-Backlog. Die Eingangsgrössen für die Sprint-Planung dienen das Product Backlog, die Schätzung des Aufwands für das neue Inkrement, die Kapazität des Entwicklungs-Teams, die bisherige Leistung des Teams. Nur das Entwicklungsteam kann beurteilen, was im kommenden Sprint machbar ist, deshalb gilt deren Einschätzung als gesetzt. Dauer des Sprint-Planungs-Prozesses: maximal 8 Stunden. 9

10 Sprint-Backlog Das Sprint-Backlog ist eine Liste der Aufgaben, die erforderlich sind, um das angestrebte Inkrement zu erreichen. Es ist eine Prognose des Entwicklungsteams über die erforderliche Arbeit, um diese Funktionalitäten zu liefern. Das Sprint-Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt in den Daily Scrums kontrollieren zu können. Das Sprint-Backlog entwickelt sich während des Sprints weiter, während das Team mehr über die benötigten Schritte zur Erfüllung aller Ziele lernt. Nur das Entwicklungsteam kann das Sprint-Backlog während des Sprints ändern. Das Entwicklungsteam verfolgt die verbleibende Restarbeit mindestens zu jedem daily scrum, um die Wahrscheinlichkeit, das Sprint-Ziel zu erreichen, sichtbar zu machen. Durch die Nachverfolgung er verbleibenden Arbeit kann das Entwicklungsteam das Team seinen Fortschritt steuern. Inhalte: Die Menge der für den Sprint ausgewählten Product-Backlog Einträge Plan für die Lieferung des Produkt-Inkrements und Sprint-Ziels Was genau ist das Ergebnis am Ende des Sprints? Welche Produkt-Inkrements wollen wir erreichen? Welche Funktionalitäten wollen wir bauen? Welcher Aufwand ist dafür notwendig? Im Sprint-Ziel ist damit die Messlatte für die Ergebnisse definiert, die im Product Backlog festgehalten wird. Alles zusammen bildet eine zusammenhängende Funktionalität, die potenziell ausgeliefert werden könnte Das Sprint-Backlog schafft Transparenz durch ein solide Einschätzung der Arbeit des Entwicklungsteams 10

11 Sprint-Backlog ( Beispiel) Task-Nr. Verantwortl. Start Ende Stunden-Plan Stunden-Ist Status 11

12 Umgang mit Veränderungen während des Sprints Änderungswünsche sorgen oft für Verwirrung in Projekten. Deshalb brauchen wir klare Spielregeln für den Umgang mit Veränderungen. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden wird der Qualitäts-Anspruch nicht gemildert wird der Anforderungs-Umfang zwischen Product Owner und Entwicklungsteam geklärt bzw. neu ausgehandelt, wenn sich neue Erkenntnisse ergeben kann die Arbeit am Sprint vom Product Owner abgebrochen werden, wenn es dafür schwerwiegende Gründe gibt wie z.b. Anraten der Stakeholder, des Entwicklungsteams, des Scrum Masters 12

13 Abbruch eines Sprints Schwerwiegende neue Anforderungen können es ratsam erscheinen lassen, einen Sprint abzubrechen. Ein Sprint kann abgebrochen werden, wenn das Sprint-Ziel obsolet wird. Gründe dafür können zum Beispiel sein: Das Unternehmen wechselt die Zielrichtung Veränderung der Rahmenbedingungen in Markt oder Technologie Wenn ein Sprint abgebrochen wird, dann gelten folgende Regelungen Alle abgeschlossenen Product-Backlog-Einträge werden begutachtet. Die auslieferbaren Teile der Arbeit werden vom Product Owner abgenommen. Unvollständige Product Backlog Einträge werden neu geschätzt und wieder ins Product Backlog aufgenommen. 13

14 Fertigstellungs-Kriterien ( Done ) Bei Entwicklungsarbeiten gibt es meist nur wenige vordefinierten Qualitäts-Kriterien. Diese müssen erst erarbeitet werden, weil es diese Bauteile ja vorher noch nicht gegeben hat. Die Anforderung ist, dass alle Bauteile zusammenpassen und dass sie erwartungsgemäss funktionieren. Wie das genau auszusehen hat, muss während der Planung festgelegt werden. Eine klare Definition von Fertig ( Done ) ist deshalb zentral für den Erfolg. Erst dann, wenn ein Schritt fertig ist, erfolgen weitere Massnahmen. Für unterschiedliche Stadien der Bearbeitung können unterschiedliche Kriterien für fertig definiert werden Analyse: Ziele SMART definiert Erste Arbeits-Schritte definiert Entwicklung: Funktionalitäten überprüft Integration überprüft Benutzbarkeit überprüft Abnahme: Kunden-Abnahme Übergabeprozesse ok Uneingeschränkte Einsatz-Bereitschaft 14

15 Daily Sprint Meeting (Daily Scrum) Wenn es viele Unbekannte gibt, dann müssen wir sicherstellen, dass alle Beteiligten möglichst alle notwendigen Informationen haben. Das tägliche Spring Meeting (Daily Scrum) dient zum ständigen Informationsaustausch, es dient der Synchronisation von Planung und Aktivitäten für die nächsten 24 Stunden. Diese täglichen Meetings verbessern die Kommunikation und identifizieren Hindernisse. Abweichungen sollten frühzeitig erkannt und abgestellt werden. Das tägliche Meeting wird an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten und dauert immer 15 Minuten. Nur Mitglieder des Entwicklungsteams nehmen aktiv am täglichen Meeting teil. Inhalte: Überprüfung der Ergebnisse seit dem letzten Meeting Prognose der Ergebnisse, die bis zum nächsten Meeting erreicht werden können Jedes Mitglied berichtet: Was habe ich gestern erreicht, das dem Team hilft, die Ergebnisse zu erzielen? Was werde ich heute erledigen, um dem Team bei der Erreichung der Ziele zu helfen? Gibt es irgendwelche Hindernisse, die uns vom Erreichen des Ziels abhalten können? Detaillierte Diskussionen können im Anschluss an das tägliche Meeting stattfinden. Der Vergleich zwischen geplanten und tatsächlichen Zeitbedarfen (z.b. Burndown Chart) hilft, besser zu verstehen, was dem Team helfen könnte, seine Arbeit besser zu machen. 15

16 Task Board Für die gemeinsame Planung sind Visualisierungs-Tools wie ein Task Board hilfreich 16

17 Fortschritts-Kontrolle Die Schätzung der Bearbeitungs-Zeiten ist immer ein kritischer Punkt in Projekten. Manchmal können wir die benötigte Zeit ziemlich genau schätzen, manchmal ist es ziemlich schwierig. Hier kann die Gruppen-Intelligenz helfen. Wenn die einzelnen Schätzungen für ein bestimmtes Arbeitspaket weit auseinander liegen, kann zum Beispiel erst mal die Komplexität der Aufgabe geschätzt werden. Um herauszufinden, ob das Team effiziente Leistungen erbringt, werden häufig Burndown-Charts verwendet. 17

18 Burndown-Chart Burndown-Charts helfen, Einschätzungen zu verbessern und eine Schätzung über die Fertigstellung von Aufgaben abzugeben. Die gesamte Bearbeitungszeit wird geschätzt (x Stunden) und die Bearbeitungszeit für ein Arbeitspaket (geschätzt) von der Gesamtzeit abgezogen. Die verbleibende Restzeit wird in ein Diagramm eingetragen (Remaining-Plan). Die aktuelle Bearbeitungszeit für ein Arbeitspaket wird ebenfalls von der Gesamtzeit abgezogen. Dies gibt die verbleibende Zeit für die restlichen Aufgaben (Remaining-Ist). In der Darstellung wäre die zur Verfügung stehende Zeit bereits bei Task Nr. 3 verbrannt, so dass es am Ende sehr eng wird Remaining-Plan Remaining-Ist 18

19 Sprint Review In jedem Sprint machen wir Erfahrungen, deshalb ist es vorteilhaft, diese Erfahrungen am Ende eines Sprints in einem Sprint Review festzuhalten. Aus Fehlern können wir lernen und dadurch die Performance steigern. Feedback von Product Owner und Scrum Master sowie gegenseitiges Feedback dienen dazu, besser zu werden. Sprint Reviews sind informelle Meetings, kein Status-Report. Teilnehmer: Projekt-Team und bei Bedarf wichtige Stakeholder, die vom Product Owner eingeladen werden Dauer: Ca. 4 Std. für einmonatige Sprints, bei kürzeren Sprints weniger Inhalte: Der Product Owner erklärt, welche Backlog-Einträge fertig sind und welche nicht. Product Owner stellt den aktuellen Stand des Product Backlogs dar. Er gibt bei Bedarf eine aktuelle Vorhersage des Fertigstellungstermins ab auf Basis des Entwicklungs-Fortschritts. Je nach Bedarf wird das Product Backlog angepasst Das Inkrement wird vorgestellt und Fragen dazu beantwortet Überprüfung des Inkrements Was lief gut, was lief weniger gut? Wie wurden die Probleme gelöst? Ausarbeitung der nächsten Schritte für die nächsten Sprint-Plannings Feedback über wichtige Informationen aus der Markt-Situation bzw. den möglichen Produkt-Einsatz Überprüfung Zeitplan, Budget, potenzielle Eigenschaften, Markterwartungen für das nächste Release 19

20 Sprint Retrospektive Die Prozesse des Teams sollten immer wieder überprüft und verbessert werden. Die Spring-Retrospektive bietet dem Team die Gelegenheit, sich selbst zu überprüfen und Verbesserungspläne für den kommenden Sprint zu erstellen. Wann: Zwischen Sprint-Review und nächstem Sprint-Planning. Dauer: Für einen einmonatigen Sprint ca. 3 Stunden Teilnehmer: Entwicklungsteam und Scrum-Master als gleichberechtigtes Mitglied Ein wichtiger Teil: Eine Liste aller Faktoren, die das Team daran gehindert haben, seine Aufgaben zu erledigen. ( Impediment-Backlog ) 20

21 Lektion 4: Rollen im Scrum-Team Projekt-Teams soll möglichst flexibel, kreativ und produktiv arbeiten können. Dafür gibt es die folgenden Leitlinien: Das Team ist selbstorganisierend: Es entscheidet eigenständig, wie es seine Arbeit organisiert Interdisziplinäres Arbeiten: Alle Kompetenzen sind an Bord, die für die Lösung der Aufgaben wichtig sind Die Rollenverteilung besteht aus: Product Owner Entwicklungs-Team Scrum Master 21

22 Rolle Product Owner Der Product-Owner kann diese Aufgaben selbst erfüllen oder delegieren. Er bleibt aber in der Verantwortung für die Erfüllung dieser Aufgaben. Product-Owner ist eine Person, kein Komitee. Der Product Owner kann aber die Wünsche eines Kommittees im Backlog wiedergeben. Für die Effizienz ist es wichtig, dass die gesamte Organisation die Entscheidungen des Product Owners respektiert. Ein Entwicklungsteam arbeitet ausschliesslich für einen Product Owner. 1 Wertmaximierung des Produkts. Return on Invest optimieren 2 Verantwortung für die Arbeit des Entwicklungsteams 3 Management des Product Backlog, Verantwortung für den vollen Zugriff aller auf alle Informationen 4 Formulierung der Product Backlog Einträge 5 Priorisierung der Product Backlog Einträge 6 Optimierung des Arbeits-Wertes des Entwicklungs- Teams; Einschätzung der Leistungsfähigkeit des Teams 7 Transparenz des Product-Backlog 8 Sicherstellen des Verständnisses für Product-Backlog- Einträge 22

23 Rolle Entwickler-Team 1 Übergabe eines fertigen, potenziell auslieferbaren Inkrements nach jedem Sprint 2 Entwicklungsteams steuern sich selbst Entwicklungsteams sind gross genug, um alle erforderlichen Spezialisten an Bord zu haben und klein genug, um schnell und effizient zu arbeiten. Zwischen drei und neun Mitgliedern ist eine optimale Anzahl. 3 Niemand, nicht einmal der Scrum Master kann das Entwicklungsteam anweisen, wie es aus dem Product Backlog eine potenziell auslieferbare Funktionalität erstellen soll 4 Es gibt keine weiteren Titel oder Unterteilungen des Entwickler-Teams 5 Die Rechenschaftspflicht hat das Team als Ganzes 6 7 Verantwortung für alle Schätzungen, die im PB enthalten sind. Die Schätzung erfolgt immer von denjenigen, die die Arbeit zu erledigen haben 8 23

24 Rolle Scrum-Master 1 Verantwortung für Verständnis und Durchführung von Scrum. 2 Einhaltung der Scrum-Regeln. Insbesondere laufende Überprüfung der Arbeiten auf Transparenz 3 Hilfe für die Interaktion zwischen Scrum-Team und Aussenstehenden Der Scrum-Master ist Trainer und Coach des Teams Hilfe für den Product Owner bei der Verwaltung des Product Backlog, bei der Anordnung des Product Backlog zur Generierung des grösstmöglichen Werts Vermitteln von Verständnis für klare, prägnante Einträge in das Product Backlog Schaffung von Verständnis für Produkt-Planung, Produktentwicklung in der Organisation / bei Stakeholdern Coacht das Entwicklungs-Team in der Selbstorganisation und Teamarbeit, laufende Überprüfung und Verbessserung der gemeinamen Arbeit Beseitigung von Hindernissen für das Entwicklungs-Team, Produktivitäts-Steigerung des Teams 24

25 Quellenangaben Das vorliegende Manuskript wurde weitestgehend an den gültigen Leitfaden für Scrum: Die Spielregeln von Jeff Sutherland und Ken Schwaber angelehnt: Siehe auch Scrum.org. and Scruminc., 2015 Bildnachweis: shutterstock.com, Siehe Bildnachweis bei Management-Tools-Shop.de 25

26 Management Tools Das vorliegende Kapitel ist ein Teil von Management Tools. Management Tools ist eine Sammlung der weltweit besten Management-Konzepte. Die dargestellten Methoden lassen sich auf die meisten Aufgabenstellungen innerhalb des beruflichen Bereichs anwenden. Eine Garantie für Vollständigkeit und Anwendbarkeit der Methoden kann nicht übernommen werden, da es immer auf die Besonderheit der jeweiligen Umstände ankommt. Für die Bewältigung von sehr schwierigen Situationen wird empfohlen, sich mit Fachleuten in Verbindung zu setzen. Autoren: Knowledge Management Systems Dr. Strasser GmbH Bilder: KMS GmbH Ton: Helmar Prechtl, Dipl. Ing. Sprecher: Literatur: Siehe Literaturverzeichnis in Management-Tools Bitte kontaktieren Sie uns, wenn Sie mehr über Management Tools wissen wollen: 26