Soy el Agile Coach de un equipo que consta de 4 plataformas completamente diferentes (iOS, Android, Javascript, Windows) cada una con 1 o 2 ingenieros. Hay 2 probadores automáticos/manuales en total y 1 PO.
Las 4 plataformas funcionan precisamente a partir de la misma acumulación de historias de usuarios (tenemos historias de usuarios idénticas separadas para cada plataforma).
Actualmente tenemos un solo tablero kanban en Jira que extrae datos de 4 proyectos diferentes. Tenemos un carril para cada plataforma, pero compartimos límites WIP, standups, retro y demostraciones.
Problemas actuales:
La pregunta es, ¿deberían estas plataformas dividirse en 3 equipos diferentes o qué técnica podría usar para solucionar esto?
A menos que pueda proporcionar un solo Sprint Goal que permita a todos los ingenieros concentrarse en un solo resultado que sea relevante para todos, tiene poco valor tener un solo equipo.
Si solo tiene 2 personas en un equipo, los gastos generales de Scrum y otras prácticas ágiles son un poco redundantes. Simplemente pídales que se dividan en equipos de dos y descubran cómo cumplir con el trabajo pendiente de su plataforma/producto.
Sin embargo, si puede tener un solo objetivo unificado, entonces deberían preocuparse por el trabajo de los demás en el Daily Scrum. Esto les devolverá el enfoque y les permitirá trabajar juntos, en lugar de separarse.
Parece que el equipo tiene demasiada influencia y el PO no es suficiente.
El equipo que tiene 4 elementos atrasados idénticos es una gran bandera roja. Si comienza con uno y luego lo divide para ellos, solo está habilitando el comportamiento. Déjalo como uno y el equipo en su conjunto lo terminará o no. A veces, al principio, los equipos pueden permanecer aislados y avanzar en los elementos de la cartera de pedidos colectiva de manera efectiva, pero se necesita un conjunto casi imposible de coincidencias para mantener ese equilibrio. Tan pronto como alguien se va de vacaciones o una plataforma se topa con un obstáculo, la necesidad de miembros del equipo interdisciplinarios se hace evidente. Desde aquí, puede asesorar al equipo en cualquier camino a seguir (y hay muchos) que les funcione para resolverlo.
Sin embargo, una advertencia a medida que se aventura en esto: me he encontrado con muchos desarrolladores que se resisten a esto porque no quieren ser un experto en todo y esa es una opinión completamente razonable. Por mucho que sea irrazonable que los desarrolladores piensen que pueden aprender una habilidad y hacer que la empresa se adapte a ese silo, es igualmente irrazonable que la empresa piense que todos deberían desarrollar todas las habilidades. Desea suficiente superposición para que el equipo no sea frágil en cuanto a habilidades. Exactamente cuánta superposición será diferente para cada equipo y el scrum master debe ayudarlos a encontrarla, no obligarlos a hacerlo.
No hables de cosas técnicas aburridas en el día a día. Hable sobre el proceso y los obstáculos y el producto, etc. Exija que los miembros del equipo se respeten durante 15 minutos cada día escuchándose activamente.
Sigue siendo el mismo producto correcto, la misma organización y el mismo proceso, todavía está utilizando el mismo backend o API, por lo que el 90% de lo que se discute en el diario debería ser interesante para todos. Se pueden mencionar cosas específicas de la plataforma y aún se deben escuchar, pero esto solo debe ser del 10%.
Y debido a que desea que estas interfaces de usuario funcionen de manera similar en todas las plataformas, eso también debe discutirse, por lo que es más como un 95% de cosas comunes, un 5% específico de la plataforma.
Tiene sentido que los especialistas no trabajen tan de cerca entre sí si están desarrollando front-end separados, así que no esperes mucho de eso. En realidad, elimine que deberían trabajar en estrecha colaboración para asegurarse de que las interfaces de usuario no diverjan demasiado y funcionen aproximadamente igual en todas las plataformas.
Intenta centrarte un poco más en el producto que en la plataforma. Incluya a los chicos de back-end y de negocios en el equipo.
Parece que el propietario del producto no ha creado una visión del producto para el producto final en el que se está trabajando. Este sería un buen punto de partida para que todos compartan un punto de vista común.
En segundo lugar, estoy de acuerdo con @Daniel, tener 4 historias idénticas para cada una es una señal de alerta y no genera una acumulación de productos común. Tenga solo una historia para cada característica y haga que cada mini-equipo de 2 complete sus tareas, luego reúnase y comparta el progreso y cualquier impedimento. Hacer esto dos veces al día debería permitirles permanecer en la misma página y estar más listos para ayudarse mutuamente en caso de que surja la necesidad.
Para que esto funcione, la Historia deberá tener criterios de aceptación bien definidos; no solo como preguntas para hacer, sino teniendo en cuenta cada una de las 4 plataformas en las que se está desarrollando. Es casi como asegurarse (probar) que las funciones de una página web funcionen de la misma manera en diferentes versiones de Windows y en diferentes navegadores web para cada versión.
Lo principal es darles a todos un conjunto de valores comunes que los acerque a todos para lograr el mismo objetivo.