Categoría: inspección_adaptación

Agile White Book de AXA liberado

AXA (EMEA-LATAM Emerging Markets) ha liberado su Agile White Book, descargable en el siguiente enlace : http://www.slideshare.net/AXAEMEALA/documents

awb-axa-emeala

Este libro es una guía de Agile que cubre los conceptos fundamentales y proporciona una terminología común para los diferentes países de la región EMEA-LATAM (aspecto importante dados sus diferentes niveles de madurez en Agile). Sirve como punto de entrada para futuros Scrum Masters que van a empezar a trabajar en Agile en AXA y esperamos que pueda servir también a otras organizaciones que están comenzando en este camino basado en personas y trabajo en equipo“.

Algunos ejemplos de contenido:

readiness-criteria

metrics-balanced-scorecard

También cuenta con varios checklists que puede ser útil consultar:

PBL-Refinement-checklist.jpg

Videos cortos sobre retrospectivas

A continuación se muestra una lista de posibles técnicas a utilizar y pasos a realizar en una Retrospectiva, en forma de videos cortos (en castellano, con subtítulos en inglés):

retrospectiva-agenda-video

 

Video

Descripción

1 – Agenda de Retrospectiva (4′)

Se explica cuál es el objetivo de una retrospectiva (ir cambiando la manera de trabajar para mejorar) y un ejemplo de pasos a realizar durante la reunión para conseguir su objetivo.

2 – Reglas de etiqueta (4′)

Se explican consejos para que los asistentes a una reunión de retrospectiva tengan una participación positiva  y considerada.

3 – Aportar datos objetivos. Motivación del equipo (3′)

Se explica la importancia de aportar datos objetivos en el  inicio de una retrospectiva. Un dato importante es la motivación del equipo, que se puede recoger fácilmente mediante la técnica Niko-Niko.

4  Identificar qué está funcionando bien (4′)

Se explica la importancia de empezar identificando aquello que ha funcionado (o está funcionando) bien, así como reconocer el trabajo bien hecho. También se muestran una técnica para conseguir que todos los asistentes participen aportando su visión.

5 – Identificar qué mejorar (5′)

Se explica una técnica para recoger aspectos a mejorar, agrupar por temas y escoger aquellos sobre los que trabajar.

6 – Análisis causal y plan de acción (7′)

Se explica la importancia de realizar un análisis causal sobre aspectos críticos a mejorar, para poder llegar a su raíz y que sea más efectiva la solución (las acciones de mejora, las best practices a incorporar o los team agreements a crear). Para ello se muestra un uso sencillo de la técnica de diagrama de espina de pez o Ishikawa.

7 – Retrospectiva de la reunión y gestión visual de tareas de mejora (5′)

Se muestra una técnica sencilla para evaluar el resultado de una reunión, cómo se ha trabajado en ella y qué mejorar o cambiar para que la siguiente todavía sea más productiva. Esta técnica es útil en todo tipo de reuniones, especialmente en aquellas en las que participan muchas personas.

  

Artículos relacionados

 

Retrospectivas ágiles – Resultados del septimo encuentro ágil en Barcelona

En este encuentro se presentaron dos tipos de retrospectivas, a las que se llamaron “Express” (para iteraciones cortas, de 2-3 semanas) y “full equipe” (para iteraciones de 1 mes, releases, fin de proyecto o empresa).

Se expuso la conveniencia de utilizar el principio de Pareto en la resolución de los problemas de un proyecto, es decir, unas pocas causas producen los problemas con más impacto. Por ello, y para ser más efectivos en las retrospectivas, se consideró de especial importancia ir haciendo “shortlists” de los resultados de las actividades típicas (identificación de problemas, causas y soluciones).
 
Se hizo una simulación de retrospectiva “full equipe”. Se partió de un “blind brainstorming” para decidir el tema a tratar (“Nuevos negocios, la mayoría mueren en el primer año”).
 
Se señalo la importancia de transmitir el conocimiento generado en las retrospectivas al resto de equipos y se finalizó haciendo una retrospectiva del encuentro.
 

 
Objetivo de una retrospectiva
 
