Wir haben uns für ein Agiles Vorgehen entschieden, weil wir der Ansicht sind, dass der gemeinsame kreative Prozess, die Stärkung der Kommunikation und Interaktion uns langfristig ein besseres Produkt und eine bessere Mitarbeiterzufriedenheit beschert (Zumindest hoffe ich, dass das einige der Gründe für Ihre Entscheidung sind). Diese Dinge unterschreibe ich jederzeit und unterstütze sie aus vollem Herzen. Doch vergessen wir nicht, bei all der lebhaften Diskussion und der Konsensfähigkeit aller Beteiligten muss am Ende des Tages einer die Entscheidung treffen.
Sie wissen sicherlich alle bereits, dass diese Rolle in der Theorie dem Product Owner zukommt. Vielleicht haben Sie jedoch ein ungutes Gefühl dabei, dem Product Owner so viele Kompetenzen an die Hand zu geben, und schlagen sich mit dem Gedanken, ein Product Owner Team einzusetzen. Bitte vertrauen Sie mir: lassen Sie es. Vergessen Sie den Gedanken, in aller Regel geht es schief.
Vielleicht kennen Sie die Situation aus einem Meeting, wenn mehrere Personen gemeinsam eine Entscheidung treffen müssen: entweder es kommt zu einem faulen Kompromiss, mit dem kaum jemand bauchschmerzenfrei leben kann, oder einer setzt sich durch (in aller Regel derjenige, der in der Unternehmenshierarchie am weitesten oben steht). Seien wir ehrlich, bei solchen Gelegenheiten wird meistens nur zum Schein argumentiert, in aller Regel geht es um das Ego. Verstehen Sie mich nicht falsch. Ich verurteile das nicht. Das liegt in der Natur des Menschen. Ich habe das akzeptiert und kann damit inzwischen umgehen. Zur bestmöglichen Entscheidung wird man so jedoch nur in den seltensten Fällen kommen.
Und was geschieht, wenn die Sache schief geht? Dann war es doch eine gemeinsame Entscheidung, die alle zu gleichen Teilen zu verantworten haben. In einem Product Owner Team geschehen solche Dinge auch. Man kommt zu faulen Kompromissen, die niemandem helfen. Einer setzt seine Meinung durch, weil er einfach hartnäckiger ist als die anderen.
Und wer verantwortet die Entscheidungen gegenüber der Geschäftsleitung? Alle gemeinsam? Glauben Sie mir: im Streitfall wird einer sagen, dass es nicht seine Idee gewesen sei, um seinen Kopf doch irgendwie aus der Schlinge zu ziehen. An wen wendet sich das Entwicklungsteam bei Unklarheiten? Je nach Anforderung an einen anderen? Das alles bringt Sie nicht wirklich voran. Am effektivsten arbeitet ein Team, wenn es einen Ansprechpartner hat, dem es vertraut. Bei mehreren Ansprechpartnern wird meistens sowieso nach Sympathie entschieden.
Wenn Ihr Projekt für einen Product Owner zu komplex ist, dann ist es auch zu komplex für ein Entwicklungsteam. Sobald Sie mehrere Teams und mehrere Product Owner haben, kommen Sie recht schnell wieder an den Punkt, dass es nur einen geben kann. Häufig wird dann von einem Chief Product Owner gesprochen. Animal Farm: einige Tiere sind gleicher als andere. Vielleicht erinnern Sie sich.
Ich möchte damit jedoch nichts Negatives zum Ausdruck bringen, ganz im Gegenteil: die Sache mit dem Chief Product Owner kann ganz wunderbar funktionieren. Es ist dabei ganz unerheblich, ob dieser selbst auch ein Team betreut oder wie ein König über den anderen thront. Das hängt eher von der Größe der Aufgabe ab. Wenn es sehr viele Teams sind, gibt es viele Dinge zu besprechen und zu entscheiden. Dann wird es mit der Zeit etwas knapp. So ab vier Teams sollte der Chief nur noch Chief sein können, damit er genug Zeit hat, sich wirklich in die zu besprechenden Dinge einzufinden.
Verabschieden wir uns auch von der Illusion, dass der Product Owner alles allein entscheidet. Er spricht sch mit Geschäftsleitung und anderen Interessenvertretern ab. Die »großen« Entscheidungen bereitet er vor. Er kann Dinge empfehlen und wird so zum Berater derjenigen, die wirklich die Entscheidungen treffen. Wenn diese klug sind, hören sie auf den Product Owner. Dieser hat sich mit der Materie auseinandergesetzt und (hoffentlich) viele Dinge recherchiert. Ich spreche jetzt nicht von der Frage, ob ein Gestaltungselement grün oder blau wird, ich rede von den grundlegenden Entscheidungen eines Produkts (z.B. soll es eine Mobile App geben, ja oder nein?).
Abschließend noch ein Wort der Warnung: Wenn eine Geschäftsleitung einem Product Owner nicht so weit vertraut, dass sie ihm wirklich weitreichende Entscheidungskompetenzen gibt, dann können wir uns Scrum sparen. Wenn der Product Owner zum Verwalter der Entscheidungen Anderer wird, dann hat das nichts mehr mit Agilität zu tun.
Ich kann es verstehen, wenn man noch etwas zurückhaltend ist, wenn sich die Dinge erst finden, vor allen Dingen, wenn ein Product Owner vielleicht neu ins Unternehmen gekommen ist. Wichtig ist dann jedoch, dass die Leine möglichst schnell gelockert wird. In dem Fall ist darauf zu achten, dass es schnell spürbare Veränderungen gibt, ansonsten ist der Product Owner auch im Empfinden des Entwicklungsteams nur der verlängerte Arm eines Anderen.
