Blog





Durante el Agile Open Camp 2016, facilité una sesión para conocer y practicar algunas técnicas simples para tener un día más Slow.








Introducción

La sesión empezó con todos los participantes formando un circulo, con una breve introducción a Slow.

La Propuesta Slow
“Elegir continua y conscientemente el ritmo adecuado para lograr calidad placentera, beneficios sostenibles y conexiones verdaderas.”


La Paradoja Slow
“El ritmo contrarreloj al cuál solemos llevar nuestro día no siempre es necesario, e invertir tiempo en momentos Slow nos permite por ejemplo enfocarnos, vivir mejor y ser más productivos.”


Estaciones de Auto-Aprendizaje


Luego tuvimos dos espacios de 10 minutos en los cuales se formaron grupos en cada una de las estaciones de auto-aprendizaje, donde pudieron leer en conjunto la explicación de la técnica, experimentarla y luego compartir sobre la experiencia. Al cabo de los 10 minutos, la gente se ubica en grupo otra estación, para repetir el espacio con otra técnica.


Las estaciones de auto-aprendizaje


Puedan bajarse las fichas de cada estación de auto-aprendizaje a continuación:

Cierre

Luego de los dos espacios, no quedamos con poco tiempo (¡Slow!), pero pudimos re-armar un circulo con todos los participantes y compartir un poco sobre lo experimentado, hacer comentarios sobre la utilidad de las distintas técnicas y mencionar otras técnicas de interés. 


Tu Propia Técnica

Un aspecto que remarcaron varios de los participantes es lo de encontrar cada uno su propia técnica Slow, la que nos funcione mejor. Para eso hay que ir probando distintas técnicas, experimentar e inventar.

Quizás detectaste la inconsistencia entre el “6” del título y las 5 estaciones mencionadas hasta ahora… Justamente había una sexta estación especial: “Diseña tu propia técnica”. Si bien no tuvimos tiempo en la sesión de ejecutarla, la mencione rápidamente y la comparto acá:




A continuación, comparto el material correspondiente a la estación:
Comparto también una ficha de una técnica creada por Gabriel Garcia Peña durante el evento: Freno Natural

Te invito a compartir tus propias técnicas en los comentarios.


Feedback y Más

Como los participantes no pudieron hacer todas las estaciones durante la sesión, dejé en un costado del salón del evento las fichas de cada estación durante el resto del evento, para que cada uno pueda mirarlas o practicarlas cuando quiera. Se ve que algunos de los tomaron muy en serio, y así quedaron:






Después del evento pedí feedback sobre la sesión y eso es lo que recibí:
"Me gustó mucho tu sesión slow, gran aplicación de "estaciones de aprendizaje". El material fue muy bueno, tanto por contenido como por la parte visual -- iconitos grosos. Todos nos quedamos con las ganas de poder hacer todas las estaciones . . . Para una sesión de Open Space en perfection game para mí fue un 10." - Ricardo C.

"Puntaje 9,5
Destaco: Las técnicas, el incluir "tu propia técnica", el trabajo en grupos pequeños, el material pre-impreso.
Mejoraría: Daría mas SLOW la introducción antes de los grupos (la introducción de las técnicas para poder elegir se dijo muy rápido)" - 
Diego S.R.


Como material adicional, podes consultar el post Slow Agile – Que vuelvan los lentos, que tiene referencias de interés. Y si queres conocer más de Slow y de cómo revertir tu relación con el tiempo, quizás te interese el Taller del Tiempo online.
La facilitación de procesos grupales tiene miles de facetas y escuelas. Muchas veces vemos facilitadores buscando protagonismo, lo cual suele atentar contra la emergencia de la inteligencia colectiva del grupo facilitado.

Basado en una idea de mi colega Juan Gabardini en Kleer, co-creamos con el un experimento de auto-facilitación que tuvo lugar el 12 de septiembre del 2017 en Santiago de Chile: Taller de Auto-Facilitación.

Gracias a todos los participantes, viví una experiencia increíble, que quiero compartir en este post.

Los Jardines Japoneses

A finales del siglo XVI, la elaborada ceremonia japonesa del té fue llevada de la casa principal a un pequeño refugio dentro de su propio jardín especial. Los visitantes caminaban por un estrecho sendero llamado roji que conducía a la casa de té. 

A través de este sendero, los visitantes podían recorrer el jardín, y, a lo largo del camino, despojarse de sus preocupaciones y ansiedades antes de entrar en el estado de ánimo espiritual especifico para la ceremonia del té. 

La sofisticada experiencia del recorrido del jardin japones es consecuencia del trabajo (o arte) del diseño del jardín y del sendero, donde varios elementos como el agua, las rocas, la puerta, las curvas del sendero, entre otros, logran efectos específicos sobre el visitante. 

Juan Gabardini tuvo la idea de explorar esta metáfora del jardin japones en el contexto de la facilitación de procesos grupales. Con él, nos interesa en particular los contextos en los cuales se pueden aplicar mecanismos relacionados con esta metáfora para lograr una facilitación de procesos grupales sin recurrir a un facilitador protagónico dirigiendo a todos. 

Este taller fue un gran experimento en el cual intentamos aplicar esta metáfora a varios mecanismos de auto-facilitación.

Desarrollo del Taller

El taller siguió los siguientes pasos:

1.Inicio

Inicio del taller

Al entrar al lugar del taller, los participantes recibían una ficha de bienvenida con algunas explicaciones sobre el taller. En particular se los invitaba a participar en todas las actividades y además se le delegaba una responsabilidad de facilitación, descrita en la ficha. 


Las responsabilidades delegadas fueron: 
  • Cuida-Tiempo: Asegurarse que cada actividad empieza y termina a tiempo.
  • Cuida-Atrasados: Asegurarse que los participantes que llegan tarde puedan integrarse a las dinámicas del taller.
  • Cuida-Materiales: Asegurarse que todos los participantes o grupos tengan los materiales adecuados para las actividades.
  • Cuida-Consigna: Asegurarse que los participantes conozcan y entiendan la consigna de la actividad.
  • Cuida-Foco: Asegurarse que los participantes mantengan el foco durante la actividad, y que la misma se lleve sin bloqueos.
  • Cuida-Grupo: Asegurarse que se armen y mantengan  los grupos de trabajo durante la actividad.

Ejemplo de ficha de facilitación

Se combinaban algunas de estas responsabilidades con las 4 estaciones del taller. Tuvimos varias personas cumpliendo la misma responsabilidad y en algunos casos se pudieron conocer y ponerse de acuerdo. 

A partir de este momento, no iba a intervenir más en el taller. Ya había dejado armado 4 estaciones bien identificadas y visibles, cada una con sus horarios definidos y consigna, con flechas en el piso para destacar el sentido a seguir.

2. Conexión

En esta estación, el objetivo era que los participantes puedan conectarse con la temática, con algo relacionado de su contexto laboral y con los otros participantes. Para eso tuvieron que dibujar cada uno la entrada de su lugar de trabajo y luego compartir varias veces en pareja sobre el tipo de interacciones que ocurren en esta entrada. Una vez terminado el tiempo, se movieron solos a la segunda estación. 

Estación A.Conexión

3. Metáfora

En esta estación, el objetivo era que los participantes estudien en grupo alguna parte de la metáfora del jardin japones, que la resumieran y que finalmente la presenten al resto de los participantes. Para eso, formaron 4 grupos que recibieron cada uno una ficha que describe algunos aspectos importantes de los jardines japoneses: el jardin exterior y la puerta, el camino (roji), la casa de té, el agua.

Cada grupo estudió por su lado la ficha, y luego dibujaron en una lamina grande un resumen del tema. Finalmente cada grupo presentó brevemente su resumen al resto de los grupos. 


Un grupo trabajando

Otro grupo presentando

4. Debate

En esta estación, el objetivo era que los participantes puedan debatir todos juntos en forma ordenada sobre la aplicación de la metáfora del jardin japones a la facilitación de procesos grupales. Se utilizo el formato de debate Fishbowl, con unas preguntas para guiar el debate sobre los campos de aplicación y los mecanismos de facilitación relacionados. 

Debate en formato Fishbowl


5. Para llevar

En esta ultima estación. el objetivo era reflexionar sobre los principales aprendizajes del taller y proyectar cómo aplicarlos en el día a día de cada participantes. Para eso, primero cada uno escribió en post-its los aprendizajes que destacaba del taller. Luego en pareja se compartieron los aprendizajes y pensaron como aplicarlos en su día a día. Finalmente se intercambiaron datos de contacto, con la consigna de escribirse a la semana para compartir como les fue con la aplicación. 

Compartiendo aprendizajes en parejas

6.Cierre

En este punto, se terminó el experimento de auto-facilitación, y armamos un circulo con los participantes que se querían quedar, en el cuál analizamos y compartimos la experiencia. 

Aquí comparto todas las fotos del taller.

Reflexiones

El taller en si duró 1h45, y el cierre posterior 30 minutos. Participaron aproximadamente 25 personas. Comparto algunas reflexiones sobre el experimento, e invito a los participantes a sumar sus propias reflexiones en comentarios:

  • La preparación fue importante. Si bien Juan Gabardini había madurado la idea, había facilitado una sesión de debate sobre el tema en el Agile Open Camp Chile 2017, y una Jam Session No Facilitator en Agile 2017, la preparación implicó varias reuniones y horas de preparación de los materiales y consignas. La instalación en el lugar del taller también requirió más de una hora.
  • Unos momentos iniciales incómodos. Al inicio del taller, varios participantes comentaron que sintieron cierta incomodidad al no tener una persona que les dijera que hacer. Personalmente estaba inquieto, esperando a ver si iban a empezar como estaba previsto. Por suerte en el momento adecuado, el participante Cuida-Tiempo llamo a todos y explico su rol y que era el momento de empezar con la actividad. A partir de ahí todo fluyó muy bien. 
  • Un facilitador prescindible. Me había puesto el reto de intentar no intervenir en el taller. En varias oportunidades me tuve que morder la lengua para lograrlo. Finalmente tuve que intervenir en algún momento con el participante Cuida-Materiales ya que había un problema de entendimiento de la palabra "Rotafolio". También participe brevemente en el debate Fishbowl ya que me estaban haciendo una pregunta concreta sobre el diseño de las cartas. Y finalmente me sume en la ultima estación porque tenía muchas ganas de escuchar y compartir con los participantes. Aparte de eso, fue una experiencia increíble "soltar" la facilitación para que emerja la auto-facilitación. 
  • Unos facilitadores compenetrados. Comentaron varios participantes que se compenetraron son sus responsabilidades y que intentaron cumplirla de la mejora forma, aunque al principio se sentían un poco desorientados. En algunos momentos surgieron actos de facilitación emergentes no previstos en las cartas que ayudaron a que las actividades fluyan. Se ve que todos entendieron bien las cartas, ya que no tuve casi ninguna pregunta al respecto.
  • Un buen experimento. Me quede muy satisfecho con los resultados del experimento, y pude corroborar que los participantes también. Varios mencionaron el camino personal que siguieron durante el taller y como la secuencia de las estaciones los llevo por distintos estados. Muchos reconocieron también los mecanismos de auto-facilitación usados en el taller y como se relacionan con la metáfora del jardin japones. Algunos identificaron el gran potencial de estos mecanismos para aplicarlos en su trabajo. 

Aprendizajes potentes


En el cierre del taller los participantes me regalaron con su feedback varias sugerencias de mejora del taller, que espero poder implementar para poder realizar otros experimentos en breve... Nuevamente gracias a todos los participantes por su predisposición y por prestarse al experimento! Y muchas gracias a COE Everis por el lugar, comida y bebida, y a Movimiento Ágil por la organización impecable!

Más

Comparto algunas referencias que para mi fueron inspiradoras en esta temática: 
La Ventana a la Cultura del Equipo

En una entrevista, una vez me preguntaron: como Agile Coach, ¿cuál sería la primera intervención que harías en un equipo? Sin haberlo pensado antes lo primero que se me vino a la mente fue: Asistir a la Daily Scrum en calidad de observador.

Años después y tras haber trabajado con muchos equipos desde Kleer, me encuentro validando mi punto de vista inicial y sosteniendo que:

La Daily Scrum es el momento de mayor ancho de banda y eficiencia sobre la dinámica y la cultura de un equipo Scrum que un Agile Coach puede aprovechar.

El ancho de banda es la cantidad de información disponible por unidad de tiempo. Y la eficiencia es relación entre ambas dimensiones: la gran cantidad de información y la breve duración de la reunión. En tan sólo 15 minutos, un Agile Coach puede obtener mucha información valiosa.

Y la gran ventaja es que a diferencia de otros eventos de Scrum, es una oportunidad de aprendizaje que ocurre todos los días. 

El tablero de tareas y otros radiadores visuales de información (si existen) tienen mucha información útil, pero son sólo un poster, donde la Daily Scrum son los trailers de la película. En la Daily Scrum vemos tablero y al equipo en acción.

¿Y la Calidad de la Información?

Gracias a la experiencia y la capacidad de escucha y de observación, el Agile Coach puede obtener información realmente útil.

Incluso cuando el Agile Coach tiene muy poco contexto sobre el equipo o el producto que desarrollan, puede percibir información valiosa, ya que no se centra en el contenido, sino en la calidad del proceso, la estructura y las relaciones.

Las observaciones, deben ser tomadas como lo que son. El primer paso es validarlas con el Equipo antes de operar en base a supuestos.

¿Qué observar?

El siguiente es un listado de los aspectos a los un Agile Coach debe prestar atención. 

  • Cómo es el estado de ánimo del Equipo.
  • Cómo es el entusiasmo, interés y motivación del Equipo para con el trabajo.
  • Cómo es la claridad y entendimiento sobre el Sprint, los objetivos y las tareas planificadas.
  • Cómo es el compromiso y la responsabilidad ante los acuerdos.
  • Cómo hacen los acuerdos
  • Cómo son las relaciones entre los miembros del equipo.
  • Cómo está el nivel de confianza entre las personas. Cómo es la indagación y el cuestionamiento de los puntos de vista.
  • Cómo es la efectividad de la comunicación.
  • Cómo es el nivel de formalidad o informalidad en el trato y en el proceso.
  • Cómo es el nivel de interés y atención en el trabajo de los demás, la colaboración y soporte entre los miembros
  • Cómo es el nivel de participación y de indagación.
  • Cómo está el nivel de transparencia de información.
  • Cómo es la capacidad de coordinación táctica. Qué tipo de decisiones se toman.
  • Cómo se toman las decisiones.
  • Cómo está funcionando el Tablero de tareas y radiadores visuales de información.
  • Quién y cómo actualiza las métricas, tableros y radiadores visuales de información
  • Cómo es la capacidad de mantener el foco y manejar los tiempos.
  • Cómo es el liderazgo, el empowerment y la auto-organización
  • Cómo es la gestión de impedimentos
  • Qué métricas de proceso utilizan
  • Cómo es el manejo de las prioridades.
  • Cómo es la calidad de las discusiones en el equipo sobre lo que es posible y lo que no.
  • Cómo es la participación de otras personas externas el Equipo. ¿Es el Product Owner parte del equipo?

Además, prestar atención a todo tipo de situaciones circunstanciales y cómo el equipo se hace cargo de las mismas. Por ejemplo: un miembro del equipo no está, el Scrum Master está en otra reunión, una tarea que los presentes no reconocen, un radiador visual desactualizado, etc.

La actividad de observación genera el mínimo nivel de intervención e interrupción en el Equipo. A diferencia, por ejemplo de facilitar una Retrospectiva, donde estaríamos haciendo una intervención directa en la forma normal de operación del equipo.

Si los ojos son la ventana del alma, la Daily Scrum es la ventana a la cultura del Equipo.


En lo discursivo, la historia que nos cuentan sobre el equipo es sólo la versión de una persona, con sus recortes y distorsiones naturales. Muchas veces suele ser el caso ideal y no el cotidiano.

En Kleer, la experiencia de compartir el proceso de aprendizaje y evolución de muchos equipos, nos permite identificar los patrones de comportamiento que los potencian, así como también los anti-patrones que los limitan. 

Como Agile Coach, acompañamos a los equipos en el proceso de identificar estos comportamientos y oportunidades de mejora para potenciar el rendimiento del equipo y la satisfacción en el trabajo. 

(Foto de Damián Buonamico)
La Era Digital -también llamada Era del Conocimiento y la Innovación, sigue avanzando y acelerándose entre nosotros potenciada por: 1) la tecnología que apunta a automatizar gran parte del trabajo humano; 2) la globalización que nos exige ser cada día más creativos, competitivos y eficientes.
En este contexto la pregunta del millón es ¿Qué deberíamos cambiar o mejorar del Management para acelerar la innovación empresarial?

Y para encontrar algunas respuestas podemos recurrir a las funciones básicas tradicionales de Directores y Gerentes: Planificar, Organizar, Liderar y Controlar, buscando re-definirlas y adaptarlas a las exigencias, las oportunidades y los valores que nos presenta la Era Digital:


Función Ejecutiva
Definición tradicional
Re-definición
Planificar
Utilizar metodología y lógica para definir los objetivos, la estrategia y las acciones de la empresa.
Trabajar en equipo para la co-creación de una visión y objetivos bien conocidos y entendidos por todos. Programación de iniciativas y proyectos en forma iterativa con ciclos cortos, para aprovechar las oportunidades, obtener feedback y reducir riesgos.
Organizar
Alistar y coordinar el trabajo, la autoridad y los recursos para alcanzar los objetivos de la empresa.
Facilitar y estimular la formación de equipos empoderados; proveerlos de los materiales, formación y entorno de trabajo apropiados y  necesarios para crear productos y servicios con alto impacto positivo en el mundo.
Liderar
Dirigir, influenciar y motivar a los empleados para que realicen correctamente las tareas esenciales.
Crear contextos de confianza, aprendizaje y colaboración que permitan a los equipos y las personas el alcanzar su máximo potencial de Productividad, Calidad y Satisfacción.
Controlar
Asegurar que la empresa esté cumpliendo sus objetivos.
Promover la visibilidad de los resultados a través de métricas orientadas a aumentar la eficiencia de los procesos y la mejora continua.


Durante las transiciones sugerimos evitar saltos al vacío o seguir recetas que nos prometen “LA SOLUCIÓN”. Proponemos en cambio avanzar sobre seguro a través de la formulación y ejecución de experimentos de bajo riesgo con objetivos de aprendizaje validados -- así rápidamente se pueden lograr mejoras concretas, efectivas y sostenibles en algunos equipos, que luego se expanden al resto de la organización.


Textos sugeridos relacionados:
Bienvenidos a un ¿Nuevo? Mundo. Trabajadores y Conocimiento por Martín Alaimo
The Future Of Leadership And Management In The 21st-Century Organization por Brent Gleeson @ Forbes Magazine

Entrenamientos de Kleer relacionados:





"El objetivo de la comunidad es asegurarse de que todos sus miembros son escuchados y hacen entrega de los dones que han traído a este mundo. 

Sin esa entrega, la comunidad muere. Y sin la comunidad, el individuo se queda sin lugar donde hacer su contribución. 

La comunidad es ese lugar que nos equilibra y al que las personas acuden para compartir sus dones y recibir los de los demás."

- Sobonfú Somé | Historias Africanas sobre el Amor y la Amistad
Describir la realidad en un modelo o usando metáforas es un mecanismo muy potente para ayudarnos a reflexionar sobre lo que nos pasa de forma racional y poder pensar luego eventuales cambios. Por ejemplo los LEGO Serious Play o el Coaching con LEGO explotan este mecanismo de distintas formas.

La dinámica de retrospectiva que voy a presentar a continuación usa este mecanismo proponiendo describir lo más importante de la iteración pasada en una representación que usan los participantes todos los días, como puede ser el código fuente apara desarrolladores de software.



  • Nombre: Dígalo con Código

  • Participantes: 4+

  • Duración: 10-15 minutos

  • Alcance: Al finalizar una iteración corta (3 semanas o menos)

  • Propósito: Abrir la retrospectiva y/o Recolectar información

  • Facilitador: Recomendable

  • Objetivos: Esta dinámica permite a los participantes recordar lo más importante de la iteración y describirlo en una forma divertida.

  • Material y Preparación
    • 1 hoja A4 y 1 marcador por participante. 

  • Pasos

1. Explicar el objetivo de la dinámica y repartir una hoja y un marcador por participante.

2. Pedir a cada participante que se tome un tiempo para recordar la iteración que se termina. Dejar 5 minutos para que cada participantes escriba en su hoja entre 3 y 10 lineas de código que describa lo más importante de la iteración. Cada uno puede elegir el lenguaje de programación o pseudo-código que quiera.

Ejemplos de código para describir la iteración pasada

3. Una vez que terminaron todos, pedir a cada uno que comparta su código y explique brevemente porque lo escribió así.


  • Variantes
    • Esta dinámica esta pensada para equipos de desarrollo de software. Sin embargo es extrapolable a otros dominios. Por ejemplo unos testers pueden describir el sprint escribiendo un caso de prueba. Unos abogados como una clausula de un contrato, unos contadores como un balance contable, unos especialistas en procesos en un diagrama de proceso, unos diseñadores web como un wireframe de una pagina web, unos ingenieros electrónicos como el diseño de un circuito electrónico, etc.

Ejemplo de descripción de la iteración con circuitos electrónicos 

    • En lugar del paso 3, se puede solicitar a los otros participantes que intenten adivinar porque la persona escribió este código, y luego validar esta explicación con el interesado.
    • Si son muchos participantes, se puede hacer el ejercicio en parejas o de a 3, dejando un poco más de tiempo en el paso 2, para que cada grupo pueda escribir colaborativamente su código.
    • Se puede agregar un paso adicional al final, en el cual todo el equipo consolida las propuestas de todos los participantes en un solo código. En este caso contar 10 minutos más.

  • Tips
    • En la explicación no presentar un ejemplo, que puede generar un gran sesgo en lo que escriba cada participante luego. Si alguien se queda con la hoja en blanco, el facilitador puede acercarse y ayudarlo preguntando lo más importante de la iteración y dándole ideas (¿Qué tal usar un "for"? ¿Un "try-catch"?, etc.).
    • Puede ser útil poner una música tranquila no muy fuerte durante el paso 2.
    • En esta dinámica lo importante es que cada participante pueda expresarse, aunque sea brevemente. El facilitador debe cuidar que todos escuchen a la persona que cuenta su código.
    • El facilitador puede hacer un breve cierre al final de la actividad destacando lo más importante que se vio en los códigos escritos.

  • Origen: Thomas Wallet

Interpreter Book

Suelo escuchar varios podcast mientras me muevo por Buenos Aires u otras ciudades en mi trabajo. Uno de los que sigo desde hace años es el de Scott Hanselman, que es quizá una de las personas que más me impactó dentro de lo que se conoce como la "comunidad Microsoft".

Scott, más allá de seguir trabajando para Microsoft en el grupo de ASP.NET y herramientas de Azure, es un tipo inquieto que mantiene varios podcasts e iniciativas, y sobre todo valoro su constante esfuerzo por lograr una industria más inclusiva, recibiendo a a gente de toda edad, raza, identidad u orientación sexual, religión o ideario.

Pero basta de elogios al amigo Scott. El tema que me atrajo especialmente en éste último podcast fue que entrevistaba a Thorsten Ball, quien auto-publicó el libro "Writing An Interpreter In Go", que trata básicamente de eso: recorre todos los pasos de escritura de un intérprete. En su caso del lenguaje Monkey que él diseñó para el libro mismo, y que es bastante similar a JavaScript o un montón de otros lenguajes de la familia de las llaves {}.

Más allá de que es un tema interesante, me gustó que la manera en que lo hace es utilizando lo más básico de Go, sin más que la librería standard, construyendo desde cero el parser y el lexer, y sin usar ninguna librería particular. Y por supuesto, utilizando TDD.

Es un libro que recorre en mayor detalle el camino constante del Maestro Ángel Java López, que como puede verse en su cuenta de GitHub escribe este tipo de intérpretes o compiladores todo el tiempo.

¿Por qué escribir un intérprete a esta altura? Básicamente porque las capacidades y el entendimiento de sus partes nos ayudan a ser mejores programadores en general, como llegado cierto punto un buen automovilista tiene que aprender de mecánica, o un rocker necesita aprender sobre ingeniería de sonido.



¡Por tercer año consecutivo, del evento Agile Open Camp nació un libro escrito colaborativamente!







Trilogía





En el 2015 escribíamos entre varios un primer libro Experiencias Ágiles: relato de experiencias del uso de metodologías ágiles en Argentina durante el Agile Open Camp Bariloche 2015.








En el Agile Open Camp Bariloche 2016 se compaginaba el segundo libro Herramientas Ágiles: técnicas y patrones para profesionales a partir de textos escritos previamente por varios participantes del evento.






Y para este año, varios participantes del Agile Open Camp Bariloche 2017 y del Agile Open Camp Chile 2017 se coordinaron para escribir el tercer libro Ensayos Ágiles: escritos, reflexiones y críticas sobre agilidad.





¿De que trata el libro?

Personalmente, es el libro que más me gusta de la trilogía, o por lo menos el que veo más útil y acabado.

Intenta desafiar temas instalados alrededor de la agilidad, como por ejemplo capítulos que cuestionan la declaración de valores del manifiesto ágil, que expresan limitaciones de las retrospectivas, que destacan enfoques negativos de coaching ágil o que subrayan mecanismos creativos que no tienen su lugar en la agilidad.

Y si bien es un libro dirigido a un publico más conocedor de la agilidad que los dos primeros, me gusta mucho porque genera reflexiones y preguntas. Creo que es un libro superador de muchas lecturas que se pueden encontrar hoy. ¡Espero que les guste!


Créditos 

A continuación las personas que participaron en este libro:

  • Autores: Juan Gabardini, Ingrid Astiz, Rox Muñoz, Nicolás Paez, Vanesa Savino, Thomas Wallet, Martín Salías, Alejandro Faguaga, Hiroshi Hiromoto
  • Gráficos: Omar Fernández
  • Arte de tapa: Mauro Strione
  • Foto de tapa: Yamit Cárdenas
  • Revisión: Cora Fassina y Nicolás Paez
  • Idea y coordinación: Nicolás Paez


¡Kudos especiales para Nicolás Paez, iniciador y coordinador de toda la serie, y Product Owner implacable del libro!


Los derechos Slow del equipo ágil


Tuve la suerte de participar en la redacción del libro con un capítulo propio: Los derechos slow del equipo ágil.



En este capítulo además de explicar brevemente los orígenes del movimiento Slow, identifico las derivas que suelen generar las malas implementaciones de la agilidad en cuanto a ritmo de equipo y sus consecuencias nefastas.

Luego presento lo que considero los derechos Slow del equipo ágil, convencido de la necesidad de hacerlos respetar, y también las responsabilidades que acompañan estos derechos.

Espero aportar un granito de arena con este capítulo, para que los equipos ágiles puedan luchar por su dignidad en cuanto a sus ritmos de trabajo.


¿Cómo sigue?

Se puede leer en linea o descargar el libro en GitBook, y si bien está en camino, todavía no existe la posibilidad de encargar la edición impresa del libro (avisaré ni bien se pueda).

Con este tercer libro se cierra esta serie de libros. Pero como van a seguir habiendo Agile Open Camps por muchos años, estamos buscando más personas motivadas para eventuales futuros libros. ¿Quién se anima?

codewarsHace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo el Maestro.

A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.

Codewars es básicamente un sitio de práctica. Está basado en la idea de Code Katas, pero extendido a formas adicionales como el Kumite (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.

Entre las características que más me gustaron es que hay:

  • Diferentes niveles de dificultad
  • Tags que agrupan los ejercicios por temas, niveles, foco
  • Alto nivel de gamification: los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante
  • Foros y comentarios bien integrados
  • Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.
  • Y sobre todo, la chance de aprender y/o practicar en una variedad enorme de lenguajes:
    (en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.

Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.

Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden encontrarme en Codewars y eventualmente podemos hacer un Kumite.

Quiero compartir un nuevo juego de cartas que co-creamos con mi colega en Kleer y amigo Camilo Velasquez: las DoD Kards.

Es un juego de cartas cuyo objetivo es reflexionar y consensuar entre todos los miembros de un equipo cuáles son los criterios a incluir en su definición de terminado (DoD por su sigla en ingles: Definition of Done).





¿Qué es la Definición de Terminado?

La Definición de Terminado o DoD es un acuerdo co-creado por un equipo, que se aplica a todos los ítems sobre los cuales trabaja este equipo. Incluye un conjunto mínimo de actividades o condiciones a cumplir para alcanzar el nivel de compleción y calidad acordado en cada ítem de trabajo.

Es un compromiso de todo el equipo que se puede incrementar con el tiempo, y que permite transparentar el avance real del equipo.

Para más definiciones de DoD >>> Agile Alliance, Scrum Alliance.


¿En que contexto usar las DoD Kards?

El alcance del juego es la Definición de Terminado en el contexto del desarrollo de software con Scrum, aplicado a los Items de un Backlog de Producto (PBI, que muchas veces se expresan como Historias de Usuario), aunque se puede extrapolar a otros contextos.

Para más contexto sobre el uso del juego >>> Guía Ágil de Definición de Terminado


Las cartas


El juego consta de cartas de criterios que potencialmente podrán ser parte de la Definición de Terminado de un equipo. Por ejemplo:



También cuenta con cartas de criterios vacías para agregar nuevos criterios no contemplados por el juego. 

Finalmente están las cartas de elección
  • "¡Ya!", para los criterios que queremos incluir a nuestra DoD a partir de ahora.
  • "Más adelante", para los criterios que no podemos incluir por el momento pero que queremos reconsiderar en el futuro. 
  • "No", para los criterios que no aplican, no entendemos, no queremos incluir en nuestra DoD o para los cuales no logramos ponernos de acuerdo.

Se pueden descargar las cartas en formato PDF aquí.


¿Cómo se juega?


  1. Ubicar las cartas “Ya”, “Más adelante” y “No” en fila en la mesa o pared.
  2. Mezclar todas las cartas de criterios y ubicarlas en una pila boca abajo al alcance de todos. 
  3. Dejar en otra pila separada las cartas vacías de criterio.
  4. De a uno, cada jugador:
    • Roba la siguiente carta de la pila de criterios y la lee en voz alta.
    • Ubica la carta en la columna  que considera más adecuada (“Ya”, “Más adelante” o “No”).
    • Si alguien no coincide con esta elección, se conversa durante un tiempo pre-acordado para lograr un consenso. Si no hay consenso al finalizar este tiempo, ubicar la carta en la columna “No”.
  5. Se repite el paso 4 hasta que no haya más cartas de criterios disponibles o cuando lo decida el equipo.
  6. En cualquier momento un jugador puede escribir un nuevo criterio personalizado en una carta vacía de criterio y usarla en su turno.



¿Y luego?


Es una muy buena práctica hacer bien visible los criterios de la Definición de Terminado acordada en el lugar de trabajo del equipo (o su equivalente digital). Por ejemplo se puede ubicar las cartas de criterios elegidas en el Tablero de Tareas del equipo.

Foto de Diego Ludueña


Se recomienda jugarlo periódicamente (cada 2 a 3 meses), para poder incrementar la DoD del equipo en forma sostenible.

Para darnos feedback puedes usar el hashtag en Twitter: #DodKards

Por: Martín Salías y Pablo Lischinsky Este paradigma de innovación en productos y servicios para grandes empresas (las llamadas enterprises) tiene su origen en el boom de las Startups disruptivas que comenzaron a causar inquietud en los grandes jugadores de la industria, no solamente porque les quitan mercado, a veces tímida y a veces drásticamente, … Leer más "Lean Enterprise: el modelo que buscan las grandes empresas"

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):


¡Hola, Rox! 

Tarot de Arquitectura

Te paso el material:

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.

Hace pocos días encontré el Poster “Agile Product Owner” de Mia Kolmodin y me pareció muy bueno y digno de compartir, así que decidí escribirle para ofrecerle hacer la traducción  al español. No pretende ser una traducción ortodoxa sino más bien útil y enmarcada dentro del contexto de la comunidad ágil de Latinoamérica, en la que me … Leer más "Poster “Agile Product Ownership”"
Paul Cezanne, Paisaje

A comienzos del siglo XX apareció el Impresionismo, un movimiento que modificó al arte para siempre. Se trató de una nueva forma de ver al mundo con nuevas texturas, colores más expresivos, y una percepción innovadora del movimiento desde ángulos inusuales.

Algunos años después, los cultores del Impresionismo decidieron evolucionar hacia una siguiente etapa en la cual mantuvieron sus colores expresivos y pinceladas abundantes, pero derribando las limitaciones que les imponían las formas y la luz de la naturaleza. Así nació el Post-Impresionismo, movimiento en el que se comenzaron a usar los colores en forma diferente y se logró una mayor una fuerza expresiva.

A comienzos del siglo XXI apareció el Agilismo, un movimiento que modificó el mundo del trabajo y la Innovación. Se trató de una nueva forma de ver a las personas y organizaciones, reconociendo el valor de los equipos motivados trabajando con objetivos claros y buscando mejorar el valor entregado al mundo en forma sostenible.

Algunos años después, ya nos encontramos derribando algunas de las limitaciones del Agilismo.

Bienvenidos al Post-Agilismo

Ya no nos conformamos con tener un Producto valioso funcionando
Buscamos co-crear Productos Grandiosos que nos hagan sentir orgullosos

Ya no medimos el valor de lo entregado en términos de cantidad
Nos enfocamos y trabajamos en los efectos que el producto tiene en los indicadores relevantes del negocio

Ya no nos concentramos en aplicar marcos de trabajo y metodologías
Sino que ayudamos a que las personas asimilen el espíritu ágil y lo hagan parte de su ADN, para que luego les resulte muy natural adoptar la disciplina y hábitos ágiles

Ya no perdemos tiempo sumando story points, y dejamos atrás al planning poker
Logramos que personas trabajando en equipos comprometidos sean tan o más predecibles que los baqueanos que pueden recorrer con paso firme los caminos de montaña más empinados y difíciles

No nos limitamos a reaccionar al cambio
Navegamos cómodamente la complejidad, volatilidad e interdependencias internas y externas de los proyectos

No nos quedamos en la valoración de las personas y sus interacciones
Estamos 100% conscientes y convencidos de que sólo construyendo relaciones de calidad vamos a obtener resultados de calidad


Pasamos de colaborar con el cliente a co-crear relaciones y sociedades asombrosas

No nos limitamos a disminuir el re-trabajo y el desperdicio,
Tenemos una conciencia ecológica que nos impulsa a valorar con todo nuestro corazón el valor de la energía, la inteligencia, el talento y el tiempo de cada persona


¡Bienvenidos al Post-Agilismo!


Desde siempre los seres humanos hemos intentado entender y explicarnos los misterios del paso del tiempo y sus efectos sobre nuestras vidas. Por ejemplo se cuenta que en la Grecia Antigua tenían al menos 7 formas de representar al Tiempo, entre las que se encontraban los dioses Cronos y Kairos.
Cronos representaba el paso del tiempo cronológico, el que va transcurriendo y vamos registrando en minutos, horas y días, 
mientras que Kairos se relacionaba con cada  “momento memorable” que tiene impacto en nosotros y luego recordamos por largo tiempo.
Ya en nuestros días y contextos laborales vemos que generalmente hay una relación directa entre el Kairos que se genera mientras trabajamos y los resultados que vamos logrando. Por ejemplo cuando las personas se encuentran en un ambiente rutinario y sin un propósito que consideran valioso, ahí es probable que predomine Cronos, con resultados mediocres y sin que emerjan iniciativas de mejora en productividad y calidad; en cambio esas mismas personas pueden tener un desempeño muy superior en un contexto donde le encuentran sentido a lo que hacen, se celebran los éxitos y hay ambiente propicio para buscar las causas y soluciones a los problemas cuando algo sale mal.

Una forma muy eficaz de liderazgo consiste entonces en crear contextos que atraigan la generación de Kairos, y aquí va una lista con algunos tips para lograrlo:
  • Considerar que nuestro lenguaje no es simplemente descriptivo, sino que tiene el poder de crear nuevas realidades. Por ejemplo si consguimos evitar frases del estilo “acá se trabaja mal”, o “siempre tenemos el mismo problema con este cliente, no hay modo de conformarlo”, y en su lugar mencionamos en forma precisa lo que no nos gusta o algunas propuestas de cambio experimentales y de bajo riesgo. 
  • Dar feedback frecuente y cercano a los acontecimientos.  
  • Estimular una cultura de aprendizaje rápido que incluya no penalizar los errores relacionados con encontrar mejores formas de trabajo. 
  • Propiciar hábitos de reflexión individual y grupal en ambientes seguros. 
  • Comenzar nuestras reuniones a tiempo y con una agenda donde ya desde el inicio se traten temas importantes para todos. Diferenciar además a los participantes necesarios de los opcionales para esas reuniones.
¡Éxitos y hasta pronto!


En su camino hacia la Transformación Digital con una cultura de mayor Innovación, la empresas se encuentran con nuevos desafíos, entre los que se encuentran:


- cómo medir el retorno a la inversión de las iniciativas y proyectos de innovación,
- cómo evitar sumar complejidad a la operación interna y confundir a los clientes
- cómo balancear la inversión entre los diferentes tipos de innovación (incremental vs. radical) y
- cómo detectar las dependencias y potenciar las relaciones entre los diversos proyectos e iniciativas de transformación e innovación


Uno de los marcos conceptuales más utilizados para superar estos desafíos utiliza la matriz de Ansoff aplicada a la Transformación Digital. Adicionalmente, la matriz nos permite categorizar y dar soporte en forma diferente a los proyectos dependiendo de la relación costo/beneficio de cada uno. De esta forma podemos visibilizar y gestionar en forma simultánea:
- Innovaciones incrementales de bajo riesgo
- Innovaciones expansivas que se construyen sobre productos, servicios y procesos existentes
- Innovaciones disruptivas y transformacionales que buscan crear nuevos y novedosos  productos, mercados y modelos de negocio

La creación y mantenimiento de un Portfolio de Proyectos de Innovación y Transformación Organizacional genera conversaciones relevantes, facilita la comunicación fluída, y nos habilita además la posibilidad de acelerar --en un siguiente paso-- la Transformación Digital con programas de Innovación Abierta que incluyan a clientes, proveedores y socios de negocio.

El Barómetro de Equipo es una herramienta poderosa para ayudar a un equipo de trabajo a elevar su nivel de conciencia como tal y evaluarse frente a características de los Equipos de Alto Rendimiento.

Se trata de una recopilación que integra diversas fuentes y permite disparar conversaciones significativas.

Aquí podés descargar todo el material para emplearlo en tu organización!




Team Barometer fue creada originalmente por Jimmy Janlén de Crisp en Suecia, empleando diversas fuentes, entre ellas: Five Dysfunctions of a Team (Patrick M. Lencioni), Teamwork is and Individual Skill (Christopher Avery), Squad Health Check (Spotify) y otros colegas Agile Coaches. La versión original cuenta con 16 cartas.

En este post ofrezco una traducción al español, pero además, gracias al éxito de esta herramienta, el permiso de Jimmy y la colaboración de mis colegas de Kleer, podés descargar también una versión 2. En esta versión, los textos están revisados, agrego 11 tarjetas más, el rediseño visual de las mismas y una propuesta de dinámica de facilitación.

Al final del post se encuentran los link de descarga de las dos versiones en español.


Explicación


Cada tarjeta cuenta con un título que describe una característica y dos frases. La frase en color verde refleja el caso positivo y la frase en color rojo el caso negativo.

Para cada tarjeta, los miembros del equipo deben votar si se sienten más representados por la frase verde o por la frase roja. Cuando no se pueden decidir por ninguno de los dos, pueden elegir el amarillo.

Es importante mencionar que el verde y el rojo describen dos extremos. Difícilmente un equipo se encuentre en el extremo. Por ello, deben elegir el extremo más próximo aún cuando no los describa perfectamente y reservar el amarillo en la minoría de los casos.

También, es importante mencionar que la votación no refleja a la persona que vota, sino su percepción sobre el Equipo. Por ejemplo, si alguien vota con Rojo la tarjeta de Confianza, no significa que esa persona no tiene confianza, sino que su opinión es que al Equipo le falta Confianza.

Con la dinámica se obtiene una representación visual, pero el resultado más importante es conscientizar en qué aspectos el equipo se encuentra debilitado y generar conversaciones para reflexionar y mejorar.


Preparativos:


- Imprimir/Recortar una copia de las cartas. Es muy recomendable plastificarlas para usarlas repetidamente :)

- Imprimir un juego de tarjetas de votación (verde, roja y amarilla) para cada persona. La versión 2 incluye estas tarjetas para cuatro personas.

- Utilizar tres hojas de Rotafolio / Papelógrafo o un pizarrón de tamaño equivalente también funciona bien.

- Si la sala cuenta con proyector o monitor se pueden aprovechar para la facilitación (Version Presentación)

 

¿ Cómo se Facilita?

1) Emplear una actividad de Check-in que permita centrar la atención en la actividad explicando la dinámica.

2) Disponer las tarjetas en línea recta como en la siguiente imagen:



Por cada tarjeta:

3) Leer la tarjeta. Verificar si hay alguna duda de interpretación. Todos deben votar qué frase describe mejor al Equipo. Para esto, cada uno muestra la tarjeta del color elegido. Todos deben mostrar la tarjeta al mismo tiempo para que la opinión de una persona no influya en la opinión de otra.

Si hay monitor/televisor/proyector disponible, resulta muy conveniente mostrar las tarjetas para mayor apoyo visual, y que todos puedan leerla al mismo y tener en claro qué tarjeta estamos discutiendo a cada momento.



4) Contar la cantidad de votos verdes y rojos para representarlos con un marca del lado correspondiente. Los votos amarillos no llevan marca.

Es importante moderar y facilitar la conversación para administrar el tiempo y la energía. Evitar  emplear demasiado tiempo discutiendo sobre un aspecto en particular más de lo necesario y que la energía se diluya. La discusión debe estar orientada a entender como nos calificamos e identificar los motivos principales. El objetivo es primero completar toda la votación para luego pasar a conversar sobre los puntos más relevantes.

5) Los motivos principales que justifican la votación se pueden reflejar con palabras claves en post-its, cada vez que lo amerite. Utilizar post-its del color que corresponda a la calificación (verde/rojo/amarillo).



6) Con el gráfico completo, invitar al Equipo a obtener conclusiones. ¿Dónde el equipo tiene opinión dividida? (similar cantidad de votos verdes y rojos) y por qué. ¿En qué puntos estamos peor y cuáles nos destacamos? ¿Por qué?

Facilitar la selección de aspectos a mejorar ¿Qué necesitamos hacer para pasar a verde?

No olvides tomar fotos de las láminas y agendar una próxima sesión dentro de un tiempo razonable para repetir la dinámica y comparar los resultados.

Tips

Recuerda siempre que lo importa no son los datos o valores que resultan sino las conversaciones que se generan para mejorar.

Para la preparación de las sala, colgar las tres hojas de rotafolio y preparar los 27 rollitos de cinta adhesiva. Luego en la sesión, ir pegando las tarjetas a medida que se van descubriendo.

Adminsitrar el tiempo disponible a conciencia: 27 tarjetas parecen muchas, pero se pueden completar muy rápidamente con la votación de colores si no se dedica tiempo a profundizar en discusiones.

Explicar claramente que el propósito del ejercicio es para la propia reflexión del equipo, y no es un reporte o una evaluación externa, no se busca que todo figure en verde, las opiniones en rojo y amarillo son las que permiten mejorar. Si todo está en verde, no hay nada para mejorar.

No resulta conveniente utilizarla con un Equipo que se encuentre transitando problemas muy graves, ya que podría generar muchas frustraciones y tal vez sea conveniente trabajar con el equipo primero con otras herramientas de coaching.

Se puede utilizar como retrospectiva de fin de año. Recomiendo hacerlo como una sesión aparte de la retrospectiva de Sprint, para no quitarle al equipo la oportunidad de mejoras específicas del Sprint

Descargas

Actualizado: 19 de Mayo 2017



Versión Original (Inglés)
http://blog.crisp.se/2014/01/30/jimmyjanlen/team-barometer-self-evaluation-tool



Si lo utilizaste y querés compartir tu experiencia te invito a dejar tus comentarios.


Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico

Damián Buonamico


Kanban Cakes - Como Explicar Kanban de Forma Práctica

Kanban es un método para visualizar y optimizar el flujo de producción en cualquier industria. Con esta dinámica podemos facilitar una simulación que permite verlo en acción!






Contexto

El ejercicio consiste en simular el proceso funcionamiento de una repostería, produciendo tortas a pedido. Se trabaja en iteraciones cortas, se observan las métricas y se proponen mejoras del proceso para la siguiente iteración.

Realizamos este ejercicio en las Jornadas Nacionales de Metodologías Ágiles 2016 y en Lean Fest Nights del mismo año.

