visualización

¿Qué es la Facilitación Gráfica?

Esto va mas allá de la visión que tienen muchas personas de que se trata de hacer dibujitos con notas para toda la sala o grupo. Vamos a romper algunos mitos como pasa con Scrum o Kanban, en torno a esto de la facilitación gráfica.

Aunque mi base es artística y te pueda explicar algunos temas con mayor profundidad, no es necesario tener conocimientos de este tipo para utilizarlo. No necesitas saber dibujar bien para aprender facilitación gráfica. Si sabes dibujar círculos, cuadrados y flechas, tienes todo lo que necesitas.

Una buena base

Su mismo nombre te explica lo que es. Una ayuda visual para entender o comprender un concepto más allá de una definición. Para el ser humano es otra herramienta más a nuestra disposición para mejorar la comunicación entre grupos de personas.

Hace unos meses te contaba un punto interesante sobre los radiadores de información y lo necesarios que son en muchos sitios en nuestro día a día. La facilitación gráfica es como se llama al proceso de crearlos. Aunque está asociado más al facilitador que lo esquematiza en directo en una sesión o evento, hay mas roles que la usan.

Una buena base sobre ello puede conseguir que seamos capaces de comunicaros con mayor fluidez y menos esfuerzo.

En lo que te puede ayudar

Una de las preguntas más repetidas es ¿Para qué sirve?. Seguro que has asistido a algún evento o una reunión de un grupo de gente en el que alguien facilitaba. Puedes imaginarte la misma situación sin esa persona y hacerte algunas preguntas:

¿Habríamos entendido todos lo mismo sin hacerlo visible?
¿Habríamos estado pendientes de lo que se hacía en todo momento?
¿Habríamos debatido acerca de a que nos referimos con uno u otro concepto?

Cuando hay facilitación gráfica, todo esto ocurre en mayor o menor medida. Además de la ayuda a la memoria que nos proporciona algo visual.

Aprender haciendo…

Me alegra muchísimo anunciar que abrimos puertas a un taller de iniciación para los interesados en facilitación gráfica. Podrás leer algo más de información sobre el taller en sí en su página y buscar fechas disponibles en nuestro calendario.

Queremos ofrecer formación de calidad, por ello, saldrás del taller con el material básico para facilitar gráficamente y tu propio cuaderno de referencias. También hablaremos de prácticas y herramientas que van a ayudarte a mejorar al ritmo que lo necesites. Y todo va acompañado de ejercicios muy prácticos para afianzar todo lo que vayamos viendo.

Me gustaría animarte contándote, que los primeros en hacer el taller han sido mis compañeros Alberto, Nacho y Jero. Podéis leer parte de su feedback en la página del taller. Hace un par de semanas del taller y si habéis coincidido con ellos en estos días, habréis visto que se lanzan a hacer flipcharts con mucha soltura.

4 maneras de beneficiarte de Kanban y Scrum juntos

La semana pasada publiqué un artículo un tanto indendiario que ha suscitado dudas entre mis alumnos de esta semana. Hoy voy a intentar introducir la mejor manera de usar Kanban en equipos Scrum.

En primer lugar, explicar que para este artículo me voy a centrar en Kanban, tal y cómo está originalmente concebido, no en el método Kanban. Para ello, voy a basarme en la guía que publicamos hace unos meses en Scrum.org: “Professional Scrum with Kanban“.

Amplificando Scrum, no modificándolo

Kanban, tal y como lo definimos en la guía, es una estrategia para maximizar el flujo de valor hacia los stakeholders a través de un proceso visual que utiliza un sistema pull con una limitación del trabajo en curso (WIP).

Scrum sigue aplicando en su totalidad. Lo que hacemos es añadir un sistema visual para gestionar el trabajo, limitar el trabajo en curso para crear un sistema que balancea demanda y capacidad, y por último, gestionamos el trabajo dentro de ese sistema.

Utilizamos cuatro prácticas:

Visualización del flujo de trabajo
Limitar el WIP.
Gestión activa del trabajo en curso.
Inspección y adaptación de la definición de Workflow.

Empecemos por el final

Definición de Workflow

