¿Cómo leer un CFD, un diagrama de flujo acumulado?

Ejemplo de CFD con un flujo mínimo, el clásico de Scrum

Uno de los instrumentos más potentes de Kanban que nos permite hacer una lectura rápida sobre como de fluido es nuestro flujo de trabajo y de tomar decisiones a favor del flujo, es el Diagrama de Flujo Acumulado, o CFD (Cumulative Flow Diagram).

Recordemos que en Agilidad de lo que se trata es de hacer todas las acciones posibles para mejorar y optimizar el flujo, reduciendo los tiempos de ciclo y acercando los tiempos de entrega a estos. Tal como dice Donald G.Reinertsen en su libro "The Principles of Product Development Flow" hemos de poner el foco en reducir los tamaños de los batches y de las colas. Como jefes de proyecto hemos de desaprender a gestionar líneas de tiempo y aprender a controlar colas con batches cortos, lo que nos llevará automáticamente a tener control sobre nuestras líneas de tiempo.

En la figura, que se basa en un scrumboard, vemos los cuatro elementos básicos que podemos leer (si hubiera más estados cada uno de ellos tendría un WIP y un tiempo de ciclo asociados):

• Backlog (pila de entrada): nos muestra el tamaño de trabajos o peticiones en cola, en el caso de nuestro ejemplo la pila es una cola grande.
• Lead Time (tiempo de entrega): el tiempo que tarda un trabajo desde el momento en que nuestro cliente lo deposita hasta que lo acabamos y lo entregamos. En nuestro ejemplo es el tiempo desde ToDo a Done, que en el ejemplo resulta en un tiempo largo.
• WIP (trabajo en curso): nos muestra el tamaño de los trabajos en curso o batch, en este caso se trata de un batch corto.
• Cycle Time (tiempo de ciclo o servicio): el tiempo desde que el equipo empieza a trabajar en el ítem hasta que lo entrega, en el ejemplo es un tiempo relativamente corto.

Podemos ver claramente una relación directa entre colas, batches y tiempos. Grandes colas, como la pila de entrada, implican un tiempo de entrega largo. Batches cortos, como el de In Progress, implican tiempos de ciclo cortos.

En el CFD de ejemplo podemos leer que tenemos un buen equipo, capaz de resolver con celeridad los trabajos, pero la cola de trabajos es tan grande que la calidad del servicio percibida por el cliente es pobre. Podemos leer claramente que la cantidad de trabajo y la capacidad del equipo no están ajustadas. El CFD nos dice dónde están los problemas, la solución dependerá de las decisiones y de las acciones de las personas.

A continuación quiero compartir una tabla con acciones recomendadas en función de como se comporte el CFD:

Comportamiento	Motivo	Acción recomendada
Crecimiento backlog	Demanda superior a capacidad	Aumentar capacidad
		Regular demanda
Crecimiento WIP	Aumenta trabajo en paralelo en un estado	Limitar WIP
	Velocidades distintas en estados contiguos	Regular velocidad
		Reubicar capacidad
	Bloqueos por dependencia externa	Eliminar bloqueos o devolver la demanda al upstream
Reducción backlog	Capacidad superior a demanda	Reducir capacidad
		Aumentar demanda
Reducción WIP	Rendimiento en estado superior a la tasa de entrada	Reubicar capacidad
Bandas paralelas	Flujo estable	Trabajar en la reducción del Lead Time

¿Existe algún modelo de evaluación y mejora de la Agilidad organizacional?

Hoy quiero mostrar un nuevo proyecto en el que estamos trabajando en la comunidad Scrum Manager; Scrum Level, un modelo recién sacado del horno que es una guía de ayuda para mejorar la Agilidad de las empresas, tanto a nivel técnico, como de la organización en su conjunto.

---

 Scrum Level analiza y evalúa el nivel de Agilidad en las dos dimensiones:

• Dimensión técnica - flexibilidad: determinada por las técnicas y prácticas de trabajo empleadas
• Dimensión organizativa - fluidez: determinada por los rasgos de personalidad de la organización

---

Para ello Scrum Level analiza los siguientes factores:

• Ejes orgánicos

• Técnicas y prácticas de trabajo

•  Capacitación técnica de las personas

---

Scrum Level sintetiza el conocimiento y la experiencia profesional acumulada a lo largo de su trayectoria profesional por miembros y colaboradores de la comunidad, y lo comparte libremente como marco de referencia para la evaluación y mejora de la gestión ágil.

Podréis encontrar los componentes del protocolo para descargar en la página principal de Scrum Level:

• La guía que describe el qué hay que hacer
• El protocolo que describe cómo hacerlo

Os animo a que visitéis la página, y si tenéis cualquier cuestión en que pueda ayudaros, no dudéis en escribir y comentar en este post. Recordad que las organizaciones ágiles son más eficientes, atraen a los mejores profesionales y entregan valor a sus clientes de forma frecuente y continua.

¿Es la contratación el talón de Aquiles de la Agilidad?

Aquiles de Tesalia

La Agilidad pregona la gestión de entregas de un producto, no la gestión de proyectos. Uno de los mayores desperdicios que delata la Agilidad son los inicios de los proyectos: los costes para encontrar especialistas y liberarlos de posibles posiciones, formarlos en el producto en el que van a trabajar, preparar entornos, generar las conexiones con la gente de negocio del cliente, crear confianza e integración de equipo, etc. Todo eso para deshacerlo y perderlo a final de proyecto… la Agilidad habla de equipos con continuidad, expertos que trabajan de forma continuada y con ritmo sobre un producto mientras este hace que la compañía sea más competitiva y por ende genere más beneficios. Trata sobre la optimización de flujos, de ciclos cortos de entrega de valor continuada y constante adaptación a cambios, que siempre redundan en aumento de valor. 

Pero nuestra realidad empresarial es muy distinta a lo que pregona la Agilidad. Os quiero invitar a leer el artículo "El talón de Aquiles de la Agilidad" de mi compañero Alberto, con el que tenido el honor de coincidir en más de un proyecto ágil. En él habla de la contratación por capacidad, que es un paso de gigante aunque también el talón de Aquiles de la Agilidad. Él, al igual que yo en este blog, va poniendo sus granitos de arena para que la Agilidad y Scrum vayan calando en nuestra cultura TI y vaya llegando a nuestras empresas y compañías.

¿Cómo aplacar conversaciones paralelas en las reuniones?

Rotuladores. material que todo Scrum Master
tiene, como herramientas de gestión
de conversaciones paralelas o cruzadas

Estamos en reunión de planificación de sprint, o en una reunión de refinamiento o en un User Story Mapping, somos alrededor de una docena de asistentes y una y otra vez se producen conversaciones en paralelo o cruzadas. El hecho de que las conversaciones sean acaloradas y vivas es muy positivo, significa que hay conexión entre los asistentes y se está intercambiando conocimiento, pero si esto ocurre con conversaciones paralelas su potencia se reduce drásticamente ya que invariablemente nos estamos perdiendo aquello que se está tratando en la conversación de la que no participamos.

Mi idea inicial fue introducir un rotulador verde como testigo: quién tuviera el testigo tenía la palabra, pero pronto nos dimos cuenta que es mejor utilizarlo como testigo del tema sobre el que se está conversando, el tema que había iniciado la persona que lo sostiene.

Mejoró mucho la situación, pero las conversaciones cruzadas seguían produciéndose. Un compañero, Vicente, tuvo la genial idea de introducir rotuladores de penalización: quién recibiera un rotulador negro tendría que estar callado durante 1 minuto. :-)

Puse 4 rotuladores negros en el medio de la mesa y expliqué que quien hablara fuera de turno recibiría uno, y que quiénes debían de penalizar eran los propios asistentes. Pronto hubo más de uno con un rotulador negro, lo que produjo risas, broma y mucho team-building. Al cabo de media hora ya no hicieron falta los rotuladores, el equipo se había alineado con la necesidad de una reunión con un solo hilo conductor. Una vez más la autoorganización mostró su potencia.

¿Cómo mantener la motivación de los miembros de los diversos equipos de la compañía?

Cartas Moving Motivators con las motivaciones intrínsecas

Recordando el quinto principio del Manifiesto Ágil este habla de la importancia de personas motivadas:

Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea

¿Pero cómo hacer que nuestros empleados estén motivados? Así en frío y pensando en nuestra cultura empresarial parece algo que entraña cierta dificultad.

Pensemos en como nos sentimos cuando nos incorporamos en una compañía nueva: si todo es correcto y cuando el salario nos permite no preocuparnos del dinero para nuestras necesidades cotidianas, las personas nos sentimos motivadas con los nuevos retos que nos esperan y sentimos ilusión por una nueva etapa en nuestra vida profesional. Por tanto el punto de partida es excelente, las personas cuando nos incorporamos a una compañía venimos motivadas de per se, lo único de lo que hay que hacer mantener la motivación.

La motivación más fuerte es la motivación intrínseca, la que ocurre cuando nuestro ambiente profesional permite desarrollar nuestro trabajo de forma correcta, bien hecha y con el sentimiento de que aportamos. Fijémonos en los bloggers que irradian su conocimiento, en los ingenieros de TI que participan en proyectos open-source como Linux, en los moderadores de foros y muchos otros que de forma gratuita aportan al mundo o a comunidades de práctica o de intereses comunes... y lo hacen gratis, y lo hacen por la mayor de las motivaciones, la de aportar con un trabajo bien hecho.

