Nicht reden, sondern arbeiten

Nicht reden sondern arbeiten

In meinem letzten Artikel über das Gesetz der Nähe bin ich über die Aussage „die sollen nicht reden, sondern arbeiten / programmieren“ gestolpert, welche mich zu dem heutigen Artikel veranlasst. In den klassischen Strukturen geht es immer darum, alles am Ergebnis zu messen. Dementsprechend produziert ein Entwickler kein Ergebnis, wenn er redet statt zu programmieren. Natürlich muss auch der Entwickler mal was anderes machen als programmieren. Dazu gibt es ja das Pflichtenheft (Umsetzungskonzept), so dass er immer wenn er sich mit Anforderungen beschäftigt auch ein Ergebnis produzieren kann, das auch leicht abgerechnet werden kann. Dann schreibt er eben. Denn das Pflichtenheft lässt sich ja aus dem Lastenheft (Fachkonzept) ableiten, wodurch die Arbeit der Anforderer in messbare Ergebnisse gepackt wird.

Im agilen Kontext konzentrieren wir uns statt dem Ergebnis (engl. output) auf den Nutzen (engl. outcome). In dieser Betrachtungsweise hat das Reden einen großen Mehrwert, wenn damit Nutzen erreicht wird. Das Klären von Anforderungen z.B. hat einen großen Mehrwert und geht mündlich deutlich einfacher und schneller, als nur durch das Verfassen irgendwelcher Konzepte. Das ist jetzt noch ein einfaches Beispiel, weil sich die Stunden gut messen lassen und auch der Erfolg auf das Ergebnis einigermaßen leicht festgehalten werden kann.

Jetzt kommen wir zur Rolle des Scrum Masters oder Agile Coaches. Ein Mitarbeiter, der natürlich auch bezahlt werden will und kein einziges Ergebnis (im Sinne von output, was dem Kunden verkauft werden kann) produziert. Seine Rolle orientiert sich vollkommen am Nutzen für das gesamte Team. Da prallen dann häufig mal zwei Welten aufeinander, wenn in einer klassischen Organisation begründet werden soll, wieso jetzt Geld für ein Scrum Master benötigt wird. Es wird verlangt zu erklären, welches Ergebnis er produziert, oder wie genau er das Ergebnis verbessert. Nur genau das ist ja nicht so leicht zu sagen, weil er sich am Nutzen für das Team orientiert.

Genau so finde ich es immer wichtig, dass die mir unterstellten Entwickler für alles Zeit nehmen, was Wirkung zeigt. Dazu gehört auch mal ein kleines Päuschen zum snacken und mit Kollegen quatschen. Oder den Kollegen Urlaubsbilder zeigen. Oder oder oder. Das alles trägt zu Teambuilding bei, dem Wohlbefinden der Mitarbeiter, der (intrinsischen) Motivation und noch vielem mehr. Alles Dinge die zusammen eine große Wirkung, bzw. einen großen Nutzen haben und nicht vernünftig gemessen werden können.

Fokussier dich immer auf den Nutzen. Hast du noch andere Beispiele wo das zutrifft? Schreib es in die Kommentare!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.