¿Cuándo se cierran los criterios de aceptación de una historia de usuario?

Recientemente tuve un asistente especial en uno de mis cursos, Ángel, un coach ágil de los que entienden la Agilidad con una profundidad que no todos logramos. Estábamos hablando de criterios de aceptación, que transformados en escenarios de pruebas con ejemplos específicos, permiten al Propietario del Producto confirmar que el equipo ha entendido y recogido correctamente el comportamiento de la historia de usuario.

Las historias de usuario forman parte de la fórmula de captura de funcionalidades definida en 2001 por Ron Jeffries, la de las tres C's (Card - Conversation - Confirmation):

Cuadro con la técnica de las 3 C's

En la última fase de confirmación los criterios de aceptación proporcionan la precisión necesaria para garantizar que la historia se va a implementar correctamente y así se cubren los requisitos funcionales y no funcionales relevantes.

El debate se inició sobre cuándo se considera que estos criterios de aceptación se dan por cerrados. Echando un vistazo a la técnica de las 3 C's parece evidente que deberían de estar cerrados al final de la planificación de sprint. Desafortunadamente eso son resquicios de un pensamiento clásico y predictivo...

Recordemos que al final del la planificación de sprint el equipo de desarrollo se compromete con el objetivo del sprint, no con la pila de sprint y sus historias de usuario. Por tanto los criterios de aceptación se cerrarán a lo largo del sprint, probablemente cuando se haya acabado la historia de usuario.

No olvidemos que con el objetivo del sprint pretendemos dar solución de la mejor forma posible a las necesidades reflejadas en el mismo, y eso puede significar incluir información fresca alineada con el objetivo. Esa información fresca puede cambiar los criterios de aceptación. Si por ejemplo el objetivo del sprint es que nuestro cliente pueda emitir la factura, lo importante será que a final de sprint el cliente pueda facturar de la forma que más competitivo le haga, y quizá eso signifique con menos funcionalidad que la pensada en la planificación e incluyendo funcionalidad no pensada ni planificada entonces.

Mis agradecimientos a Ángel Lozano que arrojó mucha claridad sobre lo que es ser Agile

¿De qué elementos hace seguimiento una PMO ágil?

Una APMO se focaliza en los elementos de la
macrogestión, nunca en los de la microgestión

Una PMO clásica mide el seguimiento de un proyecto/producto desde una perspectiva diferente que una PMO ágil o APMO. Tradicionalmente la PMO mide el avance de un proyecto en base al progreso de las diferentes tareas o actividades del proyecto, por tanto se basa en los outputs de la microgestión del proyecto.

El seguimiento de una APMO debe de ser en base a los outcomes, elementos de la macrogestión del proyecto/producto que agregen valor de negocio, lo que significa que solo funcionalidades acabadas, historias de usuario 100% terminadas que cumplan con la definición de hecho (DOD), cuentan para hacer un seguimiento real de progreso tal como marca el séptimo principio del Manifiesto Ágil:

El software que funciona es la principal medida del progreso

Por ejemplo, el haber resuelto un botón representa un avance a nivel de la funcionalidad que lo requiere, pero no significa nada desde el punto de vista de seguimiento del proyecto/producto. Hacer seguimiento de tareas es desde la perspectiva de la Agilidad engañarnos, si la funcionalidad u historia de usuario no está terminada podemos haber hecho mucho trabajo pero no hay nada que entregar al cliente ni nada que resuelva una necesidad o problema de negocio.

Ejemplos de métricas de macrogestión para una APMO son:

• Productividad: Tiempo de ciclo medio por funcionalidad
• Time-to-market: Número de releases/entregas por unidad de tiempo
• Calidad: Número de defectos y volumen de llamadas a soporte
• Satisfacción del cliente: NPS (Net Promoter Score)
• Compromiso de los empleados: Encuestas a empleados

