Das Problem mit dem Stolz

„Worauf seid ihr so richtig stolz?“ fragte letztens die Trainerin in einem Resilienzseminar, an dem ich teilgenommen habe. Schweigen im Walde bzw. im Teilnehmerkreis. Viele Seminarteilnehmer hatten sichtliche Probleme mit dem Wörtchen „Stolz“. In einem Coaching habe ich neulich ähnliches erlebt. Der Coachee berichtete, worauf er stolz sei – nur um es gleich wieder zurückzunehmen. „Stolz sagt man ja nicht“, murmelte er entschuldigend.

„Ich bin stolz, ein Deutscher zu sein“, ist das, was viele spontan mit dem Wort „stolz“ assoziieren. In Verbindung mit diesem aus dem (Neo-) Nazitum bekannten Ausspruch hat Stolz ein ziemlich schlechtes Image. Aber auch in anderen Kulturen ist Stolz eher negativ behaftet. Im Buddhismus zum Beispiel wird er als „Störgefühl“ bezeichnet und vor allem mit materiellem Streben und Unbeweglichkeit assoziiert.¹

Warum ist es eigentlich so „out“, stolz auf etwas zu sein? Und ich meine damit nicht stolz im Sinne von „Ich bin stolz auf meine schönen blauen Augen“ (was eh gelogen wäre, denn meine Augen sind gar nicht blau), sondern stolz auf etwas, was man selbst geleistet und gut gemacht hat.

Die zwei Seiten der Medaille Stolz

Wirklich schade, dass Stolz so eine schlechte Lobby hat. Denn wie der Duden schreibt, heißt stolz sein ja nicht zwingend „in seinem Selbstbewusstsein überheblich und abweisend“ zu sein, sondern auch dass jemand „von Selbstbewusstsein und Freude über (…) eine [eigene] Leistung erfüllt“ ist.²

Und genau der Stolz auf die eigene Leistung ist immens wichtig. Nicht nur, wenn es um die eigene Persönlichkeitsentwicklung geht, sondern auch wenn es um die Entwicklung von Teams geht. Der Stolz auf etwas, was wir selbst geschafft und geleistet haben, ermöglicht es uns, positiver in die Zukunft zu schauen. Denn wer sich bewusst ist, dass er in der Vergangenheit Großes vollbringen konnte, wird auch zukünftigen Herausforderungen mutiger ins Auge blicken. Und damit sind wir wieder beim eingangs erwähnten Stichwort: „Resilienz“. Wer wünscht sich heute nicht ein resilientes Team? Ein Team, das stolz auf die eigene Leistung und in der Lage ist, auch nach Rückschlägen schnell wieder in seine Tatkraft zurückzufinden.

Ein Team am Rande der Depression

Dazu möchte ich eine kleine Geschichte erzählen. Es war einmal ein Softwareentwicklungsteam, das seit geraumer Zeit an einer Individualsoftware für einen großen Kunden arbeitete. Ein sogenanntes „Grüne-Wiese-Projekt“. Vor kurzem wurde ein wichtiger Meilenstein erreicht und das Team hat vom Kunden die Freigabe erhalten, weiter an der Software zu entwickeln. Eigentlich könnte das Team stolz auf sich und das was es erreicht hat sein …

… aber wenn man es ganz ehrlich betrachtet, wurde der Meilenstein doch nur mit Hängen und Würgen erreicht. Dass der Kunde diesen schlechten Arbeitsstand überhaupt abgenommen hat, bei den ganzen Bugs in der Software. Zwar konnten viele Fehler schon behoben werden, aber die Bugtickets nehmen weiter zu. So richtig gut scheinen die Entwickler ja nicht zu arbeiten, sonst müssten die Fehler doch eigentlich immer weniger werden. Aber das liegt wahrscheinlich auch an der gewählten Technologie, die allen immer wieder Knüppel zwischen die Beine schmeißt. Von der „verunfallten“ Softwarearchitektur gar nicht zu sprechen …

