Die ersten Tage im neuen Team

Du kommst als neuer Teamcoach in ein Softwareentwicklungsteam. Dein Auftrag ist vorab geklärt. Und jetzt?

Welche ersten Schritte gehst Du? Wie sehen die ersten Tage und Wochen aus?

Gleich vorneweg: Darauf gibt es keine Standardantwort. Im Folgenden einige mögliche Ansätze, die ich selbst nutze. Und auch mein Weg unterscheidet sich von Team zu Team.

Der Auftrag

Eingangs schrieb ich "Dein Auftrag ist vorab geklärt". Das ist er doch, oder? Wenn nicht, gehe unbedingt zunächst in das Auftrags- und Erwartungsmanagement. Unabhängig davon, ob Du als Interner oder Externer tätig wirst.

Das Thema Auftragsklärung ist dabei ein Artikel für sich. Nur so viel dazu: Stelle und lege so früh wie möglich fest, was die Erwartungen an Dich sind. Welche Ziele sollst Du verfolgen? Was sind die Rahmenbedingungen, innerhalb derer Du Dich bewegst?

Und Ziele für Dich gibt es nicht nur vonseiten Deiner Auftraggeberin. Ebenso knüpft das Entwicklungsteam Erwartungen an Dich und Deine Rolle.

Nachdem Dein Auftrag geklärt ist, hat eine Erfassung der Ist-Situation Sinn.

Die Ausgangslage

Auf einer allgemeinen Ebene bieten sich folgende Fragen an, um die Situation eines Softwareentwicklungsteams zu erfassen.

• Was sind die Ziele des Entwicklungsteams?
  • Wozu gibt es das Team?
  • Weiß jeder Mensch im Team genau, was ihr Beitrag ist und ist von diesem "warum" begeistert?
  • Noch weiter gefasst: Wie zahlt das Team auf die Vision und Mission des Unternehmens ein?
  • Und auch hier: Kennt jeder Mensch im Team das Ziel des Unternehmens und ist davon motiviert?
• Wie sieht die Zusammensetzung des Entwicklungsteams aus?
  • Welche Fähigkeiten, Fertigkeiten und Rollen sind im Team vorhanden und welche fehlen?
  • Kann das Team in seiner Zusammensetzung eigenständig etwas Wertvolles liefern?
  • Kann das Team in seiner Zusammensetzung Ende-zu-Ende-Funktionalität bereitstellen?
• Welche Abhängigkeiten hat das Entwicklungsteam?
  • Wie werden fehlende Fähigkeiten, Fertigkeiten und Rollen im Team kompensiert?
  • Wie viele "Inputs" und "Outputs" hat das Team?
  • Wie schnell bekommt das Team externe Unterstützung?
• Welche Entscheidungsmöglichkeiten hat das Entwicklungsteam?
  • Welchen Einfluss hat das Team darauf, "was" sie entwickeln?
  • Welchen Einfluss hat das Team darauf, "wie" sie etwas entwickeln?
  • Wie ist das Machtgleichgewicht zwischen Teammitgliedern und Führungskräften?
• Wie oft liefert das Entwicklungsteam?
  • Ist ein Release langweilige, schnelle Routine oder eine furchterregende, langwierige Aufgabe?
  • Kann jeder Mensch im Team ein Release... releasen?
  • Wie oft gibt es Neues vom Team? Auf welchen Umgebungen?
  • Wie wertvoll ist der Inhalt eines Release?
• Wie lernt das Entwicklungsteam?
  • Wie oft nimmt sich das Team Zeit für Retrospektiven?
  • Wie geht das Team mit Ausfällen und anderen Problemen um?
  • Wie oft feiert das Team Erfolge?
• Wie geht das Entwicklungsteam mit der Kundin um?
  • Will das Team direkten Kontakt mit Endanwenderinnen?
  • Wie oft bekommt das Team unkomplizierten Kontakt mit Endanwenderinnen?
  • Wie lange dauert es vom Release der Software bis zum ersten direkten Feedback von echten Endanwenderinnen?

