¿Cómo valida SAFe® las hipótesis de forma continua y verdaderamente Lean/Agile?

Hay mucho debate respecto a naturaleza ágil de SAFe®, cuando este es un marco Agile y Lean en toda su dimensión. Malinterpretaciones, ignorancia y adaptaciones sin comprender los principios sobre los que se basa, llevan a prácticas que no tienen nada que ver con el marco, y de hecho son contrarias al mismo.

Recientemente tuvimos un debate en el que llegamos a una conclusión muy esclarecedora:

La demanda arrastra al tren (ART)

En otras palabras; lo que arrastra la construcción basada en un epic, y por tanto el tiempo que un tren dedica al mismo, es el feedback que proviene de la validación del MPV (Mínimo Producto Viable), que por ende, a través del ciclo Lean Startup, lleva al tren a perseverar o a pivotar. Podríamos decir que en un entorno de extrema incertidumbre el ¡tren es una startup! o también podríamos imaginarnos que opere como microempresa dentro de una empresa mayor... eso es lo que le da la independencia y acelera al máximo su time-to-market.

Aqui es donde la naturaleza Agile y Lean de SAFe se hace patente, su enfoque es de producto (flujo de valor) y no de proyecto cerrado, la entrega de valor es lo que marca la decisión de seguir construyendo incrementos sobre el producto.

Recordemos que un epic en SAFe es un contenedor para una iniciativa de desarrollo de soluciones lo suficientemente grande como para requerir un análisis, más la definición de un Mínimo Producto Viable (MPV) y la aprobación financiera. La implementación se produce en Incrementos de Programa (PI) y como hemos visto ya sigue el ciclo de "construye-mide-aprende" de Lean Startup.

Ciclo Lean Startup en SAFe - imagen del tema Epic cortesía de © Scaled Agile, Inc.

Como podemos observar en la imagen, los epics no tienen un estado final como lo tiene el alcance de un proyecto tradicional, la construcción continúa mientras se produzca un beneficio económico óptimo.

Otro gran punto fuerte Agile y Lean de SAFe es su equilibrio entre lo que se concibe e inyecta desde las iniciativas estratégicas, los epics, y la capacidad de construcción del sistema subyacente, los trenes. Esto ocurre gracias a que la información fluye en ambos sentidos; desde la capa de portfolio fluyen visión y misión a través de las pilas, y de vuelta fluyen objetivos de PI planificados y feedback de usuarios de features en consumo. Este último feedback puede generar a su vez nuevos epics, que alimentan a través del ciclo Lean Startup nuevas iniciativas estratégicas.

Los trenes suelen alimentar el portfolio kanban desde el horizonte 1 del producto (flujo de valor), aquellas cosas aprendidas o identificadas a través del ciclo Lean Startup, mientras el portfolio suele alimentar a través de iniciativas a temas estratégicos desde los horizontes 2 y 3, horizontes que representan las oportunidades emergentes e iniciativas estrategicas deliberadas a largo plazo.

Entradas al kanban del portfolio también desde el ART - imagen del tema Portfolio Kanban cortesía de © Scaled Agile, Inc.

Como podemos observar, los pilares de Scrum, transparencia, inspección y adaptación están fuertemente arraigados en la naturaleza de SAFe.

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

¿Cuál podría ser un modelo de negocio para una consultora en un entorno Agile?

El papel de las consultoras en un entorno Agile - cortesía de Pixabay

En uno de los debates sobre el papel de las consultoras en el nuevo escenario con clientes Agile, o que están en plena transformación, y que trabajan con consultoras, un gerente mencionó que la Agilidad convertiría a las consultoras en puras empresas intermediarias de subcontratación de personal técnico de TI. Ese puede ser un modelo en este nuevo paradigma, pero lo que creo que realmente hace es colocar a las consultoras en su rol, en partners expertos tecnólogos.

Tradicionalmente estamos acostumbrados a ver como las consultoras gestionan proyectos para los clientes, proyectos cuya responsabilidad toman al 100%. El handicap de esto es que las consultoras, aunque puedan entender el negocio del cliente en profundidad, no tienen el conocimiento de las singularidades del cliente ni viven la realidad del mercado del mismo.

La Agilidad nos prescribe que todo proyecto debe de que ser liderado en dirección, en los "qué's", por personas que entiendan y participen del negocio del cliente, y que los expertos tecnólogos, los consultores, sean los encargados de los "cómo's" de lo que se construye. Un jefe de proyecto sabe de prioridades para optimizar recursos, tecnología y personas, pero difícilmente sabe de prioridades de negocio para entender las necesidades reales y construir una buena solución que cubra esas necesidades.

