Wer kennt sie nicht die Situation. Mit dem Team wurde hart an einem Ziel gearbeitet, die gewünschten Features umgesetzt und alles getan den Zeitplan einzuhalten. Ja geschafft, die Arbeit wird präsentiert und die einhellige Meinung aller direkt Beteiligten ist, wir haben alles richtig gemacht.
Aller Beteiligten? Ja der Product Owner, verantwortlich für die Ziele des Teams hat seine Zustimmung bereits signalisiert, er ist auch zufrieden mit dem Ergebnis. Und dennoch, als das Team die Arbeitsergebnisse im Rahmen einer Review präsentiert ist die Meinung des verantwortlichen Managers vernichtend. „Alles falsch, erfüllt nicht seine Erwartungen!“ Es spielt dabei auch keine Rolle, ob die Meinung in der Review, nach der Review oder irgendwie später kund wird. Fakt ist das „Empowerment“ des PO ist hier zu Ende.
Aber was ist eigentlich passiert? Und ist es wirklich ein Problem des Managers?
Zufriedenheit und Unzufriedenheit
Es gibt sehr schlaue Menschen, wie Frederick Herzberg und Maslow, die sich mit der so genanten „Inhaltstheorie“ beschäftigt haben. Sehr spannendes Thema bei dem es um Motivation und die Bedürfnisse von Menschen geht.Und das alles ganz besonders im Bereich unseres Arbeitslebens.
Zufriedenheit und Unzufriedenheit stellen hier (Anm. bei den Einflussgrößen) aber nicht die beiden äußersten Ausprägungen einer Eigenschaft dar, sondern sind als zwei unabhängige Eigenschaften zu betrachten. Die „Hygienefaktoren“ (unzufrieden – nicht unzufrieden) sowie die „Motivatoren“ (nicht zufrieden-zufrieden) repräsentieren diese beiden Bereiche. Der Theorie nach müssen beide Ausprägungen vorhanden sein, um Arbeitszufriedenheit zu erleben.
(Zitat aus: Wikipedia zur Zwei-Faktoren-Theorie (Herzberg))
Bei der Bewertung eines Projektes bzw. eines Reviews geht es m.E. nicht um den Inhalt im Detail, sondern genau um diese Einflussgrößen und in welcher Ausprägung der einzelne diese sieht. So ist es durchaus denkbar, dass der PO und das Team sehr zufrieden mit der Arbeit sind, da sie wissen wie viel Zeit und Abstimmung hineingeflossen sind. Ein Außenstehender weiß dies nicht und bewertet nur das Ergebnis. Je nach Fertigstellung und Informationsgehalt der Kommunikation/Präsentation fällt die Bewertung ganz anders aus.
Es gehört daher viel mehr dazu zufrieden zu sein und gleichzeitig zu vermeiden, dass ein Manager unzufrieden ist.
Was ist unser Ziel und warum scheitern wir (manchmal)?
Mit Hilfe der agilen Methoden versuchen wir Eigenverantwortung, Entscheidungskompetenz, Wissen, Selbständigkeit und vieles mehr zu fördern. Doch fast jeder bemerkt, wie schwierig dies in der Realität ist. Da fühlen sich POs nicht in der Lage, da sie das Gefühl haben nicht empoered zu sein. Auf der andern Seite stehen Manager, die glauben nicht vertrauen zu können. Und dann gibt es da noch die vielen internen und externen Beobachter oder sogar Kunden. Jeder hat eine Meinung, die sich auf das fragile Gefüge eines agilen Teams auswirkt.
Ich bin der Ansicht, dass die Probleme daher viel tiefer liegen und daher sind Konzepte wie Lean Startup auch so sinnvoll. Interessanter Weise verbinden sich hier für mich kommerzielle Projekte mit der nicht kommerziellen Open Source Welt und eigentlich können die Unternehmen hier nur von den vielen tausend Freiwilligen in der Open Source Szene lernen.
Erfolgreiche Open Source Projekte funktionieren so gut, dass mittlerweile selbst Bücher über die Führungsstrukturen geschrieben werden, denn wie schaffen es diese Projekte über Jahrzehnte immer wieder Menschen zu motivieren Arbeit, ohne Geld, in die gleiche Sache zu stecken? Der Erfolg liegt nicht in der Führung, sondern in der Sache! Es geht nicht darum, ob Projekte mit Hilfe eines „beloved leaders“, einer „Demokratie“ oder im Crowd-Sourcing geführt werden. In der Regel unterwirft sich ein Contributor einer Sache – oft seiner eigenen, aber das ist z.T. egal. Die Führung besteht darin, von allen das auszuwählen und in die gemeinsame Basis zu nehmen, das wirklich zusammen passt. Und die Menschen, welche vielleicht nur einen Teil zur gemeinsamen Sache beitragen zu überzeugen, dass zumindest dieser Teil wertvoll ist.
Aber wie wird das, was passt entschieden? Selbst bei sehr stark hierarchisch geführten Projekten spielt die Transparenz und Kommunikation über die Inhalte eine sehr große Rolle. Nur wenn die Bedürfnisse aller Beteiligten verstanden und abgeholt wurden gibt es einen Konsens und damit eine positive Weiterentwicklung. Das führt dazu, dass manche Entscheidungen sehr lange dauern – letztlich wird aber eine Entscheidung getroffen.
Zurück zu denen außerhalb des Teams
Unser Manager hat seiner Unzufriedenheit Ausdruck verliehen. Meist können wir ernsthaft dank bar sein, dass die Manager etwas sagen – auch wenn es in der Regel nicht gefällt. Viel kritischer für unseren Projekterfolg sind die Kunden oder Kollegen, die nichts sagen. Vielleicht wenden sie sich einfach ab und sagen nie wieder etwas.
Wir können nur dann Zufriedenheit schaffen, wenn wir wissen was wir erreichen wollen und welche Bedürfnisse befriedigt werden sollen. Nur wenn immer und immer wieder klar gestellt wurde, warum wir etwas bestimmtes machen, dann können wir hoffen verstanden worden zu sein.
Es ist meiner Ansicht nach daher vermessen, wenn ein Team erwartet, dass eine Person außerhalb dieser Gruppe einfach zum Planing und Review Meeting kommt und dann weiß, geleistet wurde. Meiner Erfahrung nach werden die Reviews von den Teams als Verhältnis mäßig unwichtige „Pflichtmeetings“ verstanden. „Eine User Story wird ja nicht dadurch fertig, dass wir ein Review machen.“ – Stimmt, aber nur wenn ein Review gut vorbereitet, perfekt vorgetragen und nachvollziehbar ist wird der Wert der User Story je verstanden. Nur wenn der PO während des Sprints regelmäßig allen direkt und indirekt beteiligten erklärt hat warum welche Entscheidungen getroffen worden sind und das Ergebnis so aussieht, wie es aussieht, dann wird im Review ein positives Feedback kommen. Klar fällt es leicht schnell zu sagen, dass ein Team gut gearbeitet hat, wenn es viele kleine Aufgaben umgesetzt hat. Aber wie lange erinnert sich jemand daran, wenn das nächste wichtige und große Projekt scheitert?
Lean empfiehlt einen gangbaren Weg mit möglichst kleinen, aber immer wertschöpfenden, Schritten. Diese immer wieder vorkommenden Tests und Verifikationen sind auch eine Art der Kommunikation und Prüfung der Bedürfnisse. Alles ist erlaubt, was hilft das Verständnis über die Sache des Teams zu fördern. Es ist aber auch die Aufgabe des gesamten Teams und nicht nur die des PO, SM oder Einzelner. Wenn alles zusammen greift, dann gibt es eine größere Chance so eine Aussage zu vermeiden und sehr viel Spaß bei den Projekten zu haben.
Also lasst uns für ein „That’s great!“ arbeiten und die Bedürfnisse von Kunden, Managern und Kollegen dafür erforschen.