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.

¿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.

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:

• Fricción: un resumen de la charla de Mary Poppendieck
• Management 3.0 e Improvement21.
• ¿Scrum Master o Agile Coach?
• Motivación en equipos ágiles.
• Arquitecturas Evolutivas.
• Innovación en la política.
• Agentes de cambio.

Foto: https://twitter.com/agiles2015

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.

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

• Agile User Stories, Epics and Themes - Mike Cohn, Scrum Alliance 20 de Marzo del 2014.
• Stories versus Themes versus Epics - Jeremy Martins, Scrum Alliance 13 de Marzo del 2014.

Lean Startup Machine Montevideo

El fin de semana del 1 al 3 de agosto se realizó en Montevideo la primer Lean Startup Machine.

Este evento junto a futuros emprendedores, mentores y entusiastas de la innovación, donde se puede aprender la metodología Lean Startup y enriquecerse del conocimiento de los mentores y otros participantes.

Más allá de aprender la metodología la cual me terminó de convencer como algo para aplicar, conocí inversores angeles, mentores y pude refinar muchas de las ideas que tenía en mente y agregar nuevas.

Acá van algunas de las cosas que más me quedaron y como las entendí:

• Según Evan Henshaw-Plath @rabble:
• Primero que todo, el gran factor es "suerte"
• No hay que arrancar por una mega aplicación, se puede arrancar por algo "trucho" (MVP).
• Según Pablo Brenner:
• "No hay sistema mas socialista que #wallstreet".
• Un buen producto tiene que ser una metáfora de algo real.
• Hay que festejar cuando un cliente vuelve, no cuando adquirimos uno nuevo.
• Según todos (y parte fundamental de los procesos Lean) es necesario darle un valor a las personas.
• Hay que darle una oportunidad a la idea, pero no caer en "enamorarse de la idea".
• No perder el tiempo en algo que las personas usarían, sino algo que están dispuestos a pagar.
• No un "I want to have" sino "I must have".
• Foco, una cosa a la vez.
• Hay que empezar vendiendo humo.
• Todo lo que podamos pensar son suposiciones ¡SALIR DEL EDIFICIO PARA VALIDAR!

Se puede ver un poco la cronología del evento en https://twitter.com/leanmontevideo, ya está abierto el cupo para organizar un nuevo evento en este link: http://l3an.com/1ewyoq8.
Además se va a estar organizando un Lean Startup Day el sábado 30 de Agosto en Sinergia Co-Work http://leanstartupday.wix.com/leanstartupday.
Próximamente los videos de las charlas.