Agile Project MAnAgeMent guide 2.0 ScruM / KAnbAn extreme ProgrAMMing

Transkript

1 Agile Project Management Guide 2.0 Scrum / Kanban Extreme Programming

2 IAPM International Association of project managers 1997 steckte die IAPM noch in den Kinderschuhen. Sie begann als loser Zusammenschluss von internationalen Projektmanagern, die alle ein Ziel hatten: Projektmanagement fördern, modernisieren und jungen Projektmanagern Rüstzeug an die Hand geben, um erfolgreich arbeiten zu können. Seitdem fanden in jährlichem Rhythmus mehrere International Project Manager Meetings (IPMM) statt. Schon 1998 brachte die IAPM den Vorläufer des heutigen PM Guide 2.0 heraus, die IAPM By-laws of Project Management. Diese bildeten den Grundstein für den 2010 komplett überarbeiteten, an die Bedürfnisse und den realen Alltag des modernen Projektmanagers angepassten PM Guide 2.0. Im Zuge dessen folgte 2010 der komplette Relaunch der IAPM. Im März 2011 erschien der Scrum Guide 1.0, Vorläufer des jetzigen Agile PM Guide 2.0. Im Jahr 2012 wurden erstmals zwei Awards verliehen, zum einen der Award Project Manager of the Year und zum anderen der Award Book of the Year. Der Award Project Manager of the Year liegt der IAPM besonders am Herzen, denn damit zeichnet sie Menschen aus, die besondere Leistungen im Projektmanagement erbracht haben. Dies kann die Bewältigung einer Krisensituation, ein besonders aufwändiges Entwicklungsprojekt oder auch einfach jahrelange, erwiesene Spitzenleistung in verschiedenen Aufgabenbereichen des Projektmanagements sein. Mit dem Award Book of the Year werden Werke ausgezeichnet, die sich mit dem Themenkomplex Projektmanagement beschäftigen und in deutscher und englischer Sprache herausgegeben werden. Das kann in Form von besonders innovativer Erfahrungs- und Wissensvermittlung sein, ein (auto)biographisches Werk oder ein Lehrbuch, das den Einstieg in das Thema Projektmanagement weist. Die IAPM ist Träger einer unabhängigen Zertifizierungsinstitution, die Fachwissen und Kompetenz der Zertifikatsanwärter durch ein umfassendes, faires und neutrales Prüfungssystem online bewertet. Das Zertifizierungssystem ist somit ganz speziell auf die herausfordernde Lebenswelt des Projektmanagers des 21. Jahrhunderts zugeschnitten. 3

3 ScruM-AtlAS inhalt 03 Die IAPM 34 Sprint Retrospective 04 Scrum-Atlas 35 Aspekte der Teambildung 06 Einführung 39 Motivation 40 Konfl iktmanagement 1 Kundenauftrag 2 Projektumfeld Teil 1 Scrum Die Rollen bei Scrum 42 Teil 3 Weitere agile Methoden 11 Verantwortungsbereiche 43 Kanban 12 Produktvision 44 Kanban in IT-Projekten 13 Projektumfeld 45 Wertschöpfungskette 14 Stakeholder 48 Scrum vs. Kanban 4 Produktvision 3 Stakeholder Product Backlog Nutzergeschichten Extreme Programming Values 20 Schätzklausur 51 Principles 21 Sprint Backlog 53 Practices 22 Sprinting 56 Scrum vs. Extreme Programming 23 Sprint-Fortschritts-Diagramm 57 Scrum und Extreme Programming 25 Done -Prinzip 5 Product Backlog 6 Sprint Backlog 7 Sprinting Release-Planung Release-Fortschritts-Diagramm Teil 2 Der Mensch im agilen Projekt Soft Skills Besprechungen und Meetings Teil 4 Der IAPM-zertfi zierte agile Projektmanager Einführung Die Zertifi zierung Verfahren Die Prüfungen Sprint-Vorbereitung Sprint-Planungsmeeting 64 Eidesstattliche Erklärung 9 Release Burndown Chart 8 Sprint Burndown Chart Meetings zur technischen Umsetzung Daily Scrum Sprint Review 66 Impressum 4 5

4 Einführung was ist agiles Projektmanagement? Die vier teile des Agile PM guide 2.0 Agiles Projektmanagement ist ein Oberbegriff für verschiedene Vorgehenstechniken, die auf dem sogenannten empirischen Vorgehensmodell basieren. Sie finden Anwendung, wenn der Verlauf oder das Endergebnis wie etwa bei der Softwareentwicklung zu Beginn schwer oder nicht vorhersagbar ist. Es gibt verschiedene Methoden (Scrum, Kanban, Extreme Programming oder Crystal Clear), von denen Scrum die größte Verbreitung gefunden hat. Dabei werden Rahmenbedingungen vorgegeben, die den Beteiligten den größtmöglichen agilen Bewegungsspielraum geben, den optimalen Weg zur Fertigstellung des Produktes zu finden. Bei Scrum wird auf umfangreiche Planungsdokumentation wie im traditionellen Projektmanagement weitgehend verzichtet. Zu Beginn des Projektes wird eine Sammlung der Anforderungen in Form eines Kataloges (Product Backlog) erstellt, dann geht es direkt in die Umsetzung. Im Zentrum stehen kurze Entwicklungsinkremente, sogenannte Sprints. In ihnen werden fertige Teilergebnisse erarbeitet, die dann nach ihrer Fertigstellung eine schnelle Rückmeldung des Produktmanagers (Product Owner) erlauben. Hierdurch werden bereits früh im Projekt kostpielige Fehlentwicklungen verhindert, die Zeitverluste und Zusatzkosten verursachen. Häufig können zu Beginn zunächst keine genauen Vorhersagen gemacht werden, wie lange die Entwicklung dauert oder wie der exakte Kostenrahmen aussieht. Das führt insbesondere bei der Einführung von Scrum in vielen Unternehmen zur Verunsicherung. Hierfür gibt es aber Möglichkeiten und Ansätze, die in diesem Guide vorgestellt werden. Weitherin werden die agile Projektmanagement- Methode Kanban und die Arbeitsmethode Extreme Programming vorgestellt. Diese Richtlinie soll Ihnen helfen, das vorhandene Wissen zu agilem Projektmanagement zielgerichtet zu nutzen. Dafür ist sie in vier Teile gegliedert: Teil 1: Agiles Projektmanagement Scrum Wie ich ein Scrum-Projekt aufsetzen und zu einem guten Ende führen kann. Teil 2: Der Mensch im Projekt soft facts Wie ich die weichen Faktoren im agilen Projektumfeld beachten kann. Teil 3: Weitere agile Methoden Scrum oder Kanban? Und welche Rolle kann Extreme Programming spielen? Teil 4: Der IAPM-zertifizierte Agile PM Wie ich mein Wissen und meine Kompetenz zertifizieren lassen und damit meinen Marktwert steigern kann. Wir wünsche Ihnen eine erstklassige Projektarbeit, viel Spaß beim teamorientierten Projektarbeiten und maximale persönliche Erfolge. 6 7

5 Rollen im Scrum Teil 1 Rollen bei Scrum Die drei Hauptrollen Agiles Projekt- Anders als beim klassischen Projektmanagement gibt es keinen Projektleiter, die Scrum-Welt ist dreigeteilt. Es gibt die Rollen Product Owner, Scrum-Team und Scrum Master. Der Produktmanager (Product Owner) vertritt den Kunden oder Auftraggeber und stellt sicher, dass dessen Vorstellungen eingearbeitet werden. Das Scrum-Team arbeitet selbstständig und fällt seine Entscheidungen bei der Produkterstellung in eigener Verantwortung. Ihm ist der Scrum Master als Coach und Teamentwickler beigestellt, der sich unter anderem auch darum kümmert, dass die Arbeitsumgebung optimiert wird sowie Behinderungen und Störungen abgestellt werden. manage- ment: Scrum 1 Product Owner Verantwortlich für den wirtschaftlichen Erfolg des Produkts Entwickelt die Produktvision Repräsentiert die Kunden und Anwender Zuständig für Anforderungen an das Produkt Verantwortet das Stakeholder-Management Verantwortlich für die Abnahme von Produktinkrementen (Sprint-Ergebnisse) Entscheidungshoheit, ob die Entwicklung weitergeführt oder das Projekt beendet wird 8 9

