Evita los 10 errores comunes de Scrum
Es importante tener en cuenta que aunque Scrum es uno de los marcos de trabajo ágil más utilizados posiblemente el más abusado. Scrum es simple en concepto, pero puede ser difícil hacerlo realmente bien.
Scrum como hemos comentado no es el único marco es necesario que cada equipo puede adaptarlo según sus necesidades y contexto.
Además, es fundamental comprender los principios detrás de Agile y no limitarse únicamente a seguir prácticas sin entender su propósito. La transformación a Agile y Scrum lleva tiempo y requiere un cambio cultural, y es importante mantener las expectativas realistas desde el principio.
Es importante mantener una mentalidad de aprendizaje y estar dispuesto a adaptar y mejorar constantemente las prácticas.
10 errores comunes de Scrum y cómo evitarlos:
1. Esperando que la transformación a Agile y Scrum sea fácil
Con demasiada frecuencia, alguien leerá un libro sobre Agile o Scrum, empezará a dividir los requisitos en las historias de los usuarios, comenzará a realizar reuniones diarias (stand-up), desarrollará software en Sprints de 2 a 3 semanas y luego se llamará a sí mismo Agile. Fácil, ¿verdad?
Es probable que vean alguna mejora en su capacidad para responder al cambio, e incluso pueden proporcionar software funcionando más rápido -por un tiempo.
Sin embargo, no pasará mucho tiempo hasta que las promesas de Agile se vuelvan menos evidentes, los equipos luchan por mantener el ritmo, el software no siempre cumple con las expectativas de los usuarios y, a continuación, Agile se considera un fracaso.
La transformación Agile lleva tiempo y casi siempre comienza desordenada.
La transformación real expone los problemas corporativos y culturales existentes con los que hay que lidiar: problemas como la falta de comunicación, la falta de responsabilidad, la desconfianza, etc.
La transformación Agile efectiva es a menudo un cambio cultural total. Dale tiempo y prepárate para enfrentar el dolor y la resistencia a los cambios culturales.
2. Realizando prácticas sin considerar los principios
Hacer las cosas fáciles como implementar reuniones de Scrum, llenar los roles de Scrum y usar los artefactos Scrum adecuados es bueno, pero es solo la mitad (o menos) de la batalla.
Los principios Agile son los que hacen que las prácticas funcionen bien y que sean sostenibles a largo plazo. Los principios son mucho más difíciles de incorporar que las prácticas, y esto es por lo que muchas empresas fallan rápido – no hacen las partes difíciles. Usar técnicas sin entender por qué las estás haciendo puede llevarte a la frustración. Agile se trata de personas, interacciones y cultura, no de procesos, prácticas y herramientas.
3. Complicando el arranque de Agile / Scrum
Haz todo lo que puedas para mantener el arranque Agile simple. Los proyectos Agile pueden ser exitosos sin la más novedosa y mejor herramienta de colaboración o ciclo de vida. Post-its en la pared, tareas en una hoja de cálculo y un gráfico de Burn-down-chart generado manualmente harán el trabajo. Al dedicar tiempo valioso en poner en funcionamiento una herramienta, en lugar de hacer que las personas trabajen juntas, se está enfocando en algo incorrecto. El Manifiesto Ágil otorga mayor valor a las personas e interacciones que a los procesos y herramientas.
4. Liderando un equipo Scrum igual que un Project Manager
Una mentalidad de «comando y control» va en contra a un marco Agile. Un líder que asigna tareas e impone el esfuerzo es un anti-patrón Agile. Los grandes equipos Agile son autoorganizados, el Scrum Master es un líder servicial, y los equipos aprenden a ser mejores para trabajar juntos y ofrecer mayor valor de manera más eficiente mediante la inspección y adaptación de manera periódica.
A menudo, una lección se aprende mejor por la experiencia (experiencia buena o mala) que solo por saber qué hacer. Permita que el equipo Scrum resuelva las cosas por sí mismos, cometa errores y aprenda de ellos, y logre la satisfacción de convertirse en un equipo productivo por sí mismos. Los Scrum Masters y Agile coaches guían más de lo que conducen.
5. Un Product Backlog que no esta listo
Un Product Backlog que no está «listo» es una de las razones más comunes para el fracaso del Sprint y para los equipos desmotivados. También es la causa raíz de la baja velocidad de entrega, y la no entrega de valor alto. La mayoría de los nuevos Product Owners no están listos para ser productivos por sí mismos.
Necesitan instrucción, entrenamiento y guía en los primeros Sprints para que aprenden a desarrollar y mantener un Product Backlog con suficientes features valiosos, estimados a alto nivel, y priorizadas por valor comercial. La preparación del Backlog mucho antes del próximo sprint es una necesidad. Nunca se desea que el equipo se quede sin trabajo, y ese trabajo debe ser de mayor valor en el momento en el que lo prioriza el Product Owner. Ser Product Owner puede llevar mucho tiempo. Establezca las expectativas correctas, brinde toda la capacitación y ayude al Product Owner a conservar el flujo de valor siguiente.
6. Comunicando a través del Scrum Master
Algo que veo con bastante frecuencia en los nuevos equipos de Scrum es que las personas utilizan al Scrum Master para enviar sus mensajes. Por ejemplo, un desarrollador tiene una pregunta sobre una historia de usuario; En lugar de ir directamente donde el Product Owner, envía un correo electrónico al Scrum Master para obtener la información.
Un principio clave de Agile es la comunicación cara a cara siempre que sea posible. El tiempo que lleva redactar el correo electrónico probablemente hubiera sido todo lo que se necesitaba para obtener la respuesta directamente. Pero, para muchas personas técnicas, la comunicación cara a cara es algo aterrador cuando están acostumbrados a vivir en su mundo de cubículos, sin tener que hablar con la gente. Este es un problema cultural o de personalidad que debe ser superado. Se pierde tiempo y, lo que es más importante, aumenta el riesgo de falta de comunicación.
7. Un Product Owner que no está disponible o involucrado
El rol del Product Owner puede consumir mucho tiempo. Muchos de los que son nuevos en el rol no están listos para el compromiso, o simplemente no saben que necesitan estar tan involucrados. La colaboración es crítica en el mundo Agile. La gente de negocios y los desarrolladores necesitan trabajar juntos para producir el software que la empresa quiere. Esto sucede mediante una comunicación constante, colaboración y ciclos cortos de retroalimentación para validar o hacer correcciones en el curso.
Una práctica que me encanta ver es que el Product Owner está tan involucrado en la actividad diaria del equipo del proyecto es que el Sprint Reviewes puramente una formalidad porque el Product Owner ya ha visto varias iteraciones de los features durante todo el Sprint y ha guiado al equipo para construir exactamente lo que quiere el negocio.
8. Daily Stand-ups relajados
La reunión diaria(stand-up) es muy importante desde varios aspectos. Pone a las personas cara a cara todos los días durante 15 minutos, obliga a la comunicación y la colaboración, y proporciona visibilidad y transparencia en el proyecto. Para una reunión tan importante, es importante establecer las expectativas correctas por adelantado para que el equipo se lo tome en serio.
Esto puede parecer agresivo, pero la asistencia al stand-up diario nunca es opcional. Comience a tiempo y termine a tiempo. Apégate a las tres preguntas (qué logré ayer para el proyecto, en qué trabajaré hoy, qué obstáculos me estan impidiendo completar mi trabajo a tiempo). No permita conversaciones secundarias, discusiones o resolución de problemas durante el stand-up; todo eso se puede hacer después de que el stand-up haya terminado. Esto pone al equipo en la forma de respetar el tiempo del equipo y de las personas, y aprenden a comunicarse mejor aferrándose a los objetivos y siendo concisos.
9. No levantando obstáculos de manera temprana
El stand-up diario brinda la oportunidad todos los días de comunicar los impedimentos para realizar nuestro trabajo. Una de las funciones principales del Scrum Master es eliminar obstáculos para que el equipo pueda concentrarse en la entrega de software; pero si los obstáculos no se levantan, el Scrum Master no puede ayudar a eliminarlos. Esperar para levantar un obstáculo hasta que sea demasiado tarde para recuperarse es inaceptable. Hasta que los miembros del equipo estén acostumbrados a comunicar los obstáculos de manera oportuna, recuérdele al equipo al comienzo de cada stand-up que mencione incluso los obstáculos potenciales, o si existe alguna posibilidad de que algo pueda retrasar su trabajo o si hay alguna posibilidad de que algo pueda retrasar su trabajo o hacer que no cumplan con el compromiso del Sprint.
10. No realizar retrospectivas después de cada Sprint
Uno de los doce principios detrás del Manifiesto Agile es «A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia». Desafortunadamente, la Retrospectiva a menudo se trata como un complemento o un lujo, y se realiza solo «si hay tiempo». El hecho es que Agile tiene que ver con los ajustes aquí y allá, el ajuste fino y la respuesta al cambio. Es realmente difícil de ajustar y ajustar si no hacemos una pausa para averiguar dónde se necesitan ajustes. El status quo no es Agile; la mejora continua es el camino a seguir.
Bibliografía
💡 Traducción al castellano del artículos «10 Common Scrum Mistakes and How to Avoid Them» escrito por Dwight Kingdon
📖 Ante la duda puedes consultar Scrum Guide
🔍 Glosario de terminos Scrum Manager ➡️ Aquí
✏️ Blog Mobiliza Academy ➡️ Blog
📺 Canal Youtube AgileValencia
Etiqueta:SCRUM
