Schritt für Schritt zum erfolgreichen Team

Dies ist ein Blogpost in der Serie zum Software Engineering Event 2014. Es ist ein Dialog zwischen Peter Rey (kursiv) und Daniel Marbach (gerade)

Wir haben gesehen, dass die Wahl der richtigen Technologie den entscheidenden Wettbewerbsvorteil bedeuten kann. Doch neben den Technologien sind auch Teamaspekte wichtig. Der Erfolg liegt im Detail. Sie, Ihr Team und Ihre Firma müssen einen Veränderungsprozess durchlaufen. Alte Strukturen und Denkmuster werden hinterfragt, Ihr Entwicklungsprozess wird umgekrempelt. Ein Umdenken findet statt. Wie holen Sie in einem solchen Veränderungsprozess ohne Verluste alle ab und kommen

Schritt für Schritt zu einem erfolgreichen Team?

bbv hat zusammen mit Erowa AG ein erfolgreiches Team aufgebaut. Peter Rey und ich zeigen Ihnen in diesem Vortrag bewährte Muster, die Sie und Ihr Team zum Erfolg bringt.

Aber bevor wir weiterfahren stell dich doch noch kurz vor Peter.

Mein Name ist Peter Rey und ich leite die Abteilung Software bei der Firma EROWA.         Wir sind ein international tätiges Unternehmen mit ca. 400 Mitarbeitern, davon 250 in der Schweiz in Büron LU und Reinach AG. Wir sind im Bereich Fertigungsautomatisierung tätig, mit Schwerpunkt Werkzeug- und Formenbau sowie Produktion. Wir bieten Systemlösungen an von der Palettierung der Werkstücke mit Spannfutter über Voreinstellgeräte und Messmaschinen bis zu Beladerobotern und Leitsystem

Bei EROWA hat man anfangs 2010 mit der Umsetzung eines Projektes für ein neues Leitsystem für den weltweiten Markt begonnen. Für die Einführung des neuen Entwicklungsprozesses „Scrum“ und den Technologie Aufbau & Engineering Practices mit .NET, TDD, etc. hat man bbv Software Services als Dienstleister engagiert.

Wir haben auf der grünen Wiese mit .NET gestartet. Im Januar 2010 waren 1 interner Mitarbeiter als Projektleiter und .NET Entwickler von EROWA + 2 Externe von bbv (Daniel Marbach und ich). Wir hatten ganz verschiedene Ziele:

• ein neues Produkt für internationalen Markt – Leitsystem, asiatische Sprachen, etc.
• ein Team von 9 Mitarbeitern aufzubauen
• Aufbau von Technologie & Engineering Practices (.NET, TDD, ATDD, XP+)
• Entwicklungsprozess Einführung: Scrum + Kultur!

Zudem haben wir festgestellt, dass wir ja auch noch „Domäne KnowHow aufbauen“ mussten – keiner im Projekt hatte tieferes Leitsystem KnowHow…

Bei der Einführung eines neuen Entwicklungsprozesses gibt es immer Veränderungen.

Zum Thema Veränderungen gibt Ihnen jetzt Dani eine Einführung…

Veränderungen sind mit Angst verbunden. Veränderungen sind schwierig. Veränderungen können sehr lange dauern. Wir haben oft falsche Vorstellungen, wie Veränderungen stattfinden werden, oder aber die Erwartungen, die andere an die Veränderung haben, sind nicht klar.

Die erste falsche Vorstellung ist, dass Innovation einfach akzeptiert wird aus dem Grund, weil es eine gute Idee ist. Ich glaube, Sie alle können sich an einige gute Ideen erinnern, die fehlgeschlagen sind und durch schlechtere ersetzt wurden, oder nicht?

Die Zweite ist, dass jene, die eine gute Idee haben, den Glauben vertreten, es reiche aus, logisch über die Vorteile der neuen Idee zu argumentieren und schon folgen alle der neuen Idee. Wie oft haben Sie diese Annahme getroffen und dann festgestellt, dass es trotzdem noch mehr Überzeugungsarbeit braucht?