Optimizar el flujo de trabajo requiere que tengamos uno. Por eso es importante que el equipo Scrum determine cual es su workflow y eso requiere de los siguientes elementos:

Puntos definidos entre los cuales se inicia y se completa el trabajo, potencialmente con estados intermedios de completado del trabajo.
Una definición de cuales son las unidades de trabajo que fluyen por ese sistema que aportan valor al cliente, que pueden ser Product Backlog Ítems
Una definición de los estados intermedios por los cuales fluye el trabajo, de los cuales al menos uno debe ser un estado activo de trabajo
Políticas explícitas sobre como fluyen el trabajo a través de los estados (que pueden incluir contenido de la Definition of Done)
Una definición de como se va a limitar el trabajo en curso
Una determinación de expectative de nivel de servicio fijada (Service Level Expectation, SLE) que comunique una previsión de cuanto se debería esperar para ver trabajo completado.

Puede que los estados definidos en el flujo no coincidan con los estados definidos en el Sprint Backlog. Aunque pueda ser ventajoso que sean iguales, no necesariamente tienen que gestionar. La definición de Workflow no sustituye al Sprint Backlog.

En la práctica, esto es muy similar a lo que ya vienen haciendo muchos equipos Scrum: Utilizar Kanban con limitación de WIP para mejorar el foco y de esa manera optimizar el flujo de valor hacia los clientes. Lo mejor es cuando además lo podemos combinar con métricas de flujo que potencialmente pueden llegar a eliminar la necesidad de estimaciones.

Métricas básicas de Flow

Una vez que tenemos un sistema pull, es muy sencillo obtener métricas de flow que ayuden tanto a mejorar la previsibilidad, como a incrementar la capacidad de foco y maximizar el valor ofrecido al cliente. Las cuatro métricas básicas que un equipo que utilice Scrum con Kanban debería medir son:

WIP: El número de elementos que hemos empezado pero no hemos terminado (de acuerdo a la definición de “Workflow” del equipo Scrum)
Cycle time: El tiempo que pasa entre que un elemento empieza y acaba.
Work Item Age: El tiempo que ha pasado entre que empezó un elemento y el momento actual.
Throughput: El número de elementos terminados por unidad de tiempo. Esta medida es una cuenta exacta mientras que las dos anteriores no tienen por qué serlo.

Eventos de Scrum basados en Flow

Una vez que tenemos una definición de workflow con sus elementos y las métricas básicas, entonces podemos empezar a utilizarlos como artefactos de transparencia dentro del equipo Scrum, lo que finalmente conlleva a mejorar el flujo de valor hacia el cliente.

Me dejo la descripción de los eventos para otra semana.

De gestionar personas a gestionar trabajo

Hace unos meses, mi amigo Pedro Ángel Serrano me escribió un correo para preguntarme si había probado Overcooked para Switch. Me decía que le había recordado a lo que vemos en el KSD y el KMP y que refleja muy bien como se originan los cuellos de botellas y se fomenta la colaboración.

Raudo y veloz, hace un par de semanas me lo descargué y me puse a disfrutar de él con mi mujer. Y no podría estar más de acuerdo con Pedro. Overcooked es un juego colaborativo muy sencillo orientado a preparar menús dentro de una historia apocalíptica. Cada nuevo nivel introduce nuecas recetas y retos para poder pasar al siguiente.

Aunque el juego se mueve dentro del dominio de lo complicado y no de lo complejo, es una buena introducción a la organización del trabajo. Después de dos o tres rondas jugando, quedó claro que cada uno de nosotros debíamos de hacernos cargo de una parte de la preparación de los menús y colaborar para darles el toque final (la entrega) o el lavado de los platos.

En Kanban gestionamos trabajo, no personas

He visto a varias personas jugar al juego y veo que intuitivamente tienden a intentar terminar trabajo en lugar de empezarlo (uno de los lemas del método Kanban). Sin embargo, ¿Cual es el problema cuando lo llevamos a un escenario real?

El problema es cultural. Como tradicionalmente el trabajo no sale adelante, tendemos a pensar que es una cuestión de organización o inlcuso de vagancia, así que intentamos controlar el trabajo de las personas, pasando de facto a controlarlas a ellas en lugar de controlar el trabajo.

Uno de los motivos intuitivos es que tendemos a juzgarnos a nosotros por nuestras intenciones y a los demás por sus acciones. Si observamos la portada del libro azul de Kanban, ¿Que nos sugeriría que está pasando si no existiera el tablero detrás de los protagonistas?

En efecto, la falta de información sobre lo que realmente está ocurriendo y que nos aporta el tablero Kanban que hay tras ellos, dejaría toda esta situación en una mera discusión de oficina. La gente no trabaja lo suficiente.

Y así hemos desarrollado unos sistemas muy sofísticados de control de personal. Desde horas trabjadas hasta la gestión de proyecto, los hitos, las propuestas y los comités de revisión. Y sin embargo, ninguna de estas herramientas consigue mejorar nuestra tasa de finalización del trabajo. ¿Por qué? Porque el problema no reside en controlar a las personas.

Para algunas organizaciones, el disponer de métricas directas e indirectas sobre lo que está ocurriendo en las trincheras es solamente un sueño. Así pues, se centran en la productividad, entendiendo productividad como maximizar el número de horas que una persona trabaja.

Cuando algunos alumnos o personas en las organizaciones con las que trabajamos ven Kanban por primera vez, inevitablemente piensan en un nuevo método de microgestión de personas. Y es todo lo contrario.

Sin embargo, ¿Cómo crear el entorno para entender esto?

Protokanban, creando la cultura y evitando la fricción

Protokanban es una herramienta que nos ayuda en este sentido. Sin llegar a limitar el WIP, que sin duda es el paso más difícil en la implementación de cualquier sistema Kanban, nos ayuda a ir cambiando ese prisma de ¿Qué hacen las personas? a ¿Cómo va el trabajo?.

Es un proceso lento que requiere de cierta técnica, en el que al final nos espera el poder empezar a introducir límites WIP y mejorar nuestra capacidad de entregar trabajo, nuestra calidad y la satisfacción de clientes y compañeros.

Además, permite evitar la fricción de introducir un WIP hasta el último momento responsable, que en el caso de Protokanban, es cuando ya contamos con un flujo claro de trabajo y una visualización del mismo.

Si quieres saber más, mi compañero Nacho publicó un artículo introduciendo Protokanban y sus beneficios. También puedes leer nuestra guía del método kanban en el blog.

El primer tablero Kanban del equipo

Desde la experiencia con varios equipos, hoy me gustaría hablarte de la evolución de un tablero Kanban concreto. Es cierto que las decisiones de unos equipos a otros no se parecen, ni las necesidades o su trabajo. Pero he vivido una serie de momentos que se repiten en el tiempo. Algo así como El día de la marmota para un Agilista

Podríamos llamarlo “los primeros escalones” cuando un equipo empieza a usar cualquier metodología, marco de trabajo o mentalidad Agile. Y el tablero es una de las herramientas más valiosas como comentaba en mi artículo anterior.

De menos a más

Todos empiezan con algo muy sencillo, normalmente por consejo del Scrum Master o el Agile Coach que les esté acompañando. Entonces, lo primero será visualizar el flujo de trabajo del equipo en cuestión. El equipo prepara un tablero y te enseña esto:

Ahora es cuando te toca hacer preguntas. ¿Solo tenéis 3 pasos en vuestro flujo?¿Quién pone esas tarjetas ahí?¿tienen orden alguno o prioridad?… pero voy a hablar de la primera para empezar.

Visualiza tu workflow o flujo de trabajo

Al principio los miembros de un equipo tienen oxidado este tipo de análisis. Porque no suelen analizar como trabajan, sino el trabajo en sí. Así que, a ti, que estás intentando ayudarles a crear un tablero Kanban útil, te costará muchas preguntas, algunos momentos incómodos, un poco de presión y mucha paciencia.

