domingo, 24 de marzo de 2019

¿Porqué la Agilidad desarrolla productos con flujos de valor?

En el meetup de modelado de una visión de portfolio con el SAFe® Portfolio Canvas Sonia preguntó sobre el significado de flujo de valor, o Value Stream en SAFe. Resultó que explicarlo fue más complicado de lo que hubiera pensado, de hecho no lo conseguí ya que yo mismo no tenía toda la claridad necesaria, así que decidí trabajar el tema y escribir este post.

Hoy en día conviven dos formas para desarrollar un producto de TI, la clásica a través de un proyecto en cascada enmarcado por el triángulo de hierro (alcance, coste y tiempo fijos), y la ágil a través de lo que SAFe denomina un flujo de valor. 
Dos formas de desarrollar un producto: proyecto en cascada y flujo de valor
Para entender mejor un flujo de valor repasemos primero lo que es un proyecto; este se compone de un alcance inicial cerrado, un presupuesto cerrado y un línea de tiempo con fecha de entrega. Incluye también un equipo constituido para el proyecto, los materiales y los sistemas y recursos necesarios. 

Un flujo de valor es, a semejanza, un conjunto de pasos por los que fluye un elemento de valor (una petición de un cliente por ejemplo), las personas necesarias en forma de equipos, tribus o trenes, y los materiales y sistemas necesarios. Tiene un presupuesto inicial sobre el que se pivota o persevera en función de lo aprendido a lo largo de ciclos de mejora continua sobre el producto. Son la forma ideal de desarrollar un producto con el ciclo de Lean Startup
El flujo de valor (ValueStream) incluye la secuencia de pasos para la entrega de valor, las personas, los sistemas y materiales
Imágenes PixaBay: Equipo Scrum, ART, Incremento y Sistemas y Materiales, y Tribu de Henrik Kniberg & Anders Ivarsson
Aplicando mentalidad ágil comprendemos que invirtiendo en flujos de valor en vez de proyectos maximizamos el beneficio económico y minimizamos los costes de la demora, entendiendo como tales los costes derivados de no utilizar flujos de valor. Los beneficios que obtenemos al trabajar con flujos de valor son:
  • Equipos, trenes y tribus hiperproductivas concebidas para continuidad a largo plazo, permitiendo así que se integren verdaderamente sus miembros y formen algo más grande que los individuos. El flujo se acelera a través de la autoorganización, la multifuncionalidad, el empoderamiento y en el caso de TI la cultura DevOps. El mayor desperdicio en los proyectos suele ser todo el aprendizaje por el que equipos formados específicamente para el proyecto han de pasar, para que cuando estén rodados se desmonten para crear nuevos equipos para nuevos proyectos y se inicie un nuevo ciclo de aprendizaje.
  • Sistemas, materiales y recursos que facilitan a equipos y al flujo a ser eficientes. Las herramientas adecuadas para la construcción de software, así como herramientas que aceleran el flujo, como son la integración continua, los tests automatizados, los despliegues automatizados etc., son esenciales para maximizar flujo y beneficio. Estas requieren inversión en infraestructuras y herramientas necesarias, que en todo caso es mucho más económica que los retrabajos, tests manuales y despliegues manuales que ocurren en la mayoría de proyectos en cascada.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

martes, 19 de marzo de 2019

¿Cuáles son los tres puntos críticos comunes de los que hemos de aprender al implantar Scrum?

Las compañías tradicionales que inician su andadura en Agilidad e intentan implantar Scrum suelen tener que pasar por tres puntos críticos y efectuar su aprendizaje particukar para tener éxito y acelerar la entrega de valor.
Los tres puntos críticos susceptibles de aprendizaje
1. Los equipos son quienes deben de estimar lo que cabe en la pila de sprint

Una de las disfunciones habituales se produce cuando no es el equipo de desarrollo el que estima qué cabe en la pila de sprint; en ocasiones lo hace un "jefe de proyecto" y en otras ocasiones el contenido del sprint es la parte proporcional de un alcance de proyecto cerrado negociado de antemano.

Este último es el caso de empresas que se basan en un modelo de obediencia de sus empleados, un gestor les dice al equipo cuál es la pila de sprint a ejecutar y este simplemente lo hace... o lo intenta. Este modelo no suele funcionar ya que el equipo no siente verdadero compromiso hacia la pila, se esfuerza y hace lo que puede y si no llega siente que no es culpa suya ya que la pila fue una imposición.

