¿Qué beneficios aporta la cadencia?

En Agilidad la cadencia representa el ritmo o repetición de determinados eventos, eventos que se repiten con regularidad por unidad de tiempo, y cada uno de ellos genera un incremento finalizado del producto.

En Scrum la cadencia está representada por los sprints

Podríamos decir que en cadencia trabajamos a cachitos, estos representan funcionalidades completas construidas dentro de periodos del mismo tamaño y que queremos finalizar al 100%. Digo "queremos" porque encontrar ese ritmo en el que finalizamos cosas al 100% requiere un aprendizaje por parte de equipos y compañía.

Cada equipo ha de aprender a estimar el tamaño de lo que le cabe y encontrar su capacidad media o velocidad, para después planificar en base a esa capacidad y jamás superarla; incluso deberán de planificar por debajo de la misma ya que entregar con cadencia requiere capacidad de reserva para imprevistos y accidentes. 

Por otro lado la compañía ha de aprender qué medios y recursos ha de poner a disposición de los equipos, así como demoler los impedimentos sistémicos que bloqueen o retrasen a estos.

Infografía The Sprint, cortesía de AgileGenesis

Se trata de un ritmo en el que se empiecen cosas y se acaben dentro de cada periodo. El periodo que representa los intervalos de la cadencia a nivel de equipo lo conocemos como sprint, que habitualmente suele ser entre 1 semana y un mes.

El aprendizaje más difícil para las personas es aprender a terminar cosas, y la cadencia va a fomentar ese aprendizaje. Quizá conozcáis el mantra de Kanban:

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

Veamos los beneficios de la cadencia:

• Permite focalizar a los equipos en las cosas de valor, ya que entre sprints podemos inspeccionar (tomar feedback del usuario/cliente) y adaptar la pila de producto a la nueva información.
• Convierte eventos impredecibles en predecibles, sabemos de antemano, hasta a largo plazo, la agenda de eventos, lo que permite reservar agendas y reducir costes. 
• Hace que los tiempos de espera para nuevas funcionalidades sean predecibles.
• Apoya la planificación regular fomentando la colaboración en el equipo.
• Limita el tamaño de los lotes de trabajo a lo que cabe en un sprint, con lo que aceleramos la entrega de valor y mantenemos al equipo focalizado en los elementos de la pila de sprint.
• Controla la inyección de funcionalidades nuevas; dado que el tamaño del sprint es limitado  asegura que solo entra lo prioritario.

En definitiva la cadencia hace al equipo previsible. Si le preguntamos a un manager ejecutivo o a un cliente "puede tomar la pastilla roja para la productividad o la azul para la previsibilidad. ¿Cuál tomaría?", la respuesta siempre es "la azul, previsibilidad".

Si la pregunta tradicional es "¿a que fecha estará esto o esto otro?", lo que nos lleva a tirarnos a la piscina en base a estimaciones de bola de cristal y probablemente a una entrega mediocre, la pregunta con cadencia es ¿qué cabe en el siguiente sprint? para una vez aprendida la capacidad del equipo, lo que cabe en un sprint, ser previsibles y realizar buenas entregas.

La cadencia también es de importancia vital cuando escalamos, cuando varios equipos han de colaborar:

• Nos permite tener una planificación cruzada con los equipos para gestionar dependencias y llegar a acuerdos entre los mismos.
• Proporciona puntos de integración programados al final de cada sprint en los que podemos integrar los incrementos de los diferentes equipos y asegurarnos que juntos funcionan según lo esperado.

Equipos trabajando con la misma cadencia y de forma sincronizada

¿Cuál es el valor de las certificaciones ágiles?

¿Cúal es el valor de mi certificación? - cortesía de Pixabay

Actualmente hay una moda en LinkedIn de publicar certificaciones recién obtenidas, yo no lo hago, pero si vais a la página del blog "Sobre mi" parezco un General Ágil con todas las certificaciones que he obtenido. El caso es que este tema genera muchos debate en las redes sociales sobre si las certificaciones valen para algo.

