La Filosofía Ágil plantea que el Valor para el usuario se logra cuando entregamos software funcional en la menor cantidad de tiempo posible. Cualquier resultado diferente es un indicio de que algo no anda bien en la forma de trabajo y debemos solucionarlo.

Para fines prácticos en este artículo, entenderemos estos conceptos de la siguiente forma:

• Menor cantidad de tiempo = Una iteración o Sprint.
• Software funcional = solución consumible por los usuarios finales
• Valor = Necesidades satisfechas y usuarios deleitados

Los equipos de software, que desarrollan bajo el principio iterativo, deben poner software de alto valor en las manos del usuario al final de cada sprint. Cuando esto no sucede, debemos evaluar lo que está pasando para proponer soluciones.

El Driver de la agilidad “Organización del equipo” procura la autonomía y la autodirección de los equipos de software. Es decir, que los equipos acuerden una forma de trabajo que les sirva. Si esto no se realiza adecuadamente, veremos algunos síntomas de un mal trabajo de desarrollo, como los siguientes.

Una user story en el plan es demasiado grande para ser fácilmente gestionada y comprendida 

Las user stories (historias de usuario) son representaciones escritas de los requerimientos, utilizando el lenguaje común del usuario en una o dos frases. Las user stories deben tener las características INVEST:

• Independientes unas de otras
• Negociables
• Valoradas por los clientes o usuarios
• Estimables 
• Pequeñas (Small)
• Testeables

Una user story, al ser redactada, debe ser comprendida de la misma manera por todos los que la leen, porque está libre de ambigüedad y define claramente lo que se debe desarrollar. Un ejemplo de una user story con estas características es:

Como gerente quiero un reporte para validar las transacciones del día

En este enunciado, encuentras con claridad: quién es el usuario que la necesita (gerente), qué se debe desarrollar (un reporte) y la importancia del requerimiento (validar las transacciones del día). A partir de ahí, el equipo definirá los Criterios de Finalización (DoD) en los que se desarrolla la conversación y los detalles.

Por el contrario, si la user story dice: “Hágase lo necesario para que funcione validar las transacciones”, el equipo tendrá que dedicar mucho tiempo a entender lo que debe hacer, la dimensión de la necesidad y su costo; también tendrá dificultad para pensar en las pruebas que se deben hacer y si están involucrando más requisitos.

Si en diferentes sprints encuentras que el equipo consulta constantemente dudas acerca de la misma user story o cada quién tiene una interpretación diferente, estás presentando este síntoma.

Falta de atención a la mitigación de riesgos

Un riesgo es una situación probable que tiene impacto positivo o negativo en el resultado del trabajo. Procuramos maximizar los impactos positivos (por ejemplo, adelantar el trabajo para ganar bonos) y minimizar los negativos (por ejemplo, multas). Normalmente, entendemos como “riesgo” aquello que es negativo y solemos hacer la evaluación de estos solamente. Ahí la primera falla en la atención a riesgos.

Algunos riesgos son de bajo impacto; otros, catastróficos. Algunos serán inevitables y otros, prevenibles. 

Cuando los equipos no hacen una evaluación de los riesgos, para diseñar planes de mitigación (prevención del riesgo) o de respuesta para los que son inevitables, solo podrán darse cuenta cuando la situación ya ocurrió y se ha convertido en un problema.

Si tus equipos están trabajando sin haber identificado los riesgos del sprint, sin planes de mitigación o respuesta a la crisis y sin responsables de seguimiento, estás presentando este síntoma.

No se completa una user story al final de una iteración

El resultado de cada iteración (sprint) es entregar un producto consumible a los usuarios. Esto significa que todas las user stories planeadas para el sprint fueron completadas e incluidas en la solución. Si alguna falta o quedó incompleta, es que hay algún problema.

El siguiente pensamiento no es justificación: “es que en los sprints podemos agregar, quitar o cambiar user stories según las necesidades cambiantes”. En Ágil, debemos responder al cambio rápidamente, pero no perder de vista el objetivo: terminar la iteración con un producto consumible con todas las user stories planeadas. Mucho menos debemos extender la iteración para terminar.

La gestión de cambios sigue varias etapas: recepción, evaluación, negociación, respuesta. Sin un acuerdo adecuado para hacerlo, tendremos planes irrealizables.

Si tus equipos no son capaces de responder a una solicitud de cambio dentro del día en que se hizo, estás presentando este síntoma.

¿Qué hacer?

El trabajo de desarrollo de software requiere fundamentalmente de las interacciones humanas para consolidar las prácticas de ingeniería dentro de la organización; de esta manera lograr los objetivos de clientes y proyectos. Todos los involucrados deben interactuar constante y saludablemente para acordar y mejorar su forma de trabajo, y ésta debe ser adecuada para las personas y las actividades que hacen. Sin esta interacción, la forma de trabajo se deteriora rápidamente.

Tus equipos deben ser autónomos y autodirigidos. Permite que ellos elijan sus prácticas, herramientas, rituales y roles.  Incúlcales el sentido de urgencia, que los objetivos de los usuarios y del negocio son importantes, por lo que su forma de trabajo debe permitir alcanzarlos. Evalúen los resultados juntos, siempre con transparencia, desde el enfoque constructivo. No nieguen los errores y problemas, hablen de ellos para entender qué pasó y encontrar soluciones en vez de culpables. La palabra clave es confianza.

¡Confía en tus equipos! Ellos quieren hacer un trabajo extraordinario.

¡Nos vemos en la siguiente entrega!