Der 8. Scrumtisch Rhein-Neckar drehte sich rund um die Leistungsbeurteilung von Mitarbeitern. Wir gingen dabei von einer Organisation aus, die klassisch orientierte HR-Modelle einsetzt und nicht vollständig agil handelt, sich also noch auf oder vor dem Weg der Prozessneugestaltung befindet – eine Situation in der viele Unternehmen zur Zeit sind. Dieses Thema wird deswegen auch immer wieder heiß diskutiert.
Wer gibt in agilen Teams an wen Leistungsbeurteilungen heraus? Soll ein ScrumMaster das Team bewerten? Kann das ein Product Owner machen? Gibt es Boni und wenn ja für wen und unter welchen Bedingungen?
Nach einer mehr als einstündigen Diskussion der sieben Teilnehmer ging die Gruppenmeinung zusammenfassend in die nachstehende Richtung, wenn auch keine vollkommene Einigkeit bei dieser komplexen Fragestellung bestand und manche Frage offen blieb:
- Boni sind schwierig bis gar nicht sinnvoll zu nutzen, was auch meiner Kenntnis der aktuellen Theorien zur intrinsischen und extrinsischen Motivation von Menschen entspricht. Geld muss möglichst schnell aus den Köpfen der Mitarbeiter verschwinden.
- Wenn man Boni nutzen möchte, sollten diese überraschend ausgeschüttet und nicht vorhersehbar sein. Ob diese dann für jeden Mitarbeiter monetär sind oder als Sachmittel für Teaminvestitionen zur Verfügung stehen, ist diskussionswürdig.
- Zielvereinbarungen sind mit Vorsicht zu genießen, wenn sie dem Teamziel entgegenstehen. Es gab im Gespräch Beispiele dazu, wie Einzelzielvereinbarungen zur Beschädigung von Gruppen- und Unternehmenszielen beigetragen haben.
- Ein Linienmanager kann sich in regelmäßigen Einzelgesprächen und mit Unterstützung von 360°-Feedback sein Bild über die Teamleistung eines Mitglieds machen. Eine Anpassung einer Vergütung oder andere Sachleistungen hängen daneben vor allem natürlich auch von den Bedürfnissen des Mitarbeiters ab.
Die Diskussion zu diesen wichtigen Themen ist damit nicht zu Ende sondern steht viel mehr an einem Anfang, auf den auch Bücher wie Beyond Budgeting
Es hilft, zu berücksichtigen, dass sich Systeme nach den Metriken ausrichten, an denen sie gemessen werden. Aus diesem Grund sind dies in Scrum eben nur potentziell auslieferbare Features.
Andere Metriken führen in diesem Kontext häufig zu unschönen Dysfunktionen. Ein Beispiel: Würde man ein Team zum Beispiel an seiner Commitment-Erfüllungsrate messen, entstehen schnell seltsam Phänomene, wie Teams, die bewusst zu wenig Arbeit annehmen, um genug Sicherheit zu haben, ihr Commitment auch in jedem Fall zu halten.
Und wie vergüten Sie Ihre Mitarbeiterleistung angemessen?