6 Rollen im Scrum 2 3 Scrum-Team Organisiert sich selbst Verantwortet die Ergebnisse der Entwicklungsinkremente gemeinschaftlich Cross-Functional (alle technischen Kompetenzen sollten vertreten sein, um die Entwicklungsarbeit zu vollziehen) Verhandelt mit dem Product Owner den Aufgabenumfang der Inkremente (Sprints) Hat die Verantwortung, wie die Aufgaben erledigt werden Sollte idealerweise 7 +/- 2 Mitglieder umfassen Scrum master Moderator und Teamentwickler des Scrum-Teams Unterstützt die Selbstorganisation des Teams Identifiziert und beauftragt den Product Owner (bei internen Projekten) Kümmert sich um Störungen und Hindernisse in Bezug auf die Teamarbeit Ist Organisationsentwickler, das heißt, er stellt im Unternehmen sicher, dass die Bedingungen für Scrum gegeben sind oder wenn nötig verbessert werden Kümmert sich um die Stakeholder des Projekts im Unternehmen Verfolgt die Performance des Teams Hat keine Autorität über das Team Verantwortungsbereiche Wer ist für was zuständig? Rollen und Verantwortlichkeiten in Scrum Aufgaben Product Owner Team Scrum Master Produktvision Projektumfeld Stakeholder Product Backlog Sprint Backlog Sprint Burndown Chart Release Burndown Meeting Sprint Planning Meeting Sprinting Sprint Review Sprint Retrospective Sprint Deliverable Release Planning Organisation Development Team Development 10 11

7 Produktvision Projektumfeld Produktvision der kompass für die entwicklung Mit der Produktvision entsteht der Kompass für die Entwicklung des neuen Produkts. Dabei geht der Zeitraum oder Horizont weit über den Abschluss des Scrum-Projektes hinaus und schließt den Produkt-Lebenszyklus mit ein. Es geht darum, den gewünschten wirtschaftlichen Erfolg als Vision und Zielvorstellung zu formulieren und der Frage nachzugehen, wie er erreicht werden kann. Die Verantwortung liegt beim Product Owner. Bei der Erarbeitung der Vision sollten möglichst Kunden und Anwender miteinbezogen werden. Er entwickelt für die Stakeholder des Projekts ein gemeinsames Verständnis für das Projektziel und legt die Rahmenbedingungen fest, die der Vermarktung des Produkts und seinem wirtschaftlichen Erfolg dienen. Dabei geht es um folgende Fragen: Welche Zielgruppe soll angesprochen werden? Worin besteht das Bedürfnis oder der Nutzen des Kunden/der Verbraucher? Worum handelt es sich? Was genau wird angeboten? Welche Alleinstellungsmerkmale hat die Anwendung oder das Produkt gegenüber Mitbewerbern? Wie ist das Geschäftsmodell aufgebaut? Auf welche Weise soll das Geld verdient werden? Die Analyse und das Management des Umfelds und der Stakeholder sind wesentliche Schritte bei der Planung und Umsetzung eines jeden agilen Projekts. Projektumfeld Kein Projekt wird im luftleeren Raum durchgeführt. Projekte werden durch gesetzliche/vertragliche Randbedingungen, personelle/fachliche Belange etc. eingegrenzt. Rechtzeitig die wesentlichen Sachverhalte zu erkennen und zu berücksichtigen hilft, ein erfolgreiches Projekt zu schaffen. Welches Umfeld findet ein Projekt vor? Auf was muss in den folgenden Themengebieten geachtet werden? P Politik - Politisches Umfeld Welche Machtzentren sind zu beachten? Gibt es unterschiedliche Interessensfelder? s Soziologie - Soziologisches Umfeld Sind dem Projekt ethische oder moralische Grenzen gesetzt? Muss auf Stimmungen oder Emotionen der vom Projekt betroffenen Personen geachtet werden? t Technologie - Technologisches Umfeld Sind im Projekt technische Neuerungen zu integrieren? Sind die Technologien erprobt? Müssen Schutz- oder Nutzungsrechte beachtet werden? u Alleinstellungsmerkmal Zielgruppe Produktvision Kundenbedürfnis o Ökonomie - Ökonomisches Umfeld Gibt es wirtschaftliche Begrenzungen? Herausragende wirtschaftliche Interessen? Wettbewerber? Gibt es saisonale oder konjunkturelle Schwankungen zu berücksichtigen? Umwelt - Ökologisches Umfeld Wird mit dem Projekt die Umwelt verschmutzt? Muss sich auf umweltbedingte Vorgaben oder Auflagen eingestellt werden? r geschäftsmodell Beschreibung Recht - Rechtliches Umfeld Welcher Rechtsraum liegt vor? Welche Gesetze und Vorschriften gelten für das Projekt? 12 13

8 Stakeholder Projektumfeld & Stakeholder Stakeholder Stakeholder sind von einem Projekt betroffen oder können Einfluss darauf ausüben. Sie können positiv oder auch negativ eingestellt sein. Es ist daher wichtig, sich einen Eindruck der Stakeholder zu verschaffen, um sich gegebenfalls auf deren Reaktionen einzustellen. Die Stakeholder-Strategie adressiert die Stakeholder im Projekt und bindet sie in die Gestaltung des künftigen Produktes mit ein. Sowohl Scrum Master als auch Poduct Owner sollten sich Gedanken über ihre Stakeholder machen. Was können Beispiele für Stakeholder aus der perspektive des Product Owners und Scrum Masters sein? Die folgenden Schritte müssen durchgeführt werden: 1. Analyse der verschiedenen Stakeholder oder Stakeholdergruppen nach deren Einfluss und Betroffenheit 2. Erarbeitung einer Strategie, wie mit den Stakeholdern im Projekt umgegangen werden kann (Information durch Portal oder Newsletter, Bildung eines Kernteams, Persönlicher Kontakt, Einladung zu Sprint Reviews) Grafik Stakeholderanalyse Betroffenheit hoch III IV I II Aus Perspektive des Product Owners: Kunde, Auftraggeber, Nutzer, Entwickler im Team, Vertrieb und Marketing, Zulieferer etc. Aus Perspektive des Scrum Masters: Alle Personen oder Einheiten, die am Scrum-Projekt beteiligt sind, Unternehmensumfeld, Vorstandsbereich, Vorgesetzte des Entwicklungsteams, Linienorganisation, Personalabteilung, Beschaffung, Betriebsräte etc. In Abhängigkeit der Anordnung der Stakeholder in der Grafik ergibt sich die Klärung der organisatorischen Anbindung an das Projekt und der Stakeholderkommunikation. massnahmen für projektumfeld und Stakeholder Es stehen verschiedene Maßnahmen zur Auswahl. Product Owner und Scrum Master unterliegt hiermit der Gestaltungsspielraum im Umgang mit dem Projektumfeld und den Stakeholdern. Mögliche Maßnahmen können (abhängig von der Größe des agilen Projektes) sein: Für den Product Owner: Teilnahme an den Sprint Planungsmeetings, Teilnahme an den Sprint-Reviews, Bildung eines externen Arbeitskreises, kontinuierliche Information durch Infoletter, Bildung eines Projektportals Für den Scrum Master: Vernetzung im Unternehmen, persönlicher Kontakt zu Schlüsselpersonen im Unternehmen, Bildung eines Arbeitskreises zur Etablierung von Scrum, Erstellung eines Infoportals, Erarbeitung der notwendigen Schritte gemeinsam mit Führungspersonen gering gering hoch Einflussnahme 14 15

