Siempre es el mismo. ¿Cuál es el patrón típico que imaginas cuando alguien dice que está en una transformación ágil? El escenario habitual es el siguiente: Dependiendo de la cantidad de dinero que tenga una organización, contrata a una de las 3 grandes o una “Boutique Agile” o una empresa de consultoría no tan popular. Vienen, pasan de uno a tres meses y crean un PowerPoint de 200 páginas. El documento está lleno de gráficos, diagramas, escenarios y ventajas clave de nuevos enfoques llamativos. También puede contener algunas sugerencias sobre qué herramientas usar, cómo configurar el primer tablero de Jira, qué cadencia de calendario adaptar y cuál es la diferencia entre la división del trabajo pendiente horizontal y vertical. Lo más probable es que también incluya algún tipo de implementación de SAFe en algún punto entre esas diapositivas: la alta dirección de la organización no quiere perder el control, ¿verdad? Luego, la empresa consultora se marcha. Los gerentes de proyecto pasan a llamarse Scrum Master/Agile Coach/Product Owner, dependiendo de la evaluación del nivel de madurez que los líderes senior decidan que tiene su organización durante el taller sobre la evaluación del nivel de madurez y, tal vez, de la preferencia personal de un individuo específico (incluso la frase que lo describe no tiene sentido). Luego, los equipos organizan ejercicios de Team Charter, crean tableros Scrum Kanban, perfeccionan dos sprints de trabajo y comienzan su trabajo. En este momento, todos ya están irritados porque: Como consultores, durante su evaluación inicial, no tuvieron la oportunidad, el tiempo o el dinero (o todos juntos) de comprender que algunos equipos no están trabajando en el mismo entorno y simplemente no pueden utilizar un flujo de trabajo similar al de otros; Algunos equipos nunca han estado expuestos a lo que realmente significa Agile, aunque ya llevan cinco años trabajando en “nuevas formas de trabajar”; Los ingenieros ahora dedican más tiempo a perfeccionar el trabajo que a codificar; todos saben que lo odian; … Familiar, ¿no? ¿Pero es este el enfoque correcto? De vuelta a la escuela Cuando a los niños se les presenta la geometría por primera vez en la escuela secundaria, todo comienza con lo básico: ¿Qué es un punto, una línea y una superficie? Por qué las líneas paralelas nunca se cruzan; Por qué el ángulo recto es igual a 90 grados; Con este básico es más fácil avanzar. Lo mismo ocurre con Scrum. Cuando abres Scrum Guide, comienza con la teoría. Explica suavemente al lector la idea de empirismo e introduce tres pilares: transparencia, inspección y adaptación. Lo que venga después (reglas, eventos, artefactos, etc.) son implementaciones de los conceptos básicos y son imposibles sin seguirlos. Lo mismo que la geometría, ¿no? Si abre tareas para estudiantes de secundaria, no podrá resolverlas sin los conocimientos básicos que se le proporcionaron en quinto grado. Prueba diferente Intente concentrarse en estos conceptos básicos. No se pueden tocar ni ver, y son difíciles de medir y visualizar en el tablero. Sin embargo, son sus valores los que realmente descubren la belleza de Scrum y ayudan a descubrir "mejores formas de crear software". ¿Cómo se puede promover y seguir la transparencia? ¿Cómo puede asegurarse de que realmente está teniendo en cuenta algunos hechos descubiertos para mejorar sus procesos? ¿Ves realmente todos los residuos innecesarios y exploras formas de eliminarlos? Estas preguntas son la quintaesencia de la Guía Scrum: "Fácil de seguir pero difícil de dominar". Concéntrate en comprender qué potencial descubres a través de acciones específicas. Si sabe qué hay detrás del cambio o la práctica, le resultará más fácil a su equipo comprenderlo y seguirlo. Comenzará a respaldar cada acción con la pregunta: “¿Nos ayuda a obtener mejores resultados? ¿Apoyamos nuestras acciones en tres pilares fundamentales?” Para asegurarse de no cometer los mismos errores que muchas organizaciones que están ingresando al territorio de la Transformación Ágil han encontrado antes, intente leer el Manifiesto Ágil y la Guía Scrum nuevamente. Mientras lee, piense en cómo se presenta cada elemento en estos documentos, cómo se apoyan entre sí y cómo construyen una estructura común que tenga sentido. Use su imaginación La transformación sólo aportará valor cuando se piense en los valores fundamentales cada vez que haya que tomar la decisión. Si ha cometido un error, es posible que deba incluir uno de los elementos clave. Es una locura esperar un resultado diferente sin cambiar tus acciones. De todos modos, debes cambiar algo para volver a intentarlo. Entonces, ¿por qué no intentar regresar a la escuela? Intente comprender qué elemento exacto falta. Encuéntralo, incorpóralo a tu proceso y lo más probable es que tengas éxito. Nuestro principal objetivo es eliminar el hábito que ha dominado el mercado durante los últimos veinte años: el hábito de implementar herramientas y técnicas sin considerar su valor o cómo funcionan exactamente. Recomiendo ampliamente investigar : es una lectura increíble y también la mayor biblioteca de problemas que su equipo puede encontrar si no consideran el propósito de cada elemento que implementan desde el marco. Zombie Scrum ¿Cuál es tu secreto para seguir lo que importa? Comparte en los comentarios.
