lunes, 19 de septiembre de 2016

¿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

jueves, 15 de septiembre de 2016

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

viernes, 9 de septiembre de 2016

¿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 AgilidadOs 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.

miércoles, 7 de septiembre de 2016

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