9 Scrum-Werkzeuge Product Backlog Produktanforderungen Grafik Product Backlog Zu Beginn des Projektes wird das Product Backlog erstellt. Es ist die zentrale Sammelstelle für die Anforderungen an das Produkt und unterliegt der Verantwortung des Product Owners. Hier konzentriertman sich auf die Nutzergeschichten (User Strories). Dabei handelt es sich um von den Kunden oder Nutzern einer Software in ihrer Sprache ausgedrückte Wünsche und Anforderungen an das Produkt. Das Product Backlog zeigt nicht, welche technischen Schritte notwendig sind, um die Nutzergeschichten und Anforderungen umzusetzen, zu programmieren und zu testen, denn dies erfolgt erst im Sprint Backlog. Ein wichtiges Kriterium ist dabei, diejenigen Einträge zu priorisieren, die den höchsten Geschäftswertbeitrag des neuen Produktes liefern. Alles das führt dazu, dass sich das Product Backlog permanent verändert: Neue Einträge werden priorisiert, nach oben gestellt, gegliedert und in den nächsten Sprints umgesetzt. Einträge, die weiter unten stehen, wandern dann im Laufe der Zeit nach oben. Einträge, die sich erübrigen, können herausfallen. Bei umfangreichen Einträgen mit hohem Entwicklungsaufwand spricht man von Epics. Das Product Backlog: Priorisierung Die Priorität der Einträge fängt oben an und wird absteigend fortgeführt. Je tiefer, desto umfangreicher werden die Storys EPICS: Sehr umfangreiche Storys Umfang und Granularität der einträge Sobald der erste Anforderungskatalog ermittelt ist, werden die Einträge im nächsten Schritt priorisiert, das heißt, nach ihrer Wichtigkeit geordnet. Die Einträge mit der höchsten Priorität kommen an die oberste Stelle, was bedeutet, dass sie in den kommenden Sprint unmittelbar bearbeitet werden. Dazu müssen sie in kleinere Detaileinträge gegliedert werden. Es unterliegt der Verantwortung des Product Owners Es enthält eine Liste der gewünschten Funktionalitäten Es enthält als wesentlichen Bestandteil Nutzergeschichten Es enthält Einträge, die nach Wichtigkeit (Geschäftswertbeitrag) priorisiert und abgeschätzt werden Die höchstprioren Einträge werden im kommenden Sprint bearbeitet Wartung erfolgt nach Maßgabe des Product Owners regelmäßig während der Projektlaufzeit Es unterliegt der konstanten Veränderung und ist das Zentrum agiler Anpassung 16 17

10 Scrum-Werkzeuge Nutzergeschichten Einträge im Product Backlog User stories Wartung des Product Backlog Ein wichtiges Kriterium bei der Erstellung und Gestaltung des Product Backlogs ist die Sichtweise des Kunden oder Endnutzers der Software. Nutzergeschichten geben dem Anwender die Möglichkeit in seiner Sprache auszudrücken, was er sich wünscht. Daher werden die Einträge in der Form der Nutzergeschichten erstellt und in das Backlog eingetragen. Während bei der Einführung von Scrum die technische Umsetzung der Anforderungen noch in das Backlog eingetragen wurde, wird mittlerweile weitgehend darauf verzichtet. Technische Aspekte und Fragen der Umsetzung im Team werden im Sprint Backlog eingetragen (siehe S. 21). Eine Nutzergeschichte besteht aus den Anteilen Rolle, Funktionalität und Geschäftswertbeitrag, also worin der Nutzen oder Mehrwert aus Sicht des Anwenders besteht. Dadurch ist sichergestellt, dass jeder Teilnehmer am Projekt, etwa Kunden, Endnutzer oder auch andere Stakeholder ihre Wünsche ausdrücken können, ohne technische Kenntnisse zu besitzen oder sich fachlich ausdrücken zu müssen. Das Product Backlog sollte in unregelmäßigen Abständen einer Bewertung und Überprüfung unterzogen werden. Das erlaubt, die Einträge im Backlog durchzusehen und daraufhin zu überprüfen, ob sie noch aktuell sind und die Interessen der Stakeholder korrekt wiedergeben. Hierzu eignet sich das sogenannte Backlog Grooming Meeting. Titel der Story Als (Rolle) möchte ich (Funktionalität) so dass (Geschäftswertbeitrag) GröSSe Prio 18 19

11 Scrum-Werkzeuge Schätzklausur Aufwandsschätzung Sprint Backlog Was wird als nächstes bearbeitet? Eine wichtige Grundlage für jede weitere Planung ist die Abschätzung des Product Backlogs. Damit lässt sich ein erster Eindruck vermitteln, welchen Umfang die Arbeiten im Projektverlauf haben könnten. Dabei wird darauf verzichtet, konkrete Vorhersagen zu machen, wie etwa der Aufwand in Arbeitsstunden sein könnte. Vielmehr geht es darum, relative Größen zu ermitteln, das heißt man vergleicht die Größe der einzelnen Einträge untereinander. Die Schätzklausur: Die Schätzklausur erfolgt im Team Jeder Eintrag (Nutzergeschichte) wird abgeschätzt Man beginnt mit den Nutzergeschichten, die geringen Arbeitsumfang erwarten lassen Anschließend werden alle weiteren Einträge mit dem ersten Eintrag verglichen Für die anzuwendende Punktskala empfiehlt sich die Skala nach Fibonacchi: Die Zahlenfolge von Fibonacchi ergibt sich, wenn die vorausgehende Zahl jeweils zur nachfolgenden Zahl addiert wird (1,2,3,5,8,13,21,34). Einträge am oberen Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf geteilt werden. Eine weitere Möglichkeit besteht darin, die Einträge mit Kleidergrößen zu vergleichen. Diese lauten: XXS, XS, S, M, L, XL und XXL. Einträge am unteren Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf geteilt werden. Zu Beginn jedes Sprints werden diejenigen Einträge aus dem Product Backlog ausgewählt, die im kommenden Sprint bearbeitet und in ein auslieferbares (= getestetes, vorzeigbares) Produkt überführt werden sollen. Die Auswahl erfolgt im Sprint Planning Meeting unter Teilnahme des Product Owners, Scrum Masters und des Teams. Das Team entscheidet, wie viele Einträge im kommenden Sprint bearbeitet werden sollen und orientiert sich dabei an der in den vorangegangenen Sprints erarbeiteten Geschwindigkeit (Velocity). Es hat sich dabei als hilfreich erwiesen, das Sprint Backlog als sogenanntes Taskboard an einer gut sichtbaren Stelle im Arbeitsbereich zu platzieren. Das eigentliche Sprint Backlog ist in Form der User Stories in der linken Spalte eingetragen. Daneben stehen die für die jeweilige Story notwendigen Arbeiten (Tasks) so wie das Team sie im Sprint-Planungsmeeting bestimmt hat. Wieder eine Spalte weiter wird aufgeführt, was gerade getan wird und eine Spalte weiter, welche Arbeiten erledigt sind. So lässt sich jederzeit gut visualisieren, wo die Arbeiten gerade stehen. Sollte das Team über verschiedene Standorte verteilt sein, gibt es eine Vielzahl elektronischer Sprint-Backlogs. Der Sprint Backlog: Er ist die Liste der Einträge, die im laufenden Sprint bearbeitet werden sollen Die Einträge werden jeweils aus dem Product Backlog entnommen Er ist eine Beschreibung der technischen Maßnahmen (Tasks) zur Umsetzung und Implementierung (z.b. Design, Architektur, Programmierung, Testing und Refaktorierung) Er unterliegt der Verantwortung des Product Owners und des Scrum- Teams Die Erstellung erfolgt im Sprint Planning Meeting Er wird für alle sichtbar im Büro angebracht Die Wartung und das Update erfolgt im täglichen Scrum Meeting ( Scrum ) 20 21