En un modelo de compromiso hemos de entender que sólo las personas que van a hacer el trabajo pueden estimarlo. Obtendremos compromiso cuando el equipo decide libremente lo que cabe en la pila de sprint, al final de la planificación de sprint el equipo debe de estar totalmente convencido de que la pila es perfectamente ejecutable a lo largo del sprint. Solo así conseguiremos compromiso y que el equipo ponga el esfuerzo y toda su energía en la construcción del incremento.

Para que los equipos tengan oportunidad de aprender qué cabe en su pila de sprint hemos de darles la oportunidad para encontrar su capacidad, llamada velocidad en Scrum. Eso implica que la compañía les ha de dar permiso a fallar para aprender del fallo, usualmente un equipo novel encuentra su capacidad a partir del tercer sprint.

2. Aprender a terminar el sprint antes de empezar el siguiente

Una de la características del ser humano es que nos es muy fácil abrir y empezar cosas nuevas, pero nos cuesta horrores acabar las cosas. En este punto crítico el equipo, y el entorno que le rodea, ha de aprender uno de los mantras que provienen de Lean Kanban:

Stop starting and start finishing - Termina de empezar y empieza a terminar

Un incremento resultante de un sprint se define como un parte del producto totalmente terminada, con todo lo acordado hecho, y potencialmente liberable a producción. Para que todos entendamos qué significa terminado Scrum introduce el artefacto de la definición de hecho (DoD). Algo no está terminado hasta que todos los puntos de la definición de hecho estén chequeados y el usuario o interesado pueda usarlo o probarlo en un entorno del que sea propietario.

Una de las mayores disfunciones de Scrum ocurre cuando los equipos no son capaces terminar los sprints de manera recurrente. Puede haber diferentes causas detrás de la disfunción, como el punto 1 por ejemplo, cuando el equipo no tiene la oportunidad de aprender cual es su capacidad para la pila de sprint, o cuando el entorno que rodea al equipo no permite que cumplan con la definición de hecho; un ejemplo corriente es un entorno de despliegue para el usuario, test o preproducción por ejemplo, que no es estable e idéntico al de producción.

A nivel de compañía hay que pasar por el aprendizaje de que lo más importante para un Scrum exitoso es que los equipos encuentren su ritmo en el que de forma sostenible sean capaces planificar y entregar cosas totalmente terminadas. Llegado a este punto es donde los equipos aceleran y se pueden alcanzar incrementos de productividad del 400%, como muestran algunos estudios como el Chaos Report de Standish Group y los Annual State of Agile Reports de Versionone. 

3. Apoyar a los equipos para acelerar el flujo de entrega de valor

Las retrospectivas son el latido de la mejora continua, en cada una de ellas el equipo identifica su mayor "dolor" y busca mejoras para que no tropiece de nuevo en las mismas piedras en ocasiones futuras.

Las causas raíz de sus problemas pueden tener el origen dentro del equipo, con lo que el mismo equipo encuentra las mejores soluciones al visibilizar y tratar el problema desde dentro. En otras ocasiones las causas raíz son externas y por ellos mismos no pueden mejorar, así que Scrum Master ha de elevar las soluciones a donde corresponda para que se apliquen.

Este es otro punto crítico, ya que las compañías han de poner los medios para que el entorno del equipo dé solución a sus problemas, un aprendizaje a realizar para entender que es necesario poner los medios para que los equipos estén focalizados en un trabajo de valor, y para que el flujo de trabajo del equipo de desarrollo acelere y aumente la productividad del sistema. Cuando no ponemos los medios ocurre que los equipos tropiezan una y otra vez con el mismo problema y sientan frustración, hecho que a su vez afecta negativamente a la construcción de un software que de buenas soluciones a las necesidades de nuestros clientes.

Termino con una frase que me encanta: ¡para que hacer cosas serias es necesario divertirse! Encorsetados, cansados, estresados... difícilmente haremos cosas serias.

lunes, 18 de marzo de 2019

¿Cómo acercar y mantener a las personas de negocio comprometidas?

Recordemos que en las revisiones de sprint los interesados o stakeholders, los Business Owners y usuarios, en definitiva los clientes, son la audiencia primaria. En la reunión el equipo de desarrollo muestra lo que ha construido durante el sprint y así obtener feedback para mejoras y finalmente entregarles ese incremento en un entorno donde puedan probarlo. Esto es parte del ciclo de feedback que incorpora Scrum, con el objetivo de que el equipo de desarrollo siempre esté focalizado en construir lo que más valor aporte.

Los interesados no solo son importantes en las revisiones, lo son también en los refinamientos que el Propietario del Producto haga con ellos, y el la participación u aceptación de la pila y meta de sprint resultantes de la planificación de sprint.

Podemos desprender del ello que lo que asegura que se construye la mejor solución posible, y por tanto se obtenga el mayor beneficio económico posible, es el compromiso de los interesados en estos eventos de Scrum.

Los interesados tienen el conocimiento de negocio y mercado necesario para garantizar que la financiación asignada a los productos que se construyan se destine a las cosas correctas. Por lo tanto son un elemento crítico para garantizar que las prioridades de los equipos estén alineados con necesidades reales y con la estrategia de negocio.
Jenga, un juego de habilidad física

No es inusual encontrar interesados con tiempo escaso y que por sus otras tareas están poco comprometidos con los equipos de desarrollo. Esa carencia de compromiso suele ser un problema habitual en compañías que recién incorporan Scrum, con lo que es necesario realizar actividades y dinámicas para atraerlos e involucrarlos en los eventos de de Scrum.

La mejor forma para crear compromiso es crear confianza y entendimiento, y hacerlo a través de la gamificación es una opción excelente ya que las personas cuando jugamos dejamos de lado nuestras mochilas, somos más abiertos de mente y nos comportamos tal como somos.

Así que ante un problema de involucramiento diseñamos un juego para que interesados y equipos de desarrollo jugaran juntos, se creara esa confianza y todos entendieran que la construcción de las cosas correctas es responsabilidad compartida de ambos, y que por tanto colaborar es una necesidad.

Fran y Nayua propusieron basarnos en Jenga, un juego en el que se construye una torre con piezas de madera que luego se retiran una a una intentando que no se desmorone. La idea de nuestra dinámica fue que interesados y equipo de desarrollo construyeran de forma iterativa y como un equipo único la torre más alta posible.

Anunciamos que todos, Propietarios del Producto, Business Owners y equipos iban a colaborar con el objetivo de construir LA TORRE MÁS ALTA.

La construcción se hace en 3 "sprints" con:
  • 5 minutos de construcción
  • 3 minutos de retrospectiva para buscar mejoras
Todos los elementos de la sala son válidos, la única restricción es que la torre ha de empezar por y acabar en un pieza de madera de Jenga.

Efectuamos la dinámica en multitud de equipos y sus interesados, la creatividad fue increíble. Como elementos de la sala los participantes utilizaron post-its, cinta de carrocero, percheros, mesas, sillas... elementos mucho más allá de lo que hubiéramos podido imaginar. Con la restricción de que la torre hubiera de empezar y acabar en una pieza de Jenga pretendíamos decir que la torre se construyera con piezas de Jenga, pero la suma de ideas y de creatividad llevó a construcciones fantásticas:
Algunas de la construcciones fantásticas de aquellas sesiones
A lo largo de cada dinámica, que duraron dos horas, interesados y equipos estrecharon lazos y crearon sinergias. Percibimos un éxito total cuando algunos de los interesados y equipos de desarrollo decidieron ir a comer juntos después de la dinámica; la barrera negocio/tecnología había caído.

A partir de entonces el involucramiento y compromiso de los interesados se reforzó sensiblemente, estos comenzaron a asistir de forma más regular a los eventos de Scrum y los equipos de desarrollo construyeron soluciones alineadas con necesidades reales.

El equipo de Scrum Masters ensayamos previamente la dinámica con Jenga, nuestra torre la construimos exclusivamente con piezas de Jenga y viendo el resultado pensábamos que fuimos creativos... aún no podíamos imaginarnos lo que ocurriría después.

Mis agradecimientos al equipo de Scrum Masters con los que disfruté mucho: Fran, Nayua, Esther y Mario.

jueves, 14 de marzo de 2019

¿Existe alguna dinámica que facilite una estrategia de mejora de la Agilidad organizacional?

En este post quiero mostrar una herramienta concebida a tal efecto desde Scrum Level®, a continuación replico el post original del blog de Scrum Manager:

Análisis y escalado de la Agilidad con Agilevel 2D Dynamic

Agilevel 2D Dynamic es una dinámica que facilita el análisis y la identificación de la estrategia más adecuada para mejorar la Agilidad organizacional.

A través de un análisis estructurado de los componentes propios de la Agilidad se identifican las áreas que requieren especial atención o acciones de mejora.

Agilevel 2D Dynamic se basa en el modelo Scrum Level® y emplea mecánica de “gamificación” para facilitar la comprensión e implicación por parte del equipo que la realiza. Este equipo lo forman personas del departamento o área que se desea analizar y a través de esta dinámica evalúan de forma colaborativa las dos dimensiones de la organización.

El resultado es un diagnóstico global de la Agilidad de la empresa o departamento, incluyendo las valoraciones parciales de cada principio y valor ágil e identificando los  impedimentos que encontrarán las iniciativas de mejora. Este análisis muestra qué áreas se pueden acometer sin cautelas especiales y cuáles requieren especial atención.
Muestra de láminas incluidas en el Agilevel 2D Starter Pack
Agilevel 2D Dynamic ayuda a comprender las implicaciones de los cambios, tanto en la dimensión operativa de la empresa como en su organización o cultura y revela qué acciones podrían producir problemas en lugar de soluciones. Dibuja por tanto una línea guía para el diseño de la estrategia de mejora más adecuada a las características de la organización.

Agilevel 2D Dynamic es una herramienta de asesoría y también puede emplearse como actividad de gamificación en cursos y talleres educativos de Agilidad organizacional basados en el modelo Scrum Level®.

El material se puede descargar desde el enlace siguiente, o desde la página de materiales de agilevel donde también se puede adquirir ya impreso.
Agilevel 2D Starter Pack
Los derechos de uso están parcialmente liberados con licencia cc by nc nd.

No hay ninguna restricción para usos sin ánimo de lucro o de autoformación. Para usos en actividades, empresas u organizaciones mercantiles: 

Ensayo de la dinámica Agilevel 2D
Recientemente hicimos un ensayo de la dinámica con un grupo de mandos intermedios que están en el trayecto de adoptar Agilidad en sus áreas.

Después de una sesión con mucho debate los resultados fueron muy interesantes; los productos y servicios que realizan son de calidad pero el ritmo de trabajo actual no es sostenible, con lo que se hizo patente la necesidad de un cambio en la forma de trabajar e ir en dirección Agilidad.

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.

jueves, 31 de enero de 2019

¿Cuál es el ciclo de eventos para Kanban?

Kanban no prescribe eventos rigurosos como Scrum. En su nueva clase de Lean Kanban "Practicing the Kanban Method" David Anderson introduce 7 cadencias de Kanban: el ciclo de reuniones que impulsan el cambio evolutivo y la prestación de servicios "aptos para el propósito".
Ciclo de eventos Kanban - Créditos de la imagen: Leankanban.com
Strategy Review

Trata de una reunión de revisión del equilibrio estratégico entre la demanda de servicios (solicitudes) y la capacidad para entregar a los clientes esas solicitudes a través un portfolio de servicios de la empresa a lo largo de todo el "sistema de sistemas". En la reunión se realiza una evaluación sobre cómo estos sistemas están respondiendo a las demandas solicitadas y cómo toda decisión de mejora en los sistemas ha impactado en la satisfacción del cliente.

Operations Review

Una reunión de revisión de cómo funcionan los sistemas Kanban individuales, de como funcionan juntos y de cómo sus dependencias están siendo equilibradas por la organización respecto a la demanda y a la capacidad del "sistema de sistemas" general.

Service Delivery Review

La revisión de la prestación de servicios refleja el estado actual y el comportamiento pasado de las decisiones del equipo con respecto a las expectativas de sus clientes. El propósito es discutir y decidir sobre los cambios que el equipo puede emprender para abordar las variaciones o el mantenimiento de la idoneidad del sistema Kanban para el propósito con el que está sirviendo al cliente.

Risk Review

Una reunión para la revisión de los riesgos que podrían afectar negativamente la capacidad de entrega al cliente de un servicio del sistema Kanban. Esto podría implicar la revisión de más de un sistema Kanban, aunque se enfoca principalmente en la capacidad de entrega del sistema Kanban que se está revisando.

Replenishment/Commitment Meeting

Trata de una reunión de reabastecimiento que se produce a intervalos regulares o idealmente en función de la disponibilidad de las opciones y la capacidad del sistema Kanban. Esta reunión determina qué elementos de trabajo se comprometerán en el sistema Kanban.

Standup Meeting

Reunión diaria organizada por el equipo para poner foco y atención en la información que refleja su tablero Kanban y decidir en qué trabajos aplicar su energía y esfuerzo.

Delivery Planning Meeting

Reunión cuyo fin es planificar/replanificar la entrega de un lote de trabajo de valor para el cliente, y que tiene lugar con la frecuencia suficiente para garantizar que el sistema Kanban cumpla con su propósito y atienda a las necesidades del cliente.

Podemos identificar 10 ciclos de feedback en el diagrama de ciclo de eventos, estos muestran el flujo de información y los flujos de solicitud de cambio entre las diferentes reuniones. El flujo de información está destinado a facilitar la toma de decisiones; por ejemplo, el resultado de una Replenishment/Commitment Meeting aparecerá como información en una Standup Meeting. Las solicitudes de cambio implican que algo no está funcionando lo suficientemente bien, que existe la percepción de que alguna política actual está llevando a un resultado que no es "adecuado para un propósito"; por ejemplo, Service Delivery Review y Operations Review proporcionan información sobre la capacidad a la Strategy Review que redundará en una solicitud de un cambio de estrategia debido a la falta de capacidad operativa para cumplir con la estrategia actual.

miércoles, 30 de enero de 2019

¿Con Agilidad la jerarquía de directivos ha de romperse?

Intento de mapeo de la estructura actual con la que aporta SAFe
Una de las preocupaciones más comunes en una transformación ágil surge del hecho de que en Agilidad los equipos son autoorganizados y que por tanto todos somos gestores y ejecutores a la vez, dejando claramente fuera al jefe y al gerente, y a todos aquellos que gestionan otras personas. Eso conlleva claramente un cambio en las responsabilidades, y a primera vista parece que implique que los directivos pierdan el control sobre la organización, que se tenga que aplanar la misma y romper la jerarquía existente.

De ahí que las empresas tradicionales busquen "transformaciones ágiles" en marcos donde puedan "mapear" su jerarquía. Un ejemplo ocurre cuando descubren el marco de SAFe, lo perciben como complejo y intuyen que con sus cuatro capas se le puede trasladar la jerarquía existente.

En realidad lo único jerárquico en el marco de SAFe es el flujo entre las pilas, ni siquiera las pilas son jerárquicas, una pila da misión a la pila del nivel inferior para que esta esté alineada con la estrategia, pero cada una es independiente en sus elementos para así poder adaptarse y hacer que el sistema genere el máximo valor de negocio posible.

Recordemos que no se puede gestionar a personas que saben más de su trabajo que el gestor, el jefe o el gerente, pero si se les puede liderar. Ese es el punto clave; jefes de proyecto tienen cabida como Scrum Masters y Propietarios del Producto por ejemplo. Jefes de proyecto con habilidades sociales que siempre han protegido a sus equipos pueden ser excelentes Scrum Masters, y jefes de proyecto enfocados en la ejecución de proyectos pueden ser excelentes Propietarios del Producto. Y otros, excelentes técnicos que han llegado a jefes de proyecto por el desarrollo profesional clásico, pueden volver a desarrollarse en su talento como técnicos expertos en forma de miembros de equipo, de sistemas o arquitectura.

Con una formación adecuada y una transición hacia la mentalidad ágil, estos pueden convertirse en lideres al servicio que pueden mantener a los equipos de desarrollo en un entorno basado en las motivaciones intrínsecas desarrollándolos en verdaderos equipos hiperproductivos.

En definitiva los jefes de proyecto se convierten en System Thinkers que observan al equipo de forma holística, lo apoyan, lo proveen de recursos necesarios, eliminan impedimentos y desarrollan a sus miembros. El mismo enfoque se le puede dar a cualquier  directivo, gerente o gestor de la organización. En cada nivel jerárquico hay un sistema que liderar, sea un equipo, un área o la organización al completo. Las organizaciones necesitan lideres que guíen en la dirección estratégica por ejemplo, líderes que den la visión y misión a su área, tren o tribu, líderes que inspiren y apoyen.

Desde esta perspectiva la jerarquía de una organización puede permanecer, la clave está en transicionar de una cadena de mando a una jerarquía operativa basada en el liderazgo. Establecer objetivos comunes que impulsen a colaborar a los líderes y a sus sistemas asociados y eliminar muros de confusión puede permitir que la organización pueda alinearse en su operación con los flujos de valor desde la perspectiva de la Agilidad.

Este enfoque alternativo puede ser un punto de partida que puede servir para una transición hacia una gobernanza como la sociocracia por ejemplo, en la que una jerarquía de círculos autoorganizados a diferentes niveles y doblemente enlazados en representación y voz y voto, gobiernan una organización de una forma alineada con la Agilidad.