NO se está haciendo Scrum, no se puede ir mejorando de manera continua, si regularmente no se dedica un tiempo de calidad para que el equipo reflexione sobre cómo está trabajando y aprenda a ser más efectivo y eficiente, todo ello disfrutando de su trabajo. Es decir, el equipo debe ir mejorando de manera gradual respecto a:
  • El servicio ofrecido al cliente, la calidad que percibe del producto.
  • La productividad del equipo.
  • La calidad interna del producto (que sea mantenible para poder crecer de manera sostenida).
  • Qué es aquello que le molesta, qué no deja disfrutar al equipo en su trabajo.
Si no se dedica 1 o 2 horas cada 2 semanas (o 3 o 4 horas al mes) a hacer retrospectivas, los problemas se repetirán iteración a iteración, lo cual producirá frustración en el equipo.
 
 
Enfoque constructivo y positivo

 

  • Es importante dedicar una parte de la retrospectiva a reconocer las cosas que se hacen bien, para no caer en el pesimismo y derrotismo. Respecto a la otra parte de la retrospectiva, la dedicada a las cosas que no funcionaron, en lugar de hablar de “cosas negativas” es conveniente hablar de “cosas a mejorar”.
  • En lugar de buscar culpables, el equipo tiene que pensar qué parte del proceso de trabajo hay que cambiar para que el problema no vuelva a suceder.
  • El Scrum Master es el “engrasador” que evita que se produzcan conflictos entre personas durante la retrospectiva. Identifica a tiempo que se está entrando en conflicto destructivo para pararlo.
 
Tipos de acciones de mejora
 
Las acciones de mejora que se identifican en una retrospectiva se pueden dividir en dos grupos:
  • Soluciones paliativas, aquellas que tenemos que tomar para vivir mejor a corto plazo pero que no solucionan el problema de base.
  • Soluciones “core”, aquellas que necesitan más tiempo pero que a medio plazo solucionarán el problema.
Dependiendo de su alcance, las acciones de mejora se incorporan a los sprint backlog de las siguientes iteraciones y/o a la lista de impedimentos del Scrum Master.
 
 
Ayuda externa
 
En la retrospectiva el equipo puede verse limitado en su capacidad para dar soluciones. Dado que siempre “golpea” de la misma manera, con el mismo martillo, el equipo puede encontrar como solución la participación de algún experto externo que les ayude en su trabajo, e incluso que acuda a la retrospectiva para ofrecer alternativas.
 
 
Retrospectiva Express

 retrospectiva-express

  • Se empieza pintando en el whiteboard una línea horizontal que simboliza las 2-3 semanas de la iteración. Esto nos ayuda a recordar y situar los eventos más significativos que ocurrieron.
  • En la parte superior el equipo escribe las cosas positivas que sucedieron: qué está funcionando, reconocimientos a personas, etc.
  • En la parte inferior el equipo escribe los problemas a mejorar, los efectos negativos que estamos experimentando en nuestros objetivos (ver apartado “Objetivo de una retrospectiva”).
  • Cada persona del equipo puede poner hasta 3 puntos positivos y negativos en cada evento.
  • Primer shortlist: nos quedamos sólo con los 2 o 3 problemas que el conjunto del equipo está considerado más importantes en este momento (en el futuro pueden cambiar). Si es necesario, se puede registrar el resto de problemas para en el futuro comprobar si permanecen a lo largo de las iteraciones y para recordar que de manera explícita se decidió no hacer nada con ellos en esta retrospectiva.
  • Nos preguntamos cuáles son las causas de estos problemas y hacemos el segundo shortlist: nos quedamos con las 2 o 3 causas más importantes.
  • Pensamos en las acciones que puede solucionar estas causas y hacemos el tercer shortlist: nos quedamos con las 2 o 3 acciones que tienen un mejor ROI (esfuerzo a dedicar por beneficio a obtener). Notar que en principio NO ejecutaremos todas las acciones que hayan aparecido por que:
    • El principio de Pareto también aplica a los problemas de un proyecto, es decir, será suficiente con acometer acciones muy concretas sobre las causas que producen los problemas con más impacto.
    • No tenemos todo el tiempo ni recursos del mundo para arreglar todos los problemas de nuestro proyecto.
    • Tenemos que producir para nuestro cliente, no sólo dedicarnos a mejorar.
Poco a poco, iteración a iteración, iremos arreglando los problemas más importantes que vayamos encontrando en cada momento.
 
 
Retrospectiva “full equipe”
 