12 ScruM-werKzeuge SPrinting Sprints sind Entwicklungsintervalle, in denen das Projektergebnis erarbeitet wird. Sie werden in festen Zeiträumen durchgeführt, das heißt, ein Sprint kann zwei, drei oder maximal vier Wochen lange dauern. Diese Zeiträume sollten während des Projekts möglichst nicht verändert werden. Bei komplexen Entwicklungsvorhaben bieten sich kürzere Sprints an, da auf diese Weise schneller gehandelt werden kann, wenn das Projekt nicht in die richtige Richtung läuft. Während des Sprints wird der Sprint-Backlog täglich fortgeführt. Er soll ebenso wie die Sprint- Burndown-Charts an einer gut sichtbaren Stelle angebracht sein. Somit ist jederzeit ersichtlich, wo der Sprint sich gerade befi ndet. SPrint-fortSchrittSdiAgrAMM die ArbeitSgeSchwindigKeit Das Sprint-Fortschrittsdiagramm visualisiert die noch verbleibende Arbeit und zeigt, wo das Team im Sprint steht. Damit lässt sich nach einiger Zeit auch die Arbeitsgeschwindigkeit des Teams ermitteln. Die Gesamtpunktzahl der Nutzergeschichten wird linear über die Anzahl der Arbeitstage bis zum Ende des Sprints eingetragen. Die Ideallinie wird mit dem tatsächlichen Fortschritt verglichen. daily ScruM Meeting 24 Stunden Sollte sich ergeben, dass das Team die geplante Gesamtpunktzahl nach Beendigung des Sprints nicht erarbeiten konnte, wird diese im nächsten Sprint verringert. 2-4 wochen Idealer Burndown von Tag zu Tag Product backlog SPrint backlog Potenziell lieferbares ProduKtinKreMent SuMMe der Aufwände im SPrint backlog Tatsächlicher Burndown 1 12 ArbeitStAg 22 23

13 Scrum-Werkzeuge sprint-fortschrittsdiagramm Diagrammaufbau Es gilt das Done Prinzip Storypoints vollständig erarbeiten Das Sprint-Fortschrittsdiagramm: Es wird gut sichtbar in den Arbeitsräumen angebracht. Hier haben sich einfache Planwände mit Moderationskarten bewährt. Arbeitsgrundlage sind die zu Beginn des Projekts abgeschätzten Aufwendungen für die Umsetzung der Einträge (Nutzergeschichten) Y-Achse: Summe der Aufwände in Story Points (summierter Punktewert aller Einträge im Sprint Backlog) im laufenden Sprint X-Achse: Anzahl der Arbeitstage Die Ideallinie geht von einer linearen Abnahme der Aufwände über die Laufzeit des Sprints aus Der Vergleich der Ideallinie auf täglicher Basis erlaubt eine Beobachtung der Arbeitsgeschwindigkeit (Velocity) des Teams. Anpassung der pro Sprint zu erledigenden Punkte (Story Points) erfolgt aufgrund der Arbeitseffizienz des Teams ( Velocity = Anzahl der pro Arbeitstag erledigten Punkte) Das erlaubt eine genauere Planung der Gesamtdauer des Projektes anhand der Gesamtpunktzahl im Product Backlog Das Sprint Burndownchart zeigt den Punktewert pro Tag. Daraus lässt sich zeitgenau erkennen, wenn das Scrum-Team hinter der Ideallinie zurückbleibt, oder diese ein- oder auch überholen kann. Ein wesentlicher Aspekt bei der Bearbeitung der Sprints ist die Forderung, dass ein Sprint nur dann insgesamt erfolgreich ist, wenn alle Storypoints vollständig erarbeitet sind und im Sprint Review präsentiert werden können. Dabei gelten strenge Anforderungen, die erfüllt werden müssen. Es gilt das Done -Prinzip. Grundsätzlich sollten sich Product Owner und Scrum-Team darauf einigen, was genau im spezifischen Fall dieses Kriterium erfüllt. Man kann sich dabei an folgende Eckpunkte halten. Eine Story respektive ein Sprint kann als 100% Done bezeichnet werden, wenn: das Team alle Anforderungen und Tasks im Sprint Backlog vollständig umgesetzt hat. die Stories auslieferbar sind und den beabsichtigten Mehrwert schaffen. der Code ein gutes Design aufweist, verständlich und refaktoriert ist. Stories, die nicht vollständig umgesetzt sind, wandern zurück ins Backlog und werden gegebenenfalls im nächsten Sprint angegangen

14 Release-Planung Release-Planung Product Backlog als Grundlage Zu Beginn des agilen Projekts sind Planungen in vielen Fällen nur eingeschränkt möglich: Das Product Backlog besteht aus vielen Eintragungen, die subjektiv sind und meist weitgehend angepasst werden müssen Während der Projektlaufzeit kommen neue Einträge hinzu, ältere Einträge erweisen sich möglicherweise als hinfällig und werden gelöscht Die Entwicklungsgeschwindigkeit des Teams um die Einträge umzusetzen ist zu Beginn des Projekts nicht bekannt Die Summe aller abgeschätzten Einträge im Product Backlog lässt eine Releaseplanung zu, sobald die Entwicklungsgeschwindigkeit (Velocity) des Teams bekannt ist. Handelt es sich um ein neu zusammengesetztes Team oder um die erstmalige Durchführung eines Scrum- Projektes im Unternehmen, wird diese im Verlauf des Projektes festgestellt werden können. Release fortschritts- Diagramm arbeitsgeschwindigkeit Mit dem Fortschrittsdiagramm lässt sich der Zeitpunkt des Release ermitteln, sobald die Arbeitsgeschwindigkeit des Teams bekannt und die Gesamtzahl der Einträge im Product Backlog stabil ist. Die Gesamtpunktzahl der Nutzergeschichten wird linear über die Anzahl der Sprints eingetragen. Die Ideallinie wird mit dem tatsächlichen Fortschritt verglichen. Das Release Burndown Diagramm Arbeitsgrundlage sind die zu Beginn des Projekts abgeschätzten Aufwendungen für die Umsetzung der Einträge (Nutzergeschichten) Y-Achse: Summe der Aufwände in Story Points (summierter Punktewert aller Einträge im Product Backlog) X-Achse: Anzahl der Sprints Der Vergleich der Ideallinie auf täglicher Basis erlaubt eine Beobachtung der Arbeitsgeschwindigkeit (Velocity) des Teams. Idealer Burndown von Sprint zu Sprint Summe der Aufwände im Anforderungskatalog Tatsächlicher Burndown 1 12 Sprint 26 27

15 Teil 2 der mensch Soft skills Agile Projekte nach dem Scrum-Verfahren beinhalten eine ganze Reihe von Meetings, die nach festen Schemen ablaufen. Diese Schemata werden nachfolgend inhaltlich dargestellt. Im Anschluss wird gezeigt, worauf es in Bezug auf die weichen Faktoren ankommt, damit die Aufgaben der Führungspersonen (Scrum Master und Product Owner) erfolgreich durchgeführt und abgeschlossen werden können. im Agilen projekt 28 29

