19 de abril de 2016

Retrospectivas

El propósito de una retrospectiva deberían ser los siguientes puntos como se menciona en Scrum Guide
  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.
Pienso que es necesario cuidar los tres puntos a la vez de ser posible. Es importante saber cómo se siente el equipo, descubrir oportunidades de mejora y mejorar el marco de trabajo de Scrum.
Pero, ¿cómo cuidar los tres puntos a la vez?. Quizás la retrospectiva se vuelve demasiado emotiva, quizás demasiado enfocada en mejorar "procesos", o simplemente buscar culpables.

Algo que intento cuidar constantemente es el hecho de mantener una reunión sincera, comentando las cosas que han molestado, pero a la vez buscando construir a partir de ellas, no buscando culpables sino qué cosas podemos hacer distinto para mejorar relaciones dentro o fuera del equipo y evitar cometer los mismos errores una y otra vez.

Aún no he descubierto una receta para esto. El seguir el esquema de los cinco pasos de la retrospectiva me ha ayudado a concentrar al equipo, mantener cierto orden y generar buenos action items. Otra cosa que creo que va a poder ayudar es que las retrospectivas, además de útiles sean divertidas. Voy a seguir el consejo de un compañero Scrum Master intentando adaptar cada retrospectiva a lo sucedido en el Sprint usando las ideas que se ven en el sitio http://www.funretrospectives.com/.

27 de noviembre de 2015

Generando un cambio