retrospectiva-full-equipe.jpg
 
Se hizo una simulación de retrospectiva “full equipe”. El tema se eligió haciendo un “blind brainstorming”: para que nadie se sienta cohibido con su propuesta respecto a los demás, las propuestas se escribieron de firma anónima en papeles. Tras hacerse públicas, se agruparon y se votaron para ver cual era la más interesante para todos.
 
El tema elegido fue: “Nuevos negocios, la mayoría mueren en el primer año”.
 
blind-brainstorming
 
Las causas que se identificaron fueron:
  • Business plan incorrecto (especialmente por falta de conocimiento del negocio y falta de suficiente dinero inicial).
  • Problemas con los socios.
Alexis Roqué hizo la siguiente metáfora:
  • Un buen business plan es la hoja de ruta.
  • El conocimiento del negocio es como el carné de conducir.
  • El dinero inicial es la gasolina.
retrospectiva-full-equipe-simulacion 
 
Retrospectiva de la retrospectiva
 
Siguiendo el principio de “inspeccionar y adaptar”, para ir aprendiendo a hacer retrospectivas, al final de cada una se hace una retrospectiva de la retrospectiva.
 
En el caso del encuentro, lo que más gustó fue haber podido practicar lo que se había explicado (una retrospectiva), que la gente se soltó, participó, que hubo un buen dinamizador, lo sencilla que era la retrospectiva Express, la idea de cortar y simplificar (“shortlistear”) en todas la actividades de la retrospectiva y el haber hecho timebox de las actividades del encuentro.
 
En lo que hay que seguir enfocándose es en tener encuentros menos teóricos y más prácticos.
 
 
Gestión del conocimiento
 
Es importante transferir el conocimiento adquirido en una retrospectiva (las “best practices”) al resto de equipos, para tener una mejora continua de la organización.
 
Por ello hacemos estos resúmenes 😉
 

 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
  
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

 
 
Artículos relacionados

 

Retrospectiva de estrella de mar (Starfish retrospective)

Autor: Gustavo Veliz Bernaola


 

Un bien amigo agilista tuvo a bien enviarme un mail sobre una forma de llevar retrospectivas que desconocía. La Starfish retrospective tiene ciertas ventajas frente a la forma “clásica” de llevar retrospectivas, es decir la de solo llevar las cosas como “lo malo” y “lo bueno”.

Las retrospectivas son inmensamente provechosas para cualquier tipo de proyecto sea personal o empresarial.

Algo de reflexión sobre las retrospectivas y su importancia la podemos aprender de la siguiente referencia: dont-forget-to-sharpen-the-saw

Ahora, si ya sabes que es una retrospectiva y estás convencido de su importancia, entremos más en materia.

Una de las ventajas de las retrospectivas es que nos ahorran tiempo al momento de tener un feedback del equipo del trabajo. Pero esta no es su única ventaja, también nos permite ver y exponer problemas o ventajas que de otras maneras serian muy difíciles.

Es en este contexto donde Starfish retrospective entra a tallar, bajo el siguiente esquema:

StarTechnique

Se coloca en una pizarra o donde crean apropiado. Un ejemplo:

starfishRetrospective

Ahora ¿Qué significa cada parte?. Pues me tomó algo de tiempo pero aquí va:

Empezamos por

Start Doing: Aquí van todas aquellas cosas innovadoras o que por cierta curiosidad queremos probar. O tal vez son soluciones comprobadas que notamos que deberíamos usar. Por ejemplo usar una wiki para la comunicación o repositorio interno.

More of: Este paso personalmente considero que será alimentado por el anterior en las siguiente retrospectiva (espero). Es decir que los [Start Doing] se convertirán en [More of]. Esto significa aquellas cosas que estamos usando o haciendo y que queremos que mejoren. Son practicas que creemos que requiere mas refinamiento y que nos gustan mucho por ello hay que darles mas.

Keep Doing : Como secuencia lógica aquello que fue un [More of] llegaría a un nivel de maduración y se convertirá en [Keep Doing]. Es aquello que venimos haciendo y que nos brinda valor. Debemos seguir haciéndolo pero no será preocupación mejorarlo. Está bien como esta.

