Wie ich schon im letzten Artikel erwähnt habe, sind wir aktuell 3 SCRUM Teams und haben diese auch in sehr kurzer Zeit von 4 auf 18 Entwickler hochgefahren (ca. 6 Monate).
Am Anfang gab es eine kurze Kennenlernphase zwischen den einzelnen Personen. Wir waren am gleichen Ort und arbeiteten zusammen. Danach wurden die Teams aufgeteilt und auf die Projekte losgelassen. Relativ schnell war die Kommunikation zwischen den Teams eher rar. Jedes Team hatte seine eigene Philosophie von Design, Standards usw. und über kurz oder lang, gab es kleinere Probleme. Man beschwerte sich, warum jemand das so gelöst hat und nicht so, wie es im eigenen Team geregelt war.
Wir versuchten also einen neuen Ansatz. Die zwei Teams aus Zürich und der Ukraine wurde gemischt, um die Kommunikation zwischen den beiden Standorten zu verbessern. Das Team von Liip, haben wir so belassen, weil es ein externer Partner ist.
Neu besuchen wir uns regelmässig. Leute von Kiev arbeiten 1-3 Wochen bei uns und umgekehrt. Auch die Leute vom Liip Team, arbeiten regelmässig in der NZZ.
Dieser Ansatz hat die Kommunikation zwischen den Teams extrem verbessert. Man versteht sich besser, man fühlt sich verbundener. Natürlich gibt es nach wie vor Problemchen, aber diese sind lange nicht mehr so gross wie vorher.
Was denkt ihr von dieser Lösung? Gibt es noch bessere Ansätze? Sollte man verteilte Teams generell versuchen zu vermeiden?
Ich bin gespannt auf eure Meinung.
Hallo Ralph,
Meine persönliche Meinung aus meiner Erfahrung: Ja, ein verteiltes Team hat (aus der Sicht des Teams und seiner Aufgabe) immer Nachteile gegenüber einem co-located Team.
Das ist jedoch nicht der Punkt. Der Punkt ist, dass verteilte Team aus anderen Gesichtspunkten der gesamten Organisation wiederum Vorteile ermöglichen (Scaling von Teams, Kosten, Experten Know-how, …)
Es gilt also die gesamt-organisatorischen Vorteile gegenüber den Team-orientierten Nachteile abzuwägen. Typische Kriterien aus meiner Erfahrung dazu sind: Kosten, Time2Market, Qualität (bitte messbar definieren, was Q bedeutet), Flexibilität, unverstandene und ungeprüfte Top-Management Entscheidungen (ja, diese leider auch) etc…
Aus meiner Offshoring Erfahrung mit einigen Grossfirmen würde ich gerne den Punkt “Kosten” streichen. Die Mehraufwendungen und Randbedingungen Offshoring aufzusetzen und erfolgreich zu etablieren (in Vollkostenrechnung einschliesslich Reisen und Anwalteskosten, …) heben sich mit den Kosteneinsparungen in etwa auf (das sind inoffizielle aber ernst zu nehmende Aussagen).
Dennoch ist Offshoring ein erfolgreiches Modell, wenn folgende Aspekte hinzugenommen werden: Skalierung von Projekten, Flexibilität (atmende Organisation), strategisches Offshoring (Ersteentwicklung versus Maintenence Modellen).
Ich persönlich würde vorschlagen für die Entscheidung verteilte Teams Ja/Nein einmal die Team orientierte Sicht (Kosten, Risiken) und die Organisationssicht (Kosten, Risiken) gegenüber stellen.
Tipp: Häufig hilft ein anderes “Schneiden” der Aufgaben für die Teams. Jedes Team sollte an Themen mit hoher Kohäsion arbeiten und die Teams untereinander mit Themen loser Kopplung. Also das Backlog auf Programmebene dahingehend groomen und Items auf Teams verteilen in ihr Team Backlog… Dann könnten sich ein lokales und zwei offshore Teams mit weniger Kommunikationsverlust, da weniger Kommunikationsbedarf synchonisieren…
alles meine persönliche Meinung
Viele Grüsse und viel Erfolg
Rainer
Hi Rainer
Ich kann Deinem Feedback absolut zustimmen.
Vielleicht noch als Ergänzung: Natürlich versuchen wir unsere Arbeitspakete so zu schnüren, dass sie pro Team eine hohe Kohäsion haben. Ein Ziel ist aber auch, dass das Knowhow längerfristig über alle Teams verteilt wird. Das heisst, jeder soll mal an jedem Teil eines Projektes arbeiten können (Frontends / Backend / Repository usw.).
Obwohl jedes Tier das gleiche Setup hat (Sprache, Framework), merkt man doch anhand der Naming Conventions, Designs usw, welches Team gerade an welchem Feature gearbeitet hat. Eigentlich sollte man den Unterschied ja nicht merken.
Durch das, dass wir uns jetzt regelmässig sehen und miteinander kommunizieren, gleichen sich diese unterschiedlichen Strukturen immer mehr zu einem gemeinsamen Standard an.
Wirklich ein interessantes Thema, ich hoffe du ziehst das durch und man erhält noch mehr Einblicke in Probleme und Lösungen.
@Arne – kommt immer darauf an, wieviel wir lernen 🙂 Aber natürlich versuche ich gelerntes stets hier zu verbloggen.
Was ihr auf jedenfall braucht ist eine “Defintion of Done” – wann ist eine User Story fertig, wo die Teams sich auf gemeinsame Qualitätsstandards einigen.
Zudem kann ein Scrum of Scrums (das Daily Scrum für Teams) hilfreich sein, wenn explizit über Probleme gesprochen wird, die ein Team hat. Um die gemeinsame Qualität zu verbessern kann es uch sehr hilfreich sein, Task Breakdowns mit Mitgliedern aus anderen Teams zu machen, so dass diese auch mehr Einblick in eure Arbeit haben und evtl. auch Probleme frühzeitig erkennen bei Themen, wo andere schon mehr Erfahrung haben.
Das mal so aus meiner persönlichen Sicht. Ich arbeite in einem von 5 Scrum Teams und wir haben unseren Qualitätsanspruch mittlerweile zum Anfang enorm gesteigert und nach einem eher zähen Tauziehen auf eine Defintion of Done geeinigt, welche regelmäßig angepasst wird.
@Dennis
Auch wir haben eine Definition of Done und ein Scrum of Scrums. Natürlich hilft das, ist aber doch eher auf High Level Ebene.
Man kann in der Definition of Done z.B. definieren, dass für allen Code Tests geschrieben werden. In der Praxis sieht das dann aber bei jedem anders aus. Die einen probieren die Codeabdeckung einfach irgendwie auf grün zu kriegen, andere machen sich sehr detaillierte Gedanken wo Grenzwerte sein können, sie versuchen sinnvolle Namen für die Testmethoden zu geben usw.
Auf dieser Ebene ist es schwierig gleich zu arbeiten, speziell in verschiedenen Teams, die dann noch nicht einmal am gleichen Ort sind.
Wo in der Ukraine sind Eure Leute? Auf der Krim oder am Schwarzen Meer? 😉 (ps: ich habe Deinen Blog grad im Google Reader aboniert!)
Hi Rémy. Ehrlich gesagt, weiss ich gar nicht, wo sie genau angesiedelt sind 🙁 Thx fürs abonnieren, obwohl ich ja im 2012 wirklich sehr wenige Beiträge verfasst habe.