Product Owner Skills jenseits von Scrum

Transkript

1 Product Owner Skills jenseits von Scrum wie Vertreter des Fachbereichs IT Projekte erfolgreich machen können IIBA Germany Chapter e.v. Zu Gast beim BITMi in Aachen März 2016

2 can understand can observe can listen Mr. Super-PO can talk can be strong can feel can assume can write can fly 2

3 Agenda 1. Vorstellung 2. Die IIBA, der BABOK Guide & das CBAP Zertifikat 3. Business Analyse im Projektkontext 4. Agile Vorgehensweisen als Imperativ 5. Wie kann man Agil erfolgreich verkaufen? 6. Das Dilemma des Teilzeit-PO 7. Some Stories about User Stories 8. Aspekte möglicher Vertragsformen 3

4 Vorstellung Dipl. Ing. Rainer Wendt, CBAP, PMP, PMI-PBA, SCT Ing. Nachrichtentechnik 25+ Jahre internationale IT Erfahrung in - Softwareentwicklung und -architektur - Projektleitungen in Telekommunikation und Finanzindustrie - Anforderungsmanagement, Business Analyse - Risikomanagement - Change Management - Training, Coaching - u.v.m Präsident IIBA Chapter Germany e.v. Geschäftsführer der masventa Business GmbH 4

5 The International Institute of Business Analysis (IIBA) is a growing Community of BA Professionals Established in 2003 in Toronto Canada 29,000+ Members Chartered Chapters: 116 Over 240 Corporate Members CCBA Recipients: 843 (Germany 4) CBAP Recipients: 6,110 (Germany 46) 285 Endorsed Education Provider 5

6 IIBA s Driver 6

7 The Guide to Business Analysis Body Of Knowledge Der globale Standard für Business Analyse Herausgeber: International Institute of Business Analysis (IIBA) in Toronto, Kanada 514 Seiten, 6 Wissensgebiete 5 Perspektiven wie Agile, BI, BPM Grundlage für die Zertifikate CCBA und CBAP Viele Techniken und anerkannte Best Practises BABOK v3.0 ist erschienen am 15. April

8 Wissensgebiete des BABOK v3 Quelle: BABOK v3 8

9 BABOK v3 - Business Analysis Core Concept Model (BACCM TM ) Die Vorgehensweise Changes im Kontext von Unternehmen zu ermöglichen durch die Ermittlung des Bedarfs und die Empfehlung von Lösungen, die den Stakeholdern einen Wertbeitrag liefern Quelle: BABOK v3 9

10 Das CBAP Zertifikat Weltweit anerkanntes, professionelles Zertifikat für Business Analysten auf höchstem Niveau (vergleichbar mit PMP ) Zertifizierte CBAP haben nachgewiesene 7500 h (mind. 5 Jahre) Projekterfahrung in der Business Analyse, sind deshalb erfahrene Senior Professionals. Ein CBAP hat gute Kenntnisse im Projektmanagement nach PMBOK, da das BABOK in vielen Aspekten daran orientiert ist. Die meisten CBAP sind zu finden in Banken und Versicherungen, Telekommunikation und andere Branchen folgen. Derzeit mehr als CBAP weltweit, Wachstum > 20% p.a. CBAP Examen: 3,5 Stunden Klausur mit 150 Fragen, abzulegen nach Zulassung in anerkannten Prüfungsinstituten. Examen für BABOK Version 3.0 ab ca. September 2016 verfügbar, mindestens bis dahin bis können noch v2 Prüfungen abgelegt werden The Gold Standard 10

11 11

12 Business Analyse im Projektkontext Business Need Business Case Assess Value & Performance Go/No Go Decision Design & Work Source: BABOK v3 Vision Project Go Live Live Quelle: BABOK v3, masventa 12

13 Business Analyse im Projektkontext Die Entwicklung im Projekt wird z.b. nach Scrum abgearbeitet, agil bzw. adaptive Business Need Business Case Assess Value & Performance Go/No Go Decision Design & Work Source: BABOK v3 Vision Project Go Live Live Quelle: BABOK v3, masventa 13

14 Rollen und Verantwortlichkeiten in Scrum Sponsor Stakeholders Scrum Master Product Owner Projektmanager Business Analyst Scrum Team Core Team in red Quelle: Watermark Learning

15 Der Business Analyst und Scrum Der Business Analyst nimmt typischerweise die Rolle des Produkt Owners ein oder unterstützt diesen, insbesondere wenn niemand aus dem Fachbereich die erforderliche Zeit aufwenden kann Die Anforderungen aus dem Produkt-Backlog werden nach Kriterien wie Priorität, Stabilität u.s.w. für den nächsten Sprint geplant vom BA on behalf of Business Der Business Analyst ist neben seiner PO Rolle vor allem der Communication Facilitator Business Business Analyst / Product Owner Quelle: Wikipeda 15