Desde la perspectiva de la búsqueda de empleo, y especialmente en España donde impera la titulitis, las certificaciones aumentan las posibilidades para pasar una entrevista con Recursos Humanos, generan confianza y permiten diferenciarnos de otros en el proceso de selección laboral. Por otro lado poder aportar una certificación de renombre, por ejemplo de la Scrum Alliance o Scrum Manager, o una certificación avanzada como Lean Portfolio Management, permite negociar un nivel del sueldo más alto. Pero, ¿es ese el valor de las certificaciones?

Hoy en día la importancia de introducir métodos ágiles en las compañías es evidente, estamos en un punto de inflexión donde ocurren muchas transformaciones ágiles y la demanda de profesionales competentes supera la oferta. Claro que los años de experiencia en roles y desarrollos ágiles son los que crean el entendimiento de los métodos ágiles y por tanto la competencia y habilidades necesarias, pero hay que incorporar nuevos profesionales y al fin y al cabo todos hemos empezado desde cero.

Una certificación no asegura la competencia de la persona certificada, una certificación no nos convierte en maestros de Scrum o Kanban, pero si muestra que tenemos la intención de aprender, garantiza un nivel de conocimiento y nos dota del lenguaje necesario para ayudar a introducir la Agilidad en las compañías.

El valor de las certificaciones está en entender que son un punto de partida, no un destino

Las certificaciones ágiles más potentes son aquellas que llevan un curso asociado, aquellas que para poder sacártelas has de pasar forzosamente por un curso. Las entidades certificadores que requieren un curso suelen filtrar, dotarse y formar trainers excelentes cuyas enseñanzas son transformacionales e impregnan a los alumnos de una verdadera mentalidad ágil.

A partir de aquí los grandes profesionales se forman en base al aprendizaje (microaprendizaje continuo) y a la mejora continua, y de hecho a lo largo de toda la vida profesional. Su desarrollo vendrá determinado por la actitud de búsqueda continua para seguir formándose y validar sus conocimientos, así como de la disposición de su compañía a apoyar la formación y aprendizaje continuo de sus empleados.

¿Qué ceremonias podrían servir dentro del chapter?

Chapter Meeting :-D

En mi post sobre el Chapter Lead, en los comentarios, David lanzó esta pregunta que me pareció muy interesante y a la que quiero dedicar este post.

Recordemos que un chapter es un foro para compartir conocimiento y fomentar la innovación. Los mejores resultados siempre se logran en colaboración, el todo siempre es más que la suma de las partes, así que, permitiendo que los expertos de una disciplina incorporen diferentes opiniones y perspectivas en las decisiones del chapter, hace que los resultados sean excepcionales y estén alineado con la tribu y la empresa.

Quiero exponer en este post los tres tipos de eventos/reuniones que utilizamos y nos funcionaron muy bien. Los dos primeros fomentan el pensamiento sistémico (System Thinking) para que el chapter siempre piense y actúe de forma holística, y el tercero el desarrollo de las personas miembros del chapter.

Chapter Meeting (Chapter-Sync): reunión a nivel de la tribu en la que se sincroniza y alinea el chapter; donde los miembros de diferentes squads tratan desde su expertise cómo se deben hacer las cosas. Se comparten problemas, dudas, prácticas, conocimientos, definición de estándares de trabajo, herramientas, se busca y da ayuda, se identifican puntos de mejora y se establecen temas en los que deben mejorar o formarse.

Los temas se recogen en el chapter backlog que se gestiona de la misma manera que una típica pila de producto. Estos temas se priorizan por votación de los miembros del chapter, luego son analizados y presentados en próximos chapter meetings o, dependiendo de tamaño e importancia, en reuniones específicas. El Chapter Lead es responsable de la transparencia del backlog y de la coordinación de temas que tengan que ver con otros chapters o squads.

La cadencia que aplicamos al evento es con cada sprint (cada 2 semanas). Hacerlo con cadencia semanal o mensual también está bien, aunque como mínimo debe de ser mensual. La duración es de 1h a 1h30min y deben de asistir todos los miembros del chapter, incluido Chapter Lead. La agenda del evento es variable, puntos que son usuales:

• ¿Estamos alineados con la estrategia de la tribu?
• ¿Hay novedades y conocimientos a compartir?
• ¿Hay riesgos, problemas, dudas, impedimentos a resolver?
• Revisión e inclusión de temas en el chapter backlog
• Swarming sobre el/los temas del backlog a tratar en esa sesión

Comunidad de prácticas - cortesía de Pixabay

Comunidad de prácticas: otro mecanismo para fomentar chapters excelentes es proporcionar CoPs a modo de gremio transversal, o guild, a todas las tribus dentro del ámbito del chapter. Los gremios tienen un carácter más formal e institucional que otras CoPs, por tanto tienen un papel más relevante que los Chapter Leads deben impulsar.

El evento lo moderan voluntarios que facilitan las sesiones según las reglas que el gremio haya establecido:

• Intercambio de información sobre últimas novedades y desarrollos
• Compartición de tendencias, experiencias, mejores prácticas,
• Realización de formaciones internas, hackatons, entrenamientos, experimentos
• ...

Los miembros del gremio se reúnen preferiblemente de forma regular, una buena cadencia es entre mensual y trimestral. Es de asistencia libre, pueden unirse y contribuir libremente todos los interesados, sean o no del chapter.

Reunión uno a uno - cortesía de Pixabay

Reuniones uno a uno en base trimestral el Chapter Lead, que lidera el desarrollo y madurez de los profesionales del chapter, mantiene una reunión con cada miembro del chapter.

En esta reunión se tratan temas sobre como evaluar el desempeño individual, dar feedback, tratar iniciativas para desarrollar las capacidades adecuadas según las necesidades de la tribu, establecer los objetivos de desarrollo profesional contando con la persona y actividades de coaching y mentorización.

Aunque el Chapter Lead no sea un jefe sino un líder al servicio, también trata en esta reunión temas laborales: vacaciones, aumentos de salario, permisos etc.

¿Cómo funciona una retrospectiva en Kanban?

Equipo trabajando acciones de mejora - cortesía de Pixabay

La Team Retrospective, o retrospectiva de equipo, es uno de los eventos de revisión del ciclo de eventos de Kanban que se introduce en el nivel 1 del modelo de madurez Kanban (KMM), y es una de esas prácticas ágiles que nos lleva a mejorar colaborativamente y evolucionar de forma continua, y que no se puede omitir si queremos la mejora continua y mantener el rendimiento en el mejor nivel.

El propósito del evento es que el equipo reflexione sobre cómo está gestionando su trabajo y cómo puede mejorar.

El evento se establece con periodicidad semanal o cada 2 semanas, con una duración máxima de 1 hora, que se realiza frente al tablero Kanban y asisten los miembros de equipo y opcionalmente un facilitador.

Un guion ejemplo de la revisión seria:

• Repasar resultados de acciones de mejora recientes anteriores (las que se hayan puesto en marcha).
• Repasar los elementos de trabajo completados.
• Recopilar observaciones y ocurrencias respondiéndo a preguntas como:
• ¿Qué nos falta?
• ¿Qué deberiamos de hacer además?
• ¿Qué ideas vale la pena explorar?
• ¿Tenemos problemas relacionados con las políticas actuales?
• ¿Algún otro probelema o impedimento?
• Categorizar los elementos recopilados y definir acciones de mejora.

---

En el nivel 2 del modelo de madurez Kanban (KMM) la Team Restrospective se sustituye por la Flow Review, o revisión del flujo, cuyo propósito es desarrollar una comprensión cuantitativa inicial del servicio prestado por los equipos involucrados en el servicio, para después facilitar la planificación del trabajo y así mejorar la previsibilidad..

El evento se establece con periodicidad mensual o cada 2 semanas, con una duración máxima de 30 minutos y asisten los miembros de los equipos de prestación de servicios, o parte del mismo, SDM (Service Delivery manager) y opcionalmente Team Leaders y facilitador.

Tiene una parte cuantitativa en la que el equipo desarrolla una comprensión inicial del servicio prestado, que va seguida de una segunda parte que es cualitativa. Los equipos tratan cualquier problema con el que se hayan enfrentado con los elementos de trabajo y comparten cualquier conocimiento valioso que haya adquirido mientras los procesa.

Un guion ejemplo para el facilitador de la revisión seria:

• Repasar resultados de acciones de mejora recientes anteriores (las que se hayan puesto en marcha).
• Inspeccionar al detalle el tablero Kanban de derecha a izquierda (demanda por tipo de servicio, bloqueos, retrasos, edad de los elementos, riesgos, ...).
• Comparar el desempeño actual con los objetivos marcados (SLA's) usando métricas centradas en el cliente, calidad, Lead Time/Cycle Time, tasa de llegada, throughput por clases de servicio (CFD, run charts, control charts, ...).
• Sobre el trabajo terminado compartir problemas que hayan acecido y difundir nuevos conocimientos aprendidos.
• Analizar el progreso de los elementos en los que el equipo está trabajando actualmente.
• Identificar el acciones de mejora para el flujo de trabajo a través de sus causa raíz aplicando técnicas Lean como 5 whys y el diagrama de Ishikawa, y finamente planificar como llevarlas a cabo.

---

En el nivel 3 del modelo de madurez Kanban (KMM) la Flow Review se sustituye por la Service Delivery Review, o revisión de entrega del servicio, cuyo propósito es examinar y mejorar la eficacia del servicio seleccionado tomando la perspectiva del cliente externo del servicio.

El evento se establece con periodicidad cada 2 semanas, con una duración máxima de 30 minutos y asisten representantes de los equipo de prestación de servicios, SDM (Service Delivery Manager), SRM (Service Request Manager) y opcionalmente clientes, interesados y facilitador.

Con un guion similar a la Flow Review trata de inspeccionar el flujo de trabajo, reflejar el estado actual y el comportamiento pasado de las decisiones del equipo con respecto a las expectativas del cliente, para discutir y decidir sobre mejoras que el equipo pueda emprender para abordar las variaciones o el mantenimiento de la idoneidad del sistema Kanban con el que operan para servir a ese mismo cliente.

En caso de nivel de madurez 4 del sistema Kanban de los equipos se toman inputs de la Risk Review y de la Operational Review; y de vuelta se informan las acciones y hallazgos a la Operations Review.

¿Cómo reabastecemos nuestro tablero Kanban?

Team Replenishment Meeting remota - gracias Javi, Sara y María

El evento en el que los equipos de servicio seleccionan nuevas peticiones o elementos de trabajo para el siguiente periodo y reabastecen su tablero Kanban se denomina Replenishment/Commitment Meeting.

Es una de las reuniones del ciclo de eventos de Kanban que en el nivel 1 del modelo de madurez Kanban (KMM), a nivel de equipo, se denomina Team Replenishment Meeting, o reunión de reposición del equipo.

En esta reunión, y con base a un sistema de arrastre en función de la disponibilidad de las opciones y la capacidad del sistema Kanban, el equipo determina con qué elementos de trabajo se compromete y los lleva a la columna "Ready" del tablero.

La duración máxima de la reunión son 30 minutos y la cadencia habitual del evento es semanal, aunque dependiendo de la tasa de llegada de peticiones esta puede producirse bajo demanda. Las organizaciones menos maduras suelen tener problemas con el reabastecimiento bajo demanda y prefieren la cadencia de eventos predecibles. El reabastecimiento bajo demanda es posible cuando el esfuerzo de coordinación es bajo y los Business Owners tienen alta disponibilidad y cercanía con el equipo.

Asisten los miembros del equipo, o parte del mismo, y los Business Owners que estén involucrados en el flujo de trabajo. Dado que los elementos de trabajo se comprometen es importante que estos estén claramente definidos, tanto la funcionalidad, los aspectos técnicos y posibles dependencias con otros equipos; se produce:

• Toma de decisión colaborativa sobre qué elementos de trabajo llevar a cabo y comprometerse a entregarlos con éxito al cliente final.
• Identificación y análisis de dependencias y/o riesgos que el equipo debe conocer antes comenzar a trabajar en los nuevos elementos de trabajo.

La naturaleza del trabajo de los equipos que operan bajo Kanban, como por ejemplo los equipos de mantenimiento y los de sistemas, suele ser más reactiva que la de los equipos que usan Scrum. También para éstos es beneficioso expresar una meta para el siguiente periodo, esta les permite entender el propósito y estar seguros de que esta es alcanzable, y así poder comprometerse con los elementos de trabajo y los acuerdos de nivel de servicio (tiempos de respuesta).

Para asegurar que todo el equipo cree que la meta sea alcanzable se puede hacer el siguiente chequeo:

• ¿Creéis que se puede alcanzar la meta? Puntuad levantando los dedos de una mano del 1 al 5 (1=no lo creo, 2=probablemente no, 3=tal vez no, 4=probablemente sí, 5=definitivamente)
• Si la puntuación mayoritaria está en 1 o 2 discutir qué se precisa para mejorar:
• Eliminar un impedimento
• Aliviar un cuello de botella
• Reducir el alcance
• Ajustar la meta

El evento puede llevar a cambios de comportamiento como:

• Cambios de política
• Decisiones sobre qué y como arrastrar
• Cambios en el sistema Kanban, que se llevarán a la standup diaria o Kanban Meeting

---

En el nivel 2 del modelo de madurez Kanban (KMM) la Team Replenishment Meeting se sustituye por la Workflow Replenishment Meeting, o reunión de reposición del flujo de trabajo, donde colaboran los diversos equipos involucrados en el flujo de trabajo del servicio. Su propósito es que los equipos relacionados con un servicio seleccionen las peticiones a llevar a la columna "Ready".

De forma similar a la reunión de reabastecimiento de equipo, los equipos del servicio determinan en base a un sistema de arrastre con qué elementos de trabajo se comprometen y los lleva a la columna "Ready" del tablero. Con ello se proporciona claridad al flujo de trabajo y se crea un entendimiento compartido sobre en qué se está trabajando y cuándo.

La duración máxima de la reunión son 30 minutos y la cadencia habitual del evento es semanal, asisten representantes de los equipos y los Business Owners que estén involucrados en el flujo de trabajo.

---

En el nivel 3 del modelo de madurez Kanban (KMM) la Workflow Replenishment Meeting se sustituye por la Replenishment Meeting, o simplemente reunión de reposición, cuyo propósito es decidir junto con el cliente y los interesados de negocio las solicitudes de trabajo para el próximo período.

Se tratan las solicitudes disponibles que cumplen los criterios de selección y se llevan a "Ready", lo que representa dos compromisos:

• Del cliente con respecto a no cambiar las solicitudes seleccionadas
• Del equipo para entregar dentro de las expectativas

La duración máxima de la reunión es de 1 hora y la cadencia habitual del evento es entre semanal y mensual. Asisten representantes de los equipos, SDM (Service Delivery Manager), SRM (Service Request Manager) y los Business Owners que estén involucrados en el flujo de trabajo.

Pueden llevarse observaciones de la reunión a la Service Delivery Review para un análisis adicional del sistema Kanban.

¿Cómo asegurarnos que nuestro MPV realmente lo es?

Imagen del artículo de Sugoi Labs "Framework to build an MVP"

En algún momento me crucé con la imagen de la derecha en la que se muestra qué es y qué no es un MPV (Mínimo Producto Viable).

¡Me chocó! Estaba convencido de que el MPV del ejemplo es el patinete. Siempre pensé que si nuestro cliente tiene una necesidad de movilidad no sabemos de entrada si la solución ideal es un coche, en este caso un 2CV, como nos sugiere esta imagen.

Así que quise averiguar qué es lo que nos quería enseñar y busqué el artículo con la imagen. Se trata de "Framework to build an MVP" en el que Amar Saurabh comparte un marco para productos digitales que podemos usar para cualquier idea de producto que podamos tener.

En su artículo nos cuenta que primero hemos de decidir las características mínimas que debe tener nuestro producto en su MPV, para luego iterar rápidamente sobre el producto en función del feedback recibido por nuestros clientes. Debemos crear un MVP e iterar cuando la idea sea relativamente nueva y esta no haya sido validada por usuarios o clientes reales. Pero en los casos en los que ya tenemos un número suficiente de interacciones de usuario con el producto que demuestren que los usuarios finales lo desean, no necesitamos crear un MVP.

¿Qué hacer entonces para saber cual es MPV? Adrian Solca preparó un diagrama que ha compartido recientemente en LinkedIn que ayuda a identificar si lo que necesitamos es un Prototipo, un Piloto o un MPV. El diagrama de paso también nos ayuda a entender si nuestro MPV lo es.

He aplicado el diagrama para averiguar si el MPV es el que dice que es.

Diagrama de flujo de Adrián Solca para saber si un MPV lo es realmente

El razonamiento que emplee para aplicar el diagrama de Adrián es el siguiente:

• ¿Sabes QUÉ NECESITAN los usuarios para los que estás construyendo una solución?
• Si: Necesitan una solución de movilidad.

• ¿Sabes CÓMO necesitan que sea la solución para que les sirva?
• Si: La solución ha de poder transportar a personas y circular por carretera.

• ¿Tienes identificado un mercado meta claro que está interesado en tu solución?
• Si: Familias.

• ¿Necesitas empezar a recibir feedback "real" para comenzar a crecer la idea?
• Si: Tengo un 2CV mínimo y no sé si cubre todas la necesidades básicas de los usuarios.

Eric Ries, quien introdujo el concepto, define MPV como "la versión de un nuevo producto que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo".

Si consideramos un MPV aquél que solo tiene las características básicas suficientes para lanzar el producto, y no más, parece ser que si aplicamos el diagrama a la tercera opción de la imagen descubrimos que efectivamente se trata de uno.

Este caso trata del proceso con MPV basado en la construcción de un producto, un 2 CV es nuestro caso:

• MPV: una cabina sobre ruedas para personas.
• Iteración 2: el usuario nos dice que además necesita transportar cosas, con lo que le añadimos una cajonera atrás.
• Iteración 3: el usuario nos dice que debería de ir cubierto, con lo que creamos una carrocería que cubra todo el coche.
• Iteración 4: finalmente perfilamos detalles y embellecimientos para hacer el coche atractivo.

Proceso de MPV basado en la construcción de un producto

Según la Wikipedia los propósitos de un MPV son:

• Ser capaz de probar una hipótesis de producto con recursos mínimos.
• Acelerar el aprendizaje.
• Reducir el desperdicio de horas de ingeniería.
• Presentar el producto a los "primeros seguidores" tan pronto como sea posible.
• Como base para otros productos.
• Para demostrar las habilidades de un constructor en la elaboración del producto requerido.

Eric Ries también nos dice "Enamórate del problema, no de la solución".

Todo eso arroja una luz algo diferente sobre la cuestión, en nuestro ejemplo se trata de encontrar la mejor solución a la movilidad, y esa no tiene que ser un coche, y además puede ocurrir a través de varios productos.

La respuesta a la última pregunta del diagrama podría ser:

• ¿Necesitas empezar a recibir feedback "real" para comenzar a crecer la idea?
• Si: Tengo un patinete que da solución a la movilidad, es una solución de inversión mínima que, aunque no es utilizable por una familia, me permite obtener información sobre otras necesidades reales de los usuarios.

En este caso se trataría de proceso de MPV basado en las necesidades del usuario y en nuestra propuesta de valor:

• MPV: un patinete que nos validará si la solución deseada es algo sobre ruedas.
• Iteración 2: el usuario nos dice que además necesita poder sentarse, con lo que pivotamos la solución hacia una bicicleta.
• Iteración 3: el usuario nos dice que quiere que sea autopropulsada, con lo que pivotamos hacia una motocicleta.
• Iteración 4: el usuario nos dice que quiere más seguridad y protección, con lo que pivotamos hacia un coche 2 CV.

Proceso de MPV basado en la propuesta de valor

Pienso que ambos son MPVs, en el primer caso enfocado a un proceso de construcción de un producto cuya visión está definida, y en el segundo caso enfocado a descubrir un producto que responde a nuestra propuesta de valor; fijémonos que este segundo caso cada iteración resulta en un producto funcional terminado.

La madurez en Agilidad y la naturaleza del producto determinarán cual es proceso adecuado: una empresa startup sin duda se basará en el proceso de propuesta de valor, y una compañía con un producto grande probablemente se basará en el proceso de construcción.

¿Si un equipo llega limpio a la iteración IP puede incorporar nuevo trabajo?

Imagen del tema Innovation and Planning Iteration cortesía de © Scaled Agile, Inc.

La pregunta del titulo del post la hizo recientemente un equipo cuyo avance hacia sus objetivos del PI era excelente. Básicamente estaban diciéndome que terminarían en las iteraciones previstas todas sus historias de usuario a tiempo y cubrirían todos los objetivos, tanto los comprometidos como los no comprometidos. Entonces, ¿porqué no incorporar nuevo trabajo en la iteración IP (Innovation and Planning)?

La respuesta está en System Thinking: la entrega de valor, y en definitiva la predictibilidad, está a nivel de tren (ART), no a nivel de equipo, por tanto esa situación de "todo terminado" debe de producirse en todo caso a nivel del tren. Así que mi recomendación final, no la inicial porque no estaba preparado para esta pregunta, fue que se informaran sobre la situación del resto de equipos, y quizá descubrieran que otro equipo podría necesitar su ayuda. Así que nos preparamos para tratar el tema en el siguiente Scrum de Scrums (SoS).

El entendimiento que el tren es la unidad, y que lo equipos son los que lo componen, es un concepto que tarda en calar. En un equipo que era cuello de botella por las dependencias de otros con ellos, usaron la expresión "corriendo detrás del tren", expresión que es muy ilustrativa y que muestra de nuevo la dificultad que entraña incorporar la perspectiva sistémica en las personas de los trenes.

Otra perspectiva que trae claridad es la teoría de flujo; donde lo que se conoce como slack time, tiempo sobrante, puede ser lo mejor que le puede pasar al flujo, ya que lo equilibra y lo hace más predecible. En caso de un PI este tiempo proporciona suficiente margen de capacidad para permitir la cadencia. En otras palabras, para que el tren esté optimizado a veces es necesario que alguna de sus partes esté suboptimizada. Si pretendemos llenar de trabajo al 100% cada hueco de tiempo sobrante aparecerán bloqueos y cuellos de botella que penalizarán fuertemente al flujo; incorporar nuevo trabajo puede hacer descarrilar el tren.

Lo que propone Lean es utilizar este tiempo sobrante como herramienta para aumentar la eficiencia de equipos y tren, y mejorar los procesos subyacentes. Ese es justamente una de las intenciones en la parte de innovación propuesta en la iteración IP. Por tanto la respuesta es "no", por mucha tentación de incluir más trabajo que pueda haber.

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