Los pilares de Scrum en Sophilabs: inspección

Nuestros equipos están comprometidos con practicar Scrum y organizan su trabajo en sprints de dos semanas. Sin embargo, sabemos que no basta con imponer la estructura de Scrum y esperar mayor agilidad, más responsabilidad sobre el trabajo, un desarrollo más eficiente y una mayor satisfacción del cliente. Para que Scrum sea realmente eficaz, debemos fortalecer activamente los pilares de este marco —transparencia, inspección y adaptación— y vivir sus valores de compromiso, coraje, enfoque, apertura y respeto.

En nuestro artículo anterior hablamos de cómo procuramos mantener la transparencia. En esta segunda entrega de nuestra serie sobre los pilares de Scrum veremos cómo practicamos la inspección en cada sprint.

¿Cómo es la inspección en Scrum?

Según la Guía de Scrum, «Los usuarios de Scrum deben inspeccionar frecuentemente sus artefactos y el progreso hacia un objetivo de sprint para detectar variaciones no deseadas. La inspección no debe ser tan frecuente que interfiera con el trabajo. Las inspecciones son más beneficiosas cuando las realizan con diligencia personas capacitadas, en el lugar donde se hace el trabajo». ¹ Aunque esta indicación es clara, también es general y deja espacio para analizar críticamente cómo funciona la inspección en el día a día.

Como marco ligero, en lugar de metodología completa, Scrum permite flexibilidad en las prácticas más específicas dentro de su estructura. Si un equipo prefiere ciertas formas de conversar, estimar el trabajo, revisar elementos u obtener comentarios, hay espacio para ello mientras siga obteniendo los beneficios de Scrum. Nuestros equipos siguen Scrum e incorporan algunas prácticas específicas que nos ayudan a obtener el valor que ofrece. Esto ocurre especialmente con nuestra forma de inspeccionar. A continuación veremos la inspección en sophilabs, desde las instancias ya integradas en Scrum hasta nuestras prácticas particulares alineadas con el propósito de este marco ágil.

Inspección de artefactos

Primero veremos cómo inspeccionamos los artefactos de Scrum y el valor de hacerlo regularmente.

El backlog del producto

La Guía de Scrum describe el backlog del producto como un «artefacto vivo» que puede y debe cambiar según los comentarios de los clientes y la evolución del entorno empresarial. Recomienda un refinamiento continuo para agregar «detalle, estimaciones y orden» a las historias cercanas al comienzo del backlog. Sin embargo, Scrum no establece un proceso específico de refinamiento. Simplemente recomienda que el equipo decida «cómo y cuándo se hace». ²

En sophilabs realizamos sesiones de refinamiento del backlog para preparar historias para el siguiente sprint o los dos siguientes. Las historias más lejanas son demasiado susceptibles a cambios como para que valga la pena invertir tiempo en refinarlas. A diferencia de las ceremonias de Scrum, estas sesiones no tienen un calendario fijo: pueden realizarse tantas veces como sea necesario. Sin embargo, la Guía de Scrum recomienda no dedicar más del 10% de la capacidad del equipo al refinamiento, ya que dedicar demasiado tiempo puede hacer que esta forma de inspección «interfiera con el trabajo». ³

Durante estas sesiones en sophilabs, el Product Owner se reúne con las partes interesadas para repriorizar historias y recopilar requisitos más detallados. A veces, el equipo de desarrollo también participa y hace estimaciones. Son una oportunidad para recoger comentarios, asegurar que los requisitos sean claros y poner todo en orden. Nos permiten hacer sesiones de planificación de sprint más rápidas y eficaces, porque podemos completar una parte significativa del trabajo por adelantado. Inspeccionar regularmente el backlog de esta manera mejora la eficiencia del desarrollo.

El tablero Scrum

El tablero Scrum, una herramienta visual importante para la transparencia, se inspecciona en cada scrum diario. Inspeccionarlo y actualizarlo activamente asegura que siga siendo útil para medir el progreso durante el sprint. Las inspecciones también mantienen su eficacia para fomentar la responsabilidad y el compromiso individual con el trabajo. Un tablero actualizado promueve los valores de Scrum y mantiene al equipo comprometido y enfocado en los objetivos del sprint.

Inspección del progreso

La inspección también va más allá de examinar y actualizar los artefactos mencionados. A continuación veremos cómo inspeccionamos el progreso de forma constante.

Scrum diario

El scrum diario es posiblemente la instancia de inspección más importante en Scrum. La inspección es el centro del propósito de esta ceremonia. En cada reunión, el equipo debe medir su progreso y determinar dónde está respecto de los objetivos que busca alcanzar al final del sprint. Esto suele requerir un análisis crítico para identificar bloqueos clave y proponer soluciones juntos. Aunque no siempre es práctico discutir las soluciones por completo en esta reunión breve, mantiene a todos alineados sobre los problemas que deben abordarse.

