Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Quelle: FotoliaWelche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

  • Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
  • Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

  • Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
  • Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
  • Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
  • Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
  • Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
  • Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
  • Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
  • Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Mit Tag(s) versehen: , , , , ,

4 thoughts on “Wie hole ich mein Team ab

  1. Krisztina Hirth (@YellowBrickC) 13. Mai 2014 um 17:13 Reply

    Hi Uli,

    ich könnte darüber ein Buch schreiben, was bei uns rockt und was stockt :)
    Also nur über das „rocken“: der Änderungswunsch entstand aus einer kleinen Gruppe von Menschen, die grundlegende und gravierende Probleme der bestehenden Legacy-Plattform lösen wollten. Aus 3 wurden dann 10 und danach 15 => so entstanden 3 Gruppen, die alle von dem Weg überzeugt waren.
    Inzwischen haben wir ein paar Kollegen dabei, die am Anfang absolut skeptisch waren. Aber das die Engagement der anderen und die eindeutige Erfolge eines cross-funktionalen agilen Teams hat sie überzeugt.

    Das wäre alles nicht machbar gewesen, wenn die Teamleads die Änderungen nicht selbst gewollt und mitgetragen hätten. Oder wenn sie auf ihre Position als Teamlead bestanden hätten.

    Wir haben alle Werkzeuge, die du aufgelistet hast, verwendet bis auf dem Blog – bis jetzt wenigstens. Die größte Angst bestand daran, dass wir unseren Technologie-Peers nicht mehr abholen oder um Rat fragen können. Das haben wir durch ein Konzept namens „COP-Community of Practice“ gelöst und das kann ich euch auch nur empfehlen.

    Wir sind noch lange nicht über dem Berg, was die Kollegen betrifft, die in der Kategorie nicht-wollen oder nicht-können gehören, aber der Weg ist eingeschlagen, und die Geschäftsleitung zieht mit. Das bedeutet: alea iacta est – die Würfel sind gefallen :)

    Krisztina

    Gefällt mir

    • Uli Armbruster 14. Mai 2014 um 16:24 Reply

      Hey Krisztina,
      ein paar Fragen dazu, falls du die beantworten darfst. Ansonsten das nächste Mal unter 4 Augen, wenn wir uns sehen.

      – Haben sich die Coding Dojos inzwischen etabliert und finden regelmäßig statt?
      – Gehen alle Teammitglieder zu Community Treffs?
      – Wie groß ist euer Team bzw. die Teams?
      – Wie intensiv macht ihr Pair Programming? Nur noch ausnahmslos oder sporadisch?

      Grüße aus Karlsruhe

      Gefällt mir

  2. […] Dojos sind in dem Kontext ein erprobtes Mittel. Weitere habe ich in diesem Artikel bzw. in der unten stehenden Grafik […]

    Gefällt mir

  3. Sebastian 16. Mai 2014 um 23:48 Reply

    Siegmund Freud hat es so formuliert:
    Um etwas zu verändern befarf es einen Leidensdruck, ein Ziel(Ausweg) und eine Weg(zum Ziel)

    Den guten Entwickler’n muss man nur das Problem vor Augen führen.
    Alles andere läuft dann von selbst. Einige brauchen vielleicht Hilfe für die 2. Stufe, also den Weg, was völlig okay ist(Keiner hat die Weisheit mit Löfeln gefressen).

    Wer das Problem nicht erkennt sollte die Firma verlassen, für die Lösung zu werben ist deine Aufgabe, den Weg zu erklären ist auch deine Aufgabe und dein Unternehmen sollte dafür auch Ressourcen bereitstellen. Ich denke das ist fair für alle beteiligten ;)

    Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: