Nacho Navarro

Cómo elegir un buen WIP Limit

El agilismo es una mentalidad, una manera de entender el desarrollo de software que cuando te sumerges te va salpicando poco a poco en muchos aspectos de la vida.

Cuando comenzaba en esto de las formaciones uno de los principios ágiles por los que pasaba rápidamente por encima era:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Cuando estuve ayudando a nuestros amigos de Product Hackers me tocó ponerme el gorro de Product Owner y este principio al que no le daba mucha importancia… se convirtió en mi preferido. Sólo en el momento en el que todas las piezas encajaron a nivel equipo, empresa, cliente, etc… y conseguimos un entorno de desarrollo sostenible y constante, empezamos a entregar valor de verdad y satisfacer las necesidades prioritarias de nuestros clientes una y otra vez creando una relación de confianza que nos permitió alcanzar grandes éxitos.

Wip limit: Creando el espacio

Una vez me hicieron la pregunta: “Si tenemos una capacidad máxima de delivery, ¿cómo que no limitamos la capacidad de entrada?”

Más o menos me quedé así:

Y es que…. ¿sirve de algo meter más trabajo del que va a salir en un sistema? Si tengo una depuradora de agua en mi piscina… ¿le intentaría meter más agua de la que es capaz de depurar para intentar depurar más? Si lo que quiero es pagar una gran factura de reparación y una mirada incrédula de un técnico de depuradora… entonces puede que sí.

Y es que limitar el WIP es precisamente lo que nos permite que nuestro sistema sea estable y constante en el tiempo. Es como una tubería donde solo entra caudal si sale.

WIP limit: La palanca magica

Hubo un señor que demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. Ahora estaréis pensando…¿y por qué me cuestas esta gran anécdota Nacho? Pues porque este señor se llamaba Little, y esta es la ley de Little y es la base de Kanban:

Como vemos, el WIP es la relación entre el lead time y el throughput rate o delivery rate. También podemos ver como afecta el WIP al lead time mirando un CFD (Cumulative Flow Diagram):

¿Cómo elegir mi WIP Limit?

La relación entre cuanto menos WIP menos lead time está clara con la ley de little o el CFD. Así que alguien puede pensar… ¡pues pongo 1 de WIP limit! Eso nos deja la paradoja del One piece flow dónde te aseguras que cuando una tarea entra en el sistema sale muy rápido, pero tu delivery rate se verá afectado y será muy bajo. ¿Esto es malo? ¿esto es bueno? Pues ni bueno… ni malo… en algunos entornos necesitarán un tiempo de respuesta muy rápido y no les importará tanto la tasa de entrega y en otros entornos necesitarán un equilibrio mayor.

En una de mis vidas pasadas colaboraba con un cliente muy tradicional dónde había una pequeña galia trabajando con Kanban y funcionando muy bien. Ellos querían poner en producción al menos una vez a la semana. Pero esta empresa solo permitía subir una vez al mes. En esta situación…. ¿un lead time de 1 o 2 días me ayuda? ¿O puedo pensar en abrir un poco el WIP, aumentar un poco el lead time, pero subir el delivery rate? La capacidad de absorción de nuestros clientes es un factor a tener en cuenta también.

Creo que este vídeo explica muy bien como puede ser una búsqueda de el WIP deseado (Nota: en el vídeo se habla de cycle time que es el tiempo que está la tarea desarrollándose. El Lead Time es el tiempo desde que me comprometo hasta que lo entrego. Como es de suponer, están estrechamente relacionados)

En definitiva, hay que encontrar un equilibrio entre el Lead Time y el Delivery Rate.

¿Cómo elijo mi primer WIP limit?

¿Cómo elijo ese primer WIP limit que mediré, inspeccionaré y adaptaré si aún no tengo métricas?. El primer WIP limit habrá que elegirlo según la experiencia de los miembros del equipo o con consejo externo. Lo importante es tener una mentalidad empírica para inspeccionar y adaptar así que tampoco me volvería loco eligiéndolo.

Una frase que a mi me sirvió: “El WIP limit debe doler”. Es una restricción. Muchas veces los equipos tienen a pensar… si somos 4… y cada uno puede con 2 o 3 cosas a la vez… ¡pues pongamos 10! Como ya he dicho antes este número no está ni bien ni mal. Habrá que medir, inspeccionar y adaptar si hace falta. Pero una primera elección que nos duela suele resultar más acertada la mayoría de las veces. Como probar uno por persona en todo el sistema. Pero como vimos antes, cada entorno es un mundo y persigue diferentes métricas.

¿Qué pasa si cambio el WIP limit?

Imaginemos que quieres bajar el Lead Time porque quieres ganar predictibilidad y poder asegurar un SLA más bajo. En ese momento decidís bajar el WIP limit. Ahora te tocará esperar a que el sistema se vacíe para ver como funciona. Es como si tienes una cisterna de 5 litros y la cambias a una de 3. No podrás ver como se comporta el nuevo sistema hasta que se vacíe y se llene de nuevo. Es un proceso que pasará de forma natural y no requiere ningún esfuerzo extra que no sea respetar vuestras reglas y paciencia.

Conclusiones

Limitar el WIP es un arma muy poderosa para crear un entorno sostenible. Siempre es difícil elegir el primer WIP, pero hay que acordarse de que:

Se puede cambiar en cualquier momento. Siempre que se esté persiguiendo la mejora del sistema y no una auto-trampa para eliminar una restricción que nos molesta.
Hay que tener en cuenta la capacidad de absorción de nuestros clientes
Es una restricción y como tal, la primera vez que lo estipulamos, es buena señal si nos duele.
Hay que mirar (al menos) nuestras métricas de Lead Time y de Throughput para ir equilibrando entre ellas cambiando nuestro WIP si fuera necesario.
Una vez cambiado el WIP Limit, el impacto no es inmediato.

Flujo downstream: Cómo ir más allá de Proto-Kanban

https://jeronimopalacios.com/kanban/Este es el segundo artículo de una serie dedicada a la introducción de Lean Kanban en organizaciones. Si no lo has hecho ya, es recomendable empezar leyendo Proto-Kanban: Qué es y sus beneficios donde hablé sobre como la visualización y una mentalidad pull podían ayudar a un equipo que está empezando en esto de Kanban.

¿Como ir más allá de Proto-Kanban?

Con Proto-Kanban hemos empezado a tener una mejor visualización de nuestro sistema y estamos empezando a gestionar trabajo y no personas. Pero aún estamos lejos de tener un flujo de trabajo real. ¿Cómo continuar?

Nuestra mentalidad pull nos ha ayudado a mejorar el lead time y la tasa de entrega. Pero esto no es suficiente. En nuestras formaciones vemos una y otra vez que existe una gran tendencia a hacernos auto-push y cuando la demanda crece, tenemos elementos con fecha fijada o urgentes, el acto reflejo es empezar a meter y meter trabajo en nuestro sistema colapsándolo.

Lo único que conseguirá sobrecargar un sistema por encima de su capacidad es tener mucho trabajo empezado y nada terminado. Esto es un desperdicio de tiempo y dinero, aumentará el lead time, disminuirá la capacidad de adaptación de nuestra empresa y de entregar a sus clientes lo que necesitan cuando lo necesitan.

Para crear un sistema pull completo vamos a utilizar algunas de las prácticas de Lean Kanban:

Limitar el WIP
Políticas explícitas
Clases de servicio
Feedback loops

Limitando el WIP (Work in Progress)

Llegó el momento de dar un paso más, ir de la mentalidad pull adquirida con Proto-Kanban a un sistema pull con trabajo limitado. Estableciendo WIP limits en nuestro sistema nos aseguramos que esa tentación de auto-push desaparece porque ahora nuestro sistema, sencillamente, no lo admite.

Establecer WIP limits no es más que limitar el trabajo en curso en nuestro sistema. Podemos poner un límite para todo el sistema (no puede haber más de 6 elementos empezados), podemos poner límites por columnas, por persona, podemos combinar todos, etc…

En la imagen podemos ver los WIP limits representados en la cabecera de cada columna por un número rodeado de un círculo.

Esta limitación permitirá al equipo:

Reducir aún más la sensación de sobrecarga
Focalizarse en lo realmente importante en ese momento
Entregar con mayor calidad

Esta calidad bajará drásticamente el número de elementos mal acabados que vuelven a entrar en el sistema (re-work), lo que impactará positivamente en el lead time, en la tasa de entrega y en lo más importante, la satisfacción del cliente.

Además, limitar el WIP nos permitirá crear un sistema sostenible en el tiempo ganando predictibilidad basado en datos y no en estimaciones u opiniones. Lead times medios, cycle times, etc…

En este post hablamos sobre qué hay que tener encuenta para elegir un buen WIP limit.

Haciendo las políticas explícitas

Hemos creado un flujo de trabajo pero… ¿cómo funciona? ¿quién mueve qué? ¿cómo se deciden las prioridades? ¡Las políticas explícitas acuden al rescate!

La selección de políticas debe hacerse por aquellos que son responsables de realizar el trabajo. Las políticas son variadas y de muchos tipos. Pueden existir políticas por columna (quien mueve que, como se deciden las prioridades), políticas para todo el sistema (cuando se hacen replenishments, como se revisan los ítems) o políticas por clase de servicio.

Las políticas deben estar visibles en todo momento. Algo que ayuda a los equipos a hacer explícitas las políticas es pensar que cualquier persona que pase por delante del tablón debe entender perfectamente como funciona el sistema al completo.

Es común en los equipos que están empezando intenten crear políticas nuevas que son más bien buenas intenciones que una política de funcionamiento. Esto desemboca en post-its gigantes con una norma que nadie está cumpliendo, generando frustración y la sensación de que la visualización puede ser algo que no es tan importante mantener. Es fundamental que el equipo entienda que las políticas:

Deben ser escasas
Simples
Estar bien definidas
Visibles
Las políticas no son un deseo, deben aplicarse siempre. Hay que ser realistas e inspeccionar si la estamos usando, si no, por qué no, etc…
Tienen que ser fácilmente modificables

Clases de servicio

Para poder gestionar el flujo correctamente es importante conocer el coste del retraso (cost of delay) de los elementos de trabajo. Debemos saber qué ítems son importantes, urgentes, con una fecha dada, etc… Kanban utiliza cuatro arquetipos para definir como cambia el valor del ítem de trabajo según su coste de retraso:

En la imagen podemos ver como evoluciona el coste del retraso o el impacto según pasa el tiempo.

Urgente: El coste del retraso crece y crece desde el primer día de forma lineal con una gran pendiente. Lo necesito, lo necesito ya y cada minuto cuenta.
Fecha fija: Al principio, el coste de retraso es bajo. Pero a partir de una fecha el coste de retraso es altísimo. Por ejemplo, si te piden una campaña de marketing para el blackfriday.
Estándar: Crece casi de forma lineal y constante en el tiempo. Suelen ser las más comunes en un sistema.
Intangible: Los ítems de clase intangible pueden ser importantes y valiosos, pero no hay costo de retraso tangible asociado con ellos en el futuro cercano.Lo que pasa con los ítems de esta clase es que un día estallan y el coste de retraso se dispara y se comportan como una urgente.

Pero cada sistema es un mundo y por tanto, el equipo debe encontrar las clases de servicio que mejor se ajusten a su sistema. Hay equipos que han llegado a definir una clase de servicio con el nombre de su CEO. Y una política asociada a esta clase de servicio que rezaba: “No empezaremos nunca un ítem de trabajo bajo esta clase de servicio hasta después de una semana”. Este CEO era especialista en pedir cosas muy urgentes y luego… arrepentirse. Como vemos, la combinación de clases de servicio y políticas es muy poderosa y nos permite gestionar perfectamente nuestro flujo.

Hay un comportamiento que nos encontramos muchas veces: “He empezado con este elemento de trabajo por qué me apetecía”. Las clases de servicio, junto a las políticas definidas, nos ayudan a eliminar la subjetividad y la procrastinación a la hora de elegir qué elemento de trabajo comenzar. La elección ahora tiene unas reglas objetivas que todo el equipo conoce, entiende y han establecido de mutuo acuerdo.

Feedback loops

El Agilismo se basa en el empiricismo por lo que no debemos olvidar los procesos de inspección y adaptación. Kanban define hasta siete cadencias con diferentes objetivos. Esto puede provocar rechazo por parte del equipo por la sensación de sobrecarga de reuniones. A nosotros nos da buen resultado empezar con la Daily Kanban y un Replenishment meeting semanal. Poco a poco, los equipos van teniendo necesidades que encajan con los objetivos de las otras cadencias y van sumándolas. Escribiré otro post para tratar exclusivamente de las cadencias.

¿Cómo podemos medir nuestro impacto?

Lo ideal es tener un histórico de métricas del equipo para poder comparar. Pero al menos, con Proto-Kanban ya deberíamos tener:

Lead time medio:Tiempo desde que nos comprometemos a tener una tarea hasta que la entregamos.
Cycle time medio: Tiempo que la tarea está desarrollándose.
Tasa de entrega: Cantidad de ítems entregados en unidad de tiempo.

Es importante medir, al menos, estas tres. A mi me gusta también introducir el customer lead time que es el tiempo desde que un ítem entra en nuestro backlog hasta que se entrega. Al fin y al cabo, al cliente le interesa cuanto tiempo tardas en entregarle la tarea desde que se la pide al equipo.

Nos hemos encontrado empresas con lead times muy bajos y muy orgullosos. Pero luego, cuando indagabas, encontrabas tasas de entregas bajísimas. Habían estado eliminando las tarjetas que llevaban en el sistema mucho tiempo. De esta manera “camuflaban” su lead time real. Pero la tasa de entrega no engañaba. ¿Sirve para algo medir y autoengañarse?

Conclusion

Una vez que tenemos Proto-Kanban funcionando es el momento de introducir más prácticas para crear y gestionar un flujo de trabajo:

Limitar el WIP
Políticas explícitas
Clases de servicio
Feedback loops

Debemos recordar que Kanban se ocupa del diseño, la gestión y la mejora de los sistemas de flujo. Conseguir un sistema estable en el tiempo es solo el primer paso. El equipo debe seguir mejorándolo continuamente por lo que hay que medir, inspeccionar y adaptar.

Si quieres profundizar más puedes leer nuestra guía de Kanban o el Kanban esencial condensado de David J. Anderson y Andy Carmichael

Continuar leyendo: Upstream, flujo de generación de opciones >>

Proto-Kanban: Qué es y sus beneficios.

Me gustaría compartir mi experiencia ayudando a empresas en la adopción de Lean Kanban y arrojar un poco de luz de este proceso. Este es el primero de una serie de posts donde hablaré de:

Proto-Kanban: Qué es y sus beneficios.
Downstream y cómo ir más allá de Proto-Kanban.
Upstream, discovery Kanban o Kanban de descubrimiento.
Cómo encajar al usuario: Upstream, Downstream y Customer Kanban.

Proto-Kanban: Qué es y sus beneficios.

Muchas de las empresas que nos llaman lo hacen con los mismos síntomas:

La desmotivación de los equipos es alta. Se sienten totalmente desbordados, con fechas imposibles y cambios de dirección constantes.
Los representantes de negocio y los clientes internos/externos se sienten frustrados. Las fechas de entrega no se respetan y la calidad de los entregables es muy baja.
El equipo directivo y muchos managers empiezan a pensar que los equipos no están comprometidos o no trabajan lo suficiente.

Tras las primeras conversaciones con el cliente decidimos colaborativamente dónde poner el foco, allí donde podemos aportar más valor. En algunos casos se determina comenzar trabajando en uno o varios equipos implementando Lean Kanban.

Al comenzar el acompañamiento en este nuevo reto, uno de los primeros pasos es facilitar un taller con tres objetivos:

Introducir el método Kanban. Necesitamos mostrarle al equipo una idea de dónde se quiere llegar y explicar la diferencia entre el Método Kanban y tener un simple tablón. Si quieres saber más sobre el Método Kanban puedes leer nuestra guía aquí.
Experimentar y comprender cómo un sistema pull pude ayudar a satisfacer la demanda y eliminar la sensación de sobrecarga.
Explicar el concepto de Proto-Kanban. Llegar a tener un sistema Kanban completo no es algo que se consiga en dos días, y mucho menos en escenarios empresariales de corte tradicional.

Se define Proto-Kanban a un sistema que, sin ser un sistema Kanban completo, ya tiene algunas pautas:

Visualización de todo el trabajo y sus etapas en un tablero.
Pueden aparecer ya algunas políticas explícitas o algunas clases de servicio.
Pueden establecerse también feedback loops: Algunos equipos solo se quedan con la Daily Strandup Meeting. Otros adoptan el Replenishment Meeting, y algunos van más allá y se atreven con retrospectivas.

Proto-Kanban tiene una gran ventaja y es que es poco disruptivo. Uno de los principios de cambio de Kanban es: empieza con lo que tienes; esto es, diseña el sistema para que refleje los procesos actuales, y una vez que lo domines, entonces empieza a mejorarlo colaborativamente. Esto lo convierte en algo más sencillo para comenzar que Scrum, por ejemplo.

Pero si es cierto que, aunque empieces con lo que tienes, existe una gran fricción y resistencia en las empresas a introducir WIP (Work In Progress) limits. Para superar esta barrera Proto-Kanban ofrece una serie de pasos o estados según la madurez del equipo y de la organización, que te ayudan a ir avanzando:

Personal Kanban: Un tablero por persona dónde cada uno visualizará su trabajo.
Personal Kanban agregado: Un tablero para el equipo con una fila para cada personal Kanban de cada miembro del equipo. En este momento aún estamos gestionando personas y no trabajo.
Team Kanban: Eliminar carriles por persona: Me centro en qué tengo que hacer, pero no en quién lo hace.
Introducir WIP Limits por persona: Empezamos a gestionar trabajo y no a las personas.

Proto-Kanban tiene una serie de quick-wins que lo hacen muy potente:

Al tener la visualización de todo el trabajo, se toman mejores decisiones.
Una mentalidad pull obtiene mejores resultados, priorizan acabar el trabajo antes de empezarlo (start stopping, stop starting).
Se generan conversaciones alrededor del trabajo que antes eran imposibles como cómo organizarse para responder a un deadline.
Se empiezan a medir y tener gráficas del sistema:
- Lead time: Tiempo desde que nos comprometemos a tener una tarea hasta que la entregamos.
- Cycle time: Tiempo que la tarea está desarrollándose.
- Tasa de entrega: Cantidad de ítems entregados en unidad de tiempo.

En el siguiente post entraremos más a fondo en estas métricas y cómo mejorarlas.

Me gustaría compartir nuestra última experiencia con Proto-Kanban. El escenario es una multinacional con una estructura jerárquica fortísima donde la relación con los jefes es de pánico. Una cultura empresarial basada en micromanagement y donde la comunicación entre equipos y hacia las personas que solicitan el trabajo es inexistente. Además, cada miembro del equipo trabaja de forma aislada a sus compañeros y nadie tiene tiempo de ayudar a nadie.

Cuando el equipo con el que arrancamos la transformación empezó a trabajar con Proto-Kanban, ocurrió un hecho que jamás se había dado en esta empresa. Llegó una petición urgente con fecha de entrega en una semana y…

