29 de diciembre de 2011

¿Cómo hacer retrospectivas con equipos distribuidos?

No hay caso: siempre es mejor la retrospectiva cara a cara, donde todo el equipo está presente en el mismo lugar. Permite ampliar fuertemente y hacer más fluida la comunicación entre todos, el contacto visual, la lectura de expresiones corporales, etc.

Sin embargo, a veces la situación no es ideal, el equipo está distribuido y no siempre se puede reunirlo físicamente. En estos casos, aconsejo lo siguiente:
  1. Tratar de todas las formas posibles de reunir el equipo físicamente para la retrospectiva. 
  2. Si no se puede, hacer una retrospectiva distribuida. Me parece una lástima no usar esta herramienta fantástica que es la retrospectiva por el pretexto de la distancia geográfica. Obviamente no va a ser igual, quizás la calidad de la retrospectiva no sea la misma, pero aún así me parece que vale la pena hacer la actividad.
Dicho esto, quiero compartir algunos tips que pude valorar en retrospectivas distribuidas:

  • Sobre el Espacio Compartido
Con equipos distribuidos, a veces la tentación es fuerte de no hacer una retrospectiva, aunque sea virtual. Y en algunas ocasiones se prefiere pedir a los miembros del equipo para que hagan su retrospectiva personal y manden sus conclusiones por email. Eso es lo peor que se puede hacer!
En equipos distribuidos me parece crítico tratar por todos los medios posibles de aumentar y cuidar las instancias de comunicación para limitar el déficit comunicacional generado por la distancia. Para las retrospectivas en particular es fundamental establecer un espacio (virtual) en un tiempo compartido por todos.

Con lo cual, mis recomendaciones para garantizar el espacio compartido son:
  1. Convocar la reunión con anticipación, teniendo en cuenta las particularidades de cada locación involucrada (por ejemplo en una locación terminan de trabajar a las 17h, en otra tienen 2h de almuerzo, etc.).
  2. Garantizar la presencia de todos en el horario acordado, con los medios y las herramientas correspondientes.
  3. En cada locación, velar por lograr buenas condiciones para la retrospectiva (por ejemplo que el ambiente no sea muy ruidoso, que se pueda hablar sin molestar a nadie, etc.).
  4. Durante la retrospectiva, si una persona se va, es importante que lo notifique explícitamente a todo el equipo, ya que no hay otra forma de darse cuenta. De la misma forma es importante que el facilitador avise explícitamente cuando inicia la retrospectiva, cuando termina, y eventualmente cuando se hacen pausas.

  • Sobre la Comunicación Verbal
Al no estar físicamente juntos, el soporte a la comunicación durante una retrospectiva es crítico, y hay que tomarlo como tal. 

Para comunicación verbal, se puede usar el teléfono, skype, gtalk o alguna otra opción equivalente. Es importante probar previamente el medio elegido, para asegurar que se escuche bien a todos, que no haya cortes, etc.

Mis recomendaciones para garantizar la comunicación verbal son:

  1. Elegir el mejor soporte a la comunicación verbal disponible. Eventualmente tener un Plan B por si se cae la comunicación en el medio de la retrospectiva.
  2. Garantizar la disponibilidad de uso de los dispositivos (por ejemplo que haya micrófonos y auriculares disponibles, o teléfono con alto-parlantes, etc.).
  3. Probar entre todos el soporte previo a la reunión para asegurar su buen funcionamiento. 
  4. Durante la retrospectiva, es importante que el facilitador haga periódicamente chequeos para asegurar que todo el mundo sigue escuchando bien y pueda hablar sin problema. 

  • Sobre la Comunicación Visual
Ver a los miembros del equipo que no están presentes en el mismo lugar es una fuente de información muy importante. En las retrospectivas, donde muchas veces afloran las emociones, la información visual y corporal aporta mucho contexto, y es uno de los aspectos más difíciles de garantizar en retrospectivas distribuidas. Además –y sobre todo si la reunión se extiende más de 1h- es mucho menos cansador poder ver a los interlocutores para mantener la atención y concentración en la reunión.

Conviene llevar al extremo todos los medios disponibles para tratar de compensar la distancia física. En particular los check-in / check-out de las retrospectivas son actividades que hay que cuidar mucho con equipos distribuidos (ver por ejemplo esta explicación de check-in/check-out por Ingrid Astiz). Es el momento donde todo el equipo escucha a los miembros uno a uno. Contar con vídeo para ver la cara y/o el cuerpo de la persona que habla durante el check-in y check-out aporta un contexto visual muy útil para la retrospectiva.

Mis recomendaciones sobre la Comunicación Visual son:
  1. Si se puede contar con una instalación para hacer video-conferencias, usarla. Lo mejor es poder compartir una pantalla para trabajar y otra para ver la gente participando.
  2. En caso de no contar con tal instalación, recomiendo usar Skype o Google+ Hangouts con webcams, o algo similar.
  3. En la eventual ronda de check-in y check-out de la retrospectiva, recomiendo usar el video. En particular resulta muy útil enfocar la cara y/o el cuerpo de la persona que habla en estos momentos. 
  4. Como siempre, garantizar los medios (webcams, etc.) para la vídeo y probar previamente que todo funciona bien.

  • Sobre el Soporte Colaborativo
A mi gusto trabajar con post-its, marcadores y rota-folios en las retrospectivas presenciales es fantástico e incrementa notablemente la colaboración. En las retrospectivas distribuidas es otro aspecto complicado de implementar.

Sin embargo existen algunas herramientas para ayudarnos con eso. Personalmente he hecho retrospectivas distribuidas con planillas colaborativa en google docs y pizarra colaborativa de post-its en Edistorm.

Si bien todavía tiene algunas funcionalidades a mejorar, recomiendo muchísimo Edistorm. Es una herramienta estupenda que fue para mí un gran habilitador para hacer retrospectivas distribuidas. Básicamente Edistorm permite escribir post-its y compartirlos en un pizarra colaborativa en tiempo-real. Además tiene un mecanismo básico para poder votar sobre los post-its compartidos. En la captura siguiente podemos ver parte del resultado de una retrospectiva distribuida. En azul uno de los problemas tratados colaborativamente,  en verde las acciones de mejora elegidas y en amarillo otras acciones de mejora que no fueron elegidas.







Mis recomendaciones sobre el Soporte Colaborativo:
  1. Elegir herramientas que permiten la colaboración en tiempo real, o sea que cada uno pueda ver en el momento lo que está editando el otro. 
  2. Contar con un proyector en cada locación o con una notebook/PC para cada participantes (o eventualmente cada 2 participantes), para que todos puedan seguir en tiempo real lo que pasa en la herramienta.
  3. Buscar herramienta que traten de re-crear el trabajo con post-its, como por ejemplo Edistorm. Identifiqué otras herramientas similares que no llegue a probar todavía en retrospectivas:  Twiddla, CardMeeting, Cacoo, BubbleUs, LinoIt, Corkboard
  4. Preparar antes lo necesario (por ejemplo crear y compartir el soporte entre todos, crear usuarios/claves, armar la estructura de post-its necesaria en la herramienta, etc.).
  5. Que el facilitador de la retrospectiva explique el uso de la herramienta a todos, para que no sea una traba a la hora de usarla. Elegir herramientas de uso simple. 
  • Sobre el Cierre de la Retrospectiva
En las retrospectivas se recomienda terminar la reunión con un momento de feedback donde cada uno cuenta como percibió la reunión y/o como se sintió. Sin embargo, para las reuniones distribuidas, debido a la limitación comunicacional, suele ser difícil captar lo que siente cada participante si no se expresa explicitamente. Por ejemplo a veces no se puede notar a la distancia la cara de enojo de un participante. En retrospectivas es clave encontrar formas alternativas de expresión de este feedback. 

Por otro lado, las interferencias comunicacionales en las retrospectivas distribuidas son comunes (por ejemplo se escucha mal, hay ruido de fondo, se corta la comunicación, no se sabe quien habla, etc.). Para poder  sacar provecho igual, suele ser útil manejar cierta redundancia en las conclusiones de la reunión o en la información critica expresada.

Mis recomendaciones sobre el Cierre:
  1. Hacer un ejercicio especifico de check-out o bien pedir feedback sobre la retrospectiva a cada uno. Es importante tomarse el tiempo necesario para que cada uno a su tiempo pueda expresarse y ser escuchado sobre el tema. En particular pedir feedback sobre como impacto el hecho de estar distribuidos.
  2. Mandar a todos los participantes luego de la retrospectiva un resumen escrito de los resultados importantes de la retrospectiva (eventualmente quedan documentados en la herramienta elegida).

Dos reflexiones para cerrar (ya escribí mucho):

Para mí el agilismo implica un aprendizaje continuo, y por eso recomiendo ser tolerante con la retrospectiva actual y exigente con la próxima, en particular cuando se trata de equipos distribuidos. De esta forma podremos equivocarnos, aprender y descubrir entre todos mejores formas de hacer retrospectivas distribuidas. De a un paso a la vez...

Veo la retrospectiva como la herramienta más eficiente de consolidación de equipo (a veces se habla de team building, pero personalmente prefiero el termino de "Team Jelly", que vi en el gran libro Peopleware). En el caso de equipo distribuido, las posibilidades de hacer actividades que aportan a la consolidación de equipo son más limitadas que en equipos locales, con lo cual creo que hay que dar una importancia especial a las retrospectivas distribuidas. 

23 de diciembre de 2011

Dinámica de Retrospectiva: 3 caras y 4 capas

Me pareció muy buena esta dinámica de retrospectiva propuesta por Pablo Tortorella, que combina los conceptos de las 4 Capas de Raúl Uribe con la conocida técnica de retrospectiva Sad/Mad/Glad.








  • Nombre: 3 caras y 4 capas
  • Participantes: 5 a 12 personas
  • Duración: 25 a 40 minutos
  • Alcance: al finalizar una iteración corta (4 semanas o menos)
  • Propósito: recabar información e indagar
  • Facilitación: necesaria
  • Objetivos: Esta dinámica grupal permite identificar aspectos positivos o negativos de una iteración y clasificarlos con una taxonomía integral.
  • Material y Preparación: post-its, un  tablero o pared donde se puedan pegar los post-is, marcadores para cada participante. Se necesita únicamente preparar el tablero, pegando los post-its de columnas (Caritas) y lineas (Capas), como en el diagrama siguiente: 



  • Pasos:
    1. Quien facilita explica el objetivo de la actividad. En particular es importante explicar las 4 capas y dar ejemplos que permitan a quienes participan hacer la diferencia entre cada una de estas capas. Ver por ejemplo esta explicación de Ingrid Astiz, o este vídeo. Para explicar los conceptos de Mad/Sad/Glad, se puede usar esta definición
    2. Cada persona participante escribe en post-its algunos aspectos de la iteración que la dejaron frustrada o enojada (Mad), aspectos que la pusieron triste (Sad) y aspectos que la pusieron feliz (Glad). 
    3. Luego, las personas participantes presentan una a una uno de sus post-its, y en conjunto con el grupo identifica en que línea se tiene que ubicar, según si tiene que ver con Técnicas, Metodología, Filosofía o Ecosistema. Eventualmente se puede dividir el post-it en varios si abarca aspectos de varias capas. Si otra persona participante tiene un post-it muy similar, lo presenta y se pegan los dos post-its juntos. 
    4. Una vez pegados todos los post-its, quien facilita ayuda al grupo a revisarlos para discubrir post-its que se puedan unir, algunos que haya que dividir, identificar algunos patrones o relacionar post-its de una misma temática. 