De la presentación "Hackeando la Cultura para gestionar el cambio en la empresa" de Angel Medinilla (http://agiles2015.agiles.org/) pude extraer lo siguiente.

Es usual al enfrentarse a un problema intentar proponer cambios, buscamos mejorar las cosas siempre. PERO, en una empresa podemos enfrentarnos a un gran oponente al momento de intentar cambiar algo: La cultura. ¿Y qué sucede? ¿Podemos cambiar la identidad (cultura) de una empresa de la noche a la mañana? No, pero si se puede cambiar a través de pequeños cambios bien enfocados.
El cambio según Angel es un proceso no un evento.

Extraído de la charla de Johnny Ordonez, para empezar un movimiento podemos seguir el ejemplo de los siguientes videos:




Empecemos entonces identificando a los distintos grupos que nos vamos a encontrar:
1. Followers
2. Skeptics
3. Diehards
4. Saboteurs
https://www.mountaingoatsoftware.com/blog/four-types-of-resistors-when-adopting-agile

Teniendo una visión clara empezamos por observar, encontrar "grietas" e identificamos aquella comunidad que quiere seguir el cambio que proponemos. Luego debemos nutrirlos,  darles espacio para aprender, experimentando y aprendiendo de cada iteración de aprendizaje (lean startup thinking). Tenemos que crear una jerga, y hablar todos el mismo lenguaje.

Yendo hacia el segundo grupo, empezamos por ignorar a los rezagados; los podemos tener en cuenta más adelante o la misma cultura los va a alcanzar. Debemos escuchar a los escépticos; podemos elegir un "Champion Skeptic", quien va a ser un agente de mejora en nuestro proceso de cambio y uno de los principales colaboradores para encontrar grietas. Debemos ser abiertos. Realizar victorias a corto plazo y difundirlas, esto puede atraer a aquellos que aún no se deciden; testimonios de aquellos que han adoptado y encuentran un logro al adoptar el cambio puede ser útiles, así como también campeones que impulsen el cambio (Sponsors). Guionizar las diferentes herramientas, interacciones, etc. puede ayudar también (guías de retrospectivas, TDD, etc).

Ahora ya en los últimos dos grupos tenemos una cultura creada con ya varios seguidores, pero es necesario mantenerla. Algunas ideas para esto son:

  • Hacer las alternativas dolorosas.
  • Modificar el entonrno (por ejemplo burndown charts en las paredes).
  • Los dos primeros grupos son poderosos aliados.
  • Y por último, mantener el esfuerzo!


Se puede ver un poco más sobre la presentación en esta ppt http://www.slideshare.net/proyectalis/hackeando-la-cultura-para-gestionar-el-cambio-en-la-empresa.




27 de octubre de 2015

¿Scrum Master o Agile Coach?

Una de las charlas a las que concurrí durante el open space realizado en las jornadas ágiles que se
realizaron el pasado fin de semana en Montevideo fue una llamada "Agile coaching". Asistí a dicha charla con la pregunta ¿un Scrum Master tiene que saber de coaching?. Para nuestra suerte se encontraban entre los asistentes tanto CSMs como Coaches.

Esta charla, la cual se convirtió rápidamente en un debate se habló de ambos roles por separado, hicimos algunas actividades que a mi entender lograron mostrar dónde ambos se fusionan.

La conclusión de la charla fue que un Scrum Master necesita ser directivo cuando el equipo necesita aprender sobre Scrum, y bajo el concentimiento del equipo: Mentor cuando puede mejorar las actividades que el equipo realiza o Agile Coach cuando necesita mejorar las relaciones interpersonales; esto último bajo la tutela de un Coach en el caso de CSMs sin capacitación en coaching.

Para finalizar definamos qué es qué:

  • Scrum Master: es el "experto en Scrum", guía al equipo en dicho framework.
  • El Mentor es un experto que ayuda a mejorar al equipo.
  • El Coach es un guía para ayudar a mejorar el desempeño de las funciones de los individuos. (https://es.wikipedia.org/wiki/Coaching)

Siendo este un tema que tengo poco dominio, se aceptan comentarios.

25 de octubre de 2015

Retrospectivas en 5 pasos


Desde hace ya algún tiempo decidí estructurar las retrospectivas basado en los 5 stages tomado del Agile Retrospectives de Esther Derby y Diana Larsen.
libro
  1. Preparar el escenario
  2. Recolectar Datos
  3. Generar Ideas
  4. Action Items
  5. Cerrar la retrospectiva
Pueden leer además en este blog un excelente resumen de dichas técnicas y cuando aplicarlas.

De lo que trata este post es sobre los resultados que he tenido.

Durante la preparación del escenario es muy común que el equipo se encuentre disperso, distraído quizás con los resultados de la review, u otras obligaciones. Es por eso que considero muy importante el hecho de poner a todo el equipo en sintonía.

Al recolectar datos no solo estamos exponiendo cosas que consideramos pertinentes resaltar sino que además alertamos al resto del equipo de nuestros pensamientos. De forma que cambiamos la realidad del resto; quizás para un miembro del equipo el sprint fue exitoso, pero no para otros.

Generar ideas es sencillo, generar ideas que luego esté dispuesto a tomar la responsabilidad ya no. Es por eso que últimamente decidí cambiar las retrospectivas para que en esta etapa el equipo diga "Qué salió bien" y "Qué puedo hacer YO para mejorar". De esta manera lo negativo queda implícito e interno, pero busco soluciones para esas cosas que me molestan y me hago cargo de ellas.

He escuchado que otros equipos, y me ha sucedido que se generan action items, pero sin dueños... ¿entonces quién los termina haciendo? Es tan importante tener responsables como tener action items.

Por último y tomando el consejo de un compañero (aunque no lo dijo con estas palabras), para algunos equipos se puede aplicar las mismas técnicas como un kata para que el equipo no se sorprenda a la hora de la retrospectiva y pueda compartir lo que tenia pensado. Por otro lado ir cambiando las técnicas es motivante para el equipo y puede ayudar a descubrir cosas inesperadas. Por ejemplo lo que le tengo preparado para la retro de este viernes a uno de mis equipos.

Agiles 2015 - Agentes del cambio

Los últimos 3 días (del 22 al 24 de octubre, 2015) se realizó en Montevideo, Uruguay el encuentro Agiles 2015 en el hotel Radisson Victoria Plaza.

Como no me va a dar un solo post (y aún no he digerido todo lo aprendido) para describir voy a ir creando una serie de posts con todo lo que me llamó más la atención.

Los temas que más me interesaron, son casualmente todas las charlas a las que atendí... ¿o será que el nivel de las charlas fue más que excelente? No se, la cuestión es que ningún minuto ahí tuvo desperdicio.

El título de este post es a mi entender la esencia de lo que se cubrió en este Agiles 2015: Agentes de cambio.

Los temas que voy a ir cubriendo los próximos días serán:

Foto: https://twitter.com/agiles2015


23 de diciembre de 2014

Transformación ágil: Agile PMO

¿Cómo entra un proyecto ágil dentro de una clásica PMO? Esta es una pregunta que me he estado haciendo desde que asumí el rol de Scrum Master. Al principio parecía fácil; mantener el foco, facilitar reuniones y remover impedimentos... pero hay mucho más aparte de eso.
Se nos sugirió leer el siguiente articulo https://www.cprime.com/resource/white-papers/agile-pmo/. En este, cPrime introduce qué es una PMO, luego empieza a incluir artefactos ágiles dentro de las distintas disciplinas que maneja la PMO. En mi opinión no es una verdad absoluta que hay que seguir al pie de la letra, pero se puede tomar de punto de partida para una transformación hacia un híbrido de oficina ágil y clásica.
En siguientes posts voy a seguir tocando el tema de transformación ágil, lo cual es en cierta manera mi evolución en ese mundo y como me adapto a los distintos intereses y procesos ya establecidos.

23 de octubre de 2014

Stories, Epics & Themes

Stories que se vuelven muy grandes, stories relacionadas por factores en común, veamos un poco los artefactos que nos brinda Scrum en cuanto a entregar valor a través de stories y como categorizarlas.

Stories

Una Story comienza con una descripción vaga de una necesidad/funcionalidad la cual es refinada entre el equipo Scrum y los stake holders.
Por ejemplo: "Como administrador del sistema me gustaría tener acceso a los logs así puedo descubrir si algo no funciona".

Epics

Es un conjunto de stories que pueden o no tener un valor de forma independiente. Es el Epic quien agrega el valor al entregar el conjunto de funcionalidades.
It just means “big user story.” (Mike Cohn)
Puede pasar que una story sea demasiado grande o difícil de estimar por su complejidad. Esto usualmente lleva a dividir la story en en varias stories, agrupadas bajo un Epic.

Themes

Es un conjunto de historias independientes en las que cada una aporta valor y pueden ser entregadas de forma independiente pero tienen un tema en común. Por ejemplo "Registro y Autenticación del usuario", esto se puede hacer con varias stories: "Registro/Autenticación con API de Google", "Registro/Autenticación usando Facebook", "Registro/Autenticación de usuarios". Todas estas historias se podrían convertir en Epics ya que según mi perspectiva involucran varias stories cada una, que solas no aportan valor, pero juntas si.

Fuentes