Direkt zum Hauptbereich

Scrum und PRINCE2 - Rolle des Product Owners sinnvoll besetzen

Wenn wir Scrum und PRINCE2® zusammen anwenden wollen, müssen wir uns mit der Frage der Rollen auseinandersetzen. Die Rolle des Product Owners ist besonders wichtig zu klären. Wie können wir diese Rolle in einem Projekt am sinnvollsten einbinden?

Immer wieder rutscht die Kombination von Scrum und PRINCE2 für die erfolgreiche Abwicklung von Projekten ins Rampenlicht. PRINCE2 hilft der Produktentwicklungsmethode Scrum in Bereichen wie Business Case, Risikomanagement etc. Nach PRINCE2 geleitete Projekte profitieren von Scrum durch den Team-Fokus, den Scrum Master und Timeboxing.

Wenn wir Scrum und PRINCE2 zusammen anwenden wollen, müssen wir uns mit der Frage der Rollen auseinandersetzen. PRINCE2 definiert Rollen für einen klassischen Projektmanager, einen Lenkungsausschuss, Teammanager, das Team und ein paar weitere. Bei Scrum gibt es das Entwicklungsteam, den Scrum Master und den Product Owner./1/ Gerade weil die Kommunikation und Zusammenarbeit kritisch für den Projekterfolg ist, müssen wir die zwei Welten zusammenbringen.

Die Rolle des Product Owners im Projekt ist m. E. besonders wichtig zu klären. Wie können wir diese Rolle in einem Projekt am sinnvollsten einbinden?

Die Wichtigkeit des Product Owner wird häufig unterschätzt. Die Scrum Autoren betonen, dass der Product Owner die Verantwortung für die Produkte trägt. Damit ist eine volle "Accountability" gemeint, und zwar gegenüber dem Kunden und den Anwendern, die die Produkte beauftragt haben./2/ Deshalb ist diese Rolle nicht nur ein Bindeglied zwischen dem Entwicklungsteam und den Anwendern. Sie muss auch sowohl für die Anforderungen als auch deren Priorisierung gerade stehen.

Wie können wir diese Rolle sinnvoll in einem Projekt besetzen? 

Zunächst, was nicht geht: der Projektmanager übernimmt die Rolle des Product Owners./3/ Diese Rollenverschmelzung verbiegt sowohl die Verantwortung des Product Owners als auch die des Projektmanagers. Ein Product Owner verantwortet vor allem Qualität und Umfang, also die Produktanforderungen und deren Priorisierung. Darüber hinaus erteilt der Product Owner die Abnahme. Ein Projektmanager kümmert sich u. a. darum, dass Produkte innerhalb des vereinbarten Zeit- und Geldrahmen geliefert werden. Dies tut er/sie im Auftrag des Auftraggebers, der das Budget verantwortet. Wenn der Projektmanager ebenfalls die Abnahme erteilen sollte, steht er im Interessenskonflikt: "Klar nehme ich das Produkt ab, und damit beenden wir die Phase innerhalb von Budget und Zeitrahmen!"

Die deutlich bessere Rollenkombination liegt auf der Hand. Der PRINCE2-Benutzervertreter und der Scrum Product Owner haben fast deckungsgleiche Aufgabenbeschreibungen. Der Benutzervertreter vertritt die Anliegen der Anwender, insbesondere im Hinblick auf den gewünschten Nutzen und alle Produktanforderungen. Der Benutzervertreter in PRINCE2 muss auch Entscheidungskompetenz in diesen Themen zum Projekt mitbringen. Von seinem Sitz im Lenkungsausschuss kann er konfliktfrei Abnahmen erteilen.

Darüber hinaus steht der Benutzervertreter als Mitglied des Lenkungsausschusses auf Augenhöhe mit dem Auftraggeber, der das letzte Wort zum Thema Budget und Nutzen hat. Die Priorisierung der Anforderungen betrifft u. a. das Budget. Deshalb muss auf LA-Ebene entschieden werden, welche Teile mit dem begrenzten Budget entwickelt werden.