16 Meetings besprechungen & Sprint-Vorbereitung Es gelten strenge Regeln. Absolute Pünktlichkeit ist unverzichtbar, ebenso wie Disziplin während der Meetings (z.b. Abschalten der Handys). Meetings Die Vorbereitung des kommenden Sprints dient der Festlegung derjenigen bei agilen Projekten (Scrum) Einträge (Nutzergeschichten) aus dem Product Backlog, die bearbeitet werden Besprechungen finden im Scrum in festgesetzer Abfolge statt. Sie sind außer- sollen sowie der Maßnahmenplanung zur technischen Umsetzung. Bei komplizierteren Vorhaben bietet es sich gegebenendem zeitlich festgelegt (time boxed), was maßgeblich zur Effizienz des Prozesses falls auch an, das Meeting in zwei Teile beiträgt. Dabei darf dieser festgelegte aufzuteilen, in ein Sprint-Planungsmee- Zeitrahmen nicht überschritten werden. Ergeben sich während der Meetings Punkte, die einer genaueren Diskussion bedürfen, so werden diese in einer speziell dafür angesetzten Besprechung unter der Beteiligung derjenigen Personen geklärt, die davon betroffen sind. ting (Auswahl der Nutzergeschichten aus dem Product Backlog, die im nächsten Sprint bearbeitet werden sollen) sowie dem Meeting zur technischen Umsetzung (Bildung der Tasks sowie des Task- Boards). Beide Meetings können gegebenenfalls bei unkomplizierten Inhalten auch zusammengelegt und während einer einzigen Sitzung erledigt werden. Sprint-pLANUNGSMEETING Teilnehmer: Product Owner, evtl. Vertreter des Kunden oder Anwenders, Scrum Master, ausgewählte Mitglieder des Teams Dauer: Bis zu einem halben Tag Moderation: Scrum Master Verantwortlich für die Ziele: Product Owner Ergebnis: Zielbeschreibung und Sprint Backlog des kommenden Sprints Die Anzahl der Nutzergeschichten, die während des Sprints angegangen werden soll, ergibt sich zu Beginn des Projekts aus der Schätzklausur (Story Points), später aus der ermittelten Arbeitseffizienz des Teams (Velocity). Sollten Punkte oder Nutzergeschichten nicht erledigt worden sein, werden die unerledigten Aufgaben im nächsten Sprint angegangen. Außerdem sollte die Gesamtzahl der zu bearbeitenden Nutzergeschichten im nächsten Sprint gegebenenfalls reduziert werden, um Druck aus dem Team zu nehmen und die 100%-ige Erledigung sicherzustellen. Die Auswahl erfolgt durch den Product Owner

17 MeetingS MeetingS zur technischen umsetzung daily ScruM die tägliche AbStiMMung Die Planung des Sprints soll alle Schritte festlegen, die notwendig sind, um ein 100%-iges Arbeitsergebnis abzuliefern. Es gilt das Done Prinzip. Ein Sprint kann nur dann als done (erledigt) verbucht werden, wenn alle User Stories umgesetzt sind. Fehlen Stories oder Teile von Stories, so wird der Sprint insgesamt als nicht erledigt verbucht. Teilnehmer: Scrum Master, Product Owner, Team Dauer: Bis zu einem halben Tag Moderation: Scrum Master Verantwortlich für die Ziele: Team Ergebnis: Tasks zur Umsetzung des Sprint Backlogs, technische Maßnahmen, (Architektur, Coding, Testing, Refaktorierung etc.), Erstellung des Taskboards des kommenden Sprints Tägliches Abstimmungsmeeting während des Sprints Dauer: 15 Minuten, stehend Teilnehmer: Team und Scrum Master Idealerweise morgens mit unbedingter Anwesenheitspflicht und pünktlichem Erscheinen aller Teammitglieder Moderation: Srcum Master Ergebnis: Information aller Mitglieder des Teams über den gegenwärtigen Stand, Probleme, Hindernisse und Verbesserungen SPrint review Das Sprint Review dient der Präsentation der Arbeitsergebnisse des vorangegangenen Sprints. Er steht unter der Leitung des Product Owners. Das Ziel ist es, das Ergebnis durch den Product Owner und verschiedene Stakeholder seiner Wahl abnehmen zu lassen. Dabei können auch andere interessierte Personen teilnehmen, wenn er dem zustimmt. Sollten Erwartungen oder Ziele nicht erreicht worden sein, werden diese gegebenenfalls in das Sprint-Planungsmeeting des nächsten Sprints eingearbeitet. Agendavorschlag: Arbeitsfortschritt des Vortages Probleme und Hindernisse (Impediments), etwa durch Lärm, Ausfall der Server, Beeinfl ussungsversuche von außen etc. Planung des gegenwärtigen Tages Action items der Bearbeitung der Problempunkte durch den Scrum Master Dauer: Eine Stunde Teilnehmer: Product Owner, Stakeholder, Auftraggeber und Nutzer, Linienverantwortliche Moderation: Product Owner Ergebnis: Abnahme des Sprint-Ergebnisses durch den Product Owner sowie gegebenenfalls weitere durch ihn ausgewählte Stakeholder (Nutzer, Vertreter der Auftraggeber und Auftragnehmer etc.) 32 33

18 Meetings Sprint retrospective Soft skills und Anwendungsmodelle aspekte der teambildung Der Sprint Retrospective dient der Verbesserung der Produktivität des Teams und der Prozesse während der Sprints. Das Meeting wird im Anschluss an das Sprint Review durchgeführt. Dabei wird der abgelaufene Sprint daraufhin überprüft, inwieweit der Ablauf störungsfrei war und was für künftige Sprints verbessert werden kann. Teilnehmer: Scrum Master und Team Moderation durch den Scrum Master Dauer: Maximal zwei Stunden Ergebnis: Reflektion des vorangegangenen Sprints und Klärung der Frage, wie es gelaufen ist und wo Verbesserungsmöglichkeiten bestehen. Dabei bietet sich folgende Agenda an: Anerkennung der Agenda durch Abstimmung (Handzeichen) Erstellung einer Timeline des vergangenen Sprints mit Post-It-Karten Anschließende Markierung spezifischer Punkte auf der Timeline mit Positiv- und Deltakarten Diskussion der Ergebnisse der Markierungen Identifikation durchzuführender Änderungen und Verbesserungen respektive Abstellung von Hindernissen für den nächsten Sprint (Infrastruktur, Störungsversuche von außen, Verbesserungen im Team etc.) Benennung von Maßnahmen (Action items), verantwortlichen Personen und Zeitpunkten zur Erledigung Das GRPI-Modell ist ein Vorgehensmodell zur Steigerung der Effektivität der Teamentwicklung und zur Verbesserung des Managements insgesamt. Der Erfolg eines agilen Projekts hängt überwiegend von den Soft Skills der Beteiligten und den weichen Faktoren des Projekts ab. Das GRPI-Modell erlaubt, diese gezielt einzusetzen: G - Goals (Ziele und Zielvermittlung) R - Roles (Rollenfestlegung und -beschreibung wer ist wofür zuständig) P - Processes (welche Prozesse finden statt, wie sind die Abläufe) I - Interpersonal (wie steht es um die zwischenmenschlichen Beziehungen) 34 35

