Ich bin der Agile Coach für ein Team, das aus 4 völlig unterschiedlichen Plattformen (iOS, Android, Javascript, Windows) mit jeweils 1 oder 2 Ingenieuren besteht. Es gibt insgesamt 2 automatisierte/manuelle Tester und 1 PO.
Alle 4 Plattformen arbeiten mit genau demselben Rückstand an User Stories (wir haben separate identische User Stories für jede Plattform.
Derzeit haben wir ein einziges Kanban-Board in Jira, das Daten aus 4 verschiedenen Projekten bezieht. Wir haben eine Swimlane für jede Plattform, teilen aber WIP-Limits, Standups, Retros und Demos.
Aktuelle Probleme:
Die Frage ist, sollten diese Plattformen in 3 verschiedene Teams aufgeteilt werden oder mit welcher Technik könnte ich das beheben?
Wenn Sie kein einziges Sprint-Ziel vorgeben können, das es allen Ingenieuren ermöglicht, sich auf ein einziges Ergebnis zu konzentrieren, das für alle relevant ist, hat es wenig Wert, ein einziges Team zu haben.
Wenn Sie nur 2 Personen in einem Team haben, ist der Overhead von Scrum und anderen agilen Praktiken etwas überflüssig. Lassen Sie sie einfach in Zweierteams aufteilen und herausfinden, wie sie den Rückstand von ihrer Plattform/ihrem Produkt erfüllen können.
Wenn Sie jedoch ein einheitliches Ziel haben können, sollten sie sich beim Daily Scrum um die Arbeit der anderen kümmern. Dies wird ihnen den Fokus zurückgeben und es ihnen ermöglichen, zusammenzuarbeiten, anstatt sich zu trennen.
Es hört sich so an, als hätte das Team viel zu viel Pull und die PO nicht genug.
Das Team mit 4 identischen Backlog-Items ist ein großes Warnsignal. Wenn Sie mit einem beginnen und es dann für sie aufteilen, aktiviert es nur das Verhalten. Lassen Sie es als Ganzes und das Team als Ganzes beendet es entweder oder nicht. Manchmal können die Teams anfangs in Silos bleiben und effektiv an kollektiven Backlog-Elementen arbeiten, aber es ist eine fast unmögliche Reihe von Zufällen erforderlich, um dieses Gleichgewicht zu halten. Sobald jemand in den Urlaub fährt oder eine Plattform ins Stocken gerät, wird der Bedarf an fachübergreifenden Teammitgliedern schnell offensichtlich. Von hier aus können Sie das Team auf jedem Weg coachen (und es gibt viele), der für sie funktioniert, um es zu lösen.
Ein Wort der Warnung, wenn Sie sich darauf einlassen: Ich bin vielen Entwicklern begegnet, die sich dagegen wehren, weil sie kein Tausendsassa sein wollen, und das ist eine völlig vernünftige Meinung. So unvernünftig es für die Entwickler ist zu glauben, dass sie eine Fähigkeit erlernen und das Unternehmen dazu bringen können, diesem Silo gerecht zu werden, so unvernünftig ist es für das Unternehmen zu glauben, dass jeder alle Fähigkeiten entwickeln sollte. Sie möchten genügend Überlappung, damit das Team nicht fähigkeitsempfindlich ist. Wie viel Überlappung das genau ist, ist für jedes Team unterschiedlich, und der Scrum Master sollte ihnen helfen, sie zu finden, und sie nicht dazu zwingen.
Reden Sie im Alltag nicht über langweiligen technischen Kram. Sprechen Sie über den Prozess und die Blocker und das Produkt usw. Fordern Sie auf, dass sich die Teammitglieder jeden Tag 15 Minuten lang respektieren, indem Sie einander aktiv zuhören.
Es ist immer noch das gleiche Produkt, die gleiche Organisation und der gleiche Prozess, Sie verwenden immer noch das gleiche Backend oder die gleiche API, also sollten 90 % dessen, was in der Tageszeitung besprochen wird, für alle interessant sein. Plattformspezifische Sachen können erwähnt werden und sollten trotzdem angehört werden, aber das sollte nur 10% sein.
Und weil Sie möchten, dass diese UIs plattformübergreifend auf ähnliche Weise funktionieren, sollte dies ebenfalls besprochen werden, also eher 95 % allgemeine Dinge, 5 % plattformspezifisch.
Es macht Sinn, dass Spezialisten nicht so eng zusammenarbeiten, wenn sie separate Frontends entwickeln, also erwarten Sie davon nicht zu viel. Eigentlich kratzen sie daran, dass sie eng zusammenarbeiten sollten, um sicherzustellen, dass die UIs nicht zu sehr voneinander abweichen und auf allen Plattformen ungefähr gleich funktionieren.
Versuchen Sie, ein bisschen mehr produktorientiert als plattformorientiert zu sein. Schließen Sie das Back-End und die Geschäftsleute in das Team ein.
Es sieht so aus, als hätte der Product Owner keine Produktvision für das Endprodukt erstellt, auf das hingearbeitet wird. Dies wäre ein guter Ausgangspunkt, um alle dazu zu bringen, eine gemeinsame Ansicht zu teilen.
Zweitens stimme ich @Daniel zu, dass 4 identische Stories für jede eine rote Fahne sind und kein gemeinsames Product Backlog ergibt. Haben Sie nur eine Story für jedes Feature und lassen Sie jedes Mini-Team aus 2 Personen ihre Aufgaben erledigen, dann treffen Sie sich und teilen Sie Fortschritte und Hindernisse. Wenn Sie dies zweimal am Tag tun, sollten sie in der Lage sein, auf derselben Seite zu bleiben und besser bereit zu sein, sich gegenseitig zu helfen, falls dies erforderlich sein sollte.
Damit dies funktioniert, muss die Story gut definierte Akzeptanzkriterien haben; nicht nur als zu stellende Fragen, sondern unter Berücksichtigung jeder der 4 Plattformen, für die entwickelt wird. Es ist fast so, als würde man sicherstellen (testen), dass die Funktionen einer Webseite in verschiedenen Versionen von Windows und in verschiedenen Webbrowsern für jede Version auf die gleiche Weise funktionieren.
Die Hauptsache ist, ihnen allen eine Reihe gemeinsamer Werte zu vermitteln, die sie alle zusammenbringen, um das gleiche Ziel zu erreichen.