16 Projektbilanz der CHAOS Report 16% erfolgreich ohne Abstriche 31% wurden ganz abgebrochen 53% waren problematisch (Gründe siehe Balkendiagramm) 53% 31% 16% Cancelled Sucessful Challenged Lack of User Input Incomplete Requirements & Specifications Changing Requirements & Specifications Lack of Executive Support Technology Incompetence Lack of Resources Unrealistic Expectations Unclear Objectives Unrealistic Time Frames New Technology 0% 2% 4% 6% 8% 10% 12% 14% Quelle: CHAOS Report by The Standish Group, 2014, 365 Respondents 16

17 Deshalb werden agile Vorgehensweisen mehr und mehr zum Imperativ! Es ist sehr schwierig bis unmöglich, Anforderungen vor dem Beginn einer Entwicklung hinreichend zu erfassen da der Kunde/Fachbereich selbst (noch) nicht weiß was er will oder es nicht ausdrücken kann da viele Erkenntnisse, die zur Formulierung und Analyse von Anforderungen benötigt werden, erst unter dem Projekt entstehen Falls man dennoch daran festhält (oder festhalten muss) sind teure Änderungen (Change Requests) unvermeidbar Längere Laufzeiten sind unvermeidbar Budgets werden stark überzogen, TCO laufen aus dem Ruder 17

18 The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions Working software Customer collaboration Responding to change over processes and tools. over comprehensive documentation. over contract negotiation. over following a plan. That is, while there is value in the items on the right, we value the items on the left more. Quelle: 18

19 Aber, was versteht eigentlich der Fachbereich unter Agil???????? 19

20 Ist Agil gut oder schlecht für mein Projekt? Einige typische (Vor-)urteile aus der Sicht des Fachbereiches Mehr Beteiligung für uns! Der Fachbereich legt immer die Prioritäten fest für jeden Sprint Changes are always welcome wir können immer noch alles ändern Ready-to-use Produktfeatures sofort nach jedem Sprint Fail Fast: Falls ein Sprint unbrauchbare Resultate liefert der Schaden ist begrenzt Wir arbeiten in einem Team ohne Grenzen zwischen Kunde und Lieferant Mehr Arbeit für uns! Entwickler machen eh was sie wollen, der Fachbereich kann nicht wirklich wirksam steuern Dokumentation oft too lean und deshalb unzureichend aus Complianceund Audit-Sicht Liefergegenstände sind nicht genau definiert im Vertrag Es wird nicht alles geliefert Hohe Risiken sowohl bei T/M als auch bei Fixed Price 20

21 Welche Haltung nimmt der Stakeholder an? Welche Einflussfaktoren bestimmen die Grundhaltung gegenüber Agil? Mehr Beteiligung für uns! Der Fachbereich legt immer die Prioritäten fest für jeden Sprint Changes are always welcome wir können immer noch alles ändern Ready-to-use Produktfeatures sofort nach jedem Sprint Fail Fast: Falls ein Sprint unbrauchbare Resultate liefert der Schaden ist begrenzt Wir arbeiten in einem Team ohne Grenzen zwischen Kunde und Lieferant Mehr Arbeit für uns! Entwickler machen eh was sie wollen, der Fachbereich kann nicht wirklich wirksam steuern Dokumentation oft too lean und deshalb unzureichend aus Complianceund Audit-Sicht Liefergegenstände sind nicht genau definiert im Vertrag Es wird nicht alles geliefert Hohe Risiken sowohl bei T/M als auch bei Fixed Price 21

22 Welche Haltung nimmt der Stakeholder an? Welche Einflussfaktoren bestimmen die Grundhaltung gegenüber Agil? Typische Einflussfaktoren: Vertrauen zum Agilen Team Vertrauen in die Fähigkeiten des Agilen Teams Die Größe des Risikos (Impact x Probability) (Die Menge an) Erfahrungen mit früheren Projekten Vorherrschende Meinungen im Kollegenkreis, Beeinflussung durch Vorgesetzte und Kollegen Aufgeschlossenheit gegenüber neuen Vorgehensweisen Streben nach Erfolg vs. Angst vor Misserfolg Training und Ausbildung, Wissen und Souveränität 22

23 Wie kann man Agil erfolgreich verkaufen? 23

24