Scrum propicia el desarrollo de personas motivadas, esto ocurre por ejemplo cuando un equipo planifica el próximo sprint, y basándose en las mediciones de su velocidad media decide dónde poner el corte en la pila de producto. Recordemos que Scrum prohibe romper sprints, por tanto el espacio para la construcción de sprints se ajusta a la capacidad del equipo y no varía, una situación correcta de principio a fin. En la revisión del sprint, cuando los interesados ven y dan feedback sobre el incremento construido, es cuando el equipo siente que aporta, y cuando el Propietario del Producto comprueba el trabajo de forma objetiva mediante los criterios de aceptación, se produce un reconocimiento implícito, todos ellos elementos motivadores aportados por las prácticas de Scrum.

Por un lado Scrum propicia personas motivadas y por otro Scrum Masters, coaches ágiles y líderes ágiles deben de interesarse activamente por el desarrollo de las personas que integran los equipos de la compañía. Para perfilar lo que motiva a nuestros compañeros de trabajo, Jurgen Apello ha concebido la baraja de cartas con los Moving Motivators que presento en este post. Esta baraja se basa en los diez deseos intrínsecos que derivan de las obras de Daniel Pink, Steven Reiss, y Edward Deci.

Para averiguar qué factores de motivación son importantes para una persona el ejercicio consiste en colocar las cartas en el orden de importancia de izquierda (menos importante) a derecha (lo más importante). A partir de estos factores podemos mantener la motivación de nuestros empleados colocandolos en el lugar más adecuado, darles las herramientas y los retos correspondientes... entre las tareas del coach ágil está la de crear conexiones entre las personas y ser catalizador para que estas vayan siendo motivadas y desarrolladas cada una según sus factores de motivación.

Los factores de motivación también pueden ayudarnos en la contratación de un nuevo miembro del equipo, sabiendo lo que motiva a una persona podemos conocer su perfil y tomar una mejor decisión. Para un perfil ágil tipo T una buena incorporación podría ser alguien que diera más importancia a las relaciones, la curiosidad, la libertad, la meta...

Juego completo de cartas Moving Motivators de Managment 3.0

Ah, y algo más, la felicidad no es incompatible con la productividad... más bien al revés :-)

¿Cuáles son las interacciones principales entre los roles de Scrum?

Interacciones entre roles - cortesía de José

Como ya sabemos los roles de Scrum son cuatro: Scrum Master, Propietario del Producto, equipo de desarrollo e interesados, pero ¿cómo interaccionan entre si?

1- Aunque no se trate de una interacción en si, el guiado por valor de negocio, poniendo el foco principal en los resultados empresariales, en otras palabras que la compañía venda más pensando a largo plazo, es el objetivo que debe de subyacer a todas las interacciones.

2- El equipo de desarrollo interacciona en dos momentos clave con el Propietario del Producto; la reunión de planificación de sprint, donde debe de comprender libre de dudas el "qué" ha de construir y decidir "cómo" lo va a hacer, y en la reunión de revisión de sprint, donde debe de entregar a los interesados un incremento con quality built-in, en otras palabras en Scrum la calidad no es una variable y la velocidad es la medición de capacidad el equipo construyendo siempre con calidad.

3- El Propietario del Producto es el responsable de explicar en la reunión de planificación de sprint de manera clara y concisa el "qué" ha de construir el equipo de desarrollo, basándose en la conversación sobre historias de usuario de calidad y apoyándose en todo tipo de documentos, diseños, prototipos y artefactos que le puedan ayudar.

4- Scrum sólo funciona con equipos pequeños que permitan a los miembros estar conectados e integrados como una unidad, es tarea del Scrum Master velar por y acompañar al equipo para que estén formados y desarrollen la autoorganización y multifuncionalidad en toda su magnitud.

5- El Propietario del Producto no está solo, forma equipo de negocio con los compañeros de su área (analistas de negocio) para el que se está construyendo el producto. Por tanto está apoyado por y es el representante de este equipo de negocio, y deben de existir todas las interacciones necesarias (reuniones, simulaciones, talleres, ...) para buenas tomas de decisión para una construcción guiada por valor de negocio. Por otro lado es responsabilidad del Propietario del Producto hacer la correcta gestión de interesados del proyecto/producto.

6- La parte crucial de la participación de los interesados está en su feedback continuo, feedback al Propietario del Producto para incluir o refinar elementos de la pila de producto, y feedback en uno de los puntos de clave de Scrum, feedback sobre el incremento entregado en la reunión de revisión de sprint.

7- La tarea por excelencia del Scrum Master es interactuar con todos y acompañarles en la correcta aplicación del marco de Scrum, sus valores y principios, y garantizar un correcto guiado por valor de negocio.

