En estos casos, el mejor enfoque es alinear cómo estas definiciones deben ser creadas, en caso de que deban ser creadas, con los stakeholders que tienen mayor influencia e impacto en el proyecto. Dejo aquí otro artículo que escribí sobre este tema llamado “Cómo usar la matriz de stakeholders para aumentar tu influencia y mejorar la comunicación del proyecto.”

Si ya eres un líder con suficiente influencia y autonomía, primero compartiré los conceptos del SAFe y luego explicaré cómo los uso en la práctica. Este también es el tipo de problema que Saint Jude ayuda a los líderes a observar con más claridad: tasks que entran en el board sin suficiente claridad, estimaciones que no coinciden con la realidad y riesgos creados por una mala definición de las tareas.

Definición de ready y definición de done en SAFe

Shift learning left

El desarrollo de productos incluye muchos escenarios desconocidos que el equipo descubrirá a medida que el proyecto avance, y lo mismo ocurre con las tasks individuales. Cuanto más tarde se descubren estos escenarios, más difícil y costoso se vuelve ajustarlos, impactando el scope, la calidad, el cronograma y los costos. Por este motivo, tener un proceso para verificar y validar posibles escenarios con anticipación se vuelve esencial para el buen avance de un proyecto.

Pair programming y peer review

Esta es una práctica valiosa y bastante conocida, pero todavía poco utilizada de forma consistente por los equipos de tecnología. Dos profesionales trabajan juntos en la misma task: uno se enfoca en construir la solución, mientras el otro actúa como navegador, ofreciendo feedback y sugiriendo mejoras en tiempo real. La idea es aportar más de una perspectiva sobre cómo la task debe ser construida, aumentando no solo el conocimiento sobre el producto, sino también la comprensión del equipo sobre cómo funciona internamente.

Collective ownership y habilidades T-shaped

Aquí, SAFe nos dice que cada persona dentro del equipo debería tener las habilidades y la autoridad suficientes para modificar una entrega, independientemente del momento del proceso en que se encuentre. Ningún profesional es dueño de la entrega o del producto. Otro punto importante de este concepto es tener profesionales que, aunque sean especialistas en un tipo de trabajo, también entiendan el proyecto como un todo.

Estándares de artefactos y definición de done

Las entregas muchas veces dependen de procesos manuales para mover tasks entre profesionales dentro del mismo equipo, lo que puede generar retrasos. Dentro de estos procesos de construcción de producto, también hay pérdida de tiempo inspeccionando tasks o buscando componentes que ya existen y que podrían reutilizarse para acelerar la entrega o mejorar la performance. Automatizar estos procesos ayuda a reducir tiempo y costos, aumentar la productividad y mejorar los estándares de entrega.

Automatización de workflow

Los workflows suelen incluir pasajes manuales de tasks entre profesionales dentro del mismo equipo, creando retrasos y reduciendo la eficiencia del flujo. Durante estos procesos de construcción, los equipos también pueden perder tiempo inspeccionando tasks manualmente o buscando componentes que ya fueron creados y podrían reutilizarse para acelerar la entrega o mejorar la performance.

Automatizar estos procesos ayuda a reducir tiempo y costos, aumentar la productividad y mejorar los estándares de entrega. En la práctica, esto está muy conectado con lo que Saint Jude busca hacer visible: dónde las tasks están esperando, dónde el workflow es ineficiente y cómo un trabajo poco claro puede impactar el cronograma, el costo y la performance de entrega.

Estos conceptos forman parte de lo que SAFe entiende como built-in quality. Como habrás notado, la Definición de Ready (DoR) y la Definición de Done (DoD) no son ideas aisladas. Forman parte de algo más grande: la calidad.

Ahora, veamos cómo uso estos conceptos para crear una mejor Definición de Ready y Definición de Done en los proyectos que gestiono.

Definición de ready/done y calidad en la práctica

Para crear claridad y mejorar la documentación, uso un trípode formado por PO, UI y tech leader para construir la Definición de Ready de cualquier task, usando la siguiente estructura:

• UI documenta el flujo esperado y los flujos alternativos
• PO documenta lo que se espera como entrega de negocio
• Tech leader documenta cómo debe ser construida

¿Por qué? Honestamente, nunca he visto un proyecto en el que todos los miembros del equipo tengan las habilidades y la autoridad para tomar todas las decisiones. Por eso, se vuelve necesario crear un liderazgo técnico y de negocio entre las partes interesadas para guiar y validar las tasks. Con base en la experiencia que he adquirido, tener a alguien que oriente técnicamente al equipo es necesario hasta que el propio equipo se vuelva autosuficiente.

Para la Definición de Done, también uso estos profesionales para validar y finalizar formalmente la entrega. Dicho esto, ahora explicaré este punto con más detalle usando los conceptos de SAFe.

Shift learning left

