jueves, 28 de febrero de 2019

¿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!

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.

domingo, 24 de febrero de 2019

¿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:
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 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 :-*

jueves, 14 de febrero de 2019

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

Kanban Standup Meeting diaria
La reunión standup diaria es una reunión corta del y para el equipo, que este realiza de pie ante su tablero Kanban para tratar el progreso de su trabajo. El objetivo de la misma es repasar los ítems importantes que se han terminado, los que están en curso y los que están por comenzar. 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 y reforzando los objetivos compartidos.
  • Refuerza la responsabilidad 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 usa la reunión para decidir acciones concretas de como gestionarlo/escalarlo. 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 arrastreUno 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:
Un buen guión 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.
  • Se revisa que todos los ítems de trabajo están presentes en la etapa que les corresponde.
  • 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.