19 Soft skills und Anwendungsmodelle Goals zielentwicklung Interpersonal Zwischenmenschliches Ziele müssen entwickelt und vermittelt werden. Sobald die Produktvision erarbeitet und die erste Version des Product Backlog erstellt ist, sollte das Team in vollem Umfang über die geplanten Projektziele informiert werden. Dies gilt auch für das Umfeld und die Stakeholder. Projekte geraten häufig in Schieflage, weil nicht Roles Rollenfestlegung Es wird festgelegt, wer welche Aufgaben hat und wofür er zuständig ist. In einem Scrumprojekt legt das Programmierteam untereinander fest, wer welche Aufgaben übernimmt. Bei Konflikten ist der Scrum Master gefragt. Der Product Owner sollte Processes Prozesse Ein wichtiger Bestandteil ist die Klarstellung, dass Scrum den Arbeitsrahmen darstellt und damit die Regeln und Abläufe vorgibt. Sie müssen eingehalten werden, damit das Vorgehensmodell alle Beteiligten wissen, was geplant ist oder weil Geplantes nicht kommuniziert wird. Daher sollten sowohl Scrum Master als auch Product Owner in ihrem jeweiligen Umfeld sicherstellen, dass die Teams in der Lage sind, auf das gemeinsame Ziel zuzusteuern. entsprechend vorgehen, sowohl in Bezug auf das Stakeholder-Umfeld als auch in Bezug auf jenen Teil, bei dem er sich nach Abschluss des Projektes um die Vermarktung kümmert. auch funktioniert. Um das zu gewährleisten, müssen sie entsprechend kommuniziert und untereinander vereinbart werden (siehe oben). Zwischenmenschliche Beziehungen sind durch die Fähigkeit geprägt miteinander zu kommunizieren, sich aufeinander einzustellen und in den anderen hineinversetzen zu können. Eine wichtige Hilfe gibt das Sender-Empfänger-Prinzip der Kommunikationslehre: Grundsätzlich besteht jede Kommunikation darin, dass Botschaften gesendet und empfangen werden. Auch besagt das Modell, dass es nicht möglich ist, nicht zu kommunizieren. Denn auch ein Abbruch oder die Verweigerung jedweden Kontaktes sendet ein Signal. Beim Austausch von Inhalten gibt es Verantwortlichkeiten: a) Verantwortungen des Senders: Sicherstellen, dass die Botschaft richtig angekommen ist durch Nachfragen. Gegebenenfalls wiederholen lassen b) Verantwortung des Empfängers: Sicherstellen, dass alles richtig verstanden wurde. Möglichkeiten sind: Botschaft in eigenen Worten wiederholen oder ebenfalls nachfragen, um sicherzustellen, dass alles verstanden wurde. Ein wesentliches Element der Arbeit eines Scrum Masters und Product Owners ist die Kenntnis, welche Stadien Teams durchlaufen, bis die Team-Mitglieder optimal aufeinander abgestimmt sind. Es gehört zu den Aufgaben, zu erkennen, wenn es Probleme gibt und falls dem so ist, das Team durch die verschiedenen Phasen zu leiten. Agile Teams sind interdisziplinär (Cross-Functional), das heißt, alle wesentlichen technischen Kompetenzen sind vorhanden, um das Projekt optimal bearbeiten zu können. Das Team sollte möglichst während der Projektlaufzeit beisammen bleiben, Mitglieder sollten nicht ausgetauscht werden. Dies ist notwendig, um ein sog. performing Team zu erhalten und eine möglichst optimale Velocity zu erreichen (siehe erster Teil des Agile Guide). Dabei obliegt die Verantwortung für das Programmierteam beim Scrum Master, während der Product Owner sich um das Management der Stakeholder kümmert. Handelt es sich um ein großes Scrum-Projekt, können verschiedene Teams unter der Leitung verschiedener Product Owner arbeiten, die Gesamtverantwortung trägt in diesen Fällen der übergeordnete Product Owner

20 Soft SKillS und AnwendungSModelle die StAdien im einzelnen: 1. Schritt Forming Das interdisziplinäre (Cross-functional) agile Team wird durch den Scrum Master in Abstimmung mit der Stammorganisation und gegebenenfalls dem Product Owner gebildet. Es sollen alle Kompetenzen und Kenntnisse für die Bewältigung des Projektes vorhanden sein. In diesem Stadium treffen sich die Teammitglieder zu Beginn des Projekts. Möglicherweise kennt man sich bereits von vergangenen Projekten oder im Unternehmen, möglicherweise kommen neue Mitglieder hinzu. 2. Schritt Storming Ab jetzt ist es die Aufgabe des Scrum Masters, ein potenzielles Chaos frühzeitig zu verhindern. Hierfür bietet sich ein Teambildungsworkshop an. Alle formellen Belange des agilen Projekts können hier thematisiert werden. Es soll aber auch genügend Raum für soziale (informelle) Belange des Teams (Kennenlernen, Teamentwicklung, Wertschätzung für erbrachte Leistungen etc.) vorhanden sein. Möglicherweise ist in dieser Phase auch die Kompetenz des Scrum Masters gefragt, mit Konfl ikten umgehen zu können und zu schlichten oder als Mediator tätig zu werden. Durch Identifi zierung mit dem Projekt und teambildende Maßnahmen soll die tägliche Arbeit zunehmend verbessert werden. Aber auch jetzt können noch Konfl ikte auftauchen, die wie in der Storming-Phase angegangen werden müssen. 3. Schritt Norming In dieser Phase nimmt die mögliche Frequenz der Konfl ikte im Team ab, man beginnt, sich aufeinander einzustellen. Aus verschiedenen Team-Mitgliedern muss schnell ein performing Team werden! Die Identität des Teams ist auf das Projekt ausgerichtet und geschaffen. 4. Schritt Performing Im Performing team kann sich jeder auf jeden verlassen, Aufgaben und Rollen sind klar und bedürfen keiner Diskussion. In dieser Phase organisiert sich das Team selber, der Scrum Master kann sich um andere Belange kümmern (etwa der Förderung von Scrum im Unternehmen oder der Bewältigung von Konfl ikten mit der Linienorganisation). Die Velocity bei der Bearbeitung der Sprints hat einen relativ stabilen und vorhersagbaren Wert erreicht (Bearbeitung einer bestimmten Anzahl von Storypoints pro Sprint). Wichtig ist es jetzt, das Team nicht auseinanderzureißen oder Teammitglieder auszutauschen, da ansonsten möglicherweise frühere Phasen erneut durchlaufen werden müssen. Etwaige Versuche aus der Linie, in die Teamzusammensetzung einzugreifen werden als Störungen bewertet und müssen vom Scrum Master angegangen werden. MotivAtion die Motive Kennen So unterschiedlich wie die fachlichen Qualifi kationen sind auch die Motivationen (Beweggründe) der Mitarbeiter. In einem Scrum-Projekt ist der Erfolg im wesentlichen von einem funktionierenden Team abhängig. Hier ist wiederum der Scrum Master gefragt. Da er keinen disziplinarischen Zugriff auf die Mitarbeiter hat, stehen ihm weitgehend nur positive Motivatoren zur Verfügung. Grundsätzlich sind für negativ wirkende Motivatoren (Drohungen, Abmahnungen etc.) nur die Linienvorgesetzten in der Verantwortung. Generell müssen die Motivationsmatrix und die beiden Grundcharaktere ( hin-zu und weg-von ) für die Motivation beachtet werden. Drohung Gewaltanwendung, i.d.r subtil Hass Angst, Furcht Neid Gier, Habsucht Geiz Zorn, Jähzorn Völlerei, Maßlosigkeit Missgunst... extrinsisch Vorleben Lob Anerkennung Belohnung Liebe Mut, Selbstbewusstsein Erfolg gönnen Bescheidenheit Freigiebigkeit Selbstbeherrschung Disziplin Leidenschaft... intrinsisch 38 39