Un beneficio que se obtiene al hacer el seguimiento de a través de los elementos de macrogestión es que con ello se focaliza al equipo en un único objetivo común, por tanto fomenta la colaboración y alienta al equipo a ser más ágil para terminar la historia de usuario en curso y entregar valor antes de empezar la siguiente.

Podemos deducir que, a diferencia de una PMO clásica que suele limitarse a tomar métricas de control y de cumplimiento, una APMO apoya a los equipos en su desempeño poniendo solución a sus necesidades y colabora con los Scrum Masters para resolver los bloqueos e impedimentos que puedan surgir a lo largo de la ejecución de los sprints.

¿Cómo gestiona SAFe® las dependencias de los equipos con otros equipos internos y externos?

Siempre que formo a los alumnos sobre la PI Planning y hablamos del Program Board de SAFe® hay cierta curiosidad y desacuerdo. Recordemos el Program Board; es uno de los tableros output de la PI Planning que muestra en qué sprint (iteración) una determinada feature está prevista que esté terminada, así como las dependencias significativas de esa feature, si las hubiera, sea una historia de usuario, una tarea o una actividad:

Program Board con la visión a nivel de tren - imagen del tema PI Planning cortesía de © Scaled Agile, Inc.

El desacuerdo suele producirse porque en las realidades de la mayoría de mis alumnos lo que ponen en el Program Board son todas aquellas historias de usuario que tienen dependencias entre si, la historia dependiente unida a la historia de la que depende. De hecho en algún tren donde he actuado de coach ágil hemos utilizado tableros de estas características, con dependencias entre historias de usuario, útil pero menos potente que un auténtico Program Board.

La disfunción en estos casos resulta en tableros con dependencias entre historias de usuario que acaban siendo muy poblados en post-its y con una intrincada maraña de hilos, útil sin duda pero ilegibles desde el punto de vista holístico del tren (ART). El Program Board, tal como lo describe SAFe, muestra todas las dependencias desde la perspectiva del nivel de tren, las features. Cuando se celebran los Scrum de Scrums y las PO-Sync ante el Program Board lo que interesa es la lectura del progreso del tren versus las features, no versus las historias de usuario que a priori solo son de interés a nivel de equipos.

En la propuesta de SAFe la gestión de dependencias no se limita al Program Board, en los tableros donde se refleja la pila (de producto) del equipo, un tablero output de la PI Planning donde el equipo ha distribuido de froma preliminar las historias en los sprints del PI, se reflejan las dependencias en las propias historias de usuario afectadas. Concretamente si una historia tiene una dependencia, SAFe sugiere poner un post-it rojo que describa la dependencia y cuando la dependencia se ha tratado y resuelto con el equipo correspondiente se le añade una marca de verificación.

Gestión de las dependencias a nivel de equipo

De esta manera tenemos la gestión de dependencias agregada a nivel de tren y la gestión de las mismas en cada uno de los equipos en la parte que le pertoca y con toda la información local que precisan.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. - Gracias a los lectores que le dan sentido a este blog

¿Cómo potenciar las PI Plannings de un Solution Train?

Distribución salas PI Planning y espacio comun

Una de las zonas más grises del marco de SAFe® es la capa Large Solution, ya que en ella hay escasas posibilidades reales de conseguir una autoorganización como ocurre en los ARTs y en los equipos. Tal como nos explica Dunbar, para que haya autoorganización a nivel de tribu o red social, no podemos superar los 125+ individuos en el tren y por ende en la PI Planning.

Recordemos que la PI Planning es el heartbeat de SAFe, el latido del corazón del marco. Si nos situamos en un excelente punto de partida, alineados entre equipos de desarrollo y negocio y con las dependencias significativas resueltas, todos los demás eventos son de menor importancia. Con un buen punto de partida solo es necesario reaccionar y ajustar en menor medida para mantener al tren en la dirección de máximo valor de negocio.

Si hubiera forma de introducir mínimos niveles de autoorganización en PI Plannings paralelas obtendríamos un mejor punto de partida que maximizaría la entrega de valor del Solution Train y por ende los beneficios económicos de la compañía.

