Faire Vergütung von Mitarbeitern in Scrum Teams

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 und Einflussfaktor Personalmanagement Antworten geben wollen.

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?

Die Kaizen-Kultur in Scrum und Kanban

Scrum ist ein sehr gutes Framework, wenn man in Teams von 7+/-2 Personen Software produzieren möchte. Mittlerweile hat sich Wissen um die Skalierung von Scrum über ganze Abteilungen und Organisation gesammelt und viele der in der Praxis auftretenden Themen sind diskutiert und mit einigen Lösungsvorschlägen umrissen worden.

Scrum bedingt per se einen kulturellen Wandel in Organisationen. Die agile Denkweise und die klare Sichtbarkeit von Problemen schafft den Grundstein für eine Kultur der stetigen Verbesserung (eine so genannte Kaizen-Kultur).

Nun hat sich während der letzten Jahre noch eine andere Art und Weise entwickelt, wie man eine solche Kultur etablieren kann. Die Methoden Kanban ist in die Softwareindustrie eingezogen und auch wenn manche den Begriff aus der Automobilindustrie kennen, so ist hier nur das transferiert worden, was im Softwarebereich funktioniert hat – unter dem gleichen Namen. Damit ist ein Werkzeug entstanden, was in seinem Grundprinzip ersteinmal bestechend simpel wirkt:

Wir visualisieren, was wir eh schon tun und begrenzen unsere Arbeit in einem Prozessschritt, um einen ausbalancierten Wertfluss zu erzeugen. Das hat viele schöne Nebeneffekte, wie bessere Teamarbeit und eben auch die Möglichkeit, zu erkennen, wie die eigenen Produktionsprozesse optimiert werden können.

Stattet man dann die Mitarbeiter auch noch mit der Befähigung aus, eigene Optimierungen durchführen zu dürfen und auch bei dabei eingeführten Fehlern das Vertrauen der Vorgesetzten zu genießen, beginnt ein Unternehmenswandel zur reifenden agilen Organisation.

Viele Wartungsteams haben sich dank der freien bzw. nicht notwendigen Einteilung in Iterationen dieses Modells bereits bedient und es lohnt sich in passenden Situationen, Kanban als Weg in die agile Welt zu nutzen. Evolution statt Revolution?

Die Frage ob Scrum oder Kanban besser ist, mag man beantworten mit der Frage, ob man besser eine Schraube oder einen Nagel verwendet, um ein Gemälde zu befestigen: Anbringen kann man es wohl mit beidem – mal ist jedoch das eine sinnvoller und mal das andere. Und manche meinen auch, es sei sowieso ein Vergleich von Äpfeln mit Birnen. Ich denke mir: Hauptsache es schmeckt.