Die Dritte ist, dass geglaubt wird, sobald die neue Idee eingeführt ist, keine weiteren Anstrengungen unternommen werden müssen. Die Realität ist aber, dass es nicht reicht, den Samen zu setzen und dann nie Wasser zu geben, zu düngen oder die Pflanze zu pflegen.

Sie haben vielleicht schon gehört, dass der schnellste Weg, etwas einzuführen, damit stattfindet, indem man einfach die Umsetzung der neuen Idee befiehlt. Wahrscheinlich erreichen Sie damit zwar Folgsamkeit, aber nicht Engagement und Hingabe. Ebenfalls besteht die Gefahr, dass langfristig trotzdem Widerstand entsteht. Um Veränderungen nachhaltig und langfristig einzuführen, sollte die Veränderung von unten nach oben mit Unterstützung des Managements auf allen Ebenen eingeführt werden. Der umgekehrte Weg funktioniert nicht. Ein altes chinesisches Sprichwort fasst dies wunderbar zusammen: „oben ist viel Lärm, aber niemand kommt herunter“.

Veränderung ist kein Ereignis, sondern ein Prozess, wie dies die Studien von E.M. Rogers und Geoffrey More zeigen. Für einen erfolgreichen Innovations- / Entscheidungsprozess und somit einem erfolgreichen Team braucht es drei Schlüsselfaktoren: den Change Agent, die Kultur und die Menschen.

Der Change Agent führt die Veränderungen ein, dabei handelt es sich um eine Rolle und nicht eine Person. Der Change Agent kann und sollte jeder sein! Das gilt auch für Sie! Fehlende Autorität ist keine Entschuldigung, nichts zu unternehmen. Fakt ist, dass viele Formen der Führung, die Sie jeden Tag sehen, werden von Personen unternommen, deren Möglichkeit, andere zu beeinflussen, ihre Autorität übersteigt. In gesunden Organisationsformen führen Menschen nicht nur ihre Peers sondern auch ihre Vorgesetzten.

Es ist offensichtlich, dass die Kultur der Unternehmung einen signifikanten Einfluss auf die Geschwindigkeit des Innovations-/ Entscheidungsprozess hat. Der Prozess wird einfacher und schneller, wenn die Kultur die Idee unterstützt und nährt. Dazu braucht es Zeit, etwas zu lernen, Neues auszuprobieren, und Geduld, Ideen zu unterstützen, die erst in Zukunft einen Return on Investment generieren, und Akzeptanz, dass die Lernkurve lang sein kann und Fehler nicht mit der Todesstrafe abgegolten werden.

Der dritte Schlüsselfaktor sind die Menschen. Bei Veränderungen müssen wir uns immer wieder ins Bewusstsein rufen, dass wir eine Gruppe von Individuen beeinflussen wollen. Um Veränderung hervorzurufen, müssen wir die Individuen verändern. Auch wenn die Unternehmenskultur offen ist werden die Menschen die Veränderungen mit unterschiedlicher Geschwindigkeit annehmen oder eben nicht. Jede Person hat ihr Potential, sie müssen es nur herausfinden und fördern!

Bei der Firma Erowa AG haben Peter Rey und ich als Change Agents operiert und Veränderung in Kultur und den Mitarbeitern ausgelöst. Ich war zuständig für die technischen Skills und Peter Rey für die Management- und Organisationsaspekte. Wir zeigen Ihnen im weiteren Verlauf dieses Vortrages, welche Herausforderungen wir als Change Agents angriffen und erfolgreich bewältigten.

Für ein erfolgreiches Team braucht man aber zuerst die richtigen Mitarbeiter. Peter wie findet ihr bei Erowa AG die richtigen Mitarbeiter?

Ja, Dani Du bringst es auf den Punkt! Das ist eine Herausforderung – gute Mitarbeiter zu finden. Grundsätzlich gibt es 3 Möglichkeiten:

a)      Neue Mitarbeiter einstellen            
dies braucht aber Geduld: unsere Erfahrung bei EROWA zeigt, dass wir durchschnittlich 6-12 Mt. brauchen bis wir die richtige Person gefunden haben

b)      Interne Wechsel
da meine Abteilung Software die einzige SW Abteilung ist, wird es schwierig…
man findet keine .NET SW Ing. bei EROWA ausserhalb meiner Abteilung.
eine Ausnahme ist unser SW Tester Fabian, er hat die Lehre als Informatiker abgeschlossen und arbeitet seit dann bei uns im Team als Tester.