Less of: En este punto ponemos aquello que tal vez en una retrospectiva fue [Start Doing] pero no nos genero el valor que queriamos. Aquello que intentamos pero no nos dan tanto beneficio como se esperaba. Está bien, démosle como una segunda oportunidad, pero no esta en nuestras prioridades. Tal vez no nos funcione. También puede ser el quitar una parte de una práctica como el reporte de horas mensual o cosas por el estilo, es decir, obligatorias de cumplir pero no nos aportan valor. Y es ahí donde seguimos con el

Stop Doing: En este punto exponemos aquellas practicas que a pesar de ser [Less of] pues podemos eliminarlas. Cuando el equipo ve que no le da valor o simplemente no le gusta una practica puede optar por eliminarla.

Como vemos Starfish retrospective nos permite ver der una manera evolutiva nuestras retrospectivas. Un análisis periódico de nuestros Starfish nos permite ver la evolución del proyecto y la resolución de problemas. Objetivo que era mas difícil de conseguir mediante las retrospectivas tradicionales.

Espero lo apliquen y dejen sus comentarios de como les fue. De manera personal me encantó y me ha dado buenos resultados.

Lugar donde conoci Starfish retrospective: http://www.thekua.com/rant/2006/03/the-retrospective-starfish/

 

Artículos relacionados

 

 

Por qué son buenas las demostraciones en Scrum

Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde el equipo va desarrollando los requisitos seleccionados al comienzo de cada una de esas iteraciones (en la reunión de planificación del Sprint). El cliente puede tener entregas del proyecto que incluyan los resultados de varios Sprints y, una vez finalizados, todos los ellos hemos terminado el proyecto.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminada una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.
 

Una de las cosas más curiosas de la demostración de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. Una semana completa antes del final la gente pasa a centrarse en sacar la demostración adelante, y durante este tiempo se descubren muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar el desarrollo durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que tras la demostración habrá que arreglar correctamente. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demostración:
 
  • Se realiza un esfuerzo por integrar los requisitos desarrollados durante las últimas semanas para obtener un resultado compacto y demostrable al cliente final, lo cual revela numerosos problemas imprevistos y de calidad. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras iteraciones de desarrollo (Sprints), mientras que en un proyecto tradicional en cascada estos errores se detectarían al final y serían mucho más complejos de resolver.
Una persona tiende a responsabilizarse sólo de la parte de trabajo que realiza, es más difícil sentir la propiedad del resultado de un requisito cuando el equipo es multidisciplinar y se necesitan varios especialistas para completar este requisito. A menudo diferentes equipos trabajan en diferentes aspectos/componentes del producto o ámbitos del proyecto, funcionando como islas independientes unos equipos respecto de los otros. Descuidar la interacción entre estos distintos aspectos o componentes puede traer problemas a largo plazo. Por ello las demostraciones ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.
 
  • Irremediablemente se crearán soluciones temporales o, hablando más claro, parches. Estos parches estarán ahí en la demostración, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.
  • Las demostraciones obligan al pragmatismo y a la creación de un producto susceptible de ser entregado al cliente con el mínimo esfuerzo necesario. Otro aspecto que yo considero importante de las demostraciones es que los miembros del equipo no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El miembro del equipo se debe centrar en desarrollar un requisito de manera pragmática y siempre pensando en tener algo que entregar, algo que se pueda demostrar. 
Esto abre otro debate sobre como poner en un Sprint requisitos no tan fácilmente demostrables como puedan ser cambios internos del producto que no aportan valor directo al cliente o usuario, pero que facilitan añadir nuevos requisitos o cambiarlos, hacen el producto más adaptable o, simplemente, permiten mejoran su calidad. Pero eso ya es un tema diferente. 
 
  • Involucración por parte de los miembros del equipo. Personalmente creo que la demostración no debe ser realizada por única persona, sino que aquí el Facilitador (Scrum Master) debe actuar como simple maestro de ceremonias. Hacer que los miembros del equipo participen en la demostración les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.
  • El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demostración para toda la compañía. Vosotros ya sabéis como es el trabajo en una compañía medianamente grande. A menudo la mayoría de departamentos o equipos trabajan de manera independiente, y prácticamente el único contacto que tienen con el proyecto es para conocer los problemas que unos tienen con el trabajo de los otros. "¿Oye, cómo teníamos que integrar vuestra parte de producto con la nuestra?", "¡Este requisito no se ha hecho como esperábamos, estamos perdidos.", "Hay que hacer cambios corriendo, ahora mismo os hacemos una petición formal de cambios", etc.
