Agiles PM: Einführung Flashcards
VUCA
Volatility = Volatilität (Schwankung von Preise, Zinsen,…)
aufgrund sich ändernde Kundenanforderungen
Uncertainty = Unsicherheit
aufgrund plötzliche Änderungen von Vorschriften
Complexity = Komplexität
aufgrund global verteilter Informationen
Ambiguity = Mehrdeutigkeit
aufgrund widersprüchlicher Ziele in verschiedenen Teilen eines Unternehmens
aus VUCA entstehende Anforderungen an die Organisation
- Trial and error mind set
- schnelle Feedback Integration
- Bereitschaft zu lernen und zu verbessern
- mentale und Verhaltensmässige Flexibilität
- Klare Kommunikation
- Kunde hat totale Priorität
- Fähigkeit Risiken zu erkennen und einzugehen
- delegierte Führung
- verhärtete Strukturen aufbrechen
–> Agil ist die beste Lösung
Klassische Organisation vs. Agile Organisation
- sind oft gut darin ihr bestehendes Geschäftsmodell zu betreiben
- reagiert aber langsam auf Veränderungen in den Märkten –> zu langsam für Innovation neuer Produkte oder Geschäftsmodelle
- zeichnen sich durch klassische Strukturen aus, z.B. viele Management-Ebenen
- viel Bürokratie –> Verlangsamung der Organisation
- haben weniger Risikobereitschaft da sie die Cash Cow schützen möchten
Agile Organisation
- anpassungsfähiger
- ist innovativ
- sucht schnell nach Lösungen –> Wettbewerbsvorteil
Agile transformation
= grosser Wandel
- essentiell um eine agile Organisation zu schaffen, die in der Lage ist, sich neu zu erfinden
Unterschied Agiles & Klassisches PM
Klassisches:
- alle Anforderungen im Voraus definieren
- verbindliche Vereinbarung über den Umfang zu einem frühen Zeitpunkt
- Handhabung von Umstandsänderungen durch formale Prozesse mit hoher Rigidität
Agiles:
- Verfeinerung des Umfangs auf sich weiterentwickelnder Basis
- regelmässige Priorisierung durch den Product Owner auf der Grundlage von häufigem Kundenfeedback
- Umfangsänderung als Spiegelbild der Realität als normal zu betrachten
Agiles Ökosystem
- Individuen und Interaktionen über Prozesse und Werkzeuge
- Arbeitende Software über verständlicher Dokumentation
- Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
- auf Wandel reagieren über Befolgen eines Plans
Geschichte des Agilen Projektmanagements
1950: Deming Circle wird in Japan vorgestellt
1950-70: Entwicklung Toyota Production System
1990: Japanische Industrie wächst stark
1994: Agility wird in einem Buch definiert
1994: Dynamic System Development Method (DSDM)
1995: Scrum
1996:
??????
Agile Methoden
- Scrum
- Hybrid
- ScrumBan
- Scrum/XP Hybrid
- Kanban
- Iterative
- Andere
Häufig genutzte Scrum Elemente in Unternehmen
- Daily StandUp
- Sprint/ Iterationsplanung
- Retrospektiven
- Sprint/ Iteration Review
- Kurze Iterationen
Herausforderungen Agiles Ökosystem
- Agil und traditionell zu balancieren
- geteilte Verantwortung
- selbst-managende Teams
- Silo Mentalität (schwer existierende organisatorische Silos aufzubrechen)
Doing Agile vs. Being Agile
Doing Agile: Agile Methoden und Tools –> Erleichterung und Unterstützung bei der Einführung einer neuen Art der Arbeit und Zusammenarbeit
Being Agile: Mindset Shift in Richtung Kundenorientierung, Teamfokus, Selbstorganisation, Selbstständigkeit/ Verantwortung, Transparenz
Führungspersonen müssen Arbeitsbedingungen für Umsatz schaffen!!!
Einführung von Agile in einer Organisation
Mind shift von Oganisation bis hin zu einzelnen Teams
- Organisationskultur
- Leadership
- Team und Kompetenzen
Organisationskultur
- Offen für Innovation, kontinuierliche Verbesserung und Feedback
- Fehlertoleranz
- proaktives Konfliktmanagement
- Transparenz
Leadership
- neue Rollen leben
- Verantwortung verteilen
- Kreativität und Innovation fördern
- Silos aufbrechen um Netzwerke zu schaffen
- Team zu Selbstorganisation coachenT
Team & Kompetenzen
- geforderte Werte leben
- Verantwortung für Entscheidungen übernehmen
- sich bei allen Handlungen auf die Bedürfnisse des Kunden konzentrieren
Einführung Agile Vorteile
- Engagement
- Innovation und Kreativität
- Continuous Learning
- Motivation
- Kundenzufriedenheit
Was macht ein High-Performing Agile Team aus?
- Verhalten (Testen und Lernen und Zusammenarbeit)
- Skills (Persönliches Skillset, organisatorische Fähigkeiten)
- Einstellung/ Attitude (akzeptieren Fehler, offen für Veränderungen)
Wann funktionieren agile Teams am Besten?
Wenn sie funktionsübergreifend, hierarchieübergreifend und nach Stärken und Fähigkeiten zusammengestellt sind
Zusammenspiel Design Thinking, Lean Startup und Scrum
Konzept eines Lean Startups
Def.: Folgt
Ziel: schnelle, positive und kundenfokussierte Ergebnisse durch ein Prototyp oder MVP (Minimum Viable Product)
Zyklus: Build - Measure - Learn
- Kundeninteraktion ist aktiv und messbar, wird für die Verbesserung des MVPs genutzt
–> besser angepasstes Produkt für den Zielmarkt nach jeden Zyklus
Was sollte ein MVP (Minimum Viable Product) beinhalten?
- wünschenswert (will der Kunde es?)
- realisierbar (nachhaltig gestaltbar und wirtschaftlich sinnvoll?)
- durchführbar (technisch umsetzbar?)
Muss gerade genug Kernfunktionen aufweisen, um Menschen (Early Adopters) anzulocken.
Scrum Überblick
- Rollen
- Ceremonies
- Artifacts
Scrum Roles
- 3 Rollen
- agiles Projekt nur erfolgreich wenn alle ihre Rollen erfüllen und eng zusammenarbeiten
Scrum Master:
- treibt den Prozess an und hilft dem Team sich selbst zu managen
- schützt den Scrum-Prozess und verhindert Ablenkungen
Product Owner:
- verantwortlich und rechenschaftspflichtig für Vision, Business Case, Produkt- und Stakeholder-Management
Development Team
- verantwortlich für Entwurf und Implementierung der Lösung
Product Owner genauer
- eine Person
- Beauftragter Vertreter des Unternehmens
- Verantwortlich für die Vision und Product Backlog (priorisierte Liste von Elementen)
-versteht und bestellt Backlog Items (PBI’s) - verfolgt Fortschritt, Wert, ROI und Total-Cost-of-Ownership (TCO)
- überprüft funktionsfähige Software
- Autorität über die Anforderungen, nicht über Schätzungen oder Mitarbeiter
- Sicherstellung, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht
- nur der PO kann einen Sprint beenden
Development Team genauer
- 3-9 selbstorganisierte Personen (empfohlen)
- besteht nicht nur aus Entwicklern
- funktionsübergreifend (keine Titel, nur Fähigkeiten)
- gemeinsame Verantwortlichkeit für die Umsetzung von PBIs in Inkremente von potentiell lieferbarer Software
- gegen die Definition von Fertigstellung
- ermächtigt und selbstorganisiert für die technische Umsetzung
- kollektive Pflegung des Codes
- Autorität über die PBI-Schätzungen, das Sprint Backlog und die Mitarbeiter
- Entwicklungsteam überwacht den Fortschritt in Richtung Sprint-Ziel
Scrum Ceremonies
- Time-box
- Sprint Planning
- Daily Scrum
- Sprint Review
- (Sprint) Retrospective
Time-box
- feste Zeitspanne mit fokussierter Arbeit
- Änderungen werden nur dann vorgenommen wenn eine Time-Box abgeschlossen ist
- Dauer der Time-Box sollte vereinbart und festgelegt werden (Dauer kann auf Grundlage gemachter Erfahrungen geändert werden)
Don’t: Viel zu tun –> Dauer verlängern
Do: Erfahrung –> wir wissen, dass wir das schaffen können
Sprint Planning
- time boxed (8h für 4 wöchigen Sprint)
- gesamtes Scrum Team nimmt teil
- 1) Was kann in dem Sprint erledigt werden? (Development Team zieht Aufgaben aus dem Product Backlog
- 2) Wie wird die Arbeit verrichtet? (Development diskutiert, designt und identifiziert Arbeitsaufgaben, plant das Sprint Backlog)
Daily Scrum
- time boxed (maximal 15min)
- Dev Team anwesend, Scrum Master und Product Owner optional
- Überprüfung der Arbeit seit dem letzten Treffen, Synchronisierung der Arbeit und Planung für die nächsten 24h
- jedes Teammitglied beantwortet 3 Fragen:
1) was habe ich seit dem letzten Daily Scrum erreicht
2) was ist meine vorraussichtliche Arbeit bis zum nächsten Daily Scrum
3) Welche Hindernisse stehen mir im Weg
(Sprint) Retrospective
- time boxed (3 Stunden für 4 Wochen Sprint)
- Überprüfen von Menschen, Beziehungen, Freude, Prozessen und Tools
- Identifizierung von Verbesserungen für den nächsten Sprint
- Geschwindigkeit prüfen
- Überprüfen der Produktqualität und der Definition von Fertigstellung
Sprint Review
- time boxed (4 Stunden für 4 Wochen Sprint)
- gemeinsame Arbeitssitzung mit Stakeholdern
- release-Plan, voraussichtliche Funktionalität und Termin werden geprüft
- Präsentation und Inspektion der “Done” Elemente (das Inkrement) aus dem aktuellen Sprint und Anpassung des Product Backlogs
–> Feedback für Inkremente wird frühestmöglich gesammelt, Änderungswünsche können geäussert werden
Scrum Artifacts
- dienen dazu das gemeinsamen Verständnis des Teams zu einem bestimmten Zeitpunkts festzuhalten
- Artefakte: Product Backlog, Sprint Backlog und Inkrement
- beinhalten:
1. Teilfunktion des zu erstellenden Produkts (Backlog)
2. fertiggestellte und potentiell lieferbare Produkt
Produkt-Backlog
- stellt Satz aller grundlegenden Anforderungen in einer priorisierten Reihenfolge dar um Produktvision zu erreichen
Sprint Backlog
- Teilmenge des Product Backlogs die während Sprint entwickelt werden soll
Inkrement
- Summe aller Product Backlog Elemente die während eines Sprints fertiggestellt werden + Wert der Inkremente aller vorheriger Sprints
Personas
- in agiler Softwareentwicklung genutzt
= fiktiver, wertefreier Nutzer einer Zielgruppe - stellen typischen Vertreter einer Nutzergruppe dar, sind aber nicht der Durchschnitt
- ermöglichen ein besseres Eindenken in die Nutzergruppe –> bessere Entscheidungsfindung in der Entwicklung
- Personas sollen in Zusammenarbeit mit einem Vertreter erarbeitet werden (Akzeptanz, Verständnis)
Typischer Aufbau einer Persona
- Definiition der Nutzergruppe
- Name, Alter, Hintergrund
- Probleme und Herausforderungen
- Ziel und Wünsche
- Motto/ Zitat
