Bienvenidos a la segunda parte de nuestra serie de consejos como evitar tembloroso escenarios (o recuperarse de ellos si se te acercan sigilosamente).
En pocas palabras, wagile es lo peor.. Es una mezcla de ágil y cascada metodologías, y muchos creen que este enfoque híbrido proporciona lo mejor de ambos mundos. De hecho, crea caos y confusión, lo que, francamente, destruye la gestión eficaz de proyectos. Si tiene un script de Wagile que puede compartir, envíelo a [email protected]y ya veremos
Métodos de mezcla
¡Hola, Kevin y Tommy!
Mi pregunta está relacionada con la velocidad de adaptación Agile en diferentes equipos. Trabajo en una gran organización en la industria automotriz con varios grupos de productos. Algunos de los equipos más grandes que trabajan en Agile están organizados como trenes para Agile Release SAFe, mientras que otros usan métodos de equipo Agile (Scrum y, a veces, Kanban).
Notamos una diferencia significativa en la tasa de adaptación entre diferentes grupos de productos. Algunos están en un alto nivel de madurez y están mejorando rápidamente, mientras que otros parecen estar más lentos: actualizamos el gráfico de madurez del radar cada tres meses. ¿Cómo podemos asegurarnos de que todos nuestros equipos han aumentado su aceptación y velocidad y se vuelven más eficientes?
Felicidades
Guardia
Adapta Agile a los componentes digitales del producto
¡Hola Garda!
Medir la madurez de la agilidad entre diferentes equipos es tan desafiante como medir la efectividad de equipos más clásicos.
En primer lugar, es importante darse cuenta de que la adopción y eficacia de los métodos ágiles depende en gran medida de los productos en los que trabajan los equipos. Algunos comandos serán más lentos de implementar simplemente porque la flexibilidad es menos aplicable a ellos. En una organización tan grande y compleja como la suya, es probable que muchos equipos diferentes estén trabajando en diferentes productos. La naturaleza de estos productos tiene una gran influencia en la eficacia de Agile. En general, podemos decir: «Cuanto más digital sea el producto, más efectiva será la flexibilidad».
Si observa ejemplos clásicos de implementaciones flexibles exitosas (Spotify, Netflix, bancos, compañías de seguros, etc.), verá que todos tienen un producto final que se inclina fuertemente hacia la derecha y se basa en unos y ceros.
La razón de esto radica en la llamada «arquitectura inicial», es decir, la cantidad de arquitectura que necesita por adelantado, para que finalmente obtenga un producto sostenible. Ejemplo:
-
La mayoría de las empresas de SaaS probablemente estén pensando en la arquitectura de su software en una etapa temprana, pero la mayor parte de la arquitectura se creará durante la programación.
-
Si crea algo más en el lado izquierdo de la escala, por ejemplo, un avión, todos los componentes deben encajar perfectamente y no se pueden controlar mientras se ensambla el avión, ya que el costo de reemplazar los componentes en medio del ensamblaje será devastador. Es por ello que este tipo de productos requieren de una arquitectura previa.
En el gráfico se ve así:
Algunas empresas han podido trabajar con productos que tienen una gran arquitectura inicial y han perfeccionado el arte de dividirlos en componentes más pequeños, algunos de los cuales son más adecuados para la creación utilizando el enfoque de arquitectura resultante (p. Software utilizado en aviones).
Cuando un producto grande y complejo consta de componentes físicos y digitales, es muy importante que las organizaciones adapten su implementación flexible solo a digital componentes del producto, no todo el producto, ya que Agile se implementa en físico componentes hacen que se vuelvan inestables.
Debido a que el producto es importante cuando se analiza la adaptación Agile en equipos, es difícil comparar el progreso entre diferentes equipos. Sin embargo, podemos aplicar un pariente medir el rendimiento de cada equipo comparándolos con ellos mismos.
Al igual que la puntuación relativa y la velocidad utilizadas en ágil planificación de póquer Podemos aplicar el mismo proceso de pensamiento para medir la productividad relativa.
Los gráficos de radar que usas son geniales para esto; evaluar bien el rendimiento relativo del equipo a lo largo del tiempo. Ten en cuenta que las métricas específicas se miden por los cinco puntos de estas webs pueden diferir entre organizaciones, departamentos y equipos. La práctica conceptual es importante aquí.
4 consejos para evaluar el nivel de aceptación de los equipos
Según nuestra experiencia, hay algunas cosas clave a tener en cuenta al ayudar a varios equipos a adoptar de manera efectiva una metodología flexible sin entrar en territorio wagile:
-
No vincule el rendimiento del equipo con la adopción de Agile.
-
El uso de Agile depende en gran medida de la naturaleza del producto.
-
Mida la velocidad de adaptación del equipo utilizando la matriz de rendimiento relativo.
-
Comparar la velocidad de adaptación entre diferentes equipos es difícil y puede llevar a conclusiones distorsionadas.
¡Buena suerte!