Es scheint ein wenig Verwirrung bei diesem Punkt zu herrschen. Sie können manchmal lesen, dass die Retrospektive eine Sache des Entwicklerteams und des Scrum Masters sei. Vom Product Owner wird da nicht gesprochen, also nimmt der auch nicht teil? Meiner persönlichen Meinung nach ist das Blödsinn. Der Product Owner gehört als aktiver Bestandteil unbedingt mit in die Retrospektive. Er ist Teil des Teams, und das gesamte Team diskutiert darüber, was gut und was schlecht läuft.
Monat: April 2015
Wenn Sie sich sehr gut mit Agilen Methoden auskennen, dann wissen Sie schon längst, dass diese Dinge weder der Heilige Gral noch der allein selig machende Weg sind. Sowohl Kanban als auch XP als auch Scrum haben Schwächen. Sie können nicht alle Fragen beantworten, und sie sind nicht die Lösung für jedes Problem. Ich möchte nach und nach ein paar der Schwächen oder Ungereimtheiten ansprechen und Ihnen vielleicht auch hier und da den einen oder anderen Weg aus der Krise zeigen.
Wenn Sie Scrum einsetzen und sich der Product Owner mit dem Team auf ein Sprintziel verständigt, können Sie dieses Planungsmeeting in zwei Schritten oder in einem Schritt durchführen, doch was sind die Vorteile dieser beiden Optionen? Und warum ist es sinnvoll, den nächsten Sprint schon einmal vor der Planungssitzung mit einem Entwickler durchzugehen?
Das leidige Thema der Raucher (ich bin selber einer) muss kein leidiges Thema sein. Es kann sogar das Team stärken. Im Normalfall gehen die Raucher gelegentlich einzeln oder paarweise für ein paar Minuten vor die Tür, während die anderen weiter vor den Monitoren sitzen.
Sie können überall lesen, dass es eine der Hauptaufgaben des Scrum Masters sei, Hindernisse in der Entwicklung zu beseitigen. Ich muss allerdings immer wieder beobachten, dass scheinbar jeder etwas Anderes darunter versteht. Gelegentlich verbringt ein Scrum Master einen Großteil seiner Zeit damit, Dokumentationen für die Entwickler zu beschaffen oder den besten Preis für den dringend benötigten schnelleren Prozessor zu ermitteln.
Wenn ein neues Team zusammengestellt wird, ist die Bestimmung des Scrum Masters ein kritischer Punkt. Bei einem eingespielten Team, in dem sich alle beteiligten Personen gut kennen, und Scrum im Unternehmen bereits gut eingeführt ist, kann das Team selbst ein Mitglied zum Scrum Master machen. Darin ist kein Problem zu sehen. Wird das Team jedoch neu zusammengestellt, müssen sich die verantwortlichen Personen darüber im klaren sein, dass es einige Zeit braucht, bis ein Team wirklich gut funktioniert. Dabei durchläuft es vier Phasen, in der modernen Zeit bezeichnet als Forming, Storming, Norming, Performing. Ganz knapp formuliert muss es sich zunächst kennenlernen und Konflikte ausräumen, bevor es in eine Phase der Normierung kommt, in der ein allgemein akzeptiertes Vorgehen definiert wird. Erst dann kann es sein gesamtes Potential ausschöpfen.
Dem Product Owner kommt die Rolle zu, die Anforderungen von Kunden oder internen Fachabteilungen einzuholen. In der Zusammenarbeit mit einem Kunden ist das kein Problem, da es in aller Regel nur eine Partei gibt, deren Wünsche und Anforderungen berücksichtigt werden müssen. Bei einem Inhouse-Projekt wird die Sache wesentlich schwieriger. Der Product Owner steht zwischen Marketing, SEO, Geschäftsleitung, Data Analyse und noch weiteren Personen, deren Feature Requests berücksichtigt werden müssen. Dabei stehen Product Owner oft vor der schwierigen Situation, dass alle Interessenvertreter gleichzeitig Wünsche äußern, die selbstverständlich alle der höchsten Priorität unterliegen.
In Scrum ist der Product Owner als Schnittstelle nach Außen definiert, der Anforderungen der Geschäftsleitung, von Kunden, Fachabteilungen oder Usern einholt und in das Product Backlog überführt. Wie er das macht, bleibt ihm überlassen.
Scrum trifft durchaus eine ganze Reihe von Aussagen von Skalierung von Projekten und gibt uns einige Regeln an die Hand, wie wir die Arbeit im Team organisieren, zur Einbindung des Entwicklungsteams in eine unternehmensweite Projektmanagementstruktur schweigt es sich jeoch weitestgehend aus. Für Scrum ist der Product Owner die Schnittstelle nach außen. Die meisten Unternehmen sind jedoch hoch komplexe Strukturen, in denen das Entwicklungsteam mit seinem Scrum Master und seinem Product Owner nur ein kleines Stück des Kuchens ausmachen. Darum herum befindet sich oftmals ein ganz anderes Projektmanagementsystem: Prince2 (Projects in controlled Environments).
Eine Software, wie z.B. Agilo, kann uns im Agilen Vorgehen in der Entwicklung einige Aufgaben abnehmen. Wir finden automatische Auswertungen und zahlreiche Assistenten. Durch einen effizienten Einsatz und geübten Umgang sparen wir Zeit. Zusätzlich begrüßen Entwickler es, wenn alles in digitaler Form vorliegt und man bequem von seinem Arbeitsplatz aus Einsicht in alle Vorgänge nehmen kann. Prinzipiell ist das ein großer Vorteil, dennoch rate ich dringend dazu, nicht auf ein analoges Product Backlog (oder Sprint Backlog) im Sichtbereich des Teams zu verzichten, in dem wir Karten aufhängen, die wir verschieben und markieren können.
© 2024 Markus Leitner Agile Consulting & Coaching
Theme von Anders Norén — Hoch ↑