En este post explico la dinámica en detalle y comparto los materiales para reproducirlo libremente  workshops o trainings.

Para este artículo se asume que se conocen por lo menos las bases de Kanban.

Preparación y Requisitos

Se requiere de una pared libre de dos o tres metros de ancho, disponible para utilizar y espacio libre para moverse delante de ella. 100 post-its (sticky notes), cinta de papel de color e imprimir las imágenes.


La preparación consiste en pegar dicha pared la Cadena de Valor (Value Stream) de la repostería, marcar los límites de nuestro sistema y trazar un tablero Kanban básico.


Para la simulación vamos a establecer un rango de tiempo en segundos que demora ejecutar cada una de las etapas del trabajo de producción de una torta. Por ejemplo: Batido (5-10”) nos dice que el batido demora como mínimo 10 segundos y como máximo 15 segundos. La persona participando debe contar los segundos y decidir cuando la tarea está terminada, dentro del rango establecido.

Esta forma de trabajo, donde cada persona debe contar dentro de un rango de segundos le agrega a la simulación cierta aleatoridad.




Formato 3 x 3 x 3:

Un formato posible de duración de la Simulación consiste en 3 iteraciones. Cada una se compone de 3 minutos de simulación y 3 minutos de retrospectiva. Así la duración es de 3 x 3 x 3 = 27 minutos + tiempos de introducción al ejercicio y conclusiones, se podría extender a 45 - 60 minutos)

En cada iteración, un grupo de personas participa en la simulación mientras el resto observa de manera activa como fluye el trabajo para luego participar con aportando sus comentarios.

Rotación: Al cambiar de iteración, puede pasar otro grupo de personas al tablero.

Nota: no confundir iteración con Sprints (de Scrum). En Kanban el flujo es continuo. En este ejercicio nos referimos a iteraciones de la simulación.



Iteración 1:

Cada persona queda asignada a una etapa del proceso: Una haciendo el batido, una haciendo el horneado, etc). Otras personas "del público" van pasando y haciendo “Pedidos”. Hacer un pedido es pegar un post-it en la columna Pedidos. Cada persona cuenta la cantidad de segundos que demora su etapa y pasa el post-it a la siguiente etapa.

Los tiempos establecidos llevan a que se genere un cuello de botella en el Decorado, mientras que el Empaque (packaging) estará ocioso la mayor parte del tiempo.



Métricas:

El Thoughput es la cantidad de pedidos entregados. Para esto se cuentan los post-its entegrados al final de la iteración. Cuanto más pedidos entregados más productividad.

El Work In Progress es la cantidad de pedidos que ingresaron al sistema y todavía no se entregaron. Para esto se cuentan cuantos post-its hay en el tablero Kanban. Cuanto más post-its mayores son los costos operativos y menor es la eficiencia del sistema.

Retrospectiva: en la retrospectiva preguntamos qué se observó y que conclusiones hay. Se debería notar que la persona en Packaging estuvo ociosa y la persona en Decorado tiene mucho trabajo sobre la mesa. Explorar posibles soluciones.

El primer aprendizaje aquí, es que una etapa NO es un departamento o una persona separada, sino que es el flujo por el que el producto (la torta) va pasando y evolucionando. Por lo tanto cualquiera podría ayudar donde el flujo está atascado. La persona en Packaging podría ayudar a la persona en Decorado.

Naturalmente las personas podrían sugerir incrementar la capacidad, es decir contratar más personas para trabajar donde está el cuello de botella, sin embargo, esto debería ser el último recurso. En este caso logramos eliminar el cuello de botella con la misma cantidad de personas, permitiendo que cualquiera puede ayudar a otro cuando hay un cuello de botellas. Así, la persona en Packaging si está ociosa ayuda en el Decorado.

La cantidad de post-its en “Delivery” es la cantidad de tortas que se pudieron producir por este sistema (conocido como “throughput” en lenguaje Lean). A mayor cantidad más productividad.  Además la cantidad de post-its en el resto de las columnas del sistema es la cantidad de trabajo en progreso total (a menos número mayor eficiencia). Es útil contar cuantos post-it hay en cada iteración (Terminados y En Progreso) para obtener conclusiones.

Iteración 2:


Para la segunda iteración, además del cambio mencionado vamos a introducir el concepto de “pull”, y para demostrarlo vamos a dividir cada columna en dos (En curso y Hecho). La persona toma el trabajo de la columna “hecho” de la etapa anterior cuando tiene capacidad, en lugar de recibir el trabajo directamente en su columna. De esta manera se puede ver el tamaño del buffer (cola) en cada momento y la cantidad de trabajo en progreso (por el momento es una sola torta por vez).





Tener en cuenta siempre, que las personas que no están participando deben observar analíticamente el flujo de post-its y comentar sus conclusiones. En cada iteración, rotar a las personas para que todos puedan participar y todos puedan observar.


Retrospectiva:En esta iteración se debe lograr mayor cantidad de post-it en delivery (throughput), eliminar el cuello de botellas y menor cantidad de post-its en progreso en el sistema.

Iteración 3:


Ahora, vamos a introducir el concepto de limitar la cantidad de trabajo en progreso por cada etapa. El límite sugerido es dos por persona. Y también limitar la cantidad de Pedidos para procesar.

Otro concepto a incorporar es el “Bloqueo / Impedimento”. Una persona se va a dedicar a poner bloqueos. Un bloqueo puede por ejemplo, que se rompió la máquina, que nos quedamos sin huevos para el batido, etc. Se representa con un post-it de otro color sobre el post-it del trabajo. Un bloqueo solo puede ser desbloqueado pidiendo ayuda a otra persona, que debe venir y quitar el bloqueo. Además debe tomarse 10 segundos para desbloquear.



Retrospectiva:

Naturalmente, cuando una tarea está bloqueada, la dejamos ahí y comenzamos a trabajar en una nueva. Sin embargo, la restricción de WIP (Work in Progress) nos fuerza a pedir ayuda y desbloquear el trabajo, haciendo que el trabajo fluya.

Tips: Conviene que participen personas con menor experiencia en Kanban, para que la simulación no se vea influenciada por los conocimientos de los participantes.

Conclusión:




Cerrar el ejercicio con una conclusión generada por el grupo en base a la experiencia. Basarse en los Principios de Kanban y el foco en entregar valor al cliente.

Agradecimientos a @julibetancur por las ilustraciones! @jolycent y @lamothe30 por las fotos y a @bastianhell por ayudarme en la facilitación!

#KanbanCakes


Descargar las Imágenes

Si querés ponerlo en práctica, podés descargar e imprimir las imágenes originales, ilustradas por  @julibetancur  para este taller.

Si lo utilizas, no olvides Twitear alguna foto con el hashtag #KanbanCakes y si tienes feedback para mejorar la actividad, te agradeceré que me cuentes.

[ DESCARGAR ]



Si te gustó y se te ocurren mejoras no dudes en dejar tu comentario!

Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico
Damián Buonamico






Soy Scrum Master - Que hago el resto del día. Foto: Marcelo Larroque
Me lo preguntan los participantes de talleres ágiles y durante sesiones de agile coaching. Se la hacen a sí mismos todos los Scrum Masters cuando son designados a cumplir su rol: ¿Qué debería hacer durante el resto del día? ¿A qué me dedico cuando no estoy facilitando eventos de Scrum?

La tendencia natural es continuar haciendo las mismas actividades del rol que se desempeñaba antes de ser designado Scrum Master. De esa manera, terminamos obteniendo Scrum Masters con dedicación part-time. Dentro de ese esquema, la persona permanece dentro de su zona de confort: no necesita seguir emprendiendo y aprendiendo el nuevo desafío de ser Scrum Master para crecer en su carrera profesional. Así, el nuevo rol se reduce a un conjunto de tareas a cumplir planificadas para cada Sprint, que se adicionan a las tareas del antiguo rol.

Otra situación que se suele dar, es la de los Scrum Masters que trabajan para dos equipos o, incluso tres. Estos casos también tienen como consecuencia Scrum Masters que cumplen con tareas básicas pero no cuentan con tiempo suficiente para “hacer su magia”.

(Fotografía: Marcelo Larroque)



Citando a Michael James:
A good Scrum Master can have two teams, 
a great Scrum Master will only have one team.

(“Un buen Scrum Master puede facilitar dos equipos,
 un gran Scrum Master facilita un solo equipo”).

La experiencia nos permite ver los “problemas” y encontrar por todos lados desafíos sobre los que accionar para ayudar al equipo. Esto sucede porque somos capaces de hacer lo que está dentro de nuestro dominio de habilidades, identificamos áreas de mejora basándonos en los conceptos que adquirimos previamente. Eso se aprende solamente fuera de la zona de confort.

Yo mismo me encontré haciendo la pregunta que origina este artículo cuando estaba iniciando mi rol de Scrum Master. Afortunadamente estaba dedicado a un sólo equipo, aunque compartiendo la responsabilidad con mi posición anterior como Analista QA.

Yo también, en mi comienzo, fui Scrum Master part-time. Mi posición como Scrum Master full-time fue algo que me gané, al demostrar a la organización que debía “soltar” el rol anterior para enfrentarme a todo lo que había que cambiar y mejorar. Creo que a medida que el Scrum Master comienza a entender el rol, descubre que hay una cultura organizacional que está esperando ser desafiada, y se convierte así en un agente de cambio.

Recomendaciones

Una práctica que puede resultar de utilidad para darte cuenta de todo lo que puedes hacer o propiciar en tu equipo y en tu organización, consiste en realizar al equipo, a los stakeholders y a ti mismo, las siguientes preguntas:
  • El equipo, ¿funciona a la perfección?
  • ¿Están todos satisfechos con el resultado y con el proceso?
  • Los artefactos, los eventos, las dinámicas de colaboración y trabajo en equipo, ¿funcionan tan bien como es posible? ¿Por qué no? ¿Qué les falta?
Puedes ayudarte con herramientas de autoevaluación como el Scrum Checklist, y el Barómetro de Equipos, entre otros. De seguro, ¡te llenarás de trabajo para los próximos 10 años!

Cuando descubras que en “casa” (tu equipo) hacemos las cosas bien y que los problemas vienen de “afuera” tendrás dos alternativas:
  1. Quejarte en retrospectivas catárticas
  2. Hacer los reclamos efectivos pertinentes. 
Si eliges la segunda opción, tu trabajo estará en la interacción con otros equipos, desafiando los comportamientos que afectan a la colaboración y a la autoorganización. Luego el camino seguirá en subida, trabajando con otras áreas de la organización, fuera de IT. Será un desafío que requerirá la colaboración de líderes y directivos, para hacer visible el impacto de ciertos comportamientos organizacionales en el rendimiento de los equipos.

El objetivo no es estar siempre ocupado al 100%, sino entregar valor a la organización. Para ello, los momentos de menor demanda permiten trabajar en mejoras de otro nivel: preparar experimentos, innovar, reflexionar sobre tu desempeño y el del equipo.

Como Scrum Master, también debes estar encargado del desarrollo de tus propias habilidades y del de las comunidades de práctica dentro de tu organización, y también fuera de ella.


Herramientas para Scrum Masters


Para inspirarte te comparto un listado de con competencias que puedes desarrollar como Scrum Master y otro listado con 42 tareas a atender.

Competencias de Desarrollo para Scrum Masters (Inglés)
http://www.journey-to-better.com/2014/04/scrum-master-competencies.html

Scrum Master Checklist (Español)
http://scrummasterchecklist.org/pdf/scrummaster_checklist_spanish.pdf

Barómetro de Equipos - Dinámica de Autoevaluación - (Español)
http://www.caminoagil.com/2016/11/tarjetas-barometro-de-equipos-cartas.html

Scrum Checklist - (Español)
http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html


Ser un agente de cambio y encontrarse con fuerzas de resistencia no es una tarea fácil. Nunca es fácil salir de la zona de confort y hacer lo que tal vez nadie en la organización intentó hacer hasta el momento.


Damián Buonamico
Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico

Fotografía de Portada: Marcelo Larroque


En mis últimas vacaciones pasé bastante tiempo contemplando el mar al tiempo que leía La quinta disciplina, el libro de Peter Senge sobre organizaciones y aprendizaje. Creo que la combinación de esas tres cosas (tiempo, mar, libro) me trajo una nueva conciencia que les comparto.

En los días de viento noté que los bañistas y embarcaciones pasaban momentos agitados en una parte del agua mientras que estaban más tranquilos en otras. Esa parte es lo que normalmente llamamos “la rompiente”.

Algunos decidían pasar con valentía esa región agitada, otros regresaban unos pasos. Sin embargo, me llamaron particularmente la atención los que se quedaban ahí, en algunos casos arriesgando la integridad física (bañistas y embarcaciones).

¿Hablaremos solo del mar?

No, esta introducción se debe a que me resonó esta escena con la que he visto en los últimos años en organizaciones que desean abandonar la playa hacia el mar de nuevos desafíos (en algunos casos por decisión propia, en otros casos forzadas por una situación amenazante).

El temor a lo desconocido y al cambio deja a las organizaciones que conozco en la rompiente, ese lugar intermedio en el cual sufren los embates constantes y desgastantes sin ver que unos pasos más allá las condiciones mejoran.

Esos pasos adicionales pueden parecer una amenaza para estas empresas, pues significan estar en aguas más profundas donde probablemente necesitemos otras habilidades. Sin embargo, la rompiente es el peor lugar en el que podrían estar.

¿Qué podemos aprender de esta metáfora?

Para mí, un primer aprendizaje fue que si vamos suficientemente profundo (un poco más que en la orilla), las cosas funcionan mejor, las piezas encajan.

He visto organizaciones en la rompiente, con el desgaste que esto significa, cuando implementan cambios equipos de desarrollo (por ejemplo Scrum) y ahí se detienen. Si el resto no cambia (especialmente los líderes) y tampoco cambian las decisiones sistémicas, lo usual es que el desgaste por la fricción ponga en riesgo la iniciativa..

Los equipos comienzan a aplicar las nuevas ideas, usualmente con la rigidez típica de quien está aprendiendo mientras que los directivos siguen con el modelo mental anterior, es decir, siguen buscando los resultados con las formas que conocen y han funcionado toda la vida.

El problema aquí no es que una o la otra forma está mal o bien, el problema es el desajuste que se sostiene por mucho tiempo. Creo que esa es la oportunidad de dar un paso más para salir de la zona de desgaste máximo.

¿Ya pasaste la rompiente?

Las organizaciones que transitan las rompientes actuales y llegan a la calma han dado exitosamente el primer paso. Pronto se darán cuenta de que es mejor prepararse para transitar rompientes más frecuentemente, en un proceso de evolución constante (shapeshifting, en inglés).

Mi segundo aprendizaje es que, si desarrollamos las habilidades para conducirnos siempre en aguas turbulentas, estaremos mucho mejor como organización en constante evolución.

No detallaré esas otras habilidades en este artículo. Les dejo una referencia una carta (en inglés) de Jeff Bezos a los accionistas y un análisis (en español) de esa carta.

Foto: https://flic.kr/p/edFwkm



Copyright © Kleer 2017