Allerdings spielt in Scrum der Product Owner eine aktivere Rolle, als für den PRINCE2-Benutzervetreter vorgesehen ist.  Damit dieser Seniormanager nicht von Details überrollt wird, muss man in größeren Projekten überlegen, ob mehrere Product Owners notwendig sind, die an  Benutzervertreter berichten und entscheidungsberechtigt für Teilprodukte sind.

Fakt ist: wenn Kunden und Anwender nicht eng im Anfordungsmanagement und im Priorisierungsprozess eingebunden sind, ist der Projekterfolg und die Arbeit des Entwicklungsteams deutlich erschwert. Deshalb haben Scrum und PRINCE2 die Notwendigkeit des Product Owners oder des Benutzervertreters erkannt, die aktiv Anwender-Interessen vertreten und durch Entscheidungsautorität umsetzen können.

Wenn Sie schon Erfahrungen mit der Kombination von PRINCE2 und Scrum gemacht haben, teilen Sie uns und anderen Lesern mit, wie es ausgegangen ist! Was ist gelungen? Wo hat es gehapert?

Anmerkungen

  • /1/ Die besten Informationen zu den zwei Methoden bieten die Handbücher selbst.  Für PRINCE2: Office of Government Commerce, Erfolgreiche Projekte managen mit PRINCE2, (London: TSO, 2009). Für Scrum: Das Scrum Guide, frei verfügbar unter Scrum.org. Zum Thema Kombination PRINCE2 und Scrum, siehe den Beitrag von Jan Fischbach im Teamworkblog "Ergebnisse liefern mit Methode" und den Vortrag "Scrum und PRINCE2: Together making projects work" vom aktuellen Autor bei den Scrum Days 2013 in Berlin.
  • /2/ Der Scrum Guide. Auch Jeff Sutherland hat unterstrichen, wie wichtig diese "Accountability" des Product Owners für den Produkterfolg ist (Scrum Days, Juni 2013, Berlin).
  • /3/ H.-P. Ritt und S. Jäger, Steuerbare Kraft: Die Integration von Prince2 und Scrum, Computerwelt.at, 11. Juli 2013.  Trotz einiger guter Überlegungen laufen die Autoren zum Thema Rollen fehl. Die Autoren sehen den Product Owner in seiner Verantwortung überfordert. Sie empfehlen daher, den Product Owner gleichzeitig als Projektmanager agieren zu lassen, so dass er die Unterstützung vom Lenkungsausschuss besser einholen kann und damit entlastet wird. Allerdings ist persönliche Accountability ein zentraler Erfolgsfaktor dieser Rolle, auch aus Sicht der Scrum-Autoren. Dies erfordert eine gewisse Seniorität, genau wie PRINCE2 sie vom Benutzervertreter verlangt. Der Verdacht liegt nahe, dass im Umfeld der Autoren einige Product Owner ernannt wurden, die wegen fehlender Seniorität ungeeignet und überfordert waren.
  • PRINCE2 is a registered trademark of the Cabinet Office.