¿Existe algún ejemplo de elementos funcionales de las diferentes pilas del marco SAFe®?

Dispositivos Responsive - cortesía de Freepik

Recientemente en una charla sobre SAFe® mi compañero José preguntó si existían ejemplos para los diferentes elementos de los backlog de SAFe. Estuvimos buscando ejemplos en la web pero no encontramos ninguno que recorriera todas las pilas. Con este post me aventuro a dar ejemplos alrededor de un proyecto de conversión de una web a responsive.

Recordemos que en SAFe hay cuatro niveles de pilas que comprenden el modelo: la pila de la cartera (Portfolio Backlog) que contiene epics y que emergen de temas estratégicos, la pila de la solución (Solution Backlog) que contiene capacidades, la pila de programa (Program Backlog) que contiene funcionalidades y la pila de equipo (Team Backlog) que contiene historias de usuario, pila que finalmente se descompone en tareas en una quinta pila, la pila de iteración (sprint).

Las pilas de SAFe - diapositiva de SAFe 4.0 in 8 Pictures

Temas estratégicos (Strategic Themes)

Los temas estratégicos son los objetivos de negocio que proporcionan diferenciación estratégica y que afectan a una solución de cartera particular, el tema estratégico en nuestro ejemplo sería:

Captar y conectar con una clientela más joven

Epics

Los epics son los elementos de negocio más grandes que capturan las mayores iniciativas transversales que se producen dentro de la cartera y que tratan temas estratégicos, estas entregan directamente valor de negocio y cruzan múltiples flujos de valor y trenes (ARTs). Los epics se escriben basados en el patrón para la visión de producto, nuestro epic de ejemplo sería:

PARA nuestra comunidad de clientes más joven

QUIEN entra a nuestra web a través de múltiples dispositivos

EL proyecto responsive

QUE ES UNA nueva visión de la comunicación, clave en la transformación digital

QUE permite que se adapten los formatos y contenidos tradicionales

para responder a las nuevas necesidades de los dispositivos de nuestros clientes

A DIFERENCIA DE nuestros competidores, cuyas webs

están diseñadas y concebidas para acceder a través de ordenadores de sobremesa

NUESTRO PRODUCTO estará dotado de la tecnología necesaria

para dar una experiencia de usuario con un nivel de escalado y personalización nunca vistos

Capacidades (Capabilities) y Funcionalidades (Features)

Dada la luz verde para la implementación de un epic, este se descompone en el nivel correspondiente (value stream o programa) en funcionalidades o capacidades. Las funcionalidades son un servicio proporcionado por el sistema que satisface alguna necesidad de los interesados. Las capacidades son similares a las funcionalidades, describen comportamientos de soluciones de nivel superior y a menudo requieren múltiples trenes (ARTs) para su construcción. Estas se escriben utilizando la matriz de Features and Benefits (FAB):

Ejemplo de capacidad:

CAPABILITY: homepage con diseño responsive
BENEFIT: una página principal atractiva y adaptable a diferentes dispositivos para ofrecer la mejor experiencia de navegación a nuestros usuarios
DESCRIPTION: debe de tener un menú desplegable y adaptable, un banner central, una zona central para contenido corporativo y un pie con links a contacto, nuestras apps y a las redes sociales

Ejemplo de funcionalidad:

FEATURE: menú flexible
BENEFIT: un menú desplegable y adaptable a diferentes dispositivo que facilite la navegación y permita dejar más espacio para el contenido
DESCRIPTION: menú hamburguesa en que los elementos del mismo estén ocultos, liberando así espacio para el contenido, y mostrándolos al interaccionar con él, de forma horizontal u vertical según la resolución del dispositivo

Historias (Stories)

Las historias de usuario son una descripción breve de una funcionalidad contada desde la perspectiva del usuario y escrita en el lenguaje común del usuario, y que son resultado de descomposición de las funcionalidades por parte del equipo. Para formularlas se utiliza en patrón de Cohn, tal como describimos en el siguiente ejemplo:

COMO cliente registrado

QUIERO poder seleccionar la opción para ver artículos en el menú principal

PARA PODER leer los diferentes artículos disponibles en la web

Tareas (Tasks)

Las tareas definen los trabajos o actividades necesarias para llevar a cabo la construcción de una historia, ejemplos de tareas serían:

• Maquetación menú versión escritorio
• Maquetación menú versión móvil/tablet
• Incluir las funcionalidades de Bootstrap (CSS base) en el tema
• Codificación del menú
• Comprobación del comportamiento del menú

Mis agradecimientos a Rivera, un compañero especialista en responsive que ha revisado los ejemplos desde la perspectiva responsive, gracias ;-)

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