Me atrevería a decir que es común que la sensación de las personas ajenas a un equipo, poco antes de terminar cada iteración es más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido es que ha habido problemas. Sin embargo, el hacer una demostración con los objetivos cumplidos que fueron marcados al inicio de Sprint, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo del Sprint. 
 
  • Visibilidad para el cliente. Teóricamente las demostraciones deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demostraciones internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demostración el cliente puede comprobar que se está progresando, lo cual en el mundo de los proyectos no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.
Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demostración, al menos en nuestro caso.

 

Una retrospectiva ágil de Scrum

A continuación se explica cómo hacer una retrospectiva para la solución de problemas de un proyecto e identificar qué cosas están funcionando bien.

La siguiente reunión de retrospectiva dura 2,75 horas. Los tiempos de cada actividad son aproximados. Están basados en el tiempo de análisis necesario para  proyectos con iteraciones mensuales. Estos tiempos pueden ser inferiores si las iteraciones son de 15 días o si el equipo ya tiene experiencia en la realización de retrospectivas.
 

 

Material necesario

 

Actividades

 

Puesta en escena (15′)

  • El facilitador explica el objetivo de la retrospectiva y enumera los diferentes pasos y tiempos que va a tener la reunión.

Identificación de problemas (60′)

  • El facilitador hace un resumen de los hechos, objetivos conseguidos (o no) y decisiones más relevantes del período o proyecto a analizar con la finalidad de mejorar en el siguiente. Se apoya en datos objetivos utilizando para ello, por ejemplo, la lista de requisitos priorizada, la lista de tareas de la iteración, las actividades realizadas, los gráficos de progreso del proyecto o de la iteración, las métricas del proyecto, etc.
  • Los miembros del equipo proponen problemas adicionales mediante, por ejemplo, una lluvia de ideas (brainstorming). El facilitador va anotando los problemas en las tarjetas y los pega en una pared o la pizarra blanca de manera que todo el equipo pueda leerlas. Como base se puede utilizar una línea de tiempo.
  • El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo utilizando para ello otra tarjeta como cabecera de grupo (grouping).
  • El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto. Para ello cada persona dispone de hasta 10 puntos en forma de post-its a repartir libremente entre los diferentes grupos.

Descubrimiento de causas (30′)

  • Para los grupos de problemas más votados, el equipo analiza por qué se están produciendo. Para ello utiliza, por ejemplo, un diagrama de espina de pez o Ishikawa, con el problema como espina dorsal y las causas como espinas que crecen a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.
  • Notar que en ningún momento se trata de buscar culpables, si no de ver qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas para que el problema no se repita.

Plan de acción (45′)

  • El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede volver a utilizar una lluvia de ideas. Su selección final puede estar basada en una votación o en criterios como coste, esfuerzo o tiempo de realización, satisfacción del cliente, sostenibilidad de la solución, etc.
  • Se generan las tareas necesarias y en ese momento las personas ya se autosignan la responsabilidad de ejecutar, o bien las tareas se introducen en la lista de requisitos priorizada del proyecto (Product Backlog) o la lista de tareas de la siguiente iteración (Sprint Backlog).

Qué ha funcionado bien

Una retrospectiva no sólo debe fijarse en la solución de problemas, si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más. Para ello, se puede aplicar un proceso muy similar al anterior, pero mucho más rápido. Para "forzar" a que todo el equipo piense en las cosas positivas que sucedieron, el proceso de brainstorming se puede iniciar de la siguiente manera: cada miembro del equipo tiene que escribir un mínimo de 2 post-its con lo que funcionó bien. A partir de ahí, ya comienza la parte de grouping.

Conclusiones de la reunión (15′)

  • Se resumen las principales conclusiones y decisiones.
  • Se revisa si se ha conseguido el objetivo de la reunión.
  • Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor (¡ la retrospectiva de la retrospectiva !).

 

Artículos relacionados


 
 
Para conocer otras técnicas que se pueden aplicar en retrospectivas, así como consejos para la facilitación de éstas:
  • Agile Retrospectives: Making Good Teams Great – Esther Derby
  • Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka.