En mi artículo anterior, inicié la discusión en torno a los hábitos mal desarrollados dentro de un equipo scrum que acabarán conduciendo (tarde o temprano) a un fracaso en la entrega. En este artículo, me gustaría ampliar este tema una vez más y centrarme ahora en los procesos funcionales dentro del equipo.
Éstos son tan importantes como la excelencia técnica del equipo. Incluso si las personas que están dentro son superdotadas para el trabajo que van a entregar, sigue habiendo áreas que pueden arruinar su esfuerzo por la perfección. Y no será tanto culpa suya como responsabilidad directa de las decisiones de gestión del proyecto y de su capacidad para servir al equipo con procesos adecuados para apoyar al equipo con una intención clara y actividades predecibles.
Equipo muy segregado con distintas habilidades
Imagine que el equipo cuenta con desarrolladores cualificados, perfectamente independientes y con la capacidad de cumplir sus promesas y entregar el contenido acordado para el sprint justo a tiempo antes del final del mismo. Incluso en un escenario tan perfecto (que de todos modos es muy poco probable que ocurra), el equipo tendrá problemas para seguir el ritmo de las (siempre crecientes) características del backlog si las habilidades están estrictamente segregadas entre los miembros del equipo.
Algunos ejemplos
- El equipo cuenta con 1 o 2 ingenieros DevOps capaces de realizar cualquier cambio en los pipelines automatizados o de ocuparse de los servicios dentro de la plataforma, pero el resto del equipo no tiene ni idea de esas cosas. Entonces, discutir esas historias en las ceremonias scrum como los refinamientos conducirá a una pérdida de tiempo para la mayoría del equipo al permanecer en la reunión sin ninguna participación y viceversa – el desarrollador DevOps no tendrá ningún interés en el resto de las historias orientadas a la funcionalidad, y el tiempo en la reunión será en su mayor parte perdido también.
- Hay un único experto en bases de datos para todo el equipo. Dependiendo de la complejidad y el uso de las soluciones de datos en el sistema que el equipo está desarrollando, esta persona podría estar constantemente sobrecargada con historias que no tiene ninguna posibilidad de completar lo suficientemente pronto, especialmente si se tienen en cuenta sus prioridades. Peor aún, otras historias también tendrán que esperar, ya que éstas dependen de la fuente de datos proporcionada por las historias de la base de datos.
- Cuando un producto en particular está orientado principalmente al desarrollo del backend, el único desarrollador del frontend está ahí por si acaso (porque de vez en cuando se necesita algún pequeño cambio incluso en la aplicación de interfaz de usuario de todos modos). En ese caso, de nuevo, la mayoría de las ceremonias scrum son una pérdida de tiempo para este miembro del equipo, ya que sus conocimientos se limitan únicamente al front-end, y nada más importa.
Dónde concluye
En cualquiera de los casos anteriores, el resultado es que las personas están perdiendo el tiempo o, alternativamente, son incapaces de ponerse al día con la demanda acumulada. Están impidiendo que el resto del equipo empiece a trabajar en las siguientes historias, o están disminuyendo efectivamente la eficacia general del equipo scrum porque hay demasiado tiempo que no se utiliza dentro del sprint.
Sin embargo, el equipo sigue contando con este número de desarrolladores. Desde fuera, no se ve (ni siquiera se quiere ver) que las personas dentro del equipo no son capaces de hacerse cargo de algunas historias sólo porque están demasiado orientadas a algún conjunto de habilidades específicas. Así que no pueden ayudar a los demás miembros del equipo con las historias, aunque su capacidad se lo permitiera y las prioridades de las historias también lo favorecieran.
Es incluso difícil para el propietario del producto componer algún contenido de sprint significativo para el equipo, ya que el propietario del producto siempre debe tener en cuenta cuántas personas pueden trabajar en cada historia y si se aportan más historias similares al sprint al mismo tiempo, en última instancia se desborda la capacidad del equipo, incluso si de hecho hay personas que podrían trabajar en esas historias, pero no tienen el conjunto de habilidades para empezar con ellas.
Resolver el dilema
Se trata de un dilema que hay que resolver, y los directores de proyecto deberán ser conscientes de la vía que deben elegir. Concretamente, elegir entre:
- Tener muchos desarrolladores full-stack capaces de trabajar en contenidos más amplios, pero no realmente expertos en muchos temas. Así pueden ir a lo ancho pero no a lo profundo. Entonces la entrega puede progresar rápidamente, pero la calidad podría resentirse.
- Tener expertos dedicados para cada tecnología, pero luego aceptar la limitación y trabajar más duro en un contenido impreso mejor adaptado. Entonces la gente puede profundizar y construir grandes historias, pero las historias tendrán que abordarse secuencialmente, por lo que se tardará más en entregarlas.
Propietario de producto débil
Éste no es necesariamente un «problema de proceso» por definición, pero lo trato así sólo porque la creación de historias sólidas puede entenderse como un proceso que el equipo debería querer tener sólido como una roca y compatible con el equipo de desarrollo.
Lo que quiero decir con débil no tiene por qué referirse a la propiedad de conocimiento de una persona, sino más bien a la capacidad del propietario del producto de servir al equipo historias que los desarrolladores puedan entender y que tengan algún sentido claro desde la perspectiva de la hoja de ruta del producto. Ambas cosas son muy importantes para el éxito de un equipo scrum.
Si a las historias les faltan detalles para que los desarrolladores puedan entender claramente el propósito, el valor funcional o las expectativas técnicas, pueden darse básicamente dos escenarios:
- Los desarrolladores construirán algo diferente de lo que realmente quería el propietario del producto. Esto es incluso difícil de detectar durante el propio sprint porque, en la mayoría de los casos, el propietario del producto no ha tenido la capacidad de seguir el progreso de las historias a un nivel tan detallado y, en la mayoría de los casos, el propietario del producto se limitará a esperar que la cosa suceda (por arte de magia).
- Los desarrolladores pasarán demasiado tiempo aclarando las historias y discutiéndolas una y otra vez en lugar de empezar a construirlas. Esto implica muchas llamadas adicionales, acuerdos repetidos y posponer el trabajo a la fase final del sprint. Se llega a un punto en el que las estimaciones originales de las historias ya no pueden considerarse exactas y éstas no pueden cerrarse dentro del sprint y se trasladan a los sprints siguientes. En el peor de los casos, la situación se repite en los siguientes sprints.
Tiempo para la autorreflexión
Suele ser difícil de admitir, pero el propietario del producto debe encontrar tiempo para reflexionar, examinar las historias del backlog creadas y, finalmente, compararlas con la visión de la hoja de ruta del producto si aún existe algún vínculo sensato entre ambas, si es que existe alguna hoja de ruta. Si no es así, eso es lo primero que hay que resolver. A veces, la solución es admitir que el propietario del producto está demasiado lejos del equipo y demasiado lejos de su propio objetivo.
En tal caso, hay que resolver la parte del equipo que corresponde al propietario del producto. Si no hay más remedio, incorporar al equipo un sólido analista de negocio orientado más hacia el contenido del equipo que hacia el contenido del negocio (para eso, ya tenemos un propietario del producto en este caso) podría ser una opción válida a la que recurrir, incluso al precio de un aumento de los costes totales del equipo.
Procesos de pruebas sin calendario fijo
¿Qué ocurre si las actividades de pruebas no están ceñidas a un calendario concreto dentro de un sprint de scrum?
A primera vista, esto podría parecer algo bueno que deseamos para un equipo ágil / scrum. La flexibilidad siempre es bienvenida y suena bien cuando se presenta en el exterior.
Mi experiencia demuestra que el resultado de esta libertad es más caos que flexibilidad. Esto no significa que la solución a esto deba ser crear «cascadas dentro del sprint» con fases de pruebas dedicadas seguidas justo después de que el desarrollo haya terminado. Este no es en absoluto el enfoque correcto en este caso. Puede leer más sobre esto en mis posts sobre la estrategia de pruebas scrum y el ciclo de vida de las pruebas ágiles.
Aún podemos permitirnos cierta flexibilidad y elegir el calendario de pruebas según nos parezca más apropiado para el equipo de desarrollo actual y las propiedades del producto que el equipo esté entregando. Sin embargo, hay dos objetivos principales que deberían lograrse con esta elección:
- Minimizar la interrupción del progreso del desarrollo durante las actividades de prueba.
- Hacer que sea una actividad sólida (desde el punto de vista del contenido), fiable (desde el punto de vista de la ocurrencia) y repetida (desde el punto de vista de la previsibilidad) dentro del equipo.
Si se cumplen esas condiciones, el equipo se adaptará de forma natural al proceso de adaptación y el calendario de entrega no se verá afectado por actividades de prueba prolongadas no planificadas.
Al final, lo que más importa es una liberación del sprint fiable y predecible, lo que me lleva al último punto de este blog.
Proceso de liberación indefinido
Ahora bien, esto es algo tan obvio para cada equipo scrum. Sin embargo, curiosamente, también suele ser uno de los procesos más subestimados.
Muy a menudo, un equipo scrum se limita a decir que la liberación se producirá después de cada sprint, pero no está respaldado por un proceso sólido. Lo que ocurre entonces, en realidad, es que surgirán un montón de actividades caóticas e impredecibles durante el tiempo de release. De repente, todas las personas están ocupadas con «tareas de lanzamiento» y nadie es capaz de centrarse en seguir desarrollando nuevas historias del sprint. Las métricas del sprint están apagadas, y el release parece una actividad aleatoria e impredecible desde el punto de vista de la tercera persona (normalmente el cliente).
La gente está tan centrada en el backlog, el contenido del sprint, el desarrollo, las pruebas y, por último, en mostrar los resultados, que se olvidan de que una vez que han terminado con todo esto, el siguiente sprint ya está en marcha, y ya están perdiendo tiempo.
Buscando un buen momento para lanzar
Entonces, ¿cuándo exactamente debe el equipo hacer la liberación real a producción? Lo único importante al final.
La respuesta a esa pregunta se encuentra en el proceso, suponiendo que tenga uno. Depende de
- la complejidad del contenido que el equipo esté produciendo en los sprints,
- la duración de un sprint,
- el número de componentes afectados en el sistema
- el número de personas que utilicen y soliciten los cambios,
deberá establecerse y seguirse un proceso de lanzamiento repetido en el futuro. Las reglas exactas del proceso pueden definirse de nuevo con flexibilidad. Pero al igual que ocurre con las actividades de prueba, convertirlo en un hábito sólido como una roca, predecible y programado para días concretos en el futuro lo convierte en algo en lo que confiar y a lo que remitirse.
Opciones a elegir
Las formas posibles de un proceso de este tipo pueden ser cualquiera de las siguientes u otras:
- Completar las pruebas de las características del sprint actual durante el sprint siguiente y liberar el contenido al final de ese sprint (una vez completadas las pruebas). Esto significa que cada liberación no tendrá ningún contenido del último sprint pero contendrá historias de los 2 sprints anteriores.
- El último sprint antes del lanzamiento siempre se dedica a probar el contenido de los dos sprints anteriores.
- Esto no significa que el desarrollo durante el «sprint de pruebas» se detenga; sólo dice que el contenido desarrollado en ese sprint de pruebas no se incluirá aún en la siguiente versión.
- Si ya existen suficientes actividades de pruebas automatizadas, esfuércese por realizar el lanzamiento tras el final de cada sprint. Entonces debe ser un proceso muy estricto con personas dedicadas que se centren en esos pocos días al 100%. Aún así, no debe afectar en modo alguno al resto del equipo de desarrollo.
- También puede optar por liberar una vez al mes o una vez cada N meses, sobre todo si eso estará bien desde la perspectiva de los usuarios finales. Esto aumentará el esfuerzo en el lado de las pruebas para cada sprint (ya que el contenido será mayor para cada lanzamiento). Pero por otro lado, significará una menor cantidad de actividades repetidas a lo largo del tiempo, lo que en este caso, puede tener beneficios para el equipo. Como resultado, puede permitir al equipo construir más características nuevas entre las versiones, a pesar del hecho de que las características realmente llegarán a producción con una cadencia más lenta.
Pero como ya se ha dicho unas cuantas veces, no es tan importante cuál de esos procesos se elegirá. Es mucho más importante hasta qué punto el equipo se ceñirá luego a ese proceso y lo convertirá en un hábito duradero.
También puede leer esta guía sobre el proceso y las prácticas de gestión de lanzamientos.