Tenemos un conjunto de equipos y están tratando de volverse ágiles. Digamos que cada equipo admite una aplicación y tenemos un total de 4 equipos y 4 aplicaciones. Cuando tenemos proyectos que están todos dentro de un equipo/aplicación y el backlog encaja dentro del equipo, todo parece funcionar bien. Donde se vuelve complicado es si hay un retraso en el que:
Parece que hay dos recomendaciones ágiles que parecen contradictorias:
El deseo de crear equipos de funciones (lo que abarcaría a personas de todos los equipos de la aplicación, presumiblemente tomando algunas personas de cada equipo de la aplicación) para que cada "equipo de proyecto" tenga una sola capacidad para entregar la función completa por sí mismos.
El deseo de tener equipos duraderos que puedan aumentar la confianza, un buen historial de velocidad de seguimiento y una mejor estimación.
El problema con este primer enfoque (y por qué entra en conflicto con el segundo) es que sigues creando nuevos equipos de proyecto para mapearlos en el alcance del proyecto y los equipos se forman y disuelven una y otra vez para que no obtengas el seguimiento de velocidad de larga duración, de esos equipos interfuncionales.
¿Hay algún consejo para estas ideas aparentemente contradictorias?
No cree una falsa dicotomía al confundir la elección organizacional de cómo estructurar los equipos con el mecanismo para escalar el marco Scrum dentro de la empresa. La estructura del equipo que elija afectará su nivel de esfuerzo de integración, pero no afectará en última instancia al mecanismo de escalado en sí.
Independientemente de cómo forme sus equipos, cada equipo trabajará a partir de un solo Product Backlog para un proyecto determinado. Sin embargo, la empresa también puede tener un Product Backlog y delegar subproyectos a diferentes equipos para operar a escala.
Por definición, cada proyecto tiene exactamente un Product Backlog. Asimismo, cada equipo trabaja a partir de exactamente un Product Backlog por Sprint.
Lo que está describiendo suena como una situación en la que es posible que desee que más de un equipo trabaje desde un solo Product Backlog general administrado a nivel empresarial. Hay varias formas de resolver los problemas relacionados con el escalado de Scrum para la empresa, que incluyen:
La mayor parte de la complejidad proviene del hecho de que su organización actualmente no está alineada con la forma en que se dota de personal a sus proyectos y se distribuye el trabajo. Esto es en gran medida un problema de ingeniería de procesos, aunque es posible que también deba realizar algunos cambios en sus organigramas.
Si tiene un nuevo producto que abarcará varios equipos en toda la empresa, ya conoce sus opciones organizacionales:
Hay pros y contras organizacionales para cada enfoque, pero eso está fuera del alcance de la pregunta original. Veamos dos ejemplos de cómo se puede escalar el proyecto.
Se forma la cartera de pedidos de la empresa, y se tallan temas y épicas para definir los subproyectos que formará equipos Scrum para entregar. Cada equipo recibe un solo Product Backlog que se compone de los temas y las epopeyas que definen los objetivos del equipo.
El Product Owner y el Scrum Master de cada equipo Scrum luego participan en el Scrum-of-Scrums (o el marco de escalado de su elección) donde se coordina el Product Backlog a nivel empresarial.
Debido a que el equipo a menudo se centra en las características, a menudo se requiere más coordinación en el nivel de Scrum-of-Scrums, y será necesario administrar muchas más dependencias entre equipos en todos los niveles. Sin embargo, el enfoque estrecho del equipo puede hacer posible trabajar con equipos que son menos interfuncionales, porque la interfuncionalidad existe entre los equipos y no dentro de cada equipo individual. Esta es una de las muchas compensaciones que debe hacer a nivel empresarial cuando planifica el proyecto de nivel superior.
En realidad, esto es muy similar al ejemplo anterior, excepto que los equipos no se forman en torno a funciones específicas. En cambio, el Product Backlog del equipo se compone de segmentos verticales que aprovechan la naturaleza interfuncional del equipo para brindar funcionalidad al Scrum-of-Scrums.
Este enfoque reduce la interdependencia entre los equipos de Scrum dentro de cada Sprint, pero aún requiere una coordinación activa a nivel empresarial para garantizar que el trabajo se integre al final de cada iteración. Además, al garantizar que los equipos sean completamente multifuncionales en lugar de especializados, hay más flexibilidad para mover elementos de la Lista de productos a nivel empresarial entre equipos a medida que cambian la capacidad, los requisitos o las prioridades.
david hillier
leora
david hillier
leora
leora
david hillier
jose bruce