21 Soft skills und Anwendungsmodelle Konfliktmanagement Die Konfliktspirale Das Hauptanliegen aller Beteiligter (Scrum-Team, Scrum Master, Product Owner) sollte stets sein, Konflikte gar nicht erst aufkommen zu lassen. Dies wird durch das Stakeholder-Management sowie die Befolgung der Regeln des agilen Frameworks ermöglicht. Es muss sichergestellt werden, dass die Meetings und Besprechungen zeitgenau eingehalten und durchgeführt werden. Sind Konflikte entstanden, müssen diese so schnell wie möglich angegangen werden. Die Verantwortung liegt grundsätzlich bei jedem Beteiligten. Kommen Konflikte auf, bestehen verschiedene Möglichkeiten, diese auszuräumen: a) Die Beteiligten sprechen sich aus b) Der Scrum Master oder Product Owner handelt als Mediator c) Ein externer Berater und Moderator wird hinzugezogen d) Eskalation auf eine höhere Ebene im Unternehmen Eine Orientierungshilfe, die beim Umgang mit Konflikten gute Dienste leisten kann, stellt das folgende BALU-Vorgehen dar: Es strukturiert den Umgang mit einem Konflikt klar und hilft so, mögliche Lösungen zu finden. Bemerken eines Konfliktes Ansprechen des Konfliktes Lösungen finden Umsetzen des Lösungsvorschlages Im nächsten Schritt kann die folgende Checkliste weiterhelfen, den Konflikt zu bewältigen: Habe ich die richtigen Konfliktpartner identifiziert? Habe ich Profile der Konfliktpartner erstellt? Habe ich die Konfliktpartner im Organigramm festgelegt? Habe ich den Konflikt in der Konfliktspirale eingeordnet? Habe ich den 10-Punkteplan zur Konfliktbewältigung beachtet? Habe ich mir qualifizierten Rat eingeholt (Betriebsrat, Betriebsarzt, Betriebspsychologe, Mediator, Schlichter, Jurist, Fachvorgesetzter, Lenkungsausschuss etc.)? Habe ich den Konflikt an den richtigen Adressaten gerichtet, weitergeleitet bzw. eskaliert? Feindseligekeit Entfremdung Schuldzuweisung VerÄrgerung Verwirrung MissverstÄndnis Der 10-Punkteplan 1. Konflikt erkennen 2. Konfliktpartner identifizieren 3. Konflikt thematisieren 4. Konflikt analysieren 5. Konfliktargumente visualisieren 6. Konflikt einordnen (Ebende des Konflikts, emotional oder sachlich?) 7. Konflikt von der emotionalen auf die sachliche Ebene bringen 8. Konflikt strukturieren 9. Lösungsalternativen sammeln, bewerten, auswählen, umsetzen 10. Konflikt für neue Wege nutzen 40 41

22 KAnbAn teil 3 weitere Agile Methoden KAnbAn Kanban ist eine Methode zur Produktionsablaufsteuerung, die ihren Ursprung im Toyota-Produktionssystem (TPS) hat. Der Begriff Kanban stammt aus dem Japanischen und bedeutet Signalkarte. Eine Kanban-Karte beinhaltet alle für die Mitarbeiter notwendigen Informationen. Dies sind im wesentlichen Kanbanart, Kanban-ID, Karten-Anzahl, Artikelnummer, Artikel-Text, Menge, Lieferant, Lagerort (Quelle), Lagerort (Ziel), Empfänger, Barcodes und Produktbild. Ziele der Kanban-Methode sind die Verbesserung der Produktivität, der Qualität und die Optimierung der Flexibilität innerhalb der Produktion. Diese Ziele sollen durch die Vermeidung von Verschwendung und von Fehlern erreicht werden. Verschwendung bedeutet hierbei Arbeit, die dem Produkt keinen Wertzuwachs bringt, Überlastung von Mitarbeitern und Maschinen und Unregelmäßigkeiten von Prozessen. Überproduktion gilt ebenfalls als Verschwendung und ist zu vermeiden. Mit Verschwendung ist hier gemeint, dass die produzierten, aber aktuell nicht benötigten Produkte Lagerplatz beanspruchen und Kapital binden, das dem Unternehmen somit nicht für andere möglicherweise wichtigere Aufgaben zur Verfügung steht. Das Kanban-Prinzip beschreibt im Wesentlichen die Vorgehensweise der Versorgung der einzelnen Produktionsschritte mit den benötigten Materialien und deren Beschaffung. Es enthält alle Informationen, die benötigt werden, um die Versorgung mit den benötigten Gütern anzustoßen. Dabei wandert die Kanban-Karte zwischen Lieferanten- und Kundenprozess hin und her. Der Materialfl uss ist hierbei vorwärts gerichtet (vom Lieferanten zum Kunden). Der Informationsfl uss ist rückwärts gerichtet (vom Kunden zum Lieferanten). Deshalb wird die Kanban-Methode auch als Pull-Prinzip (Hol-Prinzip) bezeichnet. Das Pull-Prinzip ist ein System zur Steuerung von Prozessabläufen, bei dem die Aufträge durch die Fertigung durchgezogen werden. Der Impuls zur Durchführung eines Auftrags geht vom Ende der logistischen Kette aus (nachfrageorientierte Produktionssteuerung)

23 Kanban Kanban in it-projekten Die Prinzipien von Kanban entstammen dem Produktionsprozess und konnten so nicht für IT-Projekte übernommen werden. Stattdessen wurden die Prinzipien aus Lean Production, Lean Development und der Theory of constraints kombiniert. Lean Production (schlanke Fertigung) ist Bestandteil des Lean Mangament-Konzepts. Darunter versteht man den sparsamen und zeiteffizienten Einsatz von Produktionsfaktoren (Mensch, Maschine etc.). Lean Development (schlanke Entwicklung) überträgt das Management-Konzept der Lean Production und des Lean Managements auf den Bereich der Softwareentwicklung. Theory of constraints (Engpasstheorie), geht davon aus, dass die Leistungsfähigkeit eines System ausschließlich von einem Faktor, dem Engpass, begrenzt wird. Eine Verbesserung der Leistungsfähigkeit kann nur erfolgen, wenn das Gesamtsystem ausgehend vom Engpass angepasst wird. Kanban kennt keine Iterationen sondern setzt auf einen kontinuierlichen Bearbeitungsfluss. Dazu wird die Wertschöpfungskette visualisiert und der Work-in-Progress (WiP) begrenzt. Visualisierung der Wertschöpfungskette Die Wertschöpfungskette wird für die Beteiligten mit Hilfe eines Kanban-Boards (z.b. großes Whiteboard aber auch in elektronischer Form) dargestellt. Das Board listet die einzelnen Prozessschritte (z.b. Requirement, Design, Implementation, Test etc.) in Spaltenform. Die einzelnen Aufgaben (Tasks) werden auf Karteikarten oder Post-its notiert und zeilenweise auf das Board geklebt (bzw. über entsprechende Symbole in der elektronischen Kanban-Anwendung dargestellt). Häufig kommen auch Kombinationen zum Einsatz, bei dem das Kanban-Board mit einer Kamera auf Veränderungen hin überwacht wird. Die Aufgaben/Anforderungen können als User Story, Feature, Use Case etc. formuliert sein. Die User Story beschreibt die Aktivität eines Nutzers mit einem System, wobei die Frage, wer was tut um welches Ziel zu erreichen, im Vordergrund steht. Ein Feature beschreibt ein Leistungsmerkmal, eine Funktion (z.b. Druckausgabe) einer Softwareapplikation. Ein Use Case gibt in Form eines beschreibenden Textes den Anwendungsfall wieder. Eine graphische Modellierung des Anwendungsfalls mit Hilfe der Unified Modeling Language kann ergänzend eingesetzt werden und hilfreich sein. Entsprechend dem Pull-Prinzip der Lean Production holt der Bearbeiter für den jeweils nachfolgenden Arbeitsschritt die abgeschlossene Aufgabe des vorhergehenden Arbeitsschritts. Durch diese Art Bearbeitung wandern Karteikarten/Post-its auf dem Kanban- Board von links nach rechts, bis die einzelnen Tasks abgeschlossen sind. Für die Gestaltung des Kanban-Boards gibt es keine Vorschriften, es kann frei an die individuellen Team-Bedürfnisse angepasst werden