c)      Temporär einstellen von Dienstleister
dies hat den Vorteil, dass man relativ schnell gute .NET SW Ing. findet. Die Kosten sind etwas höher verglichen mit den internen Kosten, dafür sind die Mitarbeiter sehr gut ausgebildet. Dank der Scrum Methode „Team Fokus“ ist auch der KnowHow Verlust beim Weggang des externen Mitarbeiters vernachlässigbar

Also für was habe ich mich entschieden in diesem Dilemma?

Mein Ziel ist es: gute, bestehende Mitarbeiter möglichst lange zu halten! 

Dazu muss ich natürlich wissen, was den Mitarbeitern wichtig ist, z.B.:

• Gutes Arbeitsklima & angenehme Atmosphäre schaffen
• Interessante Arbeit & Begeisterung schaffen
• Möglichkeiten schaffen, damit sich Mitarbeiter weiterentwickeln kann
• Raum geben „Fehler zu machen“
• Vertrauen geben
• Kultur etablieren
• Wertschätzung – ganz wichtig, dass MA sieht seine Arbeit wird geschätzt

Peter, wenn du jetzt potentielle neue Mitarbeiter gefunden hast, dann musst du diese auch noch nach ihren Fähigkeiten und Charakteren entsprechend zusammenstellen um ein performantes Team zu erhalten. Wie geht ihr damit um?         

Ich arbeite jetzt seit über 15 Jahren im Bereich SW Entwicklung und ich habe festgestellt, dass es für ein performantes Team unterschiedliche Fähigkeiten und Charakteren braucht. + Kennen der Fähigkeiten der Mitarbeiter

Speziell für ein Scrum Team, dass ein „fertiges, lauffähiges Stück Software“ produzieren muss, braucht ganz unterschiedliche Fähigkeiten und auch Charakteren von Mitarbeitern, vom

• Technologie Freak
• Business Domäne KnowHow
• Scrum Master -> erhöhter Sozialkompenz
• Kundenkontakt ->
• Tester
• Software Ing. mit Freude an guter SW bauen!

Story: interessant ist ja auch immer wieder, wenn ein Mitabeiter aus dem Team geht – z.B. einer der Leaders…negativ, aber auch positiv -> gibt plötzlich neue Chancen für andere Mitarbeiter…

Dani, jetzt eine Frage an Dich: Oft bringen ja die Mitarbeiter im Team einen ganz unterschiedlichen „Rucksack“ mit, wie gehst Du damit um?

Unter einem Rucksack verstehe ich, dass die Mitarbeiter im Team unterschiedliches Know-how, Fähigkeiten und auch Potential mitbringen. Entsprechend dieses Rucksackes gilt es, die Mitarbeiter zu fördern und zu stärken. In unserem Team hatten wir eine sehr heterogene Mischung aus Know-how und Fähigkeiten wie

• Knowow in WindowsForms
  wir nutzten aber Windows Presentation Foundation
• Know-how in C++ und hardwarenaher Programmierung
  wir bauten aber ein Leitsystem in C#/.NET
• Know-how in Applikationen, irgendwie zum Laufen zu kriegen
  wir wollten aber eine strukturierte und qualitätsbewusste Vorgehensweise wie Acceptance Test Driven Development und Test Driven Development mit einer modularen Architektur

Wir nutzten unter anderem Techniken & Vorgehensweisen aus den Extreme-Programming-Praktiken, um das Know-how zu verteilen und ein Alignement unter den Teammitgliedern zu schaffen. Frei nach dem Motto: Kontinuierliches Lernen und Selbstverantwortung. Hier eine kleine Auswahl an Dingen die sehr gut funktionieren:

• Workshops: Neue Konzepte, Architektur, Clean Code Regeln, ein neues Tool…
• Pair Programming: Collective Code Ownership (keine Gärtchen), weniger Bugs
• Coding Dojos: Jeder weiss, wie der andere denkt, gemeinsam Probleme analysieren
• Commit Reviews: Weniger Fehler, man unterhält sich über den Code, Wissen wird verteilt, kein Single Point of Failure
• Retrospektive: Probleme ansprechen und Lösungen dafür finden inkl. Verantwortlichen und Deadlines
• Free time: Innovation entsteht nicht unter Zeitdruck

