"Was wir brauchen, ist ein *****loch."
Das war der ehrliche O-Ton eines potenziellen Kunden bei einem Kennenlerngespräch zu einem neuen Team.
Grundsätzlich mag ich eine solche Offenheit sehr. Keine Hidden Agenda. Einfach die Karten offen auf den Tisch.
Nach Schilderung der Lage und einigen Rückfragen war klar, dass sie keinen Scrum Master brauchen, sondern einen harten Projektleiter suchen.
Das war auch nicht das erste Mal, dass ich sowas höre. Scrum oder ein anderes Vorgehen ist zwar irgendwie da, doch nur als dünne Schicht über jahrelang praktizierten Command & Control-Strukturen. Kaum läuft etwas aus dem Ruder, erfolgt der Rückfall in alte Reflexe.
Ich habe als Reaktion darauf erklärt, dass ich gerne helfen kann. Ich kann unangenehme Fragen stellen, auf Defizite hinweisen und unterstützen, für diese eine Lösung zu finden. Aber ich bin kein *****loch und werde auch keines spielen. Ich wäre sogar vorsichtig, mich als Wadenbeißer zu betiteln.
Nicht falsch verstehen: Als Teamcoach muss ich mir keine Freunde machen.
Denn der ebenfalls schon gehörten Aussage "Als Teamcoach bist Du zuständig für die 'Team Happiness'" widerspreche ich umgehend. Dabei kommt es natürlich darauf an, wie "Team Happiness" interpretiert wird. Deutet man den Begriff als "Zufriedenheit" oder noch allgemeiner als "Stimmung", können sich daraus gute Beobachtungswerkzeuge ergeben.
Übersetzt man den Begriff dagegen mit "Glück", entgegne ich das Folgende:
Doch Entwickler so zu behandeln, wie es eingangs gewünscht war, geht gegen mein Menschenbild und gegen jede Überzeugung.
Dieses Zitat kommt von Götz Werner, dem Gründer von dm:
Ich bin der Auffassung, man muss in die Menschen investieren und ihnen etwas zutrauen, so dass sie bereit sind, Verantwortung zu übernehmen. Es ist eine Grundfrage, ob man den Menschen kontrollieren oder ihm Verantwortung übertragen will. Meiner Meinung nach ist jeder verantwortungswillig und auch verantwortungsfähig.
Ich kann das nur unterstreichen.
Wie ich nun mit Menschen arbeite, wenn diese zwar grundsätzlich verantwortungsfähig ist, sich aber noch etwas zieren? Ich höre zu und stelle Fragen.
Manchmal ist es eben eine einfache Frage, die bei der Führung von Entwicklungsteams weiterhilft.
"Ich will ja nur verstehen" ist dafür ein gutes Beispiel. Das ist in meinen Augen eine starke Einführung in ein Gespräch, die man nicht nur als Führungskraft nutzen kann.
Für mich zeigt diese Aussage zum einen eine echte Neugier. Keine Schuldzuweisung, kein Hierarchietum, keine Schlaumeierei. Einfach Wissensdurst.
Und zum anderen speist man die Folgefrage auch nicht mit einer lapidaren Antwort ab, sondern hat bitte Fakten und eine vernünftige Begründung parat. Ich liebe diesen Satz. Wann hast Du das letzte Mal wirklich, ernsthaft und aufrichtig zugehört?
Einen zweiten Blickwinkel für gute Fragen bietet eines der Prinzipien des Agile Manifesto:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Und genau da ist der Punkt: "give them [what] they need". Da steht nicht "was wir von ihnen wollen", sondern "was sie brauchen".
Die Kernfrage muss (wieder) sein: Was brauchen Entwickler:innen, um das Richtige richtig zu liefern?
Da können so vermeintlich einfache Sachen dabei sein wie eine Vision und Mission, ein Ziel und Vertrauen. Oder vielleicht auch sehr technische Punkte wie Zeit für Verbesserungen, sauberes Design und saubere Architektur. Oder die Möglichkeit, technische Schuld abzubauen. Vielleicht auch Raum für neue Technologien, Pair- und Mob-Programming, DevOps-Denken, Freiheit bei den Werkzeugen und vieles mehr.
Es dürfen auch heilige Kühe geschlachtet werden: Ziel ist nicht der perfekte Prozess. Prozesse sind Mittel zum Zweck. Sie sollen unterstützen und nicht behindern. Im Mittelpunkt muss stets die Wertschöpfung stehen.
Und jetzt meine Frage an Dich: Was brauchst Du??target=_blank/blog/die-ersten-tage-im-neuen-team
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.