En esta foto se utiliza una variante mezclando Mad/Sad/Glad con Keep/Fix/Try.



    1. Variantes:
      • En lugar de las caras Sad / Mad / Glad, se puede utilizar los conceptos de Start Doing / Keep Doing / More Of / Less Of /Stop Doing de la técnica de retrospectiva Estrella de Mar.
      • Se pueden usar distintos colores de post-its según la columna (por ejemplo rojo para mad, naranja para sad y verde para glad), o según la línea de la matriz.
      • Se pueden usar un color de post-its para aspectos positivos (Glad) y otro color de post-its para aspectos negativos (sad/mad). De esta forma al final se puede destacar visualmente las capas donde hay más aspectos positivos y las donde hay más aspectos negativos.
      • Hacer la actividad sin introducir las 4 capas (solo Mad/Sad/Glad). Una vez ubicados todos los post-its en estas columnas, introducir las 4 capas y revisar los post-its para ubicarlos en las capas correspondientes. 
    2. Tips:
      • Es fundamental la explicación inicial de las 4 capas, para que cada participante pueda entender los conceptos y luego incorporarlos para el resto de las actividades. Puede ser muy útil dar varios ejemplos de cada capa. 
      • En función de la cantidad de participantes, quien facilita puede imponer la cantidad de post-its por persona y columna. Por ejemplo si hay mucha participación, puede ser bueno que cada persona escriba solamente un post-it por columna. 
      • Quien facilita debe estar atento a los post-its ambiguos ("no se documenta suficiente"), demasiado abarcativos ("no tenemos metodología"). Si surgen estos casos, puede ser útil que ayude a la persona a refinar la idea.
      • Quien facilita debe ayudar al grupo a identificar/definir los problemas, y dejar para una actividad posterior las propuestas de mejora.
      • Esta actividad es una buena base para luego trabajar la priorización de los temas más críticos y desarrollar acciones de mejora.
    3. Origen: Pablo Tortorella - Matriz de Retrospectiva

    Espero que esta dinámica los inspire y aguardo sus comentarios, mejoras, ideas, etc.

    Para aprender más sobre retrospectivas, te recomiendo el Taller de Retrospectivas Poderosas para Equipos, de Kleer: Powerful Retrospectives for Teams.

    9 de noviembre de 2011

    Open Training: un mecanismo de capacitación auto-gestionada

    De Mayo a Septiembre 2011, pudimos rodar en mi empresa una iniciativa de Open Training a la cual participaron 16 personas.

    Espíritu del Open Training
    Diseñamos este mecanismo de auto-capacitación tomando como base los conceptos de Open SpaceOpen Space Training y Caddying, que suelen convivir muy bien con los valores ágiles. En particular tratamos de sostener las siguientes premisas a lo largo de toda la iniciativa:

    • La participación es libre, espontánea y voluntaria.
    • El trabajo es auto-gestionado.
    • Los temas son propuestos y elegidos por los participantes, dentro de los intereses profesionales que se pueden desarrollar en la empresa.
    • El único objetivo es el crecimiento del grupo.
    • Es la primera iteración de la iniciativa, con lo cual se considera una prueba y hay que mejorar el mecanismo.


    Organización
    Tomando la auto-gestión como base, la organización del Open Training fue bastante sencilla, y solamente hizo falta organizar las reuniones siguientes para darle un marco:

    1. Kick-Off
    Iniciamos con una sesión de Kick-Off, donde se explicaron el concepto, la dinámica y el marco (tiempos y recursos disponibles) de la iniciativa. Luego con una dinámica Open Space, los participantes propusieron temas de interés. Finalmente se auto-formaron 3 grupos de estudio, eligiendo cada uno un tema de capacitación (eligieron Qlikview, MS EPM y Automatización de Pruebas).


    2. Diagnostico y Objetivo
    Dos semanas más tarde, juntamos los 3 grupos para que presenten la evaluación inicial de sus conocimientos en el tema correspondiente y el objetivo a lograr al final de la iniciativa. Para llegar a eso, cada grupo tuvo que reunirse, investigar sobre el tema de referencia para poder definir unos ejes de aprendizaje y una escala de evaluación para cada eje. Cada miembro del grupo auto-evaluó su conocimiento actual con esta escala. Luego cada grupo definió un objetivo grupal a lograr al final de la iniciativa. La figura siguiente muestra el ejemplo del grupo Qlikview, donde se ven los ejes de aprendizaje elegidos: Componentes, Scripts, Entorno, Teoría e Informes



    Se ven en el gráfico la evaluación promedio del diagnostico inicial y el valor objetivo de los conocimientos del grupo. Para cada eje, los grupos definieron el significado de los valores 1 a 4. Por ejemplo, para el eje Componentes, definieron la escala siguiente: 
    1. Sin conocimiento
    2. Conocimiento de los componentes disponibles y de las opciones gráficas
    3. Conocimiento básico de los componentes, manejo de las expresiones y dimensiones
    4. Conocimiento intermedio de los componentes y manejo de los componentes añadidos


    3. Checkpoint
    Siete semanas más tarde, juntamos a todos los grupos otra vez para que presenten sus avances. Cada grupo estuvo contando brevemente que estuvieron haciendo desde la reunión anterior, los resultados que lograron en este plazo y una nueva evaluación del estado del conocimiento del grupo. En algunos casos los grupos decidieron ajustar su objetivo para adecuarlo en función del conocimiento adquirido. En la figura siguiente, se ve la evaluación del conocimiento en este checkpoint para el grupo Qlikview:



    4. Cierre y Retrospectiva
    Ocho semanas después, hicimos la reunión de cierre de la iniciativa, otra vez con todos los participantes. En esta oportunidad cada grupo contó las acciones realizadas desde el checkpoint, los resultados alcanzados y presento una última evaluación de los conocimientos adquiridos, comparándolos con los objetivos iniciales. La segunda parte de la reunión fue una retrospectiva de la iniciativa, donde se trabajo sobre lo positivo y negativo de las distintas partes de la iniciativa, lo que permitió identificar y priorizar en grupo mejoras para una segunda iteración.




    Resultados y Lecciones Aprendidas

    Los resultados fueron variados:

    • Los grupos crecieron en su conocimiento de los temas correspondientes, en forma medible.
    • Un grupo se auto-disolvió al perder el interés por el tema elegido.
    • Dentro de cada grupo, algunas personas pudieron aprender más que otras.
    • En un grupo, además del conocimiento adquirido, se generaron herramientas concretas para uso en proyectos.
    • Los objetivos de aprendizaje de cada grupo fueron demasiado ambiciosos y no se pudieron cumplir del todo.
    • La mayoría de los participantes disfrutaron de la iniciativa.

    De la retrospectiva de esta primera experiencia, surgieron varias oportunidades de mejora. Las más votadas fueron:

    • Mejorar el mecanismo de selección de temas para que cada participante pueda tener un tiempo de reflexión antes de elegir.
    • Acortar los tiempos entre checkpoints. 
    Finalmente, todos los participantes expresaron el deseo de repetir la experiencia del Open Training.

    30 de octubre de 2011

    Minutas a la carte: un tip para minutear colaborativamente

    Seguro habrán participado en reuniones donde se necesita redactar una minuta que transcribe lo que ocurrió durante la reunión, las decisiones tomadas, las acciones pendientes, etc. Poder tomar notas en tiempo real y luego redactar la minuta correspondiente suele ser parte de las herramientas básicas que debe dominar un consultor.

    Sin embargo no es una tarea fácil, y siempre me ha resultado difícil encontrar un buen balance para poder tomar buenas notas sin entorpecer el ritmo de la reunión. Por eso quería compartir un tip que empezamos a aplicar la semana pasada en un proyecto con muchas minutas donde somos 3 consultores en las reuniones.

    Usamos un simple documento de Google Docs, que preparamos antes de la reunión escribiendo los puntos que queremos relevar, las preguntas a hacer, etc. Luego durante la reunión los 3 estamos editando a la vez el mismo documento, tomando nuestras notas a la vista de los otros.

    Si bien requiere un poco de practica para pulir el mecanismo, los resultados de esta técnica me parecen muy alentadores. Comparto mis primeras conclusiones y recomendaciones al respecto:

    1. Claramente el mecanismo reduce el trabajo posterior a la reunión para redactar la minuta: no hay que hacer un merge entre las notas de todos.
    2. Se gana en calidad de las notas ya que al ver lo que está escribiendo mi compañero no tengo que escribirlo yo y me puedo concentrar en enriquecer las notas o en seguir con la discusión de la reunión sin tener que pensar en escribir todo. 
    3. El uso del chat de google docs durante la sesión permite intercambiar comentarios y preguntas en el momento, tomar decisiones compartidas sin tener que interrumpir la reunión, etc.
    4. Ayuda mucho tener bien armado el temario de la reunión, para que todos sepan exactamente a donde escribir cada tema.
    5. Es bueno tratar de agrupar e indentar "on the fly" los temas que se van desarrollando a medida que se escriben notas. Ojo que a veces cuando uno se va al extremo, eso puede confundir a las otras personas que están tomando notas. 
    6. Perder la conexión con este mecanismo es lo pero que puede pasar!

     Ya lo probaron? Que opinan de este tip?

    17 de octubre de 2011

    Agiles 2011: Greatest Hits

    Algunas frases, conceptos y referencias que me impactaron durante la conferencia Agiles 2011:
    • Jeff Patton - Product Discovery with User Story Mapping
    • Robert Gallen
      • Practices of a Great Scrum Product Owner
        • Product Backlog is organic: it needs care and feeding
        • It usual to groom your Product Backlog twice a week
        • Product Backlog should include: 20% of well defined fine grained items, 30% of epics and 50% of vague themes. Different grooming should be done for each type.
        • It's usefull to manage multiples threads for the different kinds of items in a Produt Backlog: features, technical, quality, release, innovation, security, refactoring, etc.
        • The Sprint Goal is important since it gives the team the guidance to make its own decisiones and adjustments.
      •  Agile Testing - Beyond the Easy Contexts
        • Infraestructure is a fundamental part of your agile journey
        • Reward on a team base and not on an individual base
    • Mike Beedle - El Futuro de Agile y Lean
      • 80% de las empresas escandinavas son Agile y/o Lean
      • A 10 años del Manifesto Agile, Mike Beedle participo en un workshop donde definieron como mejorar el estado actual del agilismo:
        1. Pedir excelencia técnica
        2. Promover el cambio cultural
        3. Maximizar el valor para el negocio
        4. Organizar el conocimiento
    • Michael DePaoli - Optimizing Organizational / Team Collaboration & Transparency Even With Distributed Teams
      • Example from Mary Poppendieck: "In large building construction, project manager role for dealing with complex emergent problems is all about making the right skileed people to comunicate together"
      • Strength Deployment Inventory (SDI) - Elias Porter

      11 de octubre de 2011

      ¡No estimarás!

      El martes 11 de octubre del 2011, estuve dando la charla "¡No Estimarás!" en la conferencia Agiles 2011, en Buenos Aires.







      Estimación: Mecanismo esotérico que se solía usar hasta mitad del siglo XXI para intentar predecir con técnicas seudocientíficas tiempos y esfuerzos en la construcción de software. Cuestionado a final del siglo XX por el movimiento revolucionario agile, el uso de este mecanismo fue decayendo con la aparición de metodologías agiles de segunda generación como Kanban y erradicado definitivamente con la aparición posterior de otras metodologías ágiles.

      2 de agosto de 2011

      Dinámica de Retrospectiva: "Si fuera vos"

      Comparto esta dinámica de retrospectiva, que me dio buenos resultados en varias ocasiones:
      • Nombre: Si fuera vos
      • Participantes: 5 a 12 personas
      • Duración: 25 a 40 minutos
      • Alcance: al finalizar una iteración corta (3 semanas o menos)
      • Propósito: recabar información e indagar
      • Facilitador: necesario
      • Objetivos: Esta dinámica permite identificar fortalezas y oportunidades de mejora en las interacciones entre distintos grupos (por ejemplo cliente/proveedor, desarrollador/tester, etc.), ayudando a cada grupo a darse cuenta de cómo puede mejorar su interacción con el otro grupo.
      • Material y Preparación: post-its, marcador para cada participante. No requiere preparación especial.
      • Pasos:
        1. El facilitador explica el objetivo y la actividad: "Cada uno de ustedes individualmente escribirá en un post-it algo que hizo que cree puede haber generado inconvenientes en otros grupos o roles presentes".
        2. Cada participante escribe en un post-it el principal tema de la responsabilidad de su grupo que le parece que más haya causado problema al otro grupo durante el periodo considerado (por ejemplo: “mandar tarde el informe X”, “no avisar de tal posible problema”, etc.)
        3. Se repiten los pasos siguientes para cada participante:
          1. Cada participante explica al otro grupo lo que escribió en su post-it. 
          2. El otro grupo contesta diciendo si este tema realmente le ha causado problema o no. Por ejemplo cada persona del otro grupo vota desde 0 (no me molesta) a 5 (me molesta mucho) para este problema.
          3. Se puede generar un breve debate entre los participantes
        4. Una vez identificados todos los temas con su votación se puede abrir el debate para ver si hay otros problemas que no se mencionaron (ya en forma directa, sin usar el "si fuera vos").
        5. Se eligen los temas a trabajar.
      • Variantes:
        • Trabajar con 3 temas en lugar de 1 por persona, o dejar libre la cantidad de temas.
        • Hacer el paso 2 de a pares (del mismo grupo).
      • Tips:
        • Es fundamental explicar bien el objetivo de la actividad, en particular si la interacción entre los grupos es tensa.
        • El facilitador debe cuidar que nunca se revierta el sentido de los temas que se levantan. El sentido correcto es: “pienso que tal cosa que hicimos les ha causado problemas”. El sentido erróneo es: “ustedes hicieron tal cosa que nos ha causado problemas”. Eso vale en particular si la interacción es tensa.
        • El facilitador puede ayudar a que los grupos vayan identificando en el debate cual fue el impacto real (daño causado) de los temas que se levantan, para permitir relativizar o enfatizar su importancia.
        • El facilitador debe ayudar al grupo a identificar/definir los problemas, y dejar para una actividad posterior las propuestas de mejora.
        • El facilitador tiene que cuidar el grupo minoritario si la diferencia de personas es importante (uno contra varios).
        • El facilitador debe asegurar que el juicio de si un tema realmente haya causado problema o no al otro grupo lo emita el grupo o la persona involucrada y no otros que hablen en su nombre.
      • Origen: Thomas Wallet

      17 de julio de 2011

      Mitos y Realidades del Agilismo: "Agile va a solucionar tus problemas de inmediato"

      La última de las máximas que se escucha habitualmente es: “Agile va a solucionar tus problemas de inmediato”. Se suelen tener elevadas expectativas al implementar prácticas ágiles, esperando que sea una solución mágica que borre rápidamente problemas recurrentes en la empresa.


      ¿Qué nos muestra la experiencia? Que es cierto que uno puede apoyarse sobre ellas para dejar al descubierto los principales problemas de la organización para desarrollar software. La mala noticia es que el camino es difícil y que ninguna metodología agile es mágica. Al proponer un marco con iteraciones de duración igual o menor a un mes, en el cual cada equipo compromete un incremento de funcionalidad en un software que sea de valor para el negocio, se ponen en evidencia rápidamente los impedimentos que ponen en riesgo dichos acuerdos.

      Scrum propone una actividad sistemática de retrospectiva al finalizar cada iteración, en la que el equipo intenta identificar los principales obstáculos que dificultaron su trabajo. Estos impedimentos pueden revelar, por ejemplo, limitaciones del equipo, problemas en la relación con el cliente/usuario y conflictos en la organización. La parte difícil es actuar sobre los problemas emergentes que implican gestionar cambios culturales arraigados. La transparencia y la visibilidad que aportan las metodologías ágiles para todos los actores involucrados (equipo, management, clientes, usuarios) resultan difíciles de “digerir” por algunas personas. Varias de las prácticas de Lean (“Eliminar los residuos”, “Ver el conjunto”, “Crear la integridad”) permiten llevar a cabo una reflexión completa sobre el fundamento de cada actividad de un proceso, tratando de eliminar todos los pasos que no aportan valor y que suelen relacionarse con la burocracia. Estos impedimentos suelen trascender el mero ámbito del desarrollo de software e involucrar una visión transversal a todo el negocio de una empresa, implicando mejoras a articular entre múltiples sectores.

      Por esto, sobre esta tercera máxima, proponemos:
      1. Estar preparados para el momento en que se “saquen los trapitos al sol”.
      2. Trabajar en las formas de reaccionar, reflexionar y emprender iniciativas de mejora.
      3. Pensar a los equipos ágiles como laboratorios donde probar variantes con un riesgo limitado.
      4. Tener iteraciones cortas que permitan cometer errores con impacto moderado (una sola iteración) para aprender.
      5. Ser permeables al error como mecanismo eficaz de aprendizaje. Como dice el proverbio, “Aquél cuyo pie resbala, muestra el camino para muchos”.
      Este post es parte de una nota mía publicada en la revista Perspectiva (N4) del grupo Pragma Consultores

      16 de julio de 2011

      Mitos y Realidades del Agilismo: “Esto no nos va a servir, somos demasiado especiales”

      Otro mito imperante acerca de la adopción del agilismo es: “Esto no nos va a servir, somos demasiado especiales”.

      Casi todas las organizaciones se consideran únicas a la hora de decidir si introducen prácticas ágiles. Creen que la estructura, el contexto, el proyecto, el equipo o los usuarios tienen características tan específicas que van a impedir la adopción.

      Otro argumento que se suele escuchar es que las prácticas ágiles podrán ser muy buenas para equipos chicos en un mismo sitio, pero seguramente no escalan para equipos de centenares o miles de personas distribuidas.

      La realidad es que, en el mundo de los negocios actual, cualquier organización y proyecto es único y tiene su propio contexto. También es cierto que la adopción de prácticas ágiles suele chocar contra algunas características existentes de cada organización. En ámbitos con estructuras jerárquicas muy establecidas, el principio de equipos auto-gestionados de Scrum suele incomodar. Las prácticas ágiles (en particular Scrum, Kanban y XP) son difíciles de enmarcar en contratos con alcances fijos y detallados. Dicho esto, hay que remarcar que las prácticas ágiles requieren un cambio de paradigma y que las organizaciones más “conservadoras” en su cultura tendrán mayores dificultades a la hora de implementar dichos cambios. Es lo que remarca Stephen R. Covey en su muy pragmático principio: “Si seguimos haciendo lo que estamos haciendo, seguiremos consiguiendo lo que estamos consiguiendo”.

      Respecto del escalamiento en organizaciones grandes, si bien es cierto que varias prácticas ágiles fueron pensadas para equipos de menos de diez personas, hace tiempo que existen mecanismos probados y eficientes para poder aplicarlas con éxito en grupos de cierto tamaño. Yahoo, 3M, BBC, Nokia, Primavera, Amazon, Google, Microsoft y Boeing son algunas de las empresas que aplican estos conceptos a mayor escala. Yahoo, en particular, afirma haber aplicado Scrum en un proyecto con 700 desarrolladores.

      En resumen, considerando este mito, recomendamos:
      1. Elegir qué prácticas ágiles se adoptarán de inmediato y cuáles tendrán que adoptarse más adelante (por ejemplo, empezar por prácticas de test automatizado en integración continua de XP, dejando para una segunda etapa las más resistidas, como programación de a pares).
      2. Implementar cada práctica a paso firme, mostrando y difundiendo los logros. Es fundamental reevaluar constantemente por qué sí o por qué no estamos implementando cada práctica.
      3. Empezar con experiencias piloto en grupos reducidos para afirmar los valores y beneficios de las prácticas ágiles y luego definir formas de escalamiento hacia áreas o grupos más grandes.
      Este post es parte de una nota mía publicada en la revista Perspectiva (N4) del grupo Pragma Consultores

      15 de julio de 2011

      Mitos y Realidades del Agilismo: "Es demasiado nuevo y son pocos los que lo usan"

      El primero de los mitos con el que uno se encuentra cuando comienza a hablar de metodologías ágiles es éste: “Es demasiado nuevo y son pocos los que lo usan”. Lo cierto es que a pesar de que estas metodologías se han puesto de moda hace poco, especialmente en la Argentina, tienen varios años y sus procesos han sido probados repetidamente.

      Repasemos algunas fechas importantes:
      • La piedra fundamental de Scrum fue publicada hace 24 años por Hirotaka Takeuchi e Ikujiro Nonaka, y el primer proceso de este tipo fue concebido, ejecutado y documentado por Jeff Sutherland, John Scumniotales y Jeff McKenna hace 17 años.
      • Extreme Programming fue concebido y aplicado por Kent Beck, Ron Jeffries y Ward Cunningham en el proyecto Chrysler Comprehensive Compensation System, hace 14 años. El método test-first development fue usado hace 50 años en el proyecto Mercury de la NASA.
      • Los principios de Lean, llevados al desarrollo de software por Tom y Mary Poppendieck, fueron publicados hace sólo 7 años. El concepto de Just-In-Time, uno de los pilares de Lean Manufacturing, fue introducido por Toyota en la industria automotriz hace 75 años.
      • Kanban tiene sus orígenes en los sistemas mercantiles japoneses de hace cinco siglos. Luego fueron aplicados por Toyota en su principal planta de producción, hace 57 años.
      Para dar una idea de la amplitud de la comunidad agile en el mundo, basta sólo con buscar en Internet la cantidad de menciones del término.

      Para tomar un ejemplo cuantitativo, la Scrum Alliance ya registra oficialmente más de 64.000 Certified Scrum Masters (personas que tomaron el curso oficial) y más de 2.100 Certified Scrum Practicioners (personas que son CSM y que demostraron haber aplicado Scrum durante más de un año). Del lado de Extreme Programming, si bien no se consiguen números precisos de adopción, la comunidad también es muy numerosa y se habla de decenas de miles de proyectos en el mundo usando las prácticas de XP, en dominios tan variados como el de telcos, media, banca, finanzas, seguros, ERPs, defensa, Internet, salud o entretenimiento.

      Basándonos en este mito y su refutación, aconsejamos:
      1. Aprovechar que las prácticas ágiles están de moda para convencer a su organización de probarlas.
      2. Apoyarse en las experiencias existentes para no tener que “reinventar la rueda”.
      3. Hacerse acompañar por personas experimentadas y así evitar errores típicos.
      Este post es parte de una nota mía publicada en la revista Perspectiva (N4) del grupo Pragma Consultores

      8 de julio de 2011

      Webinar: El enfoque ágil para la gestión de proyectos de software

      El 8 de Julio del 2011, estuve dando el webinar: El enfoque ágil para la gestión de proyectos de software

      En este webinar se introducen las metodologías ágiles para el desarrollo de software, y se contrasta este enfoque con el enfoque predictivo tradicional. Se presenta en particular Scrum como ejemplo de metodología agil para conocer más en detalle como llevar el agilismo a proyectos reales.

      Este webinar es una introducción al curso online Metodologías ágiles para el Desarrollo de Software que estoy dando con Hernán Ricchio y Ulises Martin en la plataforma de eLearning de la UTN.

      1 de julio de 2011

      Mi próximo paso

      Acá estoy, mirando para adelante, y este post es mi próximo paso. No tengo claro cual será el siguiente, pero espero que este sea el inicio de un lindo camino.

      Siempre hay un próximo paso, y muchas veces es el más importante. "Caminante, no hay camino, se hace camino al andar" decía Antonio Machado, y así yo, Thomas Wallet, tomo mi camino profesional, paso a paso, sumando pequeños avances e ideas, que quiero compartir en este blog.

      Motivaciones tengo varias para escribir, pero más que todo creo que recorrer parte del camino acompañado lo hace más vivo, y espero humildemente que algún post pueda contribuir en sus próximos pasos.

      Ahora si, a caminar, basta de hablar!