Kommentare

  1. Dem: "Zunächst, was nicht geht: der Projektmanager übernimmt die Rolle des Product Owners./3/ Diese Rollenverschmelzung verbiegt sowohl die Verantwortung des Product Owners als auch die des Projektmanagers." kann ich nicht zustimmen. Im Gegenteil:

    Als Basis meiner Überlegungen möchte ich
    http://www.computerwoche.de/a/prince2-oeffnet-die-tuer-fuer-scrum,2489890
    nutzen.
    Dem darin Geschriebenen kann ich mich weitestgehend anschliessen. Einen essentiellen Aspekt an der Schnittstelle "PM auf Basis PRINCE2 / Entwicklung der Produktinkremente durch ein oder mehrere Scrum-Teams" möchte ich aber etwas diffrenzierter betrachten:

    Für mich ist der PRINCE2-Projektmanager als Verantwortlicher für das Tagesgeschäft innerhalb der jeweils laufenden PRINCE2-„Durchführungsphase“ innerhalb des von Lenkungsausschuss festgelegten Spielraums eindeutig und unabhängig von der Projektgrösse der Scrum-Product Owner (PO). Gemäss PRINCE2 "beauftragt" er den "Teammanager" (bzw, die verschiendenen Teammanager).
    Das aber folgt einer Vorgehensweise, bei der der Teammanager seinerseits die Leute seines Teams mit den Detailarbeiten betraut und für deren Koordination sorgt. Bei einem Scrum-Team aber verhandeln alle Entwickler (= das "Entwicklerteam" als Teil des "Scrum Teams") gemeinsam und direkt mit dem PO (= PRINCE2-Projektmanager) und organisieren dann ihre Detailarbeit selber. Im Fall eines solchen Scrum Teams (bestehend aus dem PO, den Entwicklern und dem Scrum Master) wird der PRINCE2-Teammanager zum Scrum Master (SM).
    Als PRINCE2-Teammanager ist er verantwortlich für die Herstellung der Produkte gemäss Produktbeschreibungen. Das passt gut zur Verantwortung des SM gemäss Scrum Guide:
    ""
    • Vision, Ziele und Einträge des Product Backlogs gegenüber dem Entwicklungs-Team klar kommuniziert;
    • das Scrum-Team darin unterrichtet, klare und schlüssige Product Backlog Einträge zu erstellen;
    • Coaching des Entwicklungs-Teams zu selbstorganisiertem und interdisziplinären Handeln;
    • Unterrichtung und Führung des Entwicklungs-Teams bei der Erstellung von Produkten mit hohem Wert;
    • Entfernung von Hindernissen, die den Arbeitsfortschritt des Entwicklungs-Teams aufhalten
    ""
    Insbesondere das "Vision, Ziele und Einträge des Product Backlogs gegenüber dem Entwicklungs-Team klar kommuniziert" und "Unterrichtung und Führung des Entwicklungs-Teams bei der Erstellung von Produkten mit hohem Wert" entspricht der Verantwortuing des PRINCE2-Teammanager für die Herstellung der Produkte gemäss Produktbeschreibungen.
    (Allerdings habe ich schon viele SM erlebt, die sich im Gegensatz dazu "nur" als Coaches des Teams sehen und diese Fühurngsverantwortung nicht übernehmen wollen - oder können.)

    Die in http://www.computerwoche.de/a/prince2-oeffnet-die-tuer-fuer-scrum,2489890,5 genannte "Variante 2" (Der Product Owner ist der Prince2-Team-Manager) sehe ich nicht. Sie ist für mich ein Verstoss gegen die "Logik" von Scrum.

    Was aber, wenn dieser PRINCE2-Projektmanager = PO es mit drei oder mehr Scrum-Teams zu tun hat?

    Das ist auch bei "pure Scrum" immer dann der Fall, wenn mehrere Teams an einem umfangreicheren Produkt arbeiten.
    Es gibt dann mehr als einen PO, sodass kein PO mehr als 2 Teams betreut. Und diese PO bilden ein "PO-Team", das am besten auf der Ebene des "Programm-Managements" angesiedelt ist. Bezogen auf PRINCE2 haben wir es dann also mit einem Projektmanager-Team bestehend aus Teil-PLs und einem Gesamt-PL zu tun.

    AntwortenLöschen
  2. Interessant das Kommentar insofern, dass es mein Skeptis hinsichtlich der Projektmanager als Product Owner widerspricht.

    Dadurch kommen bei mir einige Fragen im Kopf:

    1. Wie verstehen wir das Wort "Owner" im Product Owner?

    2. Warum nicht der PRINCE2-Benutzervertreter als PO? Was spricht dagegen?

    3. Wie lösen wir den Interessenskonflikt des Projektmanagers?

    Meine Antwort auf Frage 1 ist, dass die "Eigentümerschaft" des Product Owner muss ernst genommen werden. D.h. jemand mit einem wesentlichen, "aus dem Besitz heraus" Interesse muss die Anliegen der Anwender und den gewünschten Nutzen innerhalb des Projektes vertreten. Als beautragte Person hat der PM dieses Interesse in seine Tiefe nicht.

    Dies ist m.E. sehr gut mit dem Benutzervertreter aus PRINCE2 gelöst (Frage 2). Allerdings wird diese Rolle in Projekten häufig vernachlässigt (was uns wiederum dazu führt, diese Verantwortung vom PM zu verlangen).

    Zu Frage 3 sehe ich ein großes Problem, wenn der PM die Abnahme der Produkte erteilen sollte. Er gibt damit effektiv die Produkte frei, deren Erstellung er selber managen muss. Dies ist besonders problematisch, wenn der PM (wie häufig der Fall) vom Seiten des Lieferants gestellt wird.

    Der TM als Scrum Master dürfte m.E. wenig Probleme darstellen.

    Ihre Antworten auf die Fragen interessieren mich genau so. Ich freue mich auf den weiteren Dialog!

    AntwortenLöschen
  3. ad 1:
    Das Wort "Owner" im Zusammenhang mit dem "Product Owner" bei Scrum verführt zu hohen bis unrealistischen Erwartungen, siehe Seite 16 in http://www.korn.ch/archiv-open/agile-fuer-CMMI.pdf
    Letzten Endes ist der Scrum-PO "the member of the Agile Team who serves as the customer proxy, and is responsible for working with the Product Manager (or Chief Product Owner) and other stakeholders — including other product owners and the team — to define and prioritize the Team Backlog so that the solution effectively addresses user needs while maintaining technical integrity." (zitiert aus http://scaledagileframework.com/product-owner/)
    Das passt auch gut zum "Core Scrum" (http://agileatlas.org/images/uploads/AgileAtlas-DE.pdf): "Der Product Owner wird typischerweise *** von der Organisation beauftragt ***, das Produkt „herauszubringen", und er ist typischerweise derjenige, von dem man erwartet, dass er sein Bestes tut, um alle Stakeholder zufriedenzustellen. Der Product Owner tut das, indem er das Product Backlog führt, und sicherstellt, dass das Product Backlog und der Fortschritt in Bezug darauf sichtbar gemacht werden. "
    Der PO ist also - wie der PM bei PRINCE2 - eine "beauftragte Person" und er agiert nicht "aus dem Besitz heraus". "Besitzer" ist stets das Unternehmen des Lieferanten oder des Kunden. Alle anderen sind "vom Unternehmen Beauftragte".

    ad 2:
    Es geht ja darum, vom wen des Entwicklerteam "formell" beauftragt wird. Und das ist bei PRINCE2 nicht der Business-Repräsentant, der die Sicht des Kunden bei täglichen Entscheidungen repräsemntiert und die Business-Szenarios beschreibt sondern der PM. Bei PRINCE2 beauftragt er den "Teamleiter", der seinerseits für "seine" Leute die Detailplanung von Timebox-Inhalten sowie täglichen Arbeitsabläufen und –inhalten macht, im Fall von Scrum übergibt er sie an / verhandelt sie mit dem Team. Damit aber macht er genau das, was der PO macht.

    ad 3:
    Dieser Interessenskonflikt ist derselbe wie beim PO: Auch dieser "managed" sein Produkt / Teilprodukt (insbesondere via die Pflege des Product Backlogs) und gleichzeitig "akzeptiert" er auch die Ergebnisse gegenüber dem Team - jedoch vorbehaltlioh der Stakeholder-Rückmeldungen beim "Review".
    ABER, ACHTUNG: Bei Scrum gibt es keine "formelle" Abnahme der Produkte. Im Scrum Guide steht ausdrücklich: "Es handelt sich hierbei um ein *** informelles *** Meeting; die Präsentation des Inkrements ist dazu gedacht, Feedback hervorzubringen und Zusammenarbeit zu fördern."

    Für eine "formelle" Abnahme muss ausserhalb und zusätzlich zu Scrum etwas vereinbart werden. Etwa aus Basis von PRINCE2.

    AntwortenLöschen
  4. Für mich ist der Begriff "Ownership" entscheidend. Als echter Eigentümer handele ich anders, als wenn ich nur ein "Proxy" bin. Ich habe etwas zu verlieren, wenn es schlecht läuft. Das tut mir weh, und deshalb handele ich sorgfältiger.

    Einige Projektprobleme stemmen von der fehlenden Ausübung der mit Eigentümerschaft gebundenen Verantwortung. Dies erfolgt in mehreren Varianten:
    - Es gibt kein Benutzervertreter bzw. Product Owner, sondern nur ein Auftraggeber/Customer*, der die Anwender-Rolle "by Default" übernimmt.
    - Es gibt ein BV/PO ohne ausreichende Entscheidungsautorität.
    - Der Vertreter stemmt nicht aus der betroffen Gruppe.

    Wir haben dann zwei Arten von BV/PO:
    - ein robuster BV/PO aus dem Anwenderkreis
    - ein Proxy-BV/-PO, der nicht vom Anwenderkreis stemmt, aber der sich verpflichtet, die Anwender zu vertreten.

    Ein Proxy-BV/-PO kann sicherlich effektiv sein. Aber im Vergleich zum robusten BV/PO steigt das Risiko, dass die Rolle nicht im Anwendersinne ausgeübt wird. Wichtig ist allerdings, dass der BV/PO die volle Accountability für das Produkt übernimmt. Jeff Sutherland hat das betont, und so kann auch die erwähnten Zitate gelesen werden.

    Ich bleibe deshalb bei meinem Ausgangspunkt: der Projektmanager ist als PO nicht geeignet. Die Beauftragung ist nicht entscheidend, sondern die Fähigkeit, Nutzen- und Qualitätsanforderungen zu vertreten. Der Projektmanager ist nur ein Manager, kein Owner. Es entstehen Konflikte zwischen Budget, Zeit, Qualität und Nutzen, die nur einen Owner lösen kann. Insbesondere wenn der PM vom Lieferanten kommt, bedeuten die Konflikte ein höheres Risiko für das Projekt.

    Wenn P2 und Scrum kombiniert werden, ist der P2-Benutzervertreter* die bessere Wahl. Gerne könnte ein Mitarbeiter aus dem Benutzerkreis die Rolle des PO ausüben, solange er direkt am BV berichtet.

    Weder der PM noch der TM in PRINCE2 spielen übrigens eine Rolle bei der formellen Produktabnahme. Dies tut der pro (Teil)Produkt ernannte Abnahmeberechtigter. PRINCE2 empfiehlt hierfür jemand mit einem Interesse an das Produkt.


    * Der Benutzervertreter ist der Senior User in PRINCE2, nicht der "Business" Vertreter. Der Executive (Auftraggeber) vertritt der Customer-/Business-Seite (Kosten/Nutzen).

    AntwortenLöschen
  5. Beim Begriff "Product Owner" hat "Owner" nichts mit unserer Alltagsvorstellung von "Eigentümer" zu tun, so wie er etwa auch beim "Process Owner" nichts mit "Eigentümer" eines Prozesses (der ja der Firma "gehört") zu tun hat. Sondern er ist - im Fall von Scrum - jene von der Organisation beauftragte Person, welche gegenüber dem Entwicklerteam die aus Kundensicht zu realisierenden Anforderungen vertritt. Und zwar so, dass er sie für die Entwickler verständlich formulieren kann. Deshalb ist es unvorteilhaft, wenn dieser PO vom Kunden oder Benutzer gestellt wird. Und deshalb unterscheidet das SAFe zwischen "Produktmanager" und "PO", siehe Tab.1 in http://scaledagileframework.com/product-owner/

    Auf Basis von Abb 4.6 im Buch "PRINCE2:2009 - für Projektmanagement mit Methode - Grundlagenwissen und Zertifizierungsvorbereitung für die PRINCE:2009-Foundation-Prüfung" ist die Verbindung vom Scrum (= Entwicklerteam) mit PRINCE2 recht klar:

    Der "Lenkungsausschuss" besteht aus:
    - Benutzervertreter
    - Auftraggeber
    - Liefantenvertreter
    (Die Aufgaben und Verantwortlichkeiten sind im o.e. Buch auf Seite 130 gut erklärt)

    Dieser Lenkungsausschuss definiert den Rahmen, in dem sich der Projektmanager bewegen kann. Und dieser PM ist verantwortlich für das Tagesgeschäft und alle Tätigkeiten, wobei er die Verantwortlichkeiten für die Produkterstellung an den "Teammanager", im Fall von Scrum an das Team als Ganzes, übergeben kann.

    Der Teammanager (bei Scrum das Team als Ganzes mit dem Scrum Master als dienende Führungskraft des Teams) ist verantwortlich für die Herstellung der Produkte und berichtet an den PM.

    Bei der Kombination von PRINCE2 mit Scrum verhandelt das Team die zu erledigenden Arbeiten somit mit dem PM (der dann dem PO entspricht) auf Basis des Backlogs. An der Erstellung des Backlogs wirkt der Benutzervertreter im Lenkungsausschuss entscheidend mit, gegenüber dem Team wird er aber NUR VOM PM (als PO) vertreten.
    (Im Einklang mit dem Scrum Guide: "Der Product Owner kann ein Gremium repräsentieren, jedoch ist es nur dem Product Owner erlaubt, die Fertigstellungsreihenfolge der Einträge des Product Backlog zu verändern.")
    Und das Team "berichtet" an dem PM in seiner Rolle als PO.

    Zusätzlich gibt es in PRINCE2 noch die vom PM unabhängige Rolle "Projektsicherung" als qualitätssicherndes Prüforgan im Auftrag des Lenkungsausschusses.
    Im Fall von Scrum überprüft die Projektsicherung auch die Ergebnisse und den Arbeitsstatus des Teams, darf dem Team aber keine Aufträge erteilen sondern muss das in den Backlog einschleusen, der vom PM=PO gegenüber dem Team vertreten wird.






    AntwortenLöschen
  6. Dieser Kommentar wurde vom Autor entfernt.

    AntwortenLöschen
  7. Noch ein Gedanke zum Obigen:

    Zentral bei Scrum ist (zitiert aus dem Scrum Guide):

    """""
    Der Product Owner ist als einzige Person für die Verwaltung des Product Backlog verantwortlich.
    „Product Backlog Verwaltung" beinhaltet (u.a.) die Anordnung der Einträge („ordering") in der gewünschten Fertigstellungsreihenfolge, durch welche die Ziele des Vorhabens optimal unterstützt werden und die Sicherstellung, dass das Product Backlog für alle Beteiligten einsehbar, transparent sowie klar ist und dass es anzeigt, woran das Scrum Team als nächstes arbeiten wird.
    Es ist nur dem Product Owner erlaubt, die Fertigstellungsreihenfolge der Einträge des Product Backlog zu verändern. Jede andere Person, die Einfluss auf diese Reihenfolge nehmen will, muss den Product Owner von der Änderung überzeugen.
    Niemand darf das Entwicklungs-Team anweisen, mit anderen Anforderungen als den im Product Backlog festgelegten zu arbeiten und dem Entwicklungs-Team ist es nicht erlaubt, Arbeitsanweisungen von anderen Personen als dem Product Owner anzunehmen.

    Die Arbeit, die während des Sprints zu erledigen ist, wird im Sprint Planning geplant. Der Arbeitsplan wird in gemeinschaftlicher Arbeit durch das gesamte Scrum Team (= Product Owner + Entwicklerteam + Scrum Master) erstellt.
    Das Sprint Planning ist in zwei Teile aufgegliedert, von denen jeder Teil die Hälfte der Dauer einnimmt, die für die gesamte Besprechung zur Verfügung steht.
    Teil Eins: Was wird in diesem Sprint getan?
    In diesem Teil erarbeitet das Entwicklungs-Team eine Prognose („forecast") für die Funktionalität, die im Sprint entwickelt wird. Der Product Owner stellt dem Entwicklungs-Team die geordneten Einträge des Product Backlogs vor und das gesamte Scrum Team (= Product Owner + Entwicklerteam + Scrum Master) verschafft sich gemeinsam ein Verständnis über die im Sprint zu verrichtende Arbeit.
    Ausschließlich das Entwicklungs-Team bestimmt, wie viele Einträge aus dem Product Backlog zur Erledigung im Sprint ausgewählt werden, da nur das Entwicklungs-Team bewerten kann, was es im kommenden Sprint zu leisten vermag.
    Nachdem das Entwicklungs-Team eine Prognose darüber abgegeben hat, welche Elemente des Product Backlogs im Sprint geliefert werden, wird das Sprint-Ziel durch das Scrum Team (= Product Owner + Entwicklerteam + Scrum Master) erarbeitet.
    Teil Zwei: Wie wird die ausgewählte Arbeit fertig gestellt?
    Nachdem die Arbeit für den Sprint ausgewählt wurde, entscheidet das Entwicklungs-Team, wie diese Funktionalität während des Sprints in Form eines "done" (fertigen) Inkrements umgesetzt wird.
    Der Product Owner kann während dieses zweiten Teils der Besprechung anwesend sein, um für Rückfragen zu den ausgewählten Einträgen des Product Backlogs zur Verfügung zu stehen und um bei der Auflösung von Zielkonflikten zu helfen. Wenn das Entwicklungs-Team feststellt, dass es zu viel oder zu wenig Arbeit für den Sprint ausgewählt hat, kann es den Inhalt des Sprint Backlogs mit dem Product Owner erneut verhandeln.
    ((siehe Fortsetzung))

    AntwortenLöschen
  8. ((Fortsetzung))

    Ein Sprint Review wird am Ende des Sprints abgehalten, um das Inkrement zu untersuchen, und das Product Backlog, wenn nötig, anzupassen. Im Sprint Review ermitteln das Scrum Team (= Product Owner + Entwicklerteam + Scrum Master) und die Stakeholder gemeinsam, was in dem Sprint fertig gestellt wurde. Auf der Basis dessen - und möglicher Änderungen am Product Backlog während des Sprints - erarbeiten die Teilnehmer die nächsten Dinge, die angegangen werden könnten. Es handelt sich hierbei um ein informelles Meeting; die Präsentation des Inkrements ist dazu gedacht, Feedback hervorzubringen und Zusammenarbeit zu fördern.
    """""

    Der Bezug des Entwicklerteams zur "Aussenwelt" läuft also IMMER über den PO. Und NUR DER PO verhandelt mit dem Team, wann es was in welcher Qualität (= "non functional requirements") zu tun hat.

    Falls es neben diesem Scrum-PO einen PRINCE2-PM geben sollte, dann stellt sich die Frage, was er denn dann nebst diesem PO noch zu tun hat.
    Also: Bei der Kombination von PRINCE2 mit Scrum übernimmt der PRINCE2-PM auch die Rolle des Scrum-PO.

    AntwortenLöschen
  9. Diese Seite gibt Ihnen eine gute Übersicht über das PRINCE2 Foundation Manual: http://de.prince2.wiki

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.