Los RTEs tenemos nuestros foros en los que compartimos muchas experiencias de todos tipos, y hay una expuesta por Matt que me llamó mucho la atención. Él es RTE en un tren que junto con otros 3 forma parte de un Solution Train. Haciendo homenaje al sexto principio del Manifiesto Ágil que dice que la mejor comunicación ocurre cara a cara, su compañía reúne a todos los integrantes de sus trenes para las PI Plannings en una sola localización (hotel o centro de negocios).

Las cuatro PI Plannings individuales ocurren en 4 grandes salas individuales que están unidas por un pasillo o hall que permite ser punto de encuentro para representantes de los 4 trenes. En este espacio están el STE, Solution Arquitect y Solution Managers, y es donde se colocan los Program Boards de los trenes individuales junto al solution board del Solution Train. Cada dependencia individual se lleva a este espacio de manera que es visible para todos los trenes. RTEs, System Arquitects y Product Managers así como Business Owners y miembros de los equipos tienen aquí un punto de convergencia con otros trenes. Esta configuración potencia enormemente la comunicación y coordinación entre trenes, muy en dirección autoorganización y que probablemente sea una ventaja competitiva diferencial para la compañía.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿El tamaño de una tribu/ART (Agile Release Train) está limitado a semejanza de un equipo de Scrum?

¿Alguna vez habéis asistido a un boda de 90 personas? ¿A que os lo habéis pasado bien y hasta interactuado con la mayoría de los invitados? ¿Y en una de 300 invitados? También nos lo podemos pasar bien, pero en un subgrupo y sin tener consciencia del grupo de los invitados, lo que es el sistema; es por ello que una boda de 300 invitados es un sitio ideal para colarse a comer bien... todos piensan que vienes de parte de la familia de la otra parte o una amistad lejana.

Tribu o tren con cultura única
Cortesía de Pixabay

Al igual que los equipos integrados, como lo son los ágiles o de Scrum, donde existe una limitación neurobiologica de como máximo 9 miembros, existe un tipo de limitación similar que ocurre con la cantidad de individuos que pueden relacionarse plenamente en un sistema determinado, que es de aproximadamente de 125-150 individuos. Ese límite del tamaño de grupos grandes está relacionado con el tamaño de la neocorteza cerebral y su capacidad de proceso.

Este número se conoce como el número de Dunbar y que es resultado de los estudios e investigaciones del antropólogo Robin Dunbar que explica el tamaño de las tribus y villas y por ende de redes sociales (los amigos, la familia, la profesional y también virtuales como facebook y linkedin). Históricamente las villas y las tribus, compuestas de familias en lugar de equipos, se dividían en dos cuando alcanzaban este número, es algo que está enraizado en la naturaleza del ser humano.

Por tanto el tamaño de una tribu (ágil) o de un tren (ART) no debe de ser superior en número de individuos al número de Dunbar. Por encima de ese número no es posible crear una cultura única y conseguir cierto grado de autoorganización.

La autoorganización en el tren ocurre cuando colaboramos y nos ayudamos; si una persona me pide ayuda y la conozco y sé que está subida al tren, se la voy a prestar: tenemos el mismo objetivo y sé que mañana esa persona u otra me ayudará mi. Pero si no conozco a la persona, no la asocio a mi tren, ayudaré si tengo buena voluntad, pero no lo haré desde la perspectiva sistémica de unidad de un tren.

Este post nació de una conversación con Matt, un RTE experimentado en toda clase de trenes, tanto ARTs como Solution ARTs. Me contó que una vez le pidieron que acompañara un tren con más de 180 personas, primero se resistió pero insistieron y aseguraron que lo arreglarían después. Aparentemente todo fue muy bien, la sorpresa ocurrió en la tercera PI Planning cuando dio la bienvenida a dos personas que pensó se acaban de incorporar y descubrió que llevaban subidos al tren desde el primer momento... ese hecho puso de relieve la limitación de Dunbar y muestra como un system thinker, que es el RTE, puede no percibir el sistema al completo y por tanto errar en su trabajo