En este caso, con la documentación inicial proporcionada por mi trípode de profesionales, el equipo de desarrollo puede empezar a construir la task por medio de pruebas, usando el famoso enfoque TDD, mientras el equipo de QA ya puede trabajar en los escenarios de prueba usando BDD. También puedo traer aquí un concepto del mundo ágil: si el equipo no entiende lo que debe hacerse durante los eventos de refinamiento, la task no está lista para entrar en el sprint. A partir de este punto, devolvemos la task al trípode con todas las preguntas levantadas por el equipo y refinamos la documentación hasta que la task quede cristalina para todos.

Pair programming y peer review

Me gusta mucho el pair programming, pero voy a traer una verdad incómoda que casi nadie se atreve a decir:

“Si pones a dos personas a trabajar en una task en vez de dos personas trabajando en dos tasks diferentes, o tienes una influencia considerable dentro de tu empresa, o tu jefe quizá no estará muy contento contigo.”

La verdad es que casi nadie quiere sacrificar tiempo a favor de la calidad. Dicho esto, una acción que siempre aplico con mis equipos es hacer que mi trípode — PO, UI y tech leader — sirva como un grupo de oráculos durante el proceso de construcción. No importa cuánto tiempo dediquemos a documentar lo que debe hacerse, todavía pueden surgir preguntas en medio del trabajo. Cuanto más rápido respondamos a estas preguntas, más rápido avanzamos. En general, pido que este trípode reserve una hora al día para responder dudas. Funciona casi como una daily, pero con más tiempo para explicaciones complejas.

Collective ownership y habilidades T-shaped

Aquí nuevamente, confío en mi trípode de profesionales como las personas responsables de cualquier modificación en las tasks. Pero ¿por qué?

Al inicio de un proyecto, o incluso cuando entran nuevos profesionales, su conocimiento y experiencia generalmente son cero o muy bajos respecto a las reglas de negocio, a lo que debe hacerse y a lo que se espera de las entregas. Por este motivo, dependen del conocimiento de las personas que llevan más tiempo en el proyecto o tienen más experiencia, como PO, tech leader y UI. Estas son las personas que tienen las llaves para entrar y modificar cualquier proceso o entrega. Con el tiempo, el equipo gana confianza y pasa a poder intervenir en cualquier fase del proceso.

Sin embargo, existe un punto específico aquí: los seres humanos se apegan naturalmente a la autoridad que han conquistado. Si retiras de repente la autoridad previamente conquistada por alguien, puedes crear problemas de comportamiento, a veces llegando incluso a renuncias o despidos. Por otro lado, cuando estos profesionales se vayan de vacaciones, ya tendrás un equipo entrenado y capaz de modificar entregas cuando sea necesario.

Por último, sobre las habilidades T-shaped: usando la regla de Pareto, diría que en el 80% de los casos esto simplemente no sucede. Primero, porque lleva mucho tiempo adquirir un conocimiento amplio, y los proyectos no siempre duran lo suficiente. Segundo, porque es difícil encontrar profesionales interesados en aprender un poco sobre cada nuevo tema involucrado en la construcción de un producto.

Estándares de artefactos y definición de done

Ahora entraremos un poco más en la Definición de Done, pero primero comenzaré por los estándares. Todo profesional tiene patrones de trabajo y, cuando estos patrones son documentados, se convierten en los estándares del proyecto. Haré una excepción para los estándares que vienen de fuera, como estándares de la empresa o del PMO. De cualquier forma, los estándares existen e influyen en cómo se entrega el trabajo.

Con relación a la Definición de Done, mencioné antes que uno de los puntos principales es la validación y aceptación formal por parte de mi trípode. Además de eso, uso casos de prueba y automatización de pruebas unitarias como parte de la Definición de Done. El principal motivo es crear una traba de seguridad y evitar problemas en producción. Si las pruebas fallan, el producto no está listo para mis clientes.

Automatización de workflow

Para aportar más agilidad al proceso de finalización de las tasks, desde el momento en que empiezan hasta su conclusión, el mejor enfoque es equilibrar lo que debe hacerse con la cantidad de personas disponibles para hacerlo. Si tienes que elegir, es mejor tener personas esperando tasks que tasks esperando personas. Al final, queremos entregar un producto rápidamente y con alta calidad, ¿no?

Con relación a la inspección de tasks, cuando los casos de prueba y las pruebas unitarias están automatizados, la inspección manual se vuelve menos necesaria. Por último, la búsqueda de componentes puede describirse en la documentación inicial de la task. Si no está, uno de nuestros oráculos debería poder responder. También es aquí donde herramientas como Saint Jude pueden despertar la curiosidad de los líderes: cuando la claridad de la task, las estimaciones, el flujo, el cronograma y el costo se analizan juntos, se vuelve más fácil entender si el equipo está realmente productivo o simplemente ocupado.

Llego al final de este artículo. Aquí, aprendiste algunos conceptos de SAFe sobre calidad y cómo los uso para crear Definiciones de Ready y Done eficientes para mis proyectos.

¿Quieres continuar esta conversación? Dale like al artículo, comenta en LinkedIn o compártelo en tus redes sociales.

¡Hasta pronto!

Erik Scaranello