Primer cambio: Al tener una visualización de todo el trabajo en el tablón, en la Daily Standup Meeting pudieron hablar como equipo basándose en la situación real actual.

Segundo cambio: Se dieron cuenta de que no llegaban si solo una persona cogía la tarea, de manera que la desglosaron en tareas más pequeñas y vieron cómo podrían organizarse para cumplir con la petición.

Tercer cambio: Cuando vieron que aun así no llegaban, decidieron llamar a la persona de su sede central que había realizado la petición. Esto parece algo básico pero nunca había ocurrido en la compañía. Le preguntaron algo de sentido común pero muy poderoso. ¿Qué parte de esta tarea es fundamental para ti, y qué parte puede esperar?

Cuarto cambio: Negociaron con el peticionario y llegaron a un acuerdo de mínimos necesario, que sí se entregó en en una semana.

Conclusión: Por primera vez una tarea urgente cumplió un deadline, el equipo se organizó para alcanzarlo y el representante de negocio estaba feliz.

Al compartir todo esto no pretendo crear una guía que se pueda usar en cualquier equipo o en cualquier situación. Simplemente intento arrojar un poco de luz sobre Proto-Kanban y en qué casos puede funcionar compartiendo nuestra experiencia.

Si quieres saber más sobre mentalidad pull y diferencias entre Proto-Kanban y Método Kanban, puedes asistir a nuestro primer día de la Kanban Week, el TKP (Team Kanban Practitioner)

En el siguiente post hablaré de qué problemas no soluciona Proto-Kanban y cómo seguir avanzando hacía el Método Kanban.

Aquí puedes leer más sobre patrones de madurez de Kanban de la mano del tito Anderson.

Continuar leyendo Flujo Downstream: Cómo ir más allá de Proto-Kanban >>

Mi experiencia en el Product Hackers Day 2018

Este pasado jueves 10 de mayo tuvo lugar en el Google Campus la primera edición del Product Hackers Day. Un evento por y para todas las personas relacionadas con productos digitales.

Idear, crear, evolucionar o vender un producto digital son unas de las tareas más complejas y, muchas veces, subestimadas de nuestra época. Tener un espacio para compartir experiencias y recibir consejos de expertos es una idea que me fascina y enamora. No debo ser el único que piensa así ya que las entradas se agotaron antes de que se publicara y moviera el evento por parte de los organizadores. Solo se necesitó un tuit del gran @chocotuits (que no es poco) para que esto ocurriera. Creo que esto nos deja patente la necesidad de este encuentro.

El evento

Esta ha sido su primera edición y he de decir que estoy muy sorprendido con la calidad del evento, los ponentes y el público. Se nota la mano de José Carlos Cortizo alias Corti. El hombre entre las sombras hizo esta idea realidad. Si lo pienso bien es normal ya que viene de organizar eventos tan top como el Gamification World Congress.

El marco era inmejorable. El auditorio del Google Campus rellenado con multitud de sillas para ponerlo en modo máxima capacidad. Le doy las gracias a Google Campus por estar siempre dispuesto a ceder de forma gratuito escenarios como este.

En la presentación del evento Luis Díaz del Dedo, CEO de Product Hackers, dijo que lo que más le dolía cuando iba a otras conferencias similares, era las charlas tan genéricas y poco profundas que se encontraron y que habían intentado traer ponentes que permitieran que los asistentes se llevaran algo en sus mochilas, y vaya si lo consiguieron.

Asistentes

Cuando llegué, a las primeras personas que me encontré fueron a mis amigos de Datio. Ver a una empresa como Datio con la cantidad de productos (y presupuesto) que maneja, representada con tantos miembros y diciendo “¿Cómo no íbamos a venir? ¿Has visto qué buena pinta tiene esto?” ya me dio una pista de la repercusión que estaba teniendo el evento.

Luego pude distinguir personas de mucho peso en este sector, como es por ejemplo el caso de Clara Ávila.

Sinceramente, una de las cosas que más me gustaron fue la heterogeneidad del público asistente. Desde grandes empresas hasta pequeñas startups que estaban luchando por su ronda A.

Los Speakers

Me gustó el nivel en general de todas las charlas, destacando por un lado la practicidad de Ana Asuero contando cómo trabajan en Marketing dentro de Aplázame, y por otro lado, la charla de Carlos Sánchez (@chocotuit) que nos mostró cómo realizar pruebas de usuario y cómo lo hacen ellos en OnTruck. Ponencias tan prácticas y tan bien contadas siempre son de agradecer.

La mesa redonda con representación de Adara, K Fund y Kibo fue interesante. Nos permitió ponernos en la piel de los Ventures Capital y poder entender un poco mejor cómo piensan. Todo amenizado por la dirección al estilo de Javi Santan.

Mi turno: Agile y diseño de producto

Justo después de comer llegaba mi turno para presentar “Agile y diseño de producto”. Un momento tenso en todas las conferencias que duran un día entero. La parada para comer puede mandar a casa a mucha gente. Pero esta vez la inmensa mayoría aguantó el tirón. Os lo agradezco nuevamente.

Cuando Corti me llamó para pedirme que contara algo sobre Agile, al ser la primera edición, pensé en hablar sobre diseño de producto. Mi primera idea fue tratar diferentes técnicas que nos permiten gestionar este tema, es decir, diseñar productos desde una perspectiva Agile. Posteriormente, tras unas cuantas líneas escritas, me percaté de que a pesar de que este tema está a la orden del día y es realmente importante, hay otro que le precede y que bajo mi punto de vista es todavía más importante. Las empresas que nos llaman para que les formemos y acompañemos, o en las que he trabajado en vidas profesionales anteriores, donde realmente tienen o tenían sus problemas no es en conocer qué técnicas existen o cómo ejecutarlas, sino en entender el porqué la están usando y en qué marco lo hacen. Es por ello que finalmente mi charla trató de por qué nace Agile, qué problema intenta solucionar y cómo lo hace, terminándola con unos consejos de cómo se puede gestionar el proceso de ideación (upstream) y cómo se relaciona con la ejecución (downstream).

Aquí os dejo un enlace a las diapositivas. Cuando esté el vídeo actualizaré el post.

Feedback para el año que viene a la organización

El evento ha estado genial, de verdad. En cualquier caso os voy a dejar un par de tipos por si sirvieran para futuras ediciones, las cuales me encantaría que se dieran:

La gestión del tiempo de los ponentes se puede mejorar. En algunos eventos a los que suelo asistir, alguien de la organización se sitúa en primera fila con dos carteles, uno de 10 minutos y otro de 5 minutos, dándoles la vuelta cuando falten esos minutos para finalizar la charla. Barato, fácil y práctico. Como solo hay un track, también se puede poner un móvil en el suelo con una aplicación de cronómetro con números gigantes como hice yo, y es suficiente.
Sé que no es responsabilidad vuestra directamente, pero el problema con el pasa-diapositivas empobrecía la experiencia del speaker y de los asistentes. No hay que confiar en los nuevos MacBook Pro y sus adaptadores.

Mi estreno

Para terminar, me gustaría compartir con vosotros algo personal de esta experiencia y es que era mi primera charla en un evento. Mis compañeros Pablo y Alberto Serrano son unos santos y me han estado ayudando para preparármela. Pablo, que es un crack de diseño de producto, en cómo se podía orientar la charla. Alberto, que tiene unos dotes de comunicación impresionantes, en cómo podía mejorar mi puesta en escena. Estoy abrumado por el feedback recibido en el evento y la experiencia ha sido increíble.

Sin más, muchas gracias a todos los asistentes por ponerme tan fácil dar la charla y por los comentarios recibidos posteriormente. Estoy deseando disfrutar de la segunda edición de lo que para mí ha sido una experiencia muy enriquecedora.