El número de Dunbar muestra una limitación a 125-150 individuos para trenes y tribus que deriva de la naturaleza humana

¿Cuándo usar Scrum o métodos ágiles?

Marco de Cynefin de Dan Snowden

En los acompañamientos y en las clases suele ocurrir que alguien pregunte: ¿qué es mejor, Scrum o la gestión de proyectos tradicional?

Realmente una forma de trabajar no es mejor o peor que la otra, son formas distintas y cada una ellas es la mejor solución para diferentes contextos.

Para clarificarlo vamos a adentrarnos en el marco de Cynefin de Dan Snowden que se muestra en la imagen de la derecha, un modelo que contiene una tipología de contextos que se describe como un "marco de control empírico".

Simple

El dominio simple representa los "conocidos conocidos". Son problemáticas simples en donde hay reglas (o mejores prácticas), la situación es estable, y la relación entre causa y efecto es clara: si haces A ocurrirá B. No es necesario pensar la solución, se afronta con "percibir-categorizar-responder": percibe los hechos, categoriza y luego responde siguiendo la regla o aplicando la mejor práctica. Snowden y Boone ofrecen el ejemplo del procesamiento de pago de préstamos: un empleado identifica el problema (por ejemplo, un prestatario ha pagado menos de lo requerido), lo categoriza (revisa los documentos del préstamo) y responde (sigue los términos del préstamo).

Complicado

El dominio complicado consiste en "desconocidos conocidos". La relación entre causa y efecto requiere de un análisis o de una experiencia previa; hay un rango de respuestas correctas. El marco lo afronta con "percibir-analizar-responder": evaluar los hechos, analizar y aplicar la práctica apropiada. En este contexto es necesario "pensar" para aplicar la mejor práctica, es en este contexto donde se mueven los ingenieros, cirujanos, analistas de inteligencia, abogados y otros expertos. Un ejemplo sería la ingeniería civil, la construcción de un puente.

Complejo

El dominio complejo representa los "desconocidos desconocidos". Causa y efecto sólo se pueden deducir en retrospectiva, no sabemos con anticipación si una determinada solución va a funcionar, hay que descubrir la mejor solución. No hay buenas respuestas. Requiere pensar e innovar, y lo único que podemos hacer examinar los resultados y adaptarnos. Cynefin llama a este proceso "probar-percibir-responder". Casos de seguros difíciles o el desarrollo de software son un ejemplo de este contexto en el que se requieren niveles altos de creatividad, innovación, iteración y comunicación.

Caótico

En el dominio caótico la causa y el efecto no están claros. Los acontecimientos en este dominio son "demasiados confusos para esperar una respuesta basada en el conocimiento", escribe Patrick Lambe. No requiere pensar, "acción", cualquier acción, es la primera y única forma de responder adecuadamente. Un ejemplo es una sala de urgencias de un hospital, es imposible preveer, simplemente se puede reaccionar y actuar.

---

Vistos los cuatro contextos, el contexto por excelencia para Scrum es el complejo; es en este contexto donde con Scrum podemos encontrar prácticas emergentes a problemas adaptativos complejos a través de sus ciclos de inspección y adaptación para desarrollar nuevos productos o la incorporar nuevas funcionalidades en productos existentes.

Scrum también podría aplicarse en un contexto complicado, pero probablemente haya formas más eficientes dado que es posible plantear la solución ideal al principio en base a buenas prácticas. Lo que no funcionaría es aplicar una solución para un contexto complicado, como la gestión de proyectos tradicional, a un contexto complejo... y este es un aprendizaje que muchas compañías tienen pendiente todavía.

¿Cómo hacer una implantación DevOps?

Preparando una implantación DevOps