Tras una buena charla con todos los miembros del equipo, incluyendo siempre al Product Owner o Manager que tiene visión de negocio, se han añadido nuevas columnas. Ahora en algunos de los miembros del equipo puedes ver cierto brillo en los ojos, ¡incluso alguna sonrisa!. Esto se debe a que han tratado temas que les suelen doler, porque se atascan, donde no tienen mucho poder y ahora es visible. Así que el equipo trae esto:

Evitemos el caos

Ahora sabemos que hay más pasos en el flujo de trabajo. Pasos que son importantes porque se toman decisiones que no son solo técnicas, sino de negocio.

Al final muchos equipos deciden meter una columna de “Test” para la comprobación de que todo está como debería, pero pocas veces se trata de un test técnico. Es algo que al principio me sorprendía, ahora ya se que es uno de esos “primeros pasos”. Duele menos llamar así a la comprobación del Manager o el PO de que ese item es lo que ellos habían pedido.

Añadir WIP limits al tablero kanban

Como puedes observar, en el segundo tablero, hay mas columnas con el mismo número de tarjetas. Y casi todas las subtareas técnicas están en la columna “test” provocando de esta manera, un pequeño embudo que acumula tareas sin terminar. Por otro lado, todas las subtareas ya están en proceso o en test, pero algunas no se están avanzando. Toca sesión de preguntas incómodas de nuevo. ¿Esto es real? ¿se está trabajando en todas y cada una de las subtareas?

Si queremos que el tablero kanban sirva para algo y nos haga mejorar, hay que cambiar de mentalidad. Kanban nos ayuda a trabajar con una mentalidad pull y evitar el empezar mucho y acabar poco.

Hace unos días, mi compañero Nacho Navarro publicó un post interesante que te recomiendo acerca de elegir los WIP limit. Básicamente un WIP limit es un límite del trabajo activo que puede existir. Se puede limitar por columnas, por personas, el sistema completo, etc.. Por ejemplo, un equipo con 3 desarrolladores podrían decidir que no hubiera más de 3 tareas en curso en la columna “doing” a la vez. De esta forma nos asegurarnos de que creamos un sistema pull real.

Gestión del flujo de trabajo

Es importante que el mensaje de la mentalidad pull haya calado. En este tablero mejorado vimos muchos cambios:

Priorización de los elementos y sus tareas.
Orden para terminar más trabajo que antes.
Problemas de estancamiento o embudos.
Posibles necesidades de mejora para el tablero del equipo.
Métricas. Ahora podemos medir cuánto tardamos en entregar algo.

Políticas explícitas para usar bien el tablero

Esta vez, y solo para evitar tentaciones, hay que añadir las reglas del juego. Si queremos que esto funcione de verdad, necesitamos ser legales. Nada de decir que una tarea está “casi hecha” en la columna de “Done”.

Estas son una serie de requisitos que una subtarea debe cumplir si queremos pasarla a la siguiente columna. Si no los cumple, no está lista para pasar a la siguiente columna. Del mismo modo que si la columna siguiente tiene el WIP limit ocupado, tampoco puede pasar aunque las políticas se cumplan.

Esto nos ayuda a funcionar mejor con el sistema pull de Kanban. Así nos centramos en acabar el trabajo ya empezando en lugar de empezar otra tarea nueva. El equipo entendió que era necesario poner unas políticas explícitas en cada columna de paso. Así se aseguraban un mínimo en la nueva columna. El tablero quedó así:

Mejora continua de verdad

El último paso también es muy importante, ya que nos permite ir viendo estas evoluciones a lo largo del tiempo y los proyectos. Un ejemplo de ello es que en este último cambio, también añadieron algunas clases de servicios con diferentes colores en las tarjetas. Así se aseguraban que si alguna tenía fecha fija o era prioritaria, la vieran antes. Es necesario tomarse un tiempo de reflexión de todo el equipo en conjunto para tratar posibles mejoras.

Por supuesto esto es una versión reducida de un sistema que se puede complicar todo lo que necesitemos. Para ello podéis pasaros a leer la guía de Kanban que tenemos en la web, que es muy completa.

Espero que te sirva de inspiración este pequeño resumen en base a mi experiencia. En próximos post escribiré otros ejemplos, hablaremos de las tarjetas Kanban y de posibilidades dentro de un tablero kanban.