Die Rote Ampel – Freund oder Feind?
Bei der Vorlesung in Potsdam vor einigen Wochen sprach ich unter anderem auch über TDD, Test-Driven Development und darüber, dass ich mich bei der Arbeit mit TDD über rote Ampeln freue. Einer der Studenten sprach mich darauf an, er fand es seltsam, dass man sich über rote Ampeln freuen kann.
Tatsächlich habe ich mich in den 15 Berufsjahren im Projektmanagement nur selten über rote Ampeln gefreut. Wo ist der Unterschied?
Die roten Ampeln, die mich früher geärgert haben, machte jemand anders, oft ein Qualitätsmanager, und sprach dabei über mich oder mein Team. Die meisten Menschen fühlen sich in so einer Situation angegriffen und gehen in eine innere Verteidigungshaltung. Die resultierenden Diskussionen sind oft eher laut als nützlich.
Rote Ampeln im TDD (und in vielen anderen Kontexten, übrigens) mache ich für mich, als Erinnerung daran, dass noch etwas zu tun ist. Ich brauche mich gegen niemanden verteidigen, ich stelle einfach – für mich – fest, es gibt Arbeit. Na und?
Ähnlich funktionieren beispielsweise Burn-Down-Charts in Scrum oder Kanban-Karten in der Produktion. Es ist „nur“ ein Signal von „uns“ an „uns“.
Hier ist ein Schlüssel für Hochleistungsteams: Kommen in Deinem Team die roten Ampeln subjektiv gefühlt von „außen“ (und führen zu Verärgerung), oder kommen sie gefühlt von „innen“ (und Du erlebst sie als Unterstützung)? Wie reagierst Du darauf?
Hochleistungsteams organisieren sich so, dass sie voll auf ihr Ziel fokussiert sind – und dazu gehört, dass sie ihre eigenen Warnmechanismen haben, falls sie das Ziel zu verfehlen drohen. Aus diesem Fokus aufs Ziel ergibt sich dann auch ein konstruktiver Umgang mit Feedback (beispielsweise roten Ampeln). Darüber bald mehr in einem anderen Artikel.