Im Netz wirst Du noch viele ähnliche Checklisten und Ansätze finden. Bist Du beispielsweise explizit als Scrum Master unterwegs, kann ich Dir 20 Questions New Scrum Masters Should Ask Their Teams to Get up to Speed, 20 Questions from New Scrum Master to Product Owner und 20 Questions from New Scrum Master to the Developers empfehlen.

Und jede Antwort kann Dir einen möglichen Entwicklungsschritt geben.

Schritt für Schritt

Was der konkrete erste Schritt ist, ist natürlich stark situationsbedingt. Es kann sich lohnen, einen "Quick Win" zu identifizieren und diesen umzusetzen. Generell gilt es, die aktuell größte Störung zu finden und zu versuchen, diese zu beseitigen. Liegen keine Störungen vor, kannst Du ein mittel- bis langfristiges Teamentwicklungsziel festlegen und verfolgen.

Denke bei Störungen und Entwicklungszielen stets daran, was Dein Auftrag ist, ob Deine geplanten Maßnahmen auf diesen einzahlen und wie Du diese lösungsorientiert umsetzen kannst.

Mein Tipp ist zudem, Dir nicht zu viel auf einmal vorzunehmen. Das hat mehrere Gründe:

• Gemäß dem Motto "stop starting, start finishing" ist es sinnvoller, Parallelarbeit zu minimieren, um Fortschritt zu machen.
• Wenn Du mehrere Initiativen gleichzeitig verfolgst, wie willst Du erkennen, welche wirklich ursächlich wirksam war?
• Zu viele Änderungen können das Team überfordern. Schlussendlich hat das Entwicklungsteam als Hauptaufgabe, Wert zu schaffen und braucht nicht noch mehr Komplexität im Entwicklungsalltag.

Und vergiss nicht, dass auch Arbeit am Team einem iterativen Vorgehen von Inspektion und Adaption folgt. Reflektiere dazu Deine Arbeit und Dein Vorgehen regelmäßig in persönlichen wie teaminternen Retrospektiven.

Die Axt im Wald?

Eine Eigenschaft, die ich persönlich bei der Arbeit in der Teamentwicklung als sehr wichtig empfinde, ist Demut. Die Unternehmen, in denen und für die wir arbeiten, handeln in den allermeisten Fällen bereits erfolgreich im Markt. Es wäre somit vermessen und arrogant zu behaupten, dass sie bisher "alles falsch gemacht haben".

Unter diesen Gesichtspunkten gehe ich selten wie die Axt im Walde vor. Überfährt man Teams wie ein "Bulldozer", ist das in meinen Augen kontraproduktiv und birgt die Gefahr, zusätzliche Widerstände zu erzeugen.

Stattdessen sehe ich es als zielführender an, die ersten Tag zuzuhören, zu beobachten und Fragen zu stellen.

Das kann sogar so weit gehen, dass erste Maßnahmen augenscheinlich nichts mit Agilität zu tun haben. Vielleicht lohnt sich sogar ein Blick in klassische Projektmanagement-Techniken, -Prozesse und Organisationsformen?

Denn auch wenn sich natürlich Dinge ändern müssen, kann es sinnvoll sein, bestimmte Praktiken vorerst weiterzuführen - da sie für den Moment "gut genug" sind, um die gesetzten Vorgaben zu erreichen.

Dabei ist Agilität nicht das Ziel, sondern Mittel zum Zweck. Und dieser Zweck ist der Erfolg des Unternehmens.

Fazit

Es gibt nicht den einen Guide zum Einstieg. Das hast Du doch auch nicht gedacht in komplexen Umfeldern, oder? 😉

Mit diesem Artikel gebe ich Dir einen Leitfaden an die Hand, der Deinen Werkzeugkasten erweitert und Dir Deine ersten Schritte erleichtern soll.

Welche Tools Du einsetzt und wie Du dabei vorgehst, ist immer eine Frage Deines persönlichen Stils, Deiner Erfahrung - Und immer und immer wieder: Der gesteckten Ziele, denen sich alles unterordnet.

Viel Erfolg!

Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.