Stolz hilft raus aus dem Tal der Trauer

Wie geht es Ihnen nach dem Lesen des letzten Absatzes? Fühlen Sie auch die Mutlosigkeit, die aus diesen Zeilen spricht? Und – Achtung, rhetorische Frage – glauben Sie, dass ein Team in diesem Depri-Modus noch in der Lage ist, großartige Leistungen zu vollbringen? – Natürlich nicht!

Das Team könnte die ganze Situation auch anders sehen. Es könnte stolz darauf sein, dass es nach Monaten harter Arbeit mit vielen Überstunden und einigen Wochenendschichten den Meilenstein geschafft hat. Stolz darauf, dass alle so gut zusammengearbeitet haben, um dieses Ziel zu erreichen. Sich über die behobenen Fehler freuen und anerkennen, dass immer mehr Arbeit da sein wird, als es schaffen kann und dass es eine komplett fehlerfreie Software einfach nicht gibt. Und stolz darauf sein, dass es auf der einschüchternden „grünen Wiese“ überhaupt geschafft hat, sich auf eine Technologie zu committen und so etwas wie eine erkennbare (und den meisten Teammitgliedern bekannte) Softwarearchitektur zu haben.

Luft nach oben für Verbesserung gibt es natürlich immer. Und es ist auch wichtig, Verbesserungsmöglichkeiten zu benennen. Aber ebenso wichtig ist es, aus der positiven Würdigung des Erreichten die Energie zu ziehen, die Verbesserungen auch anzugehen. Wenn das nicht passiert, wird das Team irgendwann ängstlich und hört auf sich zu bewegen. Nach dem Motto „Wir haben in der Vergangenheit schon so viel in den Sand gesetzt, wir hören lieber ganz auf, etwas bauen zu wollen“. Das Team traut sich nichts mehr zu, sein Selbstwert ist im Keller.

Positive Retrospektiven mit dem kleinen Seestern

Aber auch wenn ein Team aus überzeugten Pessimisten und Zynikern besteht, kann es einen wohlwollenderen Blick auf die eigene Arbeit bekommen. Zum Beispiel durch die Änderung des Formats für Sprint-Retrospektiven.

Wir hatten in einem Team die Retrospektive bisher immer mit dem Format „Mad, glad, sad“ durchgeführt. Bei diesem Format werden Zettel einer von drei Kategorien zugeordnet. In die erste Kategorie „Mad“ hängen die Teammitglieder die Zettel mit Punkten, über die das Team richtig wütend ist. In die zweite Kategorie „Glad“ kommen die Sachen, über die sie sich gefreut haben. Und in Kategorie „Sad“ hängen am Ende die Zettel mit Punkten, die das Team traurig gestimmt haben.

Eines Tages hingen in der Retrospektive kaum noch Zettel in der Kategorie „Glad“. Die Vorstellung der Zettel wurde zu einer richtigen „Auskotzrunde“. Positive Energie: Null. Und auch wenn das gemeinsame Jammern ja bekanntlich manchmal gut tut, beschloss ich, in der nächsten Retro mal ein anderes Format auszuprobieren.

Wir machten die nächste Retrospektive mit dem Format Small Starfish. Wir nutzten drei Kategorien: „Start“ für Dinge, die das Team beginnen und ausprobieren will, „Stop“ für das, was nicht mehr gemacht werden soll, und „Continue“ für alles, was im letzten Sprint gut gelaufen ist und unbedingt beibehalten werden sollte. Erstaunlich, was diese eigentlich kleine Änderung mit der Energie im Team machte. Plötzlich machten viele Teammitglieder konstruktive Vorschläge für Verbesserungen und lobten die Leistung des Teams! Aus einem Haufen „Jammerlappen“ war plötzlich ein eigenverantwortliches Team geworden, das stolz auf die eigene Arbeit war und sein Schicksal selbst in die Hand nehmen wollte!

