Blog

"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


Cultura Ágil y Cultura Argentina.



Cuando adoptas para tu empresa una solución creada en otro contexto, ¿Tenés en cuenta la idiosincrasia de tu organización y de tu país? El contexto es un factor crítico para el éxito!

El artículo de Luis Gonçalves "Cinco motivos por los que Agile no funciona en Alemania" me llevó a pensar sobre los aspectos culturales y contextuales en Argentina.




Podemos encontrar diversos ejemplos en la industria intentando imitar modelos y soluciones, como en el caso de Toyota (Lean, Toyota Kata) y el Modelo Spotify, sin lograr los resultados esperados. Esto ocurre cuando se intenta copiar una solución como si fuera seguir una receta sin comprender las diferencias culturales y el contexto en la que esa solución particular funcionó bien. La cultura japonesa (Toyota) y la sueca (Spotify) son muy distintas a la forma de pensar de los argentinos.

Considero que Agile funciona en Argentina, siempre y cuando tengamos en cuenta algunos factores que nos caracterizan.


1. Estrategias a corto plazo

En Argentina, el contexto socio económico es volátil. Las estrategias y políticas del gobierno cambian con frecuencia, la inflación es elevada y la incertidumbre hace que las inversiones de "largo plazo" sean a 6 meses (cuando en paises desarrollados son 10 años). Esto provoca incertidumbre sobre el futuro y planificación resulta de muy corto plazo. Resulta poco efectivo planificar a mediano y largo plazo en un contexto cambiante. Así, nuestro cerebro se configura para pensar en el corto plazo.

Implementar la mejora continua (Toyota Kata) y la reducción de desperdicios para optimizar al máximo los procesos son inversiones de largo plazo. En Japón estas prácticas se apoyan en los supuestos de estabilidad en el largo plazo. Lleva muchos años de trabajo alcanzar los niveles de mejora y optimización que se logran en ese país. La cultura japonesa se basa en la confianza entre las personas que se logra cuidando relaciones de muchos años (incluso con proveedores y clientes).

El contexto Argentino es diferente, las estrategias se miden en meses más que en años. Las relaciones laborales no son de por vida.


2. Inversión en calidad más limitada

También como derivado del pensamiento cortoplacista, en Argentina es más difícil la inversión en resultados de alta calidad en el largo plazo. Muchas veces nos vemos limitados a priorizar resultados visibles en el corto plazo, por sobre soluciones de alta calidad sostenibles en el tiempo. La presión de tener los resultados "ya" es muy grande. Un ejemplo común es adquirir "deuda técnica" para cumplir objetivos cercanos y comprometer la calidad en el futuro.

3. Ahorrar en costos

Siguiendo con la línea del punto anterior, en Argentina experimentamos crisis económicas y recesiones periódicas. Por lo tanto nuestra mente está programada para reducir gastos y ahorrar en costos, en perjuicio de la calidad y con mayor predisposición a asumir riesgos.

Algunos ejemplos de estas estrategías son: Contratar a un perfil Junior en lugar de una persona con experiencia y capacitación. O saturar la capacidad de las pesonas, teniendo una al límita en lugar de dos que trabajen tranquilos y puedan atender momentos de picos de demanda sin convertirse en cuellos de botella y aplicar mejora de procesos cuando hay menos demanda. Vemos esto también aplicado a personas cumpliendo más de un rol o asignadas a más de un proyecto.

Con frecuencia juega en contra pensar que maximizando la utilización de recursos se obtiene mayor rendimiento: si bien se reducen costos, se paga el precio de menor en productividad final.

4. El Orgullo Argentino

El estereotipo argentino es más orgullosos que humilde. Es difícil para un argentino promedio aceptar que necesitamos ayuda de otros y que "nos vengan a decir cómo tenemos que hacer las cosas". Esto provoca resistencia al cambio, a la colaboración y en particular también a adoptar nuevas metodologías.

Los argentinos tendemos a cuestionar y desafiar las propuestas. Estamos acostumbrados a criticar más que escuchar nuevas propuestas, aceptar y probarlas. Pensamos que ya sabemos todo, que "eso no va a funcionar". Nos gusta hacer las cosas a nuestra manera y recibir crédito por ello. A diferencia de lo que podríamos encontrar en una empresa Sueca como Spotify.

Aunque se trate de una generalización, no cabe dudas de que tendremos que lidiar con este tipo de personalidades en nuestro trabajo.


Entonces ¿qué podemos hacer?


La buena noticia, es que siendo conscientes de los factores culturales se pueden implementar todas las soluciones, haciendo las correspondientes adaptaciones al contexto y teniendo en cuenta como se suceden las interacciones y competencias relacionales en Argentina.

Una herramienta sirve para resolver un problema determinado. Para hacer las adaptaciones correspondientes es importante comprender cada herramienta. Por ejemplo, implementar una Daily Stand-up Meeting, sin entender cuál es el propósito y qué problema resuelve, representa un riesgo al fracaso.

Primero, tenemos que preguntarnos: ¿Qué problema intenta resolver esta herramienta? ¿Nosotros tenemos este problema hoy? ¿Esta solución resuelve el problema de manera efectiva para nosotros? Seguidamente, asegurarse que el equipo entiende el propósito y está de acuerdo con el problema y la solución.

Una estrategia efectiva para lograr este acuerdo es permitir que el problema en cuestión se evidencie en el equipo, tener una conversación donde se haga visible el problema y luego proponer la solución. Los argentinos somos muy pasionales y ponemos mucha garra para trabajar en algo cuando estamos de acuerdo con la situación.

Por último, pero no menos importante, es trabajar sobre la cultura organizacional y la cultura del equipo, para lograr un equipo de alto rendimiento. Desarrollar competencias relacionales efectivas y confianza entre los miembros del equipo.

Acostumbrados a vivir con restricciones, los argentinos sabemos ser muy creativos para lograr los resultados independientemente de la situación que nos toque vivir. También somos sumamente capaces y altamente capacitados.

Cuando se tienen en cuenta los factores expuestos en este artículo podemos lograr confianza, colaboración y apertura para implementar cambios. Podremos apalancarnos en todas las características mencionadas a favor de la organización y del alto rendimiento.




Este artículo tuvo buenas repercusiones:

http://www.pmpmedellin.com/430856317/4494366/posting/qu%C3%A9-tan-compatible-es-la-cultura-%C3%A1gil-con-la-cultura-colombiana

http://www.totalmedios.com/nota/30798/cultura-agil-y-cultura-latina-son-compatibles

http://www.canal-ar.com.ar/23978-Cultura-agil-y-cultura-latina-son-compatibles.html

http://www.ebankingnews.com/columnas/cultura-agil-y-cultura-latina-son-compatibles-0036865

http://www.latinspots.com/sp/tendencias/detalle/42924/cultura-gil-y-cultura-latina-son-compatibles

http://libretadeapuntes.com/2017/02/cultura-agil-y-cultura-latina-son-compatibles/

http://www.elcontact.com/2017/02/cultura-agil-y-cultura-latina-son.html

Por Pablo Lischinsky @pablolis y Ricardo Colusso @rcolusso El Framework Scrum promueve el rol de “Product Owner” (PO) y si bien su concepción y descripción original no ha evolucionado mucho, el contexto actual de las empresas y de las transformaciones digitales sí ha cambiado las exigencias sobre este importante rol. En este trabajo cuestionamos el … Leer más "Product Owners que potencian las Transformaciones Digitales"

Me he preguntado por un largo tiempo si acaso la agilidad es más que mi trabajo, más que un cúmulo de ideas, principios, valores y herramientas que ayudan a aumentar números y estadísticas en una organización, o acaso es parte de ese pedernal que impulsa mi vida y me apasiona al saber que estoy generando lazos e impactando en personas, equipos, organizaciones y ellas a mí.

Cuando comencé con este blog tenía un norte claro, compartir conocimiento y experiencias. Pero poco a poco las ganas de escribir se fueron diezmando con el día a día que suele consumir a los soñadores. Ahora de a poco voy re descubriendo mi propia cruzada tomando este espacio como catarsis y haciendo retrospectiva cada tanto sobre la manera de renovar pasiones ante los muchos obstáculos que aparecen cada día al intentar transformar el mundo!!

Dejando un poco de lado la motivación que me trajo hasta aquí y claro hablando de esos obstáculos que me he encontrado en mi paso por distintos contextos que están adoptando la agilidad me he decidido a escribir sobre el ritmo sostenible en los equipos de trabajo colaborativo, que si bien muchas organizaciones parecen conscientes de su importancia, el status quo sigue siendo “trasnochar”, “el crunch”, “dar el 110%”, etc…y parece ser algo normal.

Las marchas de la muerte (metáfora que se refiere a una fecha inalcanzable con todo el equipo sufriendo) son un problema que aqueja a las industrias creativas desde tiempos inmemoriales.

Acercándome un poco más a una industria conocida para mí, los desarrolladores de videojuegos se enfrentan en su día a día a marchas de la muerte, que aumentan entre más avanzado esté el proyecto como una bola de nieve lo que lleva al agotamiento y al éxodo de la industria, justificado en gran medida con frases que seguramente suenen muy conocidas como:

“No estés en la industria del videojuego si no puedes amar las 80 horas de trabajo por semana, estás tomando el trabajo de alguien que realmente lo valoraría” y “Si no cumplimos el deadline nos cancelan el proyecto, ustedes verán”

Respecto al ritmo sostenible Rami Ismail resume que Los equipos deben encontrar un ritmo sostenible que puedan trabajar a largo plazo. Esto significa trabajar cerca de 40 horas por semana la mayor parte del tiempo con períodos de crisis que no duren demasiado.

Pero ¿cuánto puede durar ese periodo de “crisis” antes de convertirse en una marcha de la muerte que condena al fracaso el proyecto? Hay estudios que muestran la efectividad real de la crisis.

En medio de vagos recuerdos de un proyecto incendiado de esos que ni Uncle Bob puede apagar, buscando una estrategia que nos llevara a cumplir la fecha de entrega para el publisher “pedimos” al equipo que trabajará 6 días a la semana con una intensidad de 10 horas diarias, lo que nos llevó a un resultado similar a esto:

marchas-de-la-muerteLa primera semana fue una semana normal de ~40 horas. Las semanas 2 a 4 fueron las semanas de 60 horas (aumentando entre más cerca el deadline). Lo primero que notamos es que el tiempo extra en la semana 2 provocó que la velocidad aumentara de manera notable. ¡Más “cosas” se estaban haciendo! (¿Pero a qué costo?) Sin embargo, la velocidad disminuyó muy por debajo de la velocidad normal luego de eso, con tendencia a ser cada vez menos productivos.

¿Cómo es esto posible? Es sencillo, la gente se cansa, comete más errores y pierde el incentivo para crear valor. Como alguna vez charlamos con un viejo amigo:

“Un programador en un deadline a las dos de la mañana es como un borracho bailando, en ese momento cree estar en su estado de flow y ser el mejor bailarín, pero a la mañana siguiente cuando ve los videos lo mejor que puede hacer es borrarlos”, mejor conocido como el efecto código de borracho.

Ahora, claro que existe ese estado de “Flow”. Muchas veces vi equipos trabajando hasta la madrugada en un juego por el que se apasionaban mucho y llegaron a esa zona altamente productiva. Nunca duró más de un par de semanas y con un buen descanso luego de eso.

El error que los líderes suelen cometer es pensar que el efecto es también la causa. Pensar que obligar una persona a trabajar 80 horas a la semana los pondrá en estado de “Flow ”. Eso es como obligar a alguien a sonreír para que sea feliz. No funcionará.

Los límites del equipo necesitan ser entendidos. Una autopista llena al 100% de capacidad es un estacionamiento. Trabajar más horas para pretender ir más rápido es como intentar apagar un incendio con un vaso de agua (sin hablar de la deuda técnica que hará ir aún más lento en el futuro), consiguiendo que los proyectos se estanquen en esa marcha de la muerte interminable en la cual entre más horas trabajamos, más lento parecemos ir.

Y aquí es donde juega un papel importante el agente de cambio ágil, pues es necesario enfrentarse a los problemas con coraje… Si la marea sube, el barco también sube. Pues se necesita mucho coraje para comenzar un proyecto con ritmo sostenible y calidad técnica.

Existen maneras de  evitar las marchas de la muerte y fomentar el ritmo sostenible, como limitar el wip o el slack time. Sin embargo algo de lo cual he obtenido mucho valor es sobre la creación de evidencia empírica sobre qué funciona y qué no.

Esta es la razón por la cual no hay una “regla” específica que defina cómo debe hacerse algo, “no hay un solo ritmo, sino varios y es bueno hacerse siempre la pregunta de cuál es el ritmo adecuado para cada cosa” Thomas Wallet.

Al final del día todo depende de las situaciones, interacciones y contextos que definen la realidad de cada equipo. La única manera de descubrir cuál es su propio ritmo sostenible es lanzándose al ruedo y averiguarlo!!

Pues ¿Qué más es la agilidad sino una expresión del método científico?


¿Qué tiene que saber, ser y tener un Product Owner para ser “ideal”?   Introducción Existen varias interpretaciones para el rol “Product Owner” de Scrum, definido de forma oficial en la Guía de Scrum. Este “Checklist latino” pretende ser una herramienta útil para que tanto Product Owner’s como Scrum Masters y personas del negocio puedan … Leer más "Un Checklist latino para Product Owners"


Copyright © Kleer 2017