Estas inspecciones aseguran que el equipo enfrente los problemas en conjunto y lo antes posible, y contribuyen a la calidad del incremento de software y la eficiencia del desarrollo. En sophilabs valoramos el poder de las prácticas centradas en las personas, como los scrums diarios, y cómo permiten a los equipos organizarse por sí mismos y dar lo mejor de sí.

Retrospectiva del sprint

La retrospectiva ofrece al equipo una oportunidad regular para inspeccionarse y revisar cómo trabajan juntos sus integrantes. El progreso que se mide no necesariamente está relacionado con los objetivos del sprint, que ya deberían haberse revisado. El foco principal de esta inspección es la eficiencia del equipo y su capacidad de comunicarse y colaborar eficazmente. Al examinar a fondo estos aspectos, el equipo puede identificar problemas o ineficiencias en sus procesos y resolverlos mediante la adaptación, el tercer pilar que exploraremos en la próxima entrega. La reflexión honesta y la inspección durante las retrospectivas aportan los conocimientos necesarios para mejorar continuamente.

Existen muchas técnicas eficaces para aprovechar al máximo una retrospectiva, y los equipos Scrum tienen libertad para usar las prácticas específicas que mejor les funcionen. En sophilabs solemos estructurarlas en cinco etapas: preparar la retrospectiva, recopilar datos, generar conclusiones, tomar decisiones y planificar acciones futuras, y cerrar la retrospectiva. Pueden durar desde menos de una hora hasta noventa minutos completos, según cuánto necesitemos conversar. Las técnicas específicas que usamos dependen mucho de la madurez y la dinámica particular del equipo.

Entre nuestras técnicas favoritas para preparar las retrospectivas están las preguntas iniciales de siempre: ¿Cuál fue tu mayor logro durante este sprint? ¿Qué cambiarías de este sprint si pudieras? Esta apertura sencilla es muy eficaz para que cada integrante empiece a analizar críticamente cómo fue el último sprint. Las escalas de satisfacción son otra estrategia confiable para medir cómo se siente el equipo respecto de su colaboración y los resultados de la última iteración. Asimismo, una actividad de «pronóstico del tiempo», en la que cada integrante se ubica en una escala de tormentoso, lluvioso, nublado o soleado, ofrece una forma visual rápida de evaluar cómo se siente cada persona respecto del sprint.

Para recopilar datos solemos usar un cuadro sencillo que reúne comentarios sobre lo que estuvo bien, lo que podría haber sido mejor e ideas. A veces usamos variantes, como Mad/Sad/Glad, donde los integrantes comparten situaciones específicas que les causaron enojo, tristeza o alegría. De manera similar, la técnica 4Ls requiere identificar lo que les encantó, lo que aprendieron, lo que faltó —o detestaron— y lo que desearon. Otra estrategia, Lean Coffee, usa votaciones y límites de tiempo para ayudar a priorizar los temas.

En la etapa de generar conclusiones, nos enfocamos en hacer visibles las dificultades y determinar qué las causó. Consideramos que los 5 porqués, una técnica de análisis de causa raíz desarrollada originalmente en Japón por Toyota Motor Corporation, son especialmente eficaces para identificar el origen de los problemas. Los 5 porqués consisten en preguntar por qué ocurrió un problema y luego tomar esa respuesta y preguntar por qué ocurrió eso. El equipo continúa este patrón cinco veces, lo que suele revelar qué desencadenó la cadena de eventos negativos. Otra gran técnica, Perfection Game, pide a los integrantes describir un sprint perfecto. Luego identificamos las diferencias clave entre ese sprint y lo que realmente ocurrió.

La cuarta etapa, tomar decisiones y planificar acciones futuras, empieza a entrar en el terreno de la adaptación, por lo que la abordaremos con más detalle en la última entrega. Por ahora, diremos que los objetivos principales son alcanzar un consenso mediante votación, tener un plan claro y asegurar que cada integrante tenga acciones realistas para el siguiente sprint. En el cierre, nos enfocamos en reconocer las contribuciones de los compañeros y animarnos mutuamente a enfrentar futuros desafíos. ⁴

Una parte integral de Scrum

Practicar la inspección ayuda a asegurar que Scrum funcione como debe, permitiendo que el cliente y el equipo de desarrollo obtengan el máximo valor de este marco. Aunque ya está integrada en eventos regulares como el scrum diario, los equipos también tienen libertad para agregar prácticas y técnicas más pequeñas cuando lo consideren adecuado, siempre que sigan recibiendo todos los beneficios de Scrum.

En sophilabs consideramos que la inspección es fundamental para nuestro proceso de desarrollo y procuramos sostener este pilar. Cuando se hace bien, genera equipos productivos y software de alta calidad. En la próxima y última entrega de esta serie veremos cómo funciona la adaptación. También puedes consultar nuestro Playbook si quieres saber más sobre cómo trabajamos.