Y ahí es donde el modelo de negocio actual de las consultoras puede flaquear. Lo primero que debe de ocurrir es que la propia consultora se transforme a Agilidad; para poder proveer de servicios ágiles es necesario entender y practicar la Agilidad a nivel empresarial como manera de trabajo propia, esto es algo necesario para llegar a ser una consultora ágil.

El servicio de una consultora ágil puede consistir en la oferta de equipos hiperproductivos o ganadores, lo que redunda en:

• Equipos ágiles integrados en fase de performing con conocimiento y entendimiento de la Agilidad
• Equipos que apliquen prácticas técnicas ágiles para crear soluciones técnicas de alta calidad y bien diseñadas

Desarrollo de equipos Agile - cortesía de Pixabay

El mero hecho de juntar personas y llamarlas equipo ágil no garantiza que funcionen como un equipo alineado y de alto rendimiento. Un verdadero equipo ágil se siente responsable y comprometido con los objetivos que se han marcado en común a partir de una misión dada. Al igual que un equipo deportivo tienen éxito y fracasan juntos. Los equipos ágiles están empoderados, colaboran, se alinean en un objetivo común compartido y tienen todas las habilidades necesarias para definir, construir, probar y, cuando sea aplicable, desplegar valor en cada sprint.

Para ello las consultoras ágiles deben de desarrollar a los equipos, hacer la labor de dotarles de todas las herramientas para que se integren, eso supone formación en Agilidad, coaching, mentornig y sobre todo empoderamiento para fallar rápido y aprender rápido.

Por otro lado los equipos ágiles deben de alinearse con los y prácticas de ingenieria ágil de software para poder ofrecer soluciones de forma rápida y confiable. La Ingeniería de software es "la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software", lo que significa incorporar valores y principios Lean-Agile y prácticas de eXtreme Programming (XP), modelado ágil, enfoques probados para el diseño de software... por tanto las consultoras ágiles deben de proveer a los equipos de herramientas y recursos para ello, formación continua en herramientas y prácticas emergentes y también espacios como comunidades de práctica donde los desarrolladores y especialistas de los diferentes equipos y clientes puedan reunirse para intercambiar ideas, obtener ayuda en sus retos y compartir y discutir sobre nuevas tecnologías.

El gran reto, creo yo, está en dar valor al conocimiento tácito, entender que el conocimiento de estas personas es el mayor activo y pasar de considerar a las personas como recursos a tratarlas como personas en toda su naturaleza humana y crear equipos ágiles sin ignorar lo que la ciencia, la psicología y la sociología, nos enseña desde hace décadas. Eso implica que los consultores pasen de un modelo de obediencia a un modelo de colaboración y compromiso, y eso puede ser un cambio tan grande que quizá no todas las consultoras tengan oportunidad de sobrevivir. El autobús Agile ya ha partido, algunos pueden correr y hasta llegar a subirse, pero difícilmente sentarse en primera fila o al lado de una ventana...

Mis agradecimientos a Anderson por su profundidad y su símil del autobús :-P y a mi compañera Gertru por aportar y revisar el post :-*

¿Cómo se realiza la standup diaria en Kanban?

Kanban Standup Meeting diaria

La reunión standup diaria, también conocida como Team Kanban Meeting o reunión Kanban de equipo, es una de las reuniones del ciclo de eventos de Kanban que se introduce en el nivel 1 del modelo de madurez Kanban (KMM). Se trata de una reunión corta del y para el equipo, que este realiza de pie ante su tablero Kanban para tratar en conversación colaborativa el estado del trabajo. El objetivo de la misma es repasar los ítems importantes que se han terminado, los que están en curso, los que están por comenzar, las colas entre las etapas del flujo de trabajo y los problemas que afectan al mismo. Es el momento de la microplanificación para alinear al equipo hacia las metas y objetivos del día y poner el foco en mejorar el proceso y lograr un flujo de trabajo óptimo, ambos propósitos de Kanban.

Los beneficios de la reunión son:

• Conecta a los miembros del equipo entre sí, mejorando la colaboración, generando conocimiento compartido sobre el flujo de trabajo y reforzando los objetivos compartidos.
• Genera decisiones compartidas sobre nuevas iniciativas y asignación de capacidad.
• Refuerza la responsabilidad y el compromiso al tener a los propietarios de los ítems ante el tablero.
• Potencia la comunicación interpersonal.

