AAC2018_Die fehlenden Teile im Scrum-Puzzle mit Reinhard Wagner & Ricco Nourzad
•Transferir como PPTX, PDF•
2 gostaram•456 visualizações
Dieser Vortrag zeigt anhand von „Good Practices“ wie man abseits des Scrum-Teams das gesamte Unternehmen enabled agil zu arbeiten.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a AAC2018_Die fehlenden Teile im Scrum-Puzzle mit Reinhard Wagner & Ricco Nourzad
Semelhante a AAC2018_Die fehlenden Teile im Scrum-Puzzle mit Reinhard Wagner & Ricco Nourzad (20)
Mais de Agile Austria Conference
Mais de Agile Austria Conference (20)
AAC2018_Die fehlenden Teile im Scrum-Puzzle mit Reinhard Wagner & Ricco Nourzad
- 1. Reinhard Wagner & Ricco Nourzad 17.05.2018 Agile Austria 2018
- 2. 2 Die fehlenden Teile im Scrum Puzzle Vorstellung Reinhard Ricco
- 3. 3 Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Innovation Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 4. 4 Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Innovation Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 6. 6 Warum ist EX so wichtig? Employee Experience * Studie von IBM Smarter Work Institute (2017) 20% 25% 40% Höhere Arbeitsleistung Geringere Wechselabsichten Höhere freiwillige Bereitschaft “The skills shortage is an ever-present challenge.” – Henry G. Jackson, CEO and president of the Society for Human Resource Management
- 7. 7 Employee Experience: Übersicht Employee Experience Recruiting Onboarding Arbeits- alltag Offboarding Sozialer Bereich Arbeitsbereich Physischer Bereich
- 8. 8 Employee Experience: Recruiting Employee Experience Bedürfnis Aus- schreibung Bewerbung Infogespräch Skill Fit Social Fit Angebot Unterschrift
- 9. 9 Employee Experience: Onboarding Employee Experience 7% 11% 15% 19% 47% PDF Excel E-Mail System Handschriftlich Quelle: https://www.hr-software-vergleich.de
- 10. 10 Employee Experience: Arbeitsalltag Employee Experience Zugehörig- keitsgefühl Zweck Erfolgsgefühl Freude Vitalität * Studie von IBM Smarter Work Institute (2017)
- 11. 11 Employee Experience: Offboarding Employee Experience Feedback- geber Botschafter zukünftige Mitarbeiter Influencer Anknüpfungs- punkte Ehemalige Mitarbeiter sind..
- 12. 12 Innovation Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 14. 14 Fokus: Traditionelles Projektmanagement vs. Innovation Innovation Kosten Umfang Zeit InnovationQualität Machbar Wünschenswert Sinnvoll
- 15. 15 Ursprung des Bedürfnisses nach Innovation Innovation Proaktiv Reaktiv Teamidee Kundenidee Neue Technologie Ausbleibender Erfolg Leerer Backlog Existenzangst “If you’re not failing every now and again, it’s a sign you’re not doing anything very innovative.” Woody Allen
- 16. 16 Zusammensetzung des Teams Innovation Multidisziplinäres Team Gegenseitiger Respekt Intuitiv mit anderen Menschen verknüpfen Starker Mix von Skills Blick über den Tellerrand Empathische Personen Unvoreingenommen Offenes Mindset Neugierig Kollaborativ
- 17. 17 Ort für Innovation Innovation Facetten- reich Inspirierend Spannend Hell “Space is the body language of an organization.” – Chris Flink, Founding Faculty Member der Stanford University’s d.school
- 19. 19 Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Innovation Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 21. 21 Relativer Marktanteil = Eigener Marktanteil Marktanteil des stärksten Konkurrenten Relativer Marktanteil = Eigener Umsatz Umsatz des stärksten Konkurrenten bzw. Relativer Marktanteil Portfolioanalyse
- 22. 22 •Kunden- oder Marktanforderung •Wer profitiert von der neuen Entwicklung?NEED •Ansatz, das Projekt umzusetzen + Budget + Zeitaufwand •Was ist das „einzigartige“ daran?APPROACH •Nutzen für das Unternehmen •Welchen Vorteil bringt es unseren Kunden (Zulieferer) bzw. unserem Unternehmen selbst? BENEFIT •Konkurrenz (intern, extern) •Wodurch unterscheiden wir uns vom Mitbewerb? Was können wir besser? Welche Vorteile haben wir (z.B. IP Rechte)? Risiken. COMPETITION Stanford Research Institute (SRI) Methodik: NABC Projekt Pitch Beispiel
- 23. 23 PMI PMBOK Guide Fifth Edition Monitoring und Controlling: Prozesse Projekt Management Process Group Start Project Initiating Processes Planning and Executing Closing Processes End Project Monitoring und Controlling Prozesse
- 24. 24 http://www.disciplinedagiledelivery.com/lifecycle/agile-lifecycle/ Inception Construction Transition Identifikation, Priorisierung und Auswahl von Projekten Vision Business Roadmap Technology Roadmap • Initiales Product Backlog • Erste Definition der Qualitätskriterien (DoR, DoD) • Erste Makro-Architektur • Projekt-Organisation • Aufsetzen von Monitoring und Tracking • Definition der Aufbau- und Ablauforganisation • Aufsetzen der DevOps- Umgebung • … • Iterativ-inkrementeller Ablauf (Scrum) • Umwandlung des geordneten Product Backlogs in „potentially shipable increments“ • Fortlaufende Releaseplanung • Fortlaufende Strategieanpassung • Fortlaufendes Controlling • … • Finale Release in die Produktions-Umgebung • Übergabe an Betrieb • Betrieb und Support • Zufriedene Stakeholder • … Product Backlog (best case): Alle Use Cases (Features) sind enthalten Die PBI sind gereiht Die PBI sind geschätzt Aber! • Anforderungen sind nicht vollständig • Anforderungen sind nicht erschöpfend • Schätzungen weisen u.U. zunächst eine hohe Unschärfe auf Disciplined Agile Delivery Projektlebenszyklus nach DAD
- 25. 25 Das Kern-Team Projektinitierung PLA Members Product Manager Project Manager Agile Coach Product Owners DevOps Engineer Line Manager Program Manager Architect/ SW-Engineer
- 27. 27 Project Manager Finance & Controlling SME Program Manager Line Manager Mögliches „agiles“ Projektsetup Das Dream-Team … PLA Members Product Manager Scrum Team Scrum Team Scrum Team Scrum Team Wer hat die Hoheit über das Budget? https://rework.withgoogle.com/blog/watch-googles-research-on-awesome-managers/ Wer hat die Hoheit über das Projekt?Wer entscheidet über neue Mitarbeiter?Wer entscheidet über den Abgang von Mitarbeitern?
- 28. 28 Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Innovation Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 30. 30 Corporate Strategy Portfolio / Program Product Release Sprint Daily Development Team ProductOwner Management Unterschiedliche Ebenen Agile Planning
- 31. 31 Business Value (ROI) Releases (z.B. MVP) Inkremente (Meilensteine) Sprint (Review) Daily Scrum RISKManagement Lean Budgets Unterschiedliche Ebenen Betrachtungshorizont beim Controlling
- 32. 32 Product Backlog Ziel- und Liefertermine Sprint Backlog PSI (Inkrement) Marktsituation, Markterwartungen Zeitplan Budget Aktualisierter Zeitplan Aktualisiertes Product Backlog Aktualisiertes Budget Aktualisiertes Impediment Backlog Risiken und Maßnahmen Aktualisierte Risiken und Maßnahmen Sprint Review T&C Sprint Review
- 33. 33 Stream Quartal n Quartal n+1 danach Bereich A Bereich B Bereich C Bereich D Bereich E Bereich F Epic 1 FeatA Epic 2 Epic 3 Epic 4 Epic 5 Epic 6 Epic 7 Epic 8 Epic 9 Epic 10 Epic 11 Epic 12 Epic 13 Epic 14 Epic 15 Epic 16 Epic 17 Epic 18 Epic 19 Epic 20 Epic 21 Epic 22 Epic 23 Epic 24 Epic 25 Epic 26 Epic 27 Epic 28 FeatC FeatD FeatF FeatF FeatG FeatH FeatI FeatJ FeatK FeatL FeatM FeatN FeatP FeatP MVP FeatE FeatO FeatB FeatG T&C Meilensteine und Releases
- 35. 35 Hypothesen aus NABC + tatsächliches Projekt- Budget + Betriebskosten (oder Produktionskosten) Business Value? Einsparungen? Strategisches Produkt? Enabler? Hoffnungsträger? Prestige-Produkt? Problem: Analyse ist erst Monate nach der Inbetriebsetzung des Produkts möglich! Business Value, Rentabilität, ROI Analyse nach Abschluss des Projekts oder nach Go-Live des MVP erforderlich!
- 36. 36 https://hbr.org/2016/09/the-elements-of-value The Value Pyramide 30 Elements of Value “Business Innovation is About New Value, Not New Things. Innovation is relevant only if it creates value for customers – and therefore for the firm. Thus creating ‘new things’ is neither necessary nor sufficient for business innovation.” M. Sawhney, R. C. Wolcott und I. Arroniz
- 37. 37 Die fehlenden Teile im Scrum Puzzle Arbeitsalltag Innovation Governance Scrum Tracking Controlling Recruiting Onboarding Off- boarding
- 39. 39 Die fehlenden Teile im Scrum Puzzle Scaling Agile Distributed Teams Agile Transformation of the Middle Management Integration of BizDevOps Fortsetzung folgt.. Legal Architektur Sales Risikomanagement StaffingXP
- 41. 41 BCG Portfolioanalyse: Hochschule Karlsruhe, https://www.hs-karlsruhe.de/fileadmin/hska/W/allgemein/KDB_150720_Kunz.pdf (09.05.2018) SRI NABC Method: SRI International, https://www.sri.com/engage/innovation-programs/five-disciplines-innovation; https://nielschrist.wordpress.com/2012/07/13/the-nabc-method-standford-research-institute-sri/ (09.05.2018) Monitoring & Controlling: PMBOK Guide – Fifth Edition, PMI (2017) Disciplined Agile Delivery: The Disciplined Agile (DA) Framework, http://www.disciplinedagiledelivery.com/lifecycle/agile- lifecycle/ (09.05.2018) Google Studie: re:Work, https://rework.withgoogle.com/blog/watch-googles-research-on-awesome-managers/ (09.05.2018) Budgetierung: Scaled Agile, https://www.scaledagileframework.com/lean-budgets/ (09.05.2018) The 30 Elements of Value: Harvard Business Review, https://hbr.org/2016/09/the-elements-of-value (09.05.2018) HR at Airbnb: LinkedIn, https://www.linkedin.com/pulse/what-happened-when-airbnb-blew-up-its-hr-department-focus- denise-yohn/ (09.05.2018) Employee Experience – Fakten und Folgen: Leadership Insiders https://www.leadership-insiders.de/employee-experience- fakten-und-folgen/ (09.05.2018) Referenzen
- 42. 42 2018 will be the year of the employee experience: Forbes, https://www.forbes.com/sites/deniselyohn/2018/01/02/2018-will- be-the-year-of-employee-experience/#372107eb1c8f (09.05.2018) Studie zur Employee Experience: Eingestellt und vergessen?: HR-Software Vergleich, https://www.hr-software- vergleich.de/aktuelle-nachrichten/studie-zur-employee-experience-eingestellt-und-vergessen/ (09.05.2018) Drive - The Surprising Truth About What Motivates Us, Daniel H. Pink (2009) Ohne die richtige Motiviation ist alles nichts: Deutsche Startups, https://www.deutsche-startups.de/2016/01/19/ohne-die- richtige-motivation-ist-alles-nichts/ (09.05.2018) Mitarbeitermotivation – Wie bringe ich meine Mitarbeiter dazu, Außergewöhnliches zu leisten?: Personio, https://www.personio.de/mitarbeitermotivation-aussergewoehnliche-leistung/ (09.05.2018) make space – wie die Raumgestaltung Kreativität und Innovationskraft fördert: Der Innovationsblog, https://www.der- innovationsblog.de/make-space-wie-raumgestaltung-kreativitaet-und-innovationskraft-foerdert/ (09.05.2018) Referenzen
Notas do Editor
- Reinhard: Sehr geehrte Damen und Herren. Herzlichen Dank für ihr Interesse an unserem Thema. Unser Beitrag läuft ja in dem Slot „The Future of Agile“. Nun ja, um einen berühmten Menschen sinngemäß zu zitieren: „Innovationen sind schwierig, insbesondere dann, wenn sie die Zukunft betreffen.“ Ricco: Was wir Ihnen hier zeigen möchten, ist eine spannende Sammlung an good practices, die uns in unserem Projekt-Getriebe helfen sollen. Einige davon kratzen an agilen Frameworks wie Scrum, andere befinden sich außerhalb des Scrum’schen Sonnensystems, wieder andere scheinen aus einer anderen Galaxie zu kommen. Sie alle gehören aber zu unserem Werkzeugkasten, um agile Projekte erfolgreich abzuliefern.
- Zunächst jedoch kurz zu uns. Reinhard: Ricco nimmt natürlich einen bunten Blumenstrauss an agilen Zertifikaten mit (was ja auch nicht unbedingt so wichtig ist), er bringt aber vor allem eine ganze Blumenwiese aus Erfahrungen aus seinen international besetzten Projekten und auch aus seinem eigenen Startup mit. Was ich besonders an Ricco schätze, ist die Kombination von umfassendem agilen Know How und profundem technischen Wissen aus der Produktentwicklung. Ricco: Naja, den Blumenstrauss an Zertifikaten sehe ich bei Dir ja auch ;-). Reinhard hat mittlerweile ja schon knapp 30 Jahre Erfahrung im IT Management in den unterschiedlichsten Branchen: Von Radio, TV und Print über die Industrieautomatisierung bis hin zum Transportwesen. Und das meist mit internationaler Beteiligung von den USA über Serbien und Polen bis hin zu Indien, China und Japan. Was ich besonders an Reinhard schätze ist seine breite Kompetenz in der agilen Softwareentwicklung, wie auch Projektmanagement durch eine Vielzahl an Projekten und einer breiten Menge an Literatur, wie auch seine Fähigkeit, Probleme aus anderen Perspektiven zu betrachten, um so zur Lösung zu gelangen.
- Employee Experience… etwas enorm tolles, großartiges, wichtiges... Aber wem von Ihnen sagt der Begriff etwas? In einem Markt wie man ihn heutzutage vorfindet, wird es immer schwieriger gute Knowledge Worker zu finden. Auch wir bei BearingPoint Agile Advisory suchen akribisch um gute neue Kollegen zu finden und wollen gleichzeitig eine möglichst niedrige Fluktuation beibehalten. Und genau dabei soll eine gute Employee Experience helfen. Unter Employee Experience subsumieren sich alle Erfahrungen, die ein Mitarbeiter im Unternehmen sammelt. Darunter fällt weit mehr als der Wuzzler (Fußballtisch) im Pausenraum oder kostenloser Kaffee und Obst. Nein, es geht um jeden einzelnen Augenblick, den der Mitarbeiter im Büro verbringt und wie wohl er sich in dieser Zeit fühlt. Aber warum brauchen Unternehmen eigentlich eine Employee Experience?
- Ziel: Employee Engagement and Commitment to the company Aus was besteht nun eigentlich die Employee Experience im Detail? included 11.5 times as often in Glassdoor’s Best Places to Work listed 4.4 times as often in LinkedIn’s list of North America’s Most In-Demand Employers 28 times more often listed among Fast Company’s Most Innovative Companies listed 2.1 times as often on the Forbes list of the World’s Most Innovative Companies twice as often found in the American Customer Satisfaction Index Most importantly, he finds that “experiential organizations had more than 4 times the average profit and more than 2 times the average revenue. They were also almost 25 percent smaller, which suggests higher levels of productivity and innovation.” https://www.leadership-insiders.de/employee-experience-fakten-und-folgen/
- In unserem Vortrag kategorisieren wir die Employee Experience in 4 Themen: Recruiting: Vom Bedürfnis des Unternehmens eine neue Rolle zu besetzen bis hin zur Unterschrift des zukünftigen Mitarbeiters. Wie kann man diese mit einer möglichst großen Zufriedenheit für den Mitarbeiter durchführen? Onboarding: Unterschiedliche Wege des Onboardings und wie man hier einfachst Technologie nutzen kann um eine größere Mitarbeiterzufriedenheit herzustellen. Arbeitsalltag: Welche Faktoren sind im Arbeitsalltag zu beachten, sodass ein Mitarbeiter stets zufrieden bleibt im Unternehmen? Offboarding: Wie kann man selbst beim Offboarding die Employee Experience hoch halten und gleichzeit wertvolle Informationen erhalten?
- Bedürfnis: Ausschreibung: Bewerbung Infogespräch: Skill Fit: Social Fit: Angebot: Unterschrift: Ab dem Zeitpunkt der Bewerbung ist es hier insbesondere wichtig die Wartezeiten kurz zu halten, um so den EE Index möglichst hoch zu halten.
- Vorteile der Technlogie nutzen https://www.hr-software-vergleich.de/aktuelle-nachrichten/studie-zur-employee-experience-eingestellt-und-vergessen/
- What really motivates us (Youtube Video) Buch: Drive (Dänischer Author) -> https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us https://www.deutsche-startups.de/2016/01/19/ohne-die-richtige-motivation-ist-alles-nichts/ https://www.personio.de/mitarbeitermotivation-aussergewoehnliche-leistung/ Stufenmodell: Mastery,… (Zugehörigkeit) Belonging: Sich einer Gruppe, einem Team oder der Organisation zugehörig fühlen Purpose: Verständnis dafür, warum die eigene Arbeit bedeutsam ist Achievement: Erfolgsgefühl nach getaner Arbeit Happiness: Durchdringendes Zufriedenheits-/Glücksgefühl in und mit der Arbeit Vigor: Präsenz von Energie, Enthusiasmus, aufregender Anspannung bei der Arbeit
- Nur 29% der Organisationen haben einen formellen Offboarding Prozess https://www.geteverwise.com/human-resources/offboarding-a-crucial-part-of-the-employee-experience/ Interne vs. externe Mitarbeiter (Projektmitarbeiter) Anonymisierung Offboarding: Checklist
- Hinsichtlich ihres Anwendungsbezuges können Forschung und Entwicklung in vier Aktivitäten gegliedert werden, die sich nur unscharf voneinander abgrenzen lassen und sich zumeist im Rahmen eines einzelnen F+E-Projektes überlappen.
- 1. Traditionelles PM: Meist Fokus auf den Scope. Schedule, Cost und Quality anpassen. 2. The New Product Development Triangle – Desireable (wünschenswert - Kunde), Feasible (machbar), Viable (sinnvoll, tragfähig) Innovation Sweet Spot
- Vier Quadranten… Portfolio Slide von Reinhard
- Bild-Quelle: https://pixabay.com/de/menschen-betrachter-ausstellung-2944065/
- Inspirierend: Bilder, Sprüche die die Wand zieren Facettenreich/Flexibel: Variable Räume, welche zu den Bedürfnissen der Personen bzw. Projekte angepasst werden können Trennwände, Tische und Sessel welche verstellbar sind Wände und andere Oberflächen können zur Visualisierung genutzt werden Spannend: Soll nicht langweilig sein und die Leute sofort in ihre Comfortzone fallen lassen, sondern soll ein proaktives Handeln ermöglichen in einem offen gestalteten Raum der sowohl Steh als auch Sitzplätze hat. Hell: Kreativitätsprozesse werden durch Dunkelheit nicht gefördert, daher soll auf einen hellen Ort Wert gelegt werden Der Raum ist weit mehr als nur eine rein physische Umwelt. Der Raum ist die Kultur und das Verhalten, der die sich darin befindenden Personen widerspiegelt. Somit kann die Raumgestaltung auch erwünschte Gewohnheiten und Aktionen durch entsprechendes Design steuern und verstärken. Bild-Quelle: https://pixabay.com/de/menschen-betrachter-ausstellung-2944065/
- Design Thinking: 5-6 Phasen Modell, welches durch unterschiedliche Methodensets die Kreativität methodisch, wie auch durch das richtige Mindset im richtigen Raum mit dem richtigen Team unterstützt. Creative Problem Solving: 3-4 stufiger Kreativitätsprozess (linear vs nicht-linear) zur Generierung neuartiger Lösungen
- Bevor wir uns in ein Projekt stürzen, gilt es, einen genaueren Blick in unser Portfolio zu werfen. Welche Produkte oder Dienstleistungen sollten weiterentwickelt und welche sollten eingestellt werden. Welche dienen als Cash Cow, die derzeit keine weitere Zuwendung brauchen? Eine Entscheidungshilfe dafür kann die BCG Portfolioanalyse sein: Sie betrachtet den relativen Marktanteil sowie das vorhandene Marktwachstum und teilt die vorhandenen Produkte in vier Quadranten ein: Newcomer bzw. Fragezeichen, Stars, Dogs (Auslaufprodukte) und Cash Cows (stabile Geldlieferanten ohne signifikantes Marktwachstum). Je größer der Cash-Flow des Produkts, desto größer ist der aufgemalte Punkt. Die Fragen können vielleicht lauten: In welchem Quadranten befindet sich mein aktuelles Produkt derzeit? Wohin kann ich es bewegen? Soll das Produkt weiterentwickelt oder aussortiert werden? Nachteil an dieser Darstellung ist, dass sie das Marktwachstum als gegebene Größe betrachtet und den eigenen Einfluss darauf, etwa durch Marketing oder Werbung, außer Acht lässt. Dennoch könnte es eine von mehreren guten Input-Quellen für die Entscheidungsfindung sein. Haben wir nun etwa ein Fragezeichen identifiziert, welches wir zum Star machen wollen, so wird sogleich die Frage nach einer Vision – also WO wollen wir hin? – und einer Strategie bzw. einer Roadmap – WIE kommen wir dahin? – auftauchen? Beides ist – im Sinne unseres agilen Unternehmens – allen Beteiligten transparent zur Verfügung zu stellen.
- Ausgerüstet mit dieser Vision, der Strategie und einer Rodamap, kann sich etwa ein Product Manager daran machen, einen Teil der Strategie konkreter in Richtung Projekt voranzutreiben. Wesentliche Eckpfeiler für eine Entscheidungsfindung für ein spezifisches Projekt sind: Nutzen für den Kunden (Need) Nutzen für das Unternehmen (Benefit) Wie das Projekt umgesetzt werden soll (Approach): Budget, Zeitaufwand, etc. Die Konkurrenz (Competition, auch unternehmens-intern) Dafür eignet sich u.a. der vom Stanford Research Institute entwickelte NABC-Ansatz. Dieses NABC-Blatt stellt dennoch nur die Spitze des Eisbergs dar, es dient dem Pitch des Projekts vor einem Management-Gremium. Aufgrund der Endlichkeit von Geldmitteln werden sich also nur die besten Projekt-Vorschläge im Unternehmen durchsetzen. Somit ist dieser Pitch von enormer Bedeutung. Auch wenn noch nicht alle Details zum Projekt klar sind, so wird dennoch eine erste grobe Einschätzung der erforderlichen Budgetmittel benötigt. Wie sonst sollen ein Projektauftrag formuliert und erste Rentabilitätsbetrachtungen erarbeitet werden? Hier ist also Mut zur Lücke gefragt. Es kommt nicht selten vor, dass ein Bauchgefühl ausreicht, um das Budget für ein erstes MVP loszueisen. Es steckt also jede Menge Aufwand in der Erhebung der Kundenanforderungen, der Erarbeitung des Lösungsansatzes, der Darstellung des Nutzen fürs Unternehmen und etwa einer Mitbewerberanalyse. Von großem Nutzen sind auch hier wieder Lean Management und Vorgehensweisen à la Lean Startup. Ist die erste Hürde genommen – nämlich die Bewilligung des Projekts bzw. dessen erster Teil (à la MVP) – geht es darum, das Dream-Team aufzustellen und dann die ersten Artefakte abzuliefern.
- Lassen Sie uns dazu zunächst einen Blick auf den Life-Cycle eines Projekts werfen: Ein Projekt – egal ob agil oder nicht – kann mit einem bestimmten Lebenszyklus beschrieben werden. Ja klar, einige „Projekte“ werden nie abgeschlossen, da ein Produkt vielleicht ständig weiterentwickelt wird. Das würde aber der Definition von „Projekt“ widersprechen, da wir hier von klaren Anfangs- und Endterminen sprechen. Die einzelnen Phasen differieren stets ein wenig, je nachdem, welche Art von Projekt man vor Augen hat. Ein (vielleicht vereinfachtes) Beispiel könnte wie folgt aussehen: Nach der Entscheidung für ein neues Projekt oder eine Fortsetzung eines bestehenden Projekts (Start Project), geht es darum, dieses genauer auszuformulieren, einen offiziellen Projektauftrag zu erhalten. In diesem Initiating-Prozess stecken die Definition des initialen Backlogs, die Zusage von Budget und Ressourcen, das Alignment der Stakeholder, u.v.m. Danach folgt die eigentliche Delivery oder Construction oder – wie hier beschrieben – der Abschnitt Planning and Execution. Das verdeutlicht auch, dass die Planung das ganze Projekt über andauert. Dies ist zugleich der Abschnitt in dem der intensivste Einsatz unserer Scrum-Teams erfolgt. Der Abschluss eines Projekts erfordert in der Regel viele formale Handlungen zwischen Auftragnehmer und Auftraggeber, etwa die Übereinkunft, dass das zugesagte Resultat auch tatsächlich erzielt wurde, die letzten Handgriffe der Finanzexperten und die finale Übergabe an den Betrieb und die Maintenance. Alle drei Abschnitte werden begleitet vom Monitoring und Controlling. Letzteres startet ja im Grunde bereits dann, wenn das Projekt beauftragt und ein Budget bereitgestellt wird. Als Ergänzung zeigt die punktierte Linie den typischen Verlauf des Staffing-Level und somit der Kosten zum jeweiligen Zeitpunkt im Projekt. Ein gutes Beispiel für agiles Projektmanagement liefert uns DAD.
- DAD – Disciplined Agile Delivery, zeigt einen nahezu gesamtheitlichen Blick auf Projekte. Ich bin gewiss kein vehementer Anhänger von DAD (das in England entwickelt wurde – und fast ausschließlich dort eingesetzt wird). Es erlaubt uns aber einige spannende Einblicke in den Lebenszyklus eines Projekts. DAD kennt im Wesentlichen drei Abschnitte: Inception, Construction und Transition. In der Inception wird in der Regel nochmals der davor vereinbarte Scope (Vertrag zwischen AG und AN) weiter analysiert, was üblicherweise zu vielen Diskussionen betreffend Abänderungen führt. Daraus entsteht dann das erste, vollständige, geordnete und geschätzte Product Backlog. Darüber hinaus hat das erste Kernteam weitere Aufgaben, wie das Aufsetzen der DevOps-Umgebung, des Monitoring und Tracking, die Definition der Aufbau- und Ablauforganisation (inkl. dedizierter Namen), der ersten DoR und DoD, u.v.m. Der Kern des anschließenden Construction-Abschnitts ist die Umwandlung der Backlog-Items in ein potentially shipable increment. Projektleitung, POs und die Scrum-Teams sind zudem beschäftigt mit der Releaseplanung, der Anpassung der Strategie, usw. Insbesondere in diesem Abschnitt wird es ein intensives Controlling geben, da hier auch am meisten Personen beteiligt sind. Der Transition-Abschnitt beschäftigt sich mit der finalen Übergabe des Entwickelten an den Betrieb. Zudem sind hier auch die formalen Schritte zu finden, die notwendig sind, um ein Projekt zwischen AG und AN offiziell abzuschließen. Apropos Personal: Wie könnte ein solches Projektteam aussehen?
- Zurück zum eigentlichen Initiieren eines Projekts: Das Projekt ist bewilligt. Nun geht es darum, es aufzusetzen und die ersten Artefakte zu erzeugen. In der Regel werden die Mitglieder des Projektlenkungsausschusses (PLA) evtl. mit Unterstützung des Product Managers (dem „Erfinder“ des Projekts) und eines Program Managers, also in der Regel jene Leute, die sich zuvor über das Portfolio den Kopf zerbrochen haben, einen Projektleiter ernennen. Gemeinsam mit den betroffenen Line Managern stellt er sein Dream Team für den initialen Abschnitt zusammen, welches in der Regel aus den Product Ownern, einem Agile Coach, einem oder mehreren Software Architekten bzw. Software Entwicklern (evtl. inkl. UX-Experte) und idealerweise auch gleich einem DevOps Engineer besteht. Für spezielle Aufgaben können natürlich noch weitere Personen involviert werden, etwa Juristen, Marketing-Spezialisten oder andere Fach- oder Technologie-Experten. Kernaufgabe dieses Teams ist es, die zuvor erwähnten Artefakte zu erzeugen: Initiales Backlog inkl. Reihung und Schätzung, die erste Definition der gemeinsamen DoR und DoD, das System für Monitoring und unter anderem auch das Tracking und Controlling. Auch die Infrastruktur für die Entwicklung will bereitgestellt sein (Stichwort: DevOps). Je nach Komplexität und Umfang des Projekts können diese Vorgänge durchaus einige Monate in Anspruch nehmen. Erst danach werden die eigentlichen Scrum-Teams aufgebaut. Im besten Fall können sich die Mitarbeiter des Unternehmens auf bestimmte Rollen und Aufgabenbereiche bewerben. Ein intensives Einbinden der bereits bestehenden Team-Mitglieder bei der Aufnahme neuer Kollegen ist dabei sehr wertvoll und hilft dabei, ein wirkliches High-Performance-Team zu formen. Von Management-Seite ist darauf zu achten, die Selbstorganisation so gut wie möglich zu fördern. Der Projektleiter hat darüber hinaus noch jede Menge anderer Aufgaben zu erledigen. Das reicht von „banalen“ Dingen wie der Organisation von geeigneten Büro-Räumlichkeiten, der passenden IT-Ausstattung bis hin zu komplexeren Dingen wie der Koordination der Erstellung einer Release-Rodamap (unter Federführung der POs bzw. des Product Managers).
- Konzentrieren wir uns zunächst einmal auf das Team, wenn wir die eigentlichen Entwicklungsphase betrachten. Neben dem Scrum-Team wird man in der Praxis noch eine mehr oder weniger große Gruppe an Personen finden, die direkten oder indirekten Einfluss auf das Projekt hat. Allem voran sei hier der Projektleiter genannt. Allen Unkenrufen zum Trotz spielen Manager eine wesentliche Rolle in größeren Projekten. Ein sehr gutes Beispiel hat uns Google geliefert. Ausgehend von Scrum war die These: Wir benötigen in unseren Scrum-Teams keine Projektleiter oder Manager. Sie haben sogleich ein Team losgeschickt. Der Versuch ist kläglich gescheitert. Seither hat Google intensiv in die Ausbildung der Manager investiert. Das Ergebnis: Ein umfangreiches Trainingsprogramm, das nur „awesome“ Managers hervorbringt. Manager sind also wichtig und gut für ein Projekt, aber nur, wenn sie „awesome“ sind. Den Link dazu finden Sie auf dem Slide. In weiteren Bereichen kommen zudem zahlreiche weitere Personen ins Spiel, die wesentlichen Einfluss auf den Erfolg des Projekts haben. Vielleicht ein übergeordneter Program Manager, die Mitglieder des Projektlenkungsausschusses, der Bereich Finance & Controlling, der eine oder andere Subject Matter Expert (kurz SME), die Line Manager, welche ja Personal bereitstellen müssen, und nicht zuletzt unser awesome Project Manager. Blendet man dann auf die Makro-Ebene, stellt sich das Bild vielleicht wie folgt dar. Gehen wir nun einigen zentralen Fragen der Verantwortlichkeiten nach. Darf ich die Frage an die hier Anwesenden richten: Wer hat die Hoheit über das Budget? Wer hat die Hoheit über das Projekt an sich? Wer darf es terminieren (ums es mit Arnie zu sagen)? Wer entscheidet über neue Mitarbeiter? Wer entscheidet über den Abgang von Mitarbeitern?
- Lassen Sie uns zunächst einen kurzen Ausflug in die Welt der Strategien und der Planung machen, bevor wir ins Tracking & Controlling einsteigen Agile Planung bewegt sich in der Regel durch diese Levels, von der Corporate Strategy über … bis zum Daily. Vom Daily ausgehend wird dann die Realität wieder zurückgespiegelt zur strategischen Planung, was wiederum Auswirkungen auf die weitere Planung hat, usw. Dabei haben unsere beteiligten Personen einen unterschiedlichen Fokus bzw. steigen auf unterschiedlichen Levels in die Planung ein. Aufgabe des Management ist es, die Corporate Strategy zu erarbeiten, sich Gedanken zum Portfolio zu machen und vielleicht noch ansatzweise beim Produkt mitzureden. Die Product Owner steigen vielleicht ansatzweise beim Portfolio ein und treffen sich natürlich mit dem Development Team beim Daily.
- Das Project-Tracking und Controlling erstreckt sich vom Daily Scrum, welches gute Einblicke in den täglichen Fortschritt gibt (nur Tracking) bis hin zur Verifikation des – im NABC-Pitch als Benefit angegebenen – Business Value bzw. ROI. Hier schließt sich auch der Kreis zur zuvor erwähnten Planung. Abgesehen vom ROI bzw. vom Business Value geht es stets um die drei Fragen: Wie viel Budget wurde bislang verbraucht? Was wurde bislang umgesetzt? Wie verhalten sich diese beiden Werte zur ursprünglich aufgestellten Roadmap bzw. zur aufgestellten Planung? Zusätzlich empfiehlt es sich, Projekt-Risiken ebenfalls ins Controlling mit einzubeziehen, da sie erhebliche Auswirkungen auf die Zahlen haben können. In den bekannten Projektauftrags-Situationen wird man meist ein bestimmtes Budget für eine mehr oder weniger genau definierte Aufgabe (Produkt) bekommen? Dieses Setup hat natürlich einige Probleme mit der agilen Welt. Bessere Ansätze findet man z.B. im Scaled Agile Framework. Die Idee dabei ist, einen Value Stream zu finanzieren anstatt eines Projekts oder Produkts. Interessierte finden dazu den Link auf dem Slide: https://www.scaledagileframework.com/lean-budgets/ Dieses System hat seine Stärken vor allem bei der Finanzierung von Unternehmensbereichen oder eben Value Streams. In der sehr häufig anzutreffenden Situation eines Auftraggebers und eines externen Auftragnehmers ist diese Variante manchmals schwierig umzusetzen. I.d.R. wird man daher ein mehr oder weniger starres Budget für ein Projekt erhalten. Diese Vertragsgestaltung ist aber ein eigenes, schwergewichtiges Thema, das den zeitlichen Rahmen unseres Vortrags sprengen würde.
- Lassen Sie uns einen Blick auf die einzelnen Ebenen werfen: Ich denke, über den Inhalt und Nutzen eines Daily Scrum müssen wir in dieser Runde nicht sprechen. In Hinblick auf die folgenden Aspekte möchte ich aber ganz kurz einen Blick auf das Sprint Review werfen. Was geht rein? Was ist der Input? Und was geht raus? Was ist der Output? … Slide … Somit sind wir bereits in Besitz einer Menge an Informationen, um eine Release zu planen, das Budget zu überwachen und ggf. Korrekturen vorzunehmen. Die Frage an Sie: Was fehlt hier noch? Die Erwähnung, dass Scrum generell ein risikominimierendes Framework ist, ist in der Praxis oft nicht ausreichend. Deshalb sollte auch Risikomanagement explizit aufgenommen werden. Zudem ist es hilfreich, sich betreffend Roadmap und Release-Planung ein paar Tools zurecht zu legen… (next slide)
- Auf Ebene der Programm- oder Projektleitung ist ein solches Programmplanungsboard oder auch „Beast“, wie es liebevoll genannt wird, hilfreich. Dieses Board stellt also den Wunsch der Programm- oder Projektleitung dar, i.d.R. die Roadmap. Links vom IST-Datum (heute) stellt es hingegen den tatsächlichen Fortschritt dar. Somit eignet sich dieses Board für alle POs, Projektleiter, Programmleiter, Sponsoren, usw. um sich regelmäßig davor zu treffen, den Fortschritt nochmals besprechen, Re-Priorisierungen vorzunehmen und Problemlösungen zu triggern. Damit sollten sich also eine Menge liebgewonnener Reporting-Meetings aus der Wasserfallwelt eliminieren lassen. In der Spalte Stream stehen Verantwortungsbereiche. In der Regel also Teilbereiche oder Abteilungen die etwas produzieren oder etwas zuliefern. Die Bereiche sollten dabei so geschnitten sein, dass hier klare Verantwortlichkeiten ersichtlich werden. In den Spalten „Quartal n“, „Quartal n+1“ und „danach“ befinden sich die Lieferobjekte, die im angegebenen Zeitraster fertig werden sollen. Üblicherweise befindet man sich hier in der Flughöhe von Epics und Features. Teilt man das Board so wie hier nach Quartalen ein, empfiehlt sich, nur maximal zwei Quartale zu nennen. Die dritte Spalte enthält alles was danach kommt. Dies deshalb, da sich die nächsten 6 Monate noch einigermaßen seriös planen lassen. Alles was danach kommt besitzt schon eine zu große Unschärfe für eine seriöse Betrachtung. Im Sinne der Transparenz und Durchgängigkeit sollen sich auf diesem Board nur solche Objekte befinden, welche sich auch 1:1 im Tool (ggf. Jira) wiederfinden. Somit ist man auch in der Lage bestimmte Releases (rote Linie – MVP) sowie Abhängigkeiten (grüne Linie) auf dem Board zu visualisieren.
- Was aber nun, wenn sich im Sprint Review oder vor dem Programmplanungs-Board herausstellt, dass es Probleme mit dem Liefertermin oder dem bereitgestellten Budget gibt? Auch von der PMI gibt es dazu Vorschläge (wer hätte das gedacht? ;-) Damit werden im Grund „nur“ die – mehr oder weniger – auf der Hand liegenden Fragen beantwortet: Welche Features wurden bislang umgesetzt? Mit welchem „Wert“ wurden diese geschätzt (EV)? Welche Features waren ursprünglich bis zum jetzigen Zeitpunkt geplant (PV)? Welche Kosten sind bislang aufgelaufen (AC)? Was bedeutet das für das Gesamtbudget (BAC) sowie den Endtermin des Projekts? Hiermit sehen wir ganz klar, dass es wichtig ist, bei Projektstart einen guten Überblick darüber zu haben, welche Features oder Epics wie viel Budget und Zeit beanspruchen werden. Hier kommt auch der Scrum-Wert „Mut“ ins Spiel, da vor Projektstart meist keine 100% exakten Angaben gemacht werden und daher nur grobe Schätzungen möglich sind.
- Etwas knackiger wird es dann schon bei der Betrachtung des Business Value. Diese ist in der Regel eine Analyse nach Abschluss des Projekts oder z.B. nach Go-Live des MVP. Startpunkt sind die Hypothesen, die mit dem NABC aufgestellt wurden: Welchen Wert (Business Value) hat das geschaffene Produkt für das Unternehmen? Welche Einsparungen (Mittel, Personal) können nach Inbetriebnahme realisiert werden? Ist das Produkt von strategischer Bedeutung (auch wenn es selbst einen negativen Cash-Flow hat)? Ist es vielleicht ein Enabler für andere Produkte? Ist es vielleicht ein Hoffnungsträger für die Zukunft? Ist es ein Prestige-Produkt? … Probleme, die sich daraus ergeben: Solche Analysen können i.d.R. erst einige Monate nach der Inbetriebsetzung des Produkts durchgeführt werden. Also erst zu einem Zeitpunkt wenn das Projekt-Team u.U. nicht mehr anwesend ist und nicht mehr mit Expertenwissen unterstützen kann. Der Business Value von strategisch wertvollen Produkten ist oft nur schwer in harten Zahlen messbar. Auch die Portfolioanalyse ist hier nur bedingt hilfreich. Zudem: Personaleinsparungen sind oft (gegenüber dem Betriebsrat oder der Gewerkschaft) schwer argumentierbar Man denke nur an die Digitalisierung im öffentlichen Sektor!!! - Andere Möglichkeiten: Frage ans Publikum
- Eine interessante Idee kommt aus Harvard bzw. von Bain & Company: Etwas knackiger wird es dann schon bei der Betrachtung des Business Value. Diese ist in der Regel eine Analyse nach Abschluss des Projekts oder z.B. nach Go-Live des MVP. Startpunkt sind die Hypothesen, die mit dem NABC aufgestellt wurden: Welchen Wert (Business Value) hat das geschaffene Produkt für das Unternehmen? Welche Einsparungen (Mittel, Personal) können nach Inbetriebnahme realisiert werden? Ist das Produkt von strategischer Bedeutung (auch wenn es selbst einen negativen Cash-Flow hat)? Ist es vielleicht ein Enabler für andere Produkte? Ist es vielleicht ein Hoffnungsträger für die Zukunft? Ist es ein Prestige-Produkt? … Probleme, die sich daraus ergeben: Solche Analysen können i.d.R. erst einige Monate nach der Inbetriebsetzung des Produkts durchgeführt werden. Also erst zu einem Zeitpunkt wenn das Projekt-Team u.U. nicht mehr anwesend ist und nicht mehr mit Expertenwissen unterstützen kann. Der Business Value von strategisch wertvollen Produkten ist oft nur schwer in harten Zahlen messbar. Auch die Portfolioanalyse ist hier nur bedingt hilfreich. Zudem: Personaleinsparungen sind oft (gegenüber dem Betriebsrat oder der Gewerkschaft) schwer argumentierbar Man denke nur an die Digitalisierung im öffentlichen Sektor!!! - Andere Möglichkeiten: Frage ans Publikum
- Ricco: Wie sie sehen können, müssen wir in agilen Projekten noch an eine ganze Menge anderer Dinge denken, die wir hier nicht explizit behandelt haben. Betrachtet man diese Menge an Puzzle-Bausteinen, entsteht schnell der Eindruck, dass Scrum lediglich ein ganz kleiner Teil in einem Entwicklungsprojekt ist. Das mag auch tatsächlich so sein. Jedoch! Agilität an sich soll und muss auch alle anderen Teile unseres Handeln durchziehen, um tatsächlich ein High-Performance-Teams aus Gesamt-Projekt- oder vielleicht sogar Unternehmens-Sicht formen zu können. Das lässt den Schluss zu, dass Scrum nicht immer und überall eingesetzt werden kann, muss oder soll – agile Werte in ein Unternehmen zu bringen zahlt sich unserer Meinung nach aber immer aus!
- Nachsatz: Alle Infos und Verweise finden sie letztendlich in den Slides, die nach der Konferenz zur Verfügung gestellt werden. Auch unsere Kontaktinfos sind darin enthalten. Wir sind immer für spannende Diskussionen und einen Erfahrungsaustausch offen. <Slides mit Referenzen durchblättern – beim Slides mit den Kontaktinfos stehen bleiben>
- Reinhard: