Las expectativas (sobre todo) del equipo scrum recién formado son altas. La metodología es aún nueva para muchas empresas, y una vez que por fin son lo suficientemente valientes como para hacer el cambio, esperan mucho del cambio.
Es muy fácil que el equipo scrum no cumpla su promesa, y el fracaso puede tener muchas variantes, todas igualmente posibles 😀.
Ahora bien, este artículo no tratará sobre los procesos scrum como tales. Más bien, me gustaría centrarme en el objetivo último de (cualquier) equipo: entregar lo acordado a tiempo y con calidad. Y en este caso, la atención se centrará en las actividades más técnicas dentro del equipo que pueden conducir a sprints fallidos y en cuál podría ser una forma eficaz de abordarlas.
A continuación, hablaremos de los aspectos técnicos que pueden arruinar su sprint y de cómo solucionarlos.
Generación de backlog sin un objetivo de hoja de ruta sólido
Dependiendo de la dificultad técnica del contenido de la entrega y de lo lejos que esté el contenido del sprint de la plena comprensión de los temas por parte de los clientes, los backlogs pueden ser uno de los primeros problemas que golpeen al equipo. Esto conlleva serias complicaciones como:
- Las historias pueden generarse casi al azar y no siguiendo una línea lógica, basándose en ideas pasajeras de alguien jerárquicamente importante, en lugar de basarse en algún plan cronológico.
- Entonces el equipo scrum, a punto de salvar la coherencia, añadirá sus propias historias para complementar las ya dadas. Pero en última instancia, el resultado serán varios grandes temas en paralelo en el backlog.
- Dado que las necesidades de los clientes son siempre la prioridad, algunas de las historias importantes pero demasiado técnicas se posponen para entregar la funcionalidad solicitada por el cliente.
- El equipo intentará entonces entregarlas, pero el resultado inevitable es una entrega del contenido del sprint que parece incompleta (o incluso con errores), y la deuda técnica se amplía (lo que lleva a incluir más historias en el backlog).
Déle unos cuantos ciclos de sprint, y el problema evolucionará exponencialmente hacia una situación en la que ya no es importante lo que hay en el backlog porque está claro que el contenido que está bastante abajo nunca se resolverá. No habrá tiempo para seleccionar las historias; en cada sprint, se genera un lote de nuevas historias (y tiene mayor prioridad).
Cómo solucionar la generación de backlogs
Abordar aquí una solución y convencer a los socios para que cambien es especialmente difícil, ya que se trata de un territorio en el que la jerarquía de la organización tiene una influencia considerable.
Sin embargo, hay ciertas acciones que deben iniciarse y, aunque no se aprueben de inmediato, recordárselas periódicamente y ponerlas en contexto con el aspecto actual de la situación en el backlog y cómo podría ser, podrían conducir al éxito con el tiempo:
#1. Pida objetivos concretos de la hoja de ruta para el equipo
Esto debe ser tanto desde una perspectiva a corto como a largo plazo. Deje claro qué características deben realizarse en los próximos meses y cómo debería ser el producto un año después. Debe demostrarse a fondo una visión clara y emparejarla con objetivos concretos de la hoja de ruta.
#2. Desafíe la priorización de las características en la hoja de ruta
Nunca debe ocurrir que el equipo tenga que hacer equilibrios entre varias historias de alta prioridad y complejidad simultáneamente. Esto sólo conducirá a un progreso lento en todo en lugar de demostrar un progreso incremental sustancial en los grandes temas.
#3. Revise las viejas historias con regularidad
Revisar las viejas historias y confirmar si siguen siendo válidas y cuál es su prioridad es importante. Mapearlas en objetivos específicos de la hoja de ruta si siguen siendo válidas. Evite las historias sin mapear en el backlog: eso es señal de que esas historias no tienen un valor empresarial claro o de que la prioridad sobre ellas se perdió con el tiempo.
Aplazamiento de la deuda técnica
La deuda técnica es un estado del código (o de sus partes) en el software desarrollado que se crea como efecto secundario de priorizar la velocidad de la entrega sobre la calidad. A veces, lanzar nuevas características dentro de un sprint es un tema urgente, por lo que el equipo puede decidir no terminar las historias a la perfección.
Sin embargo, de este modo, se sigue cumpliendo el requisito principal de funcionalidad desde el punto de vista empresarial. Si no se identifica correctamente y a tiempo, puede incluso olvidarse por el camino y sólo volver a descubrirse al toparse con problemas en fases posteriores del proyecto.
El propio equipo es el más capacitado para definir historias para la deuda técnica creada por el camino. Por desgracia, estas historias suelen colocarse al final de los cuadros de prioridades, ya sea por el cliente o por el propietario del producto.
La acumulación de deuda técnica es un grave problema para el equipo scrum. Empieza siendo pequeña, pero crece exponencialmente con el tiempo:
- Las nuevas historias empiezan a verse afectadas por problemas inacabados del pasado.
- Arreglar un nuevo fallo en un sistema con una deuda técnica elevada suele dar lugar a resoluciones muy complejas porque para arreglar el nuevo fallo hay que arreglar varios otros problemas para que el proceso llegue a la fase en la que se puede hacer el arreglo.
- La frustración del equipo de desarrollo crece al ver cómo es más difícil implantar nuevas funciones en un sistema lleno de problemas técnicos sin resolver que complican innecesariamente la ampliación de la nueva funcionalidad.
Cómo solucionar el aplazamiento de la deuda técnica
La coherencia es la clave aquí. Cada equipo Scrum debe desarrollar un proceso adecuado para su caso de uso y ceñirse a él pase lo que pase. El proceso en cuestión puede ser algo similar a:
Establecer una regla según la cual se recogerán al menos 1 ó 2 historias del backlog de la deuda técnica.
Reserve un porcentaje del sprint dedicado únicamente a las tareas relacionadas con la deuda técnica. Sin embargo, esto puede resultar complicado, ya que es muy difícil hacer un seguimiento de dicho compromiso. Si opta por esta vía, probablemente sea mejor definir un día concreto del sprint dedicado únicamente a las actividades relacionadas con la deuda técnica.
Defina cada 5º sprint más o menos para reservarlo a ponerse al día con las historias de deuda técnica. Rellene en la medida de lo posible el contenido pertinente de la deuda técnica en ese sprint. Si con el tiempo se da el caso de que no hay suficientes historias de deuda técnica en las que trabajar en este momento, complete el resto de la capacidad de ese sprint con contenido de nuevas características. En cualquier caso, ese sprint concreto deberá reservarse para las historias de deuda técnica en primer lugar.
Cambio de contenido del sprint demasiado flexible antes del final del sprint
Los equipos Scrum deben ser flexibles y estar preparados para el cambio, como se desprende directamente incluso del Manifiesto Ágil, que se espera que esté en el núcleo de todo equipo Scrum.
Pero imagine una situación en la que el contenido del sprint cambia cada 2-3 días:
- Las historias se vuelven a priorizar, nuevas historias entran en el sprint y otras historias raramente salen.
- El contenido no sólo cambia, sino que aumenta con el tiempo del periodo del sprint.
- El cambio de prioridad conduce a un equipo desmotivado, ya que entonces se les exige que salten de un tema a otro, lo que aumenta el estrés y, al final, conduce a no entregar el contenido. No sólo para las historias acordadas para formar parte del sprint durante la planificación del mismo, sino a menudo también para las historias recién añadidas.
Sería estupendo poder dar libertad al equipo de scrum y luego ver cómo se completan las historias, a pesar de todos los cambios que se producen en el equipo durante el sprint. La experiencia demuestra que esto no va a funcionar. El equipo se distraerá y se sentirá abrumado por el contenido; con el tiempo, el compromiso del sprint no significará nada.
Se convertirá en norma que el equipo no complete las historias dentro del sprint; del mismo modo, se convertirá en norma arrastrar historias de un sprint a otro como consecuencia directa.
El cliente se quejará entonces de que no hay seguridad de que las historias puestas dentro de un sprint se entregarán dentro de ese sprint. La planificación de las características y de los objetivos de la hoja de ruta se cancelará.
Cómo solucionar la flexibilidad de los sprints
Creo que sacrificar algún tipo de libertad por unos pocos procesos que limiten la flexibilidad de los sprints aumentará significativamente la fiabilidad de la entrega de los sprints. Un proceso de este tipo incluiría pasos como
- No permitir una adición desorganizada de nuevas historias en el sprint existente. Disponga de un proceso de revisión, aunque sea muy sencillo, pero un punto de confirmación de que la nueva historia es relevante y tiene mayor prioridad que cualquier otra que ya esté en el sprint.
- Por cada nueva historia que se añada al sprint, elimine del mismo una historia equivalentemente compleja. Lo ideal es que se trate de una historia que aún no se haya iniciado en el sprint o que se haya iniciado muy recientemente.
- No añada automáticamente al backlog del sprint los errores ad hoc descubiertos durante el mismo. Esas son nuevas historias que deben estimarse y planificarse para su inclusión específica en el sprint.
Las historias insuficientemente definidas dejan demasiados elementos abiertos
Así que usted define las historias para el siguiente sprint, el equipo pasa por la aclaración y el refinamiento, la estimación y el desglose de tareas, y todo está listo para un desarrollo claro, ¿verdad? Pues no con las historias poco claras que aparecen dentro de los sprints.
Incluso si las historias se refinan, el equipo acordará algún tipo de estimación, aunque nadie comunique falta de claridad con las historias. Las historias mal definidas pueden identificarse fácilmente de tal forma que el equipo vuelva repetidamente a discutirlas dentro del sprint.
Esto no sólo prolonga naturalmente el tiempo de refinamiento del equipo, sino que también conduce a un nuevo cambio de alcance después de que las estimaciones para el sprint se hicieron y el contenido para el sprint fue comprometido por el equipo.
En consecuencia, las historias se hacen más grandes y complejas de lo estimado inicialmente. Además, el trabajo de desarrollo real de una historia de este tipo comenzará mucho más tarde que al principio del sprint debido a todas las aclaraciones adicionales necesarias.
En la mayoría de los casos, esto conduce finalmente a una historia inacabada en el sprint.
Cómo solucionar una historia inacabada en el sprint
Si el equipo recibe demasiadas historias poco claras, con el tiempo se volverá inmanejable, y la dirección del proyecto sólo podrá preguntarse por qué cada sprint termina con historias inacabadas.
Este puede ser un problema complejo de solucionar. Principalmente se reduce a lo lejos que esté el propietario del producto con sus conocimientos del equipo de desarrollo y si pueden entender las necesidades del equipo en cuanto a la definición clara de las historias.
A menudo, los propietarios del producto son personas con una fuerte orientación funcional y su conexión con el equipo de desarrollo es poco profunda. En otros casos, el papel de propietario del producto se combina con el de analista de negocio, lo que lleva a una confusión aún mayor. ¿Qué hacer en este caso?
Programe convocatorias mensuales para la preparación de historias, en las que se debatan en profundidad y por adelantado las características que quedan por introducir en los sprints. Disponer de una hoja de ruta clara es la condición indispensable para que esto tenga éxito.
Prepare páginas de análisis para historias tan complejas con mucha antelación (antes de que las historias se introduzcan en los sprints) para que los propietarios de los productos puedan definir fácilmente historias ricas en contenido para los equipos de desarrollo.
En casos muy complejos, es una buena forma de dedicar tiempo a la preparación del diseño antes de que el tema llegue al equipo de scrum. Deberán dedicarse a esta actividad personas específicas del equipo.
Por todos los medios, no permita que la historia no preparada llegue a un sprint. Insista en su finalización desde el punto de vista del contenido. Esto creará una presión positiva adicional sobre las partes interesadas para que preparen mejor las historias para el equipo.
Palabras finales
Centrarse en el buen contenido de cada historia da grandes frutos con el tiempo. La gestión del backlog es un territorio indefinido para la mayoría de los equipos scrum. Mapear las historias en objetivos concretos y situarlas en el contexto de objetivos de mayor alcance es una actividad infravalorada.
Esta lista pretendía arrojar algo de luz sobre esos tecnicismos y, con suerte, ayudar a orientarse si algunos de los problemas anteriores le resultan familiares.
A continuación, eche un vistazo a las mejores herramientas scrum para una startup o una mediana empresa.