Das ist schwierig zu beantworten. Letztlich hängt die mögliche Teamperformance zu erheblichen Teilen auch von den Randbedingungen ab, denen ein Team unterworfen ist. Kann das Team autonome Entscheidungen treffen oder werden sie von der Organisation 'nur als Programmierdrohnen' betrachtet? Wieviel Struktur ist im Backlog vorhanden, oder ist es gar nur eine Ansammlung aus 'Zeug, das abzuarbeiten ist' und aus dem sich keine anspruchsvollen Sprintziele ableiten lassen?
Um dem auf die Spur zu kommen, ist es sehr hilfreich, der Arbeit des Teams für ein paar Sprints zuzusehen. Hinweise sind z.B. Frustpotentiale? Welche tieferen organisatorischen Ursachen haben diese? Wer kommt zum Review? Wer hat daran Interesse? Auch Kunden, Management? Wie gut ist die Güte der Backlog-Items? Im Planning wird sich das bemerkbar machen. Usw.
Aus meiner Erfahrung ist der Performancelevel, den ein Team erreichen kann viel mehr von den äußeren Faktoren abhängig, als von den inneren Teamfaktoren und auch nicht so sehr davon, ob das Team korrekte Plannings, Dailies, Reviews oder Retros macht. Klar trägt ein gutes Planning und Daily dazu bei, dass die geplanten Sprintergebnisse besser erreicht werden. Wenn ein Product Owner aber z.B. keine anspruchsvollen Probleme ans Team heranbringen kann, die es lösen soll, dann wird ein Team halt brav 'vor sich hinarbeiten'. Es liefert natürlich Sprint für Sprint Ergebnisse, aber ob diese eine hohen Wert haben, hängt von anderen äußeren Faktoren ab. Ich habe Scrum-Teams gesehen, die sehr korrekt das Scrum-Framework anwenden und zuverlässig Sprint für Sprint liefern. Nur... die Auswirkung auf das Produkt war dennoch dürftig. Mit anderen Worten: Man kann trotz korrekter Scrum-Anwendung sehr effizient Teams auslasten, deren Ergebnisse effektiv kaum einen Unterschied machen. Aus meiner Sicht zu teuer und für den Kunden unbefriedigend!
Nicht selten wünscht sich die Managementebene daher eine höhere Teamperformance, gemäß dem Motto: mehr liefern, mehr Wirkung. Die Leute sollen also schneller arbeiten (Work harder!). Das Team, das aber schon gut und zuverlässig seine Sprintergebnisse liefert wird sich dagegen wehren, denn wie sollen sie denn aus sich selbst heraus mehr erreichen? Ständige Überstunden können schließlich nicht die Lösung sein. Schnell tappt dabei das Management in die Falle, dass die Leute einfach nicht motiviert genug seien. Aus meiner Erfahrung ist das ein fataler Beobachtungsfehler. Das Schlimme: Wenn man nun versucht an den Menschen 'herumzudoktern', damit diese doch motivierter arbeiten würden, greift man am falschen Hebel an. Meist wird der Frust dadurch noch größer, Kündigungswellen und weitere Demotivation, sowie Schuldzuweisungen sind die Folgen.
Ich behaupte: Man stelle dem Team die richtigen Randbedingungen zur Verfügung, z.B. Mitentwicklungsmöglichkeit bei der Lösung des eigentlichen Kundenproblems, dazu muss es so nah wie möglich mit dem Kunden zusammenarbeiten können; Verständnis des eigentlichen Kundenproblems (z.B. fragen, was passiert, wenn die Anforderung nicht umgesetzt wird?); Autonomie in der Gestaltung der Teamprozesse und Mitwirkung an der Teamzusammenstellung; hohe Erwartung seitens des Kunden (aber nicht des Managements, weil es das halt so will); soziale Dichte des Teams (z.B. Co-Location) usw....
dann wird sich ein Team von ganz alleine (gerne unterstützt durch den ScrumMaster) zu einem high-performance Team im Sinne hoher Wirkung für den Kunden entwickeln.