Damit dies möglich ist, muss das Management die Rahmenbedingungen bereitstellen. Es braucht eine offene Review- und Feedback-Kultur vom Management zum Team aber auch vom Team zum Management. Des Weiteren braucht es Vertrauen des Managements, dass das Team Entscheidungen trifft, die im Sinne der Unternehmung sind.

Aber Peter, der Wissensaufbau ist ja nicht nur aus technischer Sicht wichtig?

Um längerfristig erfolgreich zu sein als Firma, ist es wichtig, das Wissen aufzubauen, zu teilen und festzuhalten.

• um Wissen aufzubauen und zu verteilen – braucht es Kommunikation
  • Was ist die effizienteste Art um zu kommunizieren?
  • Leute vor einem White Board / Flipchart (Feedback & Visuell)
• um Wissen festzuhalten – braucht es  Dokumentation
  • Vorher: Word & Enterprise Architect für UML -> nie up-to-date, immer nachfragen…
  • Neu: Team hat Confluence als Wiki vorgeschlagen -> super, immer up-to-date
  • Geeignete Werkzeuge einführen, damit die Entwickler „von sich aus“ dokumentieren.
• um Wissen aufzubauen und zu teilen (verteilen) – Methodiken
  • Pair Programming: das Wissen & Verständnis kann sehr effizient weitergegeben werden
  • Reviews:   „standard“ einführen, neue Ideen von Kollegen „wie kann man es auch noch machen“…Code Reviews, Commit Reviews, Story Reviews.

Peter, ich denke wenn man so eng miteinander zusammenarbeitet enstehen auch Konflikte. Wie gehst du damit um?

In jedem Projekt und Team wo intensiv zusammen gearbeitet wird treten Konflikte & Missverst… Hier ein paar meiner Erfahrungen & wie ich damit umgehe:

• Chef überhaupt über Probleme & Konflikte informiert wird/ist:
  • Atmosphäre und Kultur schaffen, dass Konflikte und Probleme auch kommuniziert werden
  • Agile Grundwerte: Vertrauen, Offenheit (darf Fehler machen…), Respekt, Transparenz

• Konflikte und Problem ansprechen
  • Chef direkt mit Mitarbeiter, aber unter 4 Augen -> Gesicht bewahren
  • Teilnahme an Team Retrospective: Team/Mitarbeiter wird ernst genommen, info über aktuelle Kundenprobleme
• Möglichkeit bieten um Probleme zu platzieren:
  • Pro Release (alle 3 Monate, 6 Sprints) ein Restrospective Meeting im grösseren Rahmen inkl. Management durchführen. Dies schafft eine Möglichkeit für den direkten Austausch zwischen Team und Management.
• Vorbeugen:
  • Regelmässiger Abgleich mit Product Owner (PO) und Scrum Master (SM) von allen Teams

 Zum  Schluss des Vortrages möchten wir als Zusammenfassung ein paar Schlüsselfaktoren erwähnen für ein erfolgreiches Team:

• Von Anfang an automatisiert: build, installer, test-driven development
• Management Unterstützung für gute Rahmenbedingungen
• Erfolgreiches Team braucht „Leaders“ – Change Agent!
   -> Vorleben und Leaders suchen und fördern
• Technologie und Engineering Practices Wissen von bbv

Wie sieht es bei EROWA heute aus (4 Jahre später)…Wir sind heute 16 Mitarbeiter in der Software Abteilung und seit Jan. haben wir ein 2. Scrum Team für das Projekt neue Roboter Steuerungsplattform + bbv MA – Tim Bussmann

• .NET und PLC (SPS) Teil – Speicher Programmierbare Steuerung (Steuerung & Regelung von Maschinen, resp. Roboter)
• Automatisierte Acceptance Tests bis und mit PLC Code auf Build Server (Sprache IEC631 – C ähnlich)

Wie sie sehen, sind wir überzeugt, dass die Erfolgsgeschichte „zusammen mit bbv Software Services“ weiter geht!