Burnup-Charts statt Burnout

Neben einem mit Bedacht gewählten Retrospektiven-Format sind Visualisierungen eine weitere Möglichkeit, einen positiveren Blick auf die getane Arbeit zu bekommen. Der Klassiker ist hier natürlich das Kanban-Board, bei dem Entwicklungstickets im Laufe des Sprints von der Spalte „To do“ in die Spalte „Done“ wandern. Wenn auf dem Kanban-Board am Ende des Sprints viele oder vielleicht sogar alle Tickets ganz rechts hängen, ist das ein guter Grund stolz zu sein! Viele Teams nutzen elektronische Kanban-Boards, was bei verteilten Teams natürlich ein Vorteil ist. Falls das gesamte Team am selben Ort sitzt, ist jedoch ein physikalisches Board zu empfehlen. Das haptische Erlebnis, die Karte in die „Done“-Spalte zu ziehen, macht es noch viel bewusster erlebbar, was geschafft wurde.

Eine weitere und vielleicht nicht ganz so bekannte Möglichkeit, den Fortschritt für das Team sichtbar zu machen, ist das sogenannte Burnup Chart. Dieses Chart setzt die Anzahl der geplanten Features / User Storys in Relation zu den fertiggestellten Features / User Storys und stellt diese Relation im Zeitverlauf dar. Wenn ein solches Chart erstellt und zentral verfügbar gemacht wird, kann jeder sofort sehen, wie die Menge an Softwarefunktionalität kontinuierlich wächst.

Das kontinuierliche Wachstum an User Storys visualisieren

Vergleich mit sich selbst statt mit anderen

Und falls das alles nichts bringt? Dann kann es dem Team helfen, sich konsequent nicht mit anderen zu vergleichen, sondern nur mit sich selbst. Um dies zu vereinfachen, kann ein „Projekttagebuch“ oder eine „Teamchronik“ erstellt werden. Dann kann man sich einfacher gemeinsam erinnern, wie es zum Beispiel am Start des Projektes war: „Wisst ihr noch wie wir damals wochenlang gestritten haben wie wir die Software technisch schneiden sollen? Oder wie wir uns partout nicht entscheiden konnten, ob wir Technologie A oder B verwenden sollen und auch der externe Berater nicht weiterwusste?“

Wichtig ist dabei, dass das Team den eigenen Lernfortschritt im Projekt würdigt. Das Team kann stolz sein, wenn es Dinge gelernt hat, die es vorher nicht konnte oder wusste. Sei es das Einarbeiten in ein neues Entwicklungstool, die Umsetzung eines neuen Designkonzeptes oder einfach nur die Erkenntnis, dass der gewählte Architekturansatz doch einige Schwächen hat und man es beim nächsten Mal doch etwas anders machen sollte.

Und es kann gemeinsam positiv darauf schauen, dass es vielleicht trotz großer Startschwierigkeiten und widriger Umstände viele Funktionalitäten entwickeln konnte, die Nutzer bei ihrer täglichen Arbeit unterstützen.

Fazit

Wer stolz auf die eigene Leistung und Entwicklung ist – sei es nun als Einzelperson oder als ganzes Team – ist nicht zwingend gleich überheblich und redet sich alles schön, sondern verfügt in der Regel über ein positives Selbstbild. Und genau dieses positive Selbstbild macht es möglich, dass wir selbstbewusst an zukünftige Aufgaben herangehen. Das ist bei den heutigen Herausforderungen der (Softwareprojekt-) Welt eine nicht zu unterschätzende Fähigkeit. Im besten Falle sagen sich die Kollegen dann am Ende des Tages auch „Ich bin stolz, ein Mitglied dieses Teams zu sein“.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] https://www.diamantweg-buddhismus.de/
[2] https://www.duden.de/rechtschreibung/stolz#Bedeutung1a

Kathrin Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u.a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.