24 KAnbAn begrenzung des wip Backlog Requirements WiP Done Design WiP Done Implementation WiP Test Done Done Das Kanban-Board schafft Transparenz und ermöglicht das rasche Identifizieren von Engpässen. Im Beispiel ist der Engpass die Implementierung (Implementation), da die vom Design abgeschlossenen Themen nicht mit der gleichen Geschwindigkeit umgesetzt werden. Dadurch ist ein gleichmäßiger Bearbeitungsfluss nicht mehr gegeben. Backlog Requirements Implementation Test Done Done WiP (2) Done WiP Done Design WiP Abhilfe kann die Limitierung des Workin-Progress im Design schaffen. Eine Begrenzung des WiP im Bereich des Design auf zwei bedeutet, dass in der Spalte WiP nur zwei Karten angebracht werden dürfen. Damit soll sichergestellt werden, dass in einem Bearbeitungsschritt nicht mehr Ergebnisse entstehen, als weiterverarbeitet werden können

25 KAnbAn ScruM vs.kanban gemeinsamkeiten Vorneweg: Kanban ist weniger umfangreich reguliert als Scrum. unterschiede Scrum und Kanban setzen beide auf: Transparenz und Visualisierung mittels entsprechender Boards, um Prozesse zu verbessern agiles Vorgehen häufi ge und frühzeitige Auslieferung von releasefähigen Softwarekomponenten Verwendung eines Pull-Prinzips Begrenzung der gleichzeitigen Bearbeitung von Themen (Work-in-Progress) sich selbst organisierende Teams das Zerlegen von Anforderungen in detaillierte Einzelschritte wenige Regeln. Scrum Scrum kennt drei Rollen (Product Owner, Scrum Master, Team). Der WiP wird indirekt begrenzt (per Sprint). Eine Schätzung ist vorgeschrieben. Das Scrum-Task-Board wird vor jedem Sprint zurückgesetzt. Das Backlog ist priorisiert. Das Sprint Backlog gehört einem spezifi - schen Team. Einem Sprint können keine weiteren Tasks/ Items hinzugefügt werden. Das Burndown-Diagramm ist vorgeschrieben. Items müssen so aufgegliedert werden, dass sie in einem Sprint erledigt werden können. Es gibt Team commits zu einem defi nierten Arbeitsvolumen im Rahmen des Sprint Planning. Es sind zeitlich begrenzte Iterationen vorgeschrieben. Kanban Kanban defi niert keine Rollen. Bei Bedarf können Rollen projekt-individuell durch die Beteiligten defi niert werden. Der WiP wird direkt begrenzt (pro Prozessschritt). Eine Schätzung ist optional. Das Kanban-Board wird kontinuierlich gepfl egt. Die Priorisierung der Anforderungen ist optional. Das Kanban-Board kann von mehreren Teams/Einzelpersonen genutzt werden. Neue Tasks können bei verfügbarer Kapazität aufgenommen werden. Es ist kein besonderer Diagramm-Typ vorgeschrieben. Es ist keine vorgeschriebene Größe für Items defi niert. Ein Commitment ist optional. Zeitlich begrenzte Iterationen sind optional. Es kann stattdessen ereignisgesteuert (event-driven) sein. Es können unterschiedliche Metriken (Mischformen zeitlich fi xiert und ereignisgesteuert) für Planung, Release und Verbesserungsprozess zum Einsatz kommen. Scrum verwendet die Geschwindigkeit als Maßstab für die Planung und Verbesserungsprozesse. Kanban verwendet die Vorlaufzeit als Maßstab für die Planung und Verbesserungsprozesse

26 Extreme Programming Extreme Programming (XP) Principles (die Prinzipien) XP basiert auf Prinzipien, die sich aus den Werten ableiten. Die einzelnen Prinzipien dienen dem Grundverständnis von XP. XP ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund stellt und dabei einem formalisierten Vorgehen geringe Bedeutung beimisst. Mit dieser Methode nähert man sich den Kundenanforderungen in kleinen Schritten an. Es hat seinen Ursprung im Projekt Comprehensive compensation system des eh gen Daimler Chrysler Konzerns. In diesem Projekt wurde das agile Vorgehensmodell für die Erstellung Values (die Werte) Communication Alle Projektmitglieder sollen möglichst direkt miteinander kommunizieren. Dadurch lassen sich Missverständnisse schneller ausräumen und Fragen können schneller und gezielter beantwortet werden. Courage (Mut) Sich an Werten zu orientieren und die dabei praktizierte, offene und direkte Kommunikation erfordern Mut. Eine kontinuierliche Anpassung an Veränderungen und die Reduzierung der Kundenanforderungen an das Wesentliche sind besonders für die Projektbeteiligten, die das Handeln nach diesen Werten nicht gewohnt sind, eine Herausforderung. von Software entwickelt. Diese agile Arbeitsmethode basiert auf den Werten der Einfachheit, Kommunikation, Feedback, Mut und Respekt. Neben den Values (Werten) kennt XP auch Principles (Prinzipien) und Practices (Techniken). Ähnlich Scrum kennt XP auch Rollen. Diese sind im Wesentlichen der Kunde (Auftraggeber), der Product Owner (intern, häufig Projektmanager) und das Entwickler-Team. Feedback Durch das direkte, zeitnahe und kontinuierliche Kundenfeedback lässt sich die Qualität des Produktes verbessern. Eine mögliche Fehlentwicklung kann schnell erkannt und gebannt werden. Der Kunde bekommt das Produkt, das er benötigt. Respect Der Kunde respektiert das Know-how der Entwickler und umgekehrt. Jeder gibt und erfährt den Respekt und die Wertschätzung, die jedes Projektmitglied verdient. Accepted Responsibility (Verantwortung übernehmen) Verantwortung wird nicht delegiert oder zugewiesen, sondern angenommen. Dadurch identifiziert der Zuständige sich deutlich stärker mit seiner Aufgabe. Assume Simplicity (Einfachheit anstreben) Einfache Lösungen sind schneller zu implementieren, kostengünstiger und lassen sich einfacher verstehen und warten. Je niedriger der Komplexitätsgrad einer Lösung, desto einfacher kann Feedback gegeben werden. Concrete Experiments (Gezielte Experimente) Um potenzielle Risiken zu reduzieren, werden Entscheidungen durch zielgerichtete Experimente untermauert. Embracing Change (Veränderung wollen) Die Projektbeteiligten zeigen sich Veränderungen gegenüber aufgeschlossen und unvoreingenommen. Honest Measurement (Ehrliches Messen) Für die Lenkung des Projekts und den Projektfortschritt sind Messungen erforderlich. Diese sind von den Projektbeteiligten transparent, ehrlich und nachvollziehbar durchzuführen. Incremental Change (Inkrementelle Veränderung) Veränderungen sollten in kleinen Einheiten vorgenommen werden. Diese sind leichter nachvollziehbar und weniger komplex und abhängigkeitsbehaftet (Dependencies) als umfangreiche Änderungen. Local Adaptions (An örtliche Gegebenheiten anpassen) XP wird an die lokalen Bedürfnisse und Gegebenheiten angepasst. Open, honest communication (Offene, aufrichtige Kommunikation) Die Projektmitglieder praktizieren aktiv eine ehrliche, offene und direkte Kommunikation. Simplicity (Einfachheit) Einfache Lösungen lassen sich schneller implementieren als komplexe Lösungen und sind in aller Regel kostengünstiger. Deshalb wird immer versucht, die einfacheren Lösungen zu finden