DevOps es un acrónimo inglés compuesto de development (desarrollo) y operations (operaciones), que se refiere a una práctica de ingeniería de software enfocada en primera instancia en una cultura de colaboración e integración entre los desarrolladores de software y los profesionales de sistemas. Los primeros, los equipos de desarrollo ágil, viven en el cambio continuo, mientras que los segundos velan por la estabilidad y la expansión de servicios existentes, un claro conflicto de intereses. Para la entrega de software de valor a demanda del mercado ambas partes han de comprender que es necesaria la colaboración junto con un sentimiento de responsabilidad compartida.

En segunda instancia DevOps impulsa la automatización y el monitoreo en todos los pasos del flujo de construcción del software; desde la hipótesis de nuevas funcionalidades, la integración, el despliegue, el lanzamiento al mercado y posterior monitoreo de software para el aprendizaje sobre la hipótesis inicial. DevOps apunta a ciclos de desarrollo muy cortos con lotes de funcionalidades pequeños, alta frecuencia de implementación y lanzamientos más confiables que están en estrecho alineamiento con los objetivos de negocio de la compañía.

En el mundo VUCA actual la Agilidad no es una opción, esta hace que las compañías sean competitivas, por lo que se ha convertido en un imperativo de negocio. A su vez DevOps no es una opción, ya que sino la Agilidad no sería posible, no podemos ser competitivos sin los ciclos muy cortos de entrega de valor que posibilita DevOps.

La mayoría de compañías, por no decir todas, ya practican DevOps en alguna de sus facetas, la cuestión es cuan eficientes son. ¿Quién no tiene ya algunas pruebas automatizadas?, ¿quién no tiene un Jenkins rodando?...

DevOps Health Radar de SAFe
con la situación actual de una compañía

El radar DevOps de SAFe® tiene 4 dimensiones con un total de 16 subdimensiones. Cada subdimensión tiene 5 niveles, donde el 1 significa que todo se hace manualmente y 5 representa la máxima madurez DevOps. Hay técnicas, prácticas y herramientas que nos permiten pasar de un nivel a un nivel superior, por tanto el radar proporciona un total de 64 (4 posibles saltos por 16 subdimensiones) oportunidades y soluciones de mejora para nuestra aplicación de DevOps.

Una implantación de DevOps parte de encontrar la situación actual de la compañía averiguando cual es el nivel de cada una de las subdimensiones. SAFe proporciona la descripción de cada una de las coordenadas subdimensión/nivel del radar. En un taller a tal efecto, las personas de las áreas, los responsables y los equipos de desarrollo que participen en el flujo de construcción de software, conocido en SAFe como la Continuous Delivery Pipleline, identifican y representan la situación actual en el radar.

Seguidamente se representa el flujo de construcción mediante un Value Stream Mapping; se identifican todos los pasos desde que se concibe una funcionalidad hasta que es usada por usuario finales, se miden los tiempos de servicio (que miden el tiempo de puro trabajo en cada estado) y tiempos de entrega (que incluyen la espera entre estados) y el % de trabajo que pasa limpio y sin incidencias al siguiente estado. El mapa nos mostrará donde tenemos oportunidades de mejora en los puntos con los mayores retrasos o de más retrabajo. Basta con buscar la subdimensión afectada en el radar y decidirse por una de las prácticas, técnicas o herramientas que propone.

El mapa obtenido es un artefacto vivo, podemos implantar DevOps de forma paulatina actualizando el mapa de forma periódica para implantar mejoras. Se basa al igual que la Agilidad en un sistema de mejora continua que puede llevar años para su madurez, pero con el beneficio de la obtención de mejoras de forma muy rápida.

Value Stream Mapping del flujo DevOps actual para buscar mejoras en el radar

Si a alguien le interesara aprender sobre el radar de DevOps y como hacer el taller de Value Stream Mapping le quiero invitar a apuntarse a uno de los cursos de SAFe DevOps Practitioner (SDP) que hacemos en Estratecno. Es un curso/taller ideal para las áreas de sistemas cuyo objetivo debería de ser habilitadores para que los equipos ágiles sean más rápidos.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.