25 Offen und ehrlich sein (1/2) Nicht die Anforderungen werden detailliert fixiert, sondern Ressourcen und Zeit Änderungen oder Re-work können ggfs. Konsequenzen haben wie den Wegfall von Low-Prio Features 25

26 Offen und ehrlich sein (2/2) Resourcen & Zeit sind unsicher Finaler Anforderungsumfang ist unsicher Quelle: Ryan Matena, Ready for Agile, 9/28/06 26

27 Transparenz schaffen Agile Vorgehensweise und konkrete Anpassungen im Projekt erläutern, z. B. wie Zeremonien gestaltet werden Einfaches Reporting ohne unnötige IT-Komplexität mit Information Radiators, z.b. Big Visible Charts Backlog, Burn-Down Chart, Issue Tracker, Risk Register Planabweichungen transparent kommunizieren Reporting-Artefakte für jeden leicht zugänglich 27

28 Das Daily Stand-Up Meeting Daily Scrum Every 24 hours 15 Min I did I plan to do. I did I plan to do. I did I plan to do. 1. What I did since the last meeting 2. What I plan to do before the next meeting 3. Any impediments to my work I did I plan to do. Every 24 hours I did I plan to do. Quelle: Watermark Learning 28

29 Referenzen aufzeigen Bericht über erfolgreiches Leuchtturm-Projekt Nach Möglichkeit bewährtes Agiles Projektteam einsetzen Reale Reporting Artefakte aus dem Projekt demonstrieren Authentische Reaktionen auf Planabweichungen Kosteneinsparungen durch Agil Fehler und Lessons Learned in diesem Projekt Was wurde nicht realisiert? 29

30 Wissen vermitteln Professionelles Coaching und Trainings für den Fachbereich ermöglichen, z.b. Product Owner in Scrum Backlog Items (User Stories) und Acceptance Criteria zusammen mit dem Fachbereich exemplarisch formulieren Den Vertretern aus dem Fachbereich die Fähigkeiten und die Verantwortung für die kontinuierliche Priorisierung des Backlogs geben 30

31 Das Dilemma des Teilzeit-PO Ein Product Owner aus dem Fachbereich steht selten dem Projekt zu 100% zur Verfügung Das Tagesgeschäft im Fachbereich hat üblicherweise Vorrang vor dem Projekt Dem Product Owner aus dem Fachbereich fehlt es oft an Erfahrung und Ausbildung in agilen Projekten Orientierung fällt schwer 31

32 Ein PO-Team als Lösung Der Lead Product Owner aus dem Fachbereich wird unterstützt bei der Definition von User Roles / Personas Erhebung von Anforderungen von Stakeholdern/Usern Definition von Epics, User Stories und Acceptance Criteria Priorisierung und dem Managen des Product Backlogs Moderation der Story Workshops Identifikation von Themes/Epics für Releases Iterations- und Releaseplanung Schätzung für Tasks, Personal- und Budgetbedarf Analyse der Auswirkungen der neuen Lösungen Erstellung von Übergangsanforderungen (Transition Requirements) Durchführung des Akzeptanztests, Go-Live und Early Production 32

33 Das PO-Team (ein Beispiel) Der Lead PO aus dem Fachbereich hat das letzte Wort bei der nutzenorientierten Priorisierung I am a Dev SME I am the Lead PO I am a Business Analyst Der Business Analyst managed den Backlog Der Business Analyst formuliert User Stories und Akzeptanzkriterien Der Development Subject Matter Expert berät bzgl. der technischen Abhängigkeiten, Machbarkeiten und Risiken 33

34 Erfolgskritische Product Owner Skills Product Owner aus dem Fachbereich sollten Collaborative Representative Authorized Committed Knowledgeable sein! 34

35 Some Stories about User Stories Anforderungen in agilen Projekten werden meist in Form sog. User Stories geschrieben Eine User Story hat folgende Komponenten: Rolle wer, also der User (Persona) der Story Ziel was der User mit der Story erreichen möchte Motivation warum der User das Ziel erreichen möchte Achtung: nicht für alle Anforderungen ist es sinnvoll, sie als User Story zu formulieren 35

36 User Story - Template As a <user role>, I can <goal> so that <motivation or benefit>. Quelle: Watermark Learning 36

37 User Story ein Beispiel As a boat owner, I can update my boat s availability to show when the boat is available. Quelle: Watermark Learning

38 Die drei C s Die drei 3 C s für User Stories : Card: Eine aufgeschriebene Beschreibung (oft als Karteikarte oder post-it) Conversation: das Diskutieren der Story sorgt für das notwendige Verständnis und erklärt auch Details Confirmation: mit Hilfe von (Acceptance) Tests wird festgestellt, ob eine Story implementiert ist