En la standup diaria el equipo expone los problemas y trata de resolverlos, si se enfrenta a un impedimento que se puede tratar brevemente usa la reunión para decidir acciones concretas de como gestionarlo/escalarlo. Si el problema/impedimento identificado lo requiere se agenda una reunión posterior ad-hoc con los miembros del equipo con conocimientos y habilidades relevantes para resolverlo. En ausencia de problemas o impedimentos inmediatos, la standup diaria sirve como una oportunidad para mejorar los procesos y el flujo de trabajo en general.

Consejos para el facilitador (Flow Master, Scrum Master, coach ágil...) para una buena standup diaria:

• Limitar la reunión a 15 minutos.
• Mantener la reunión de pie ante el tablero Kanban y visible para todos.
• Mantener la reunión enfocada en su cometido:
• Si surge un tema sobre un proceso o problema específico no permitir que se convierta en un problema general.
• Si surge una mejora general no permitir que se profundice demasiado en un problema o situación específica.
• Si la discusión tiene valor, pero surgen problemas que necesitan ser examinados más profundamente, dejar de lado esos temas para una reunión posterior específica para tratar ese tema en otro momento, y a la que asistirán solo las partes interesadas.

El tablero Kanban es la herramienta principal y se atraviesa de derecha a izquierda para enfatizar el arrastre. Uno de los propósitos principales de Kanban es acelerar el flujo y disminuir el tiempo de entrega (Lead Time). Por tanto la standup diaria se centra en el flujo de trabajo, en la detección de cuellos de botella, hambrunas, bloqueos, etc.

Para ello el equipo se centra en responder como unidad las siguientes tres preguntas:

• ¿Qué problemas o impedimentos tenemos?
• ¿Cómo está el flujo?
• ¿Qué podemos mejorar?

Un buen guion para una excelente standup diaria sería:

• El facilitador de la reunión enumera el trabajo de derecha a izquierda, no lo hacen los miembros uno a uno.
• El facilitador puede solicitar una actualización del estado de un ítem o preguntar si hay alguna información adicional que aún no esté en el tablero.
• Se revisa que todos los ítems de trabajo están presentes en la etapa que les corresponde.
• Se revisa los ítems "arrastrables" en las colas "Done": ¿Qué ítem debería arrastrarse a continuación y por quién?
• Se eliminan los ítems completados.
• Se comprueba que se cumplen los límites WIP.
• Se revisa la priorización en función de las clases de servicio.
• Si hay bloqueos y/o problemas, se plantean acciones para eliminarlos.
• Si hay impedimentos alguien coge la responsabilidad para gestionar su resolución, usualmente será el facilitador.
• Si hay cuellos de botella, se analiza la causa raíz y se colabora para aliviarlos.

Como podemos observar las standups diarias de Kanban difieren de forma significativa de las reuniones diarias de Scrum, haciendo honor a la diferencia entre incremento iterativo e incremento continuo.

---

En el nivel 2 del modelo de madurez Kanban (KMM) la Team Kanban Meeting se sustituye por la Workflow Kanban Meeting, o reunión Kanban del flujo de trabajo, a la que asisten todos los equipos que participan en el flujo de trabajo de principio a fin de un servicio. En ella todos los equipos tratan de forma colaborativa el estado del trabajo, las colas entre las etapas del flujo de trabajo y los problemas que afectan a éste.

Se tratan las mismas cuestiones que en la Team Kanban Meeting pero desde la perspectiva holística del servicio. La reunión se realiza ante el tablero que muestra el estado del trabajo, admite como máximo a 50 personas, se realiza de forma semanal y se limita a 20 minutos de duración.

Un buen guion para una excelente Workflow Kanban Meeting sería:

• El facilitador recorre el tablero de derecha a izquierda.
• El facilitador puede solicitar una actualización del estado de un ítem o preguntar si hay información adicional que los equipos conozcan y aún no esté en el tablero.
• En caso de equipos más maduros se puede limitar a tratar sólo los elementos bloqueados.
• Se revisa los ítems "arrastrables" en las colas "Done": ¿Qué ítem debería arrastrarse a continuación y por qué equipo?
• Se eliminan los ítems completados.
• Se comprueba que se cumplen los límites WIP.
• Se revisa la priorización en función de las clases de servicio.
• Si hay bloqueos y/o problemas, se plantean acciones para eliminarlos.
• Si hay impedimentos alguien coge la responsabilidad para gestionar su resolución, usualmente será el facilitador.
• Si hay cuellos de botella, se analiza la causa raíz y se colabora para aliviarlos.