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