39 INVEST Kriterien für User Stories Gute User Stories sind Independent Negotiable Valuable Estimable Small Testable 39

40 Auf einem Bein kann man nicht stehen. Oder doch? 1. User Story 2. Acceptance Criteria

41 Acceptance (Test) Criteria Die sog. Acceptance Criteria werden verwendet um festzustellen bzw. zu testen, dass eine User Story korrekt und vollständig implementiert ist Acceptance Criteria liefern (den Entwicklern) die notwendigen Details zu den User Stories Welches Verhalten erwartet der Kunde Wie gut (mit welcher Qualität) muss die Lösung funktionieren Nicht-funktionale Anforderungen Der Product Owner liefert die Acceptance Criteria

42 Acceptance Test Format Bewährtes Format für Acceptance Tests: Unter der Voraussetzung, dass <Vorbedingung> (optional) wenn ich <die Aktion ausführe> erwarte ich <das Resultat>. Der Haupt-Testfall sollte den Happy Path bzw. das Drehbuch der Demo wiedergeben

43 Acceptance Test ein Beispiel User story: As a boat owner, I can update my boat s availability to show when the boat is available. Acceptance tests: Given that I have listed a boat for charter: When I select my boat s available dates, I expect to see a calendar showing when my boat is available. When my boat s calendar is displayed, I expect to be able to block out a range of dates. When I have blocked out a range of dates, I expect the boat s calendar to be updated to display the time as unavailable. When a charter is arranged through the site, I expect that the boat s calendar will be automatically updated with the charter dates blocked. When a charter is cancelled, I expect that the charter dates will be removed from my boat s calendar automatically. Quelle: Watermark Learning 43

44 Aspekte möglicher Vertragsformen Festpreis Budget sehr unsicher da nur grob geschätzt Gegensteuern des Lieferanten durch Kompromisse in der Qualität Änderungen führen stets zu aufwendigen Nachverhandlungen (Change Request Prozess) Deshalb werden Änderungen ungerne gesehen, notwendige Anpassungen unterbleiben, Auftrag wird abgearbeitet wie spezifiziert Time & Material das Risiko für den Lieferanten ist überschaubar, aber für den Kunden maximal hoch Entwickler können sich theoretisch Zeit nehmen Gefahr von Gold-Plating bzw. technischen Detaillösungen ohne Wert Budgetüberschreitungen bzw. deutliche Scope- Einbußen sind Regelfall Kunde hat maximalen Kontrollaufwand um o.g. Risiken vorzubeugen Agiler Festpreis Vertragsgegenstand als detaillierte Vision (Epics) Aufwände werden auf Basis von Referenz-User- Stories formuliert Scope Governance á la Exchange for Free Scope Eskalationsprozess Vernünftiger Riskshare- Ansatz Kunde kann im gesteckten Rahmen steuern (PO priorisiert) Qualitätsverantwortung bleibt beim Lieferanten

45 Fazit In vielen Unternehmensbereichen, insbesondere in der Software-Entwicklung, wird Agil zum Imperativ! Der Product Owner ist hier eine kritische Rolle, für die der BABOK Guide anerkannte Best Practices liefert, auch jenseits der Scrum Theorie. Es reicht nicht, Anforderungen in User Stories umzuformulieren; man benötigt noch viele andere Elemente Erfolgreiche agile Projekte sind nur mit geeigneten Rahmenbedingungen/Verträgen möglich

46 Mr. Super-PO s Skills: Voice of the Customer Understands Rationale Advertises for the Project Facilitates workshops Elicits Requirements Writes User Stories Prioritizes Backlog Writes Acceptance Tests Evaluates Solution Continuously Improves Agile Contributes to good contracts Is a Nice Guy ;-) 46

47 Unser nächstes Chaptermeeting Modellierung in der Business Analyse Termin: 14. Juni 2016, 10:00 bis 14:00 Ort: Signavio GmbH, Nürnberger Straße 8, Berlin Anmeldungen bei XING oder Vorläufige Agenda 10:00 Empfang und Kaffee 10:30 Impulsvortrag 1 Signavio GmbH 11:00 Networking-Kaffee 11:30 Effektive Kommunikation in der Business Analyse mit den richtigen Modellen - R. Wendt 12:15 Fingerfood Lunch 13:15 Impulsvortrag 3 Vortragsthema zu Business Analyse und Modellierung gesucht 14:00 Ausklang und Ende der Veranstaltung 47

48 Vielen Dank! Kontakt: IIBA Germany Chapter e.v. Rainer Wendt, Präsident 48