¿Usar SCRUM es ser ágil?, ¿nadie quiere ir a tus retrospectivas?, ¿el P.O. es el jefe del equipo? Éstas son algunas de las preguntas que escucho cuando acompaño a los equipos en la implementación de agilidad como forma de trabajo.
Te comparto en este blog post los antipatrones más comunes que he detectado desde mi experiencia y cómo aconsejo contrarrestarlos.
Introducción
SCRUM es un conjunto de reglas, procedimientos, eventos, artefactos y roles que tienen como objetivo generar valor constantemente; como lo dice Jeff Sutherland, son las reglas del juego. Estas reglas son flexibles y, por tal motivo, en algunas ocasiones, se pueden romper cuando no se tiene experiencia o un adecuado entendimiento.
.png?width=604&name=Anti-Patrones%20de%20SCRUM%20(2).png)
Scrum es muy fácil de entender y muy difícil de aplicar. Para entenderlo mejor, me gustaría que tengamos en cuenta las siguientes definiciones:
¿Qué es un patrón?
“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y luego describe el núcleo de la solución a ese problema; de tal manera que puedes usar esta solución un millón de veces, sin hacerlo dos veces de la misma manera”.
Christopher Alexander, Un lenguaje de patrones (A Pattern Language).
Cómo vemos en la definición anterior, los patrones nos sirven para dar soluciones a problemas recurrentes.
¿Qué es un antipatrón?
Los antipatrones ocurren cuando creemos que la solución que estamos planteando al problema parece ser la correcta y la más fácil de implementar, pero termina siendo un problema o causando más problemas de los que soluciona. Los antipatrones se ocultan dentro de las buenas prácticas y parecen parte del sistema.
Antipatrones en SCRUM
Desde mi experiencia, algunos de los antipatrones que constantemente veo en equipos y organizaciones son:
Creer que por usar SCRUM estamos siendo ágiles
Constantemente me encuentro esto, las organizaciones llevan varios años haciendo scrum y por consiguiente creen que están siendo ágiles; sin embargo, siguen teniendo las mismas prácticas tradicionales.
Para hacer la transición es necesario reforzar el “mindset ágil”, volver a las raíces, al manifiesto ágil, abrazar los 4 valores y los 12 principios.
La agilidad la podemos visualizar como una sombrilla bajo la cual están las prácticas y los marcos de trabajo. Si solo hacemos las prácticas (hay muchas) y no lo hacemos alineados con los valores y los principios tendremos un fake-agile
Ver Manifiesto por el desarrollo ágil de software
En la planeación, el Product Owner asigna el trabajo a los desarrolladores
Es muy común que en la planeación los dueños de producto (P.O.) digan a los desarrolladores como hacer su trabajo, dejando de promover la autoorganización y el compromiso.
Recomiendo que un Scrum Master con experiencia acompañe al P.O. a mejorar el entendimiento del rol y a los desarrolladores a empoderarse del cómo hacer el trabajo.
Usar la reunión diaria (daily meeting) como un momento de seguimiento
El propósito del evento es lograr la sincronización de los desarrolladores para alcanzar el objetivo del sprint, el seguimiento puede darse como consecuencia del avance del sprint y no cómo el propósito del evento.
La review se transforma en el evento donde el P.O. valida el trabajo del “equipo de desarrollo”
En SCRUM existen 3 roles (Scrum Master, Dueño de Producto y Desarrolladores) que son parte de un solo equipo, no existen subequipos. Sin embargo, he experimentado ausencia de dueños de producto en equipos SCRUM. Algunos P.O. solo van a las planeaciones y revisiones, pero no están presentes durante el sprint, y a veces van al evento daily a hacer seguimiento.
Mi recomendación es tener dueños de producto empoderados, capacitados en el rol y con el tiempo suficiente para ejercer el rol.
La retrospectiva se transforma en una reunión de media hora a la que nadie quiere ir
Cuando se pierde el propósito del o de los eventos, éstos se convierten en eventos que no le generan valor al equipo, por el contrario, sienten que les roba tiempo de trabajo.
Recomendación para este antipatrón: Tener un Scrum Master con experiencia en el agilidad o dar acompañamiento a los roles por parte de un agile coach.
Dueños de producto (P.O.) que son los jefes del equipo
Es muy común en las compañías designar a los jefes como P.O., esto no solo significa una carga adicional a las funciones de jefe, sino también promover la jerarquía en el equipo. El equipo responde a las órdenes del jefe, mermando la autonomía de los desarrolladores. Adicionalmente, si los P.O. no son jefes pero creen ser quienes dan órdenes a los desarrolladores y asignan el trabajo, este problema se agrava.
Para atacar esta situación es necesario reforzar el mindset ágil, hacer acompañamiento al P.O. con capacitaciones sobre su rol y mentoring.
Cronograma en sprints
Cuando las empresas están transicionando hacia un cambio ágil, normalmente, interpretan la planificación del producto en sprints como el nuevo GANTT, y se crea un ambiente hostil, de represión y cumplimiento de fechas a toda costa. Scrum no es para administrar proyectos, es para construir productos en un ambiente de incertidumbre donde otras formas de contracción generan menos valor.
Recomiendo reforzar el mindset ágil, crear pilotos de productos y aprender de lo encontrado con estos pilotos para ajustar la cultura.
SCRUM nos permite terminar los proyectos/productos antes
¿Usamos SCRUM para poder terminar más rápido? Muchas empresas lo asumen así, pero la verdad es que SCRUM nos permite fallar más rápido, evaluar más rápido, cambiar nuestro rumbo más rápido, abandonar más rápido, generar valor más rápido para todo lo anterior. Pero, si no se genera este valor y lo sometemos a revisión, pruebas y escrutinio de nuestros clientes, no va a servir para nada.
El Scrum Master es el nuevo gerente de proyectos
El Scrum Master es un rol que poco comprendemos, muchas veces creemos que no hacen nada, que es un hippie que solo le importa la felicidad y la paz mundial.
Realmente el propósito del rol es ayudar a que el equipo genere valor. Para eso debe tener una serie de habilidades, competencias y conocimientos. El Scrum Master debe ayudar al P.O. a encontrar la mejor forma de gestionar la lista de necesidades del producto a construir y enseñar al equipo a remover impedimentos o a cancelar las actividades en caso que ellos no puedan, facilitar los diferentes eventos del framework, ayudar a la organización a cambiar su mindset ágil. No es el que toma decisiones sobre las personas, el producto, el cronograma o la asignación del trabajo pendiente.
Nos faltó un poquito para terminar, ampliemos el sprints 2 días
Cuando estamos en un entorno de mando y control donde no se es permitido o se ve mal el no cumplir con los compromisos, los equipos scrum pueden verse forzados a estirar los tiempos de los sprints de SCRUM. Esto hace que no se tenga un ritmo constante en la entrega de valor o en la inspección por la generación de valor.
Es necesario tener ese ritmo, hacer la inspección y mejora continua para evidenciar las diferentes situaciones que no nos permiten terminar en tiempos comprometidos.
En este sprint hacemos el front, el siguiente el back y en el último hacemos las pruebas
Cuando no utilizamos adecuadamente la división de historias podemos estar construyendo productos en cascada ágil. Uno de los propósitos de dividir las historias de usuario es poder generar incrementos pequeños de productos, pero incrementos completos. No sirve de nada construir pantallas que no tienen funcionalidad completa, que no sirven para que el usuario lo pueda usar para validar flujos. De igual manera pasa con bloques construidos desde la visión técnica y que el usuario no puede interactuar.
La mejor forma de mejorar este aspecto es tener funcionalidades pequeñas completas, construidas y mejoradas de forma evolutiva e incremental.
.png?width=431&name=Anti-Patrones%20de%20SCRUM%20(3).png)
Conclusión
En algunas ocasiones, podemos creer que estas acciones o soluciones son correctas al presentarse como una respuesta lógica o que está a simple vista, pero no siempre es así. Por ello, estoy seguro que también tienes algunos tips que me serían de mucho valor para identificar nuevos antipatrones que, posiblemente, hayas o puedas encontrar en tu equipo y organización.
Por último, quisiera saber qué te parecieron estas recomendaciones. También te comparto abajo el link a la sesión que impartí sobre el tema. Puedes escribirme a etrujillo@palo-it.com, estaré encantado de conversar del contigo.
Si te ha gustado el post, suscríbete para recibir más consejos, buenas prácticas e información en el mundo de la tecnología, agilidad e innovación.
Bibliografía
Antipatrones del Scrum master (linkedin.com)
4 antipatrones agile y una mentira bien gorda | Kaleidos Blog | Beautiful tech, beautiful values
