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.

Hablando casi con propiedad

El pasado lunes 21 y martes 22 de Julio se realizó una nueva instancia del curso para acceder a la certificación de Scrum Master. El curso fue dictado en el hotel Ibis Montevideo por Martin Alaimo (Kleer).

El curso se dictó bajo una dinámica interactiva y participativa siempre fluyendo, sin quedar bloqueada o en loops interminables, esto a mi entender habla muy bien y demuestra la capacidad como educador del trainer.

Cosas que me llevo del curso:

• Muchas dinámicas integradoras aplicables a diferentes reuniones.
• Nuevas formas de resolver impedimentos y problemas interpersonales.
• La experiencia de otros colegas y de "mi compinche".
• El marco de Cynefin; algo en lo que ahondar.
• Alternativas para estimar.
• Y por supuesto un mejor entendimiento de los roles y artefactos de Scrum.

Además me gustaría agradecer a Martin por el libro Proyectos Agiles con #Scrum y a mis compañeros de curso por regalarme el libro Equipos #Más Productivos

Por último me quedo con esta frase:

El buen trabajo de un SM se nota cuando ya no se lo necesita.

Algunas contras de Kanban

Leyendo un articulo recordé un tema que me venia aquejando hace un tiempo; la falta de sentido de tiempo que genera aplicar Kanban. En mayo de este año en una de las charlas de OpenSpace de Agiles.uy propuse como tema "Kanban: Resultados" con el fin de conocer otras experiencias acerca de la aplicación de Kanban en equipos ágiles.
Algunas de las cosas de esa charla y de información que descubrí:

• Kanban parece hacer que el equipo se divida en individuos.
• La falta de objetivos claros y a corto plazo parece desmotivar a los equipos; vi este mismo padecer en más de un equipo con gente diferente.
• Necesita de un deadline fijo en el tiempo para poder medir y mejorar la velocidad de desarrollo.
• Sin embargo los miembros del equipo tienden a convertirse en puntos de una linea de ensamble y empiezan a mejorar su capacidad de producción intrínsecamente.

Algunas de las soluciones que implementamos para mejorar estas falencias fueron tomadas de Scrum:

• Daily meetings para que todo el equipo esté al tanto de lo que sucede.
• Retrospectivas luego de cada release.
• Explicitar la necesidad de pair programming en las tarjetas, esto afecta la estimación.
• A las tarjetas se les pone una estimación luego de que es analizada por el equipo con el fin de darle una idea de esfuerzo al PO y ayudar a la priorización del backlog.

Bajo el contexto de que el equipo puede cambiar así como también las prioridades se vuelve muy difícil la aplicación de Scrum, de busca una alternativa, sin perder los privilegios de Scrum, pero ganando la flexibilidad de Kanban.

Por último, algo que lei del artículo y que pensaba implementar es el hecho de tener milestones o iteraciones, donde el equipo se compromete a que si nada ajeno al equipo sucede, se sube una nueva versión con ciertos requerimientos analizados y estimados para una fecha fija. Esto debería eliminar la falta de sentido de tiempo que sufre el equipo.

Scrum y Kanban en pocos minutos

Scrum

Kanban

Cambiando las daily meetings

Hace algún tiempo leí un articulo propuesto por mi antiguo profesor Gabriel Ledesma (@gafaled) acerca una alternativa para la dinámica de las daily meetings.
En este articulo se habla de cambiar las clásicas preguntas "qué hiciste ayer y que vas a hacer hoy" a orientar la daily en base a las historias que se encuentran en el Sprint Backlog, donde el facilitador (en el caso de Scrum el SM) recorre el Sprint Backlog y pide una actualización de progreso de cada historia. De esta forma todo el equipo participa de la reunión y ninguno se aburre (y consecuentemente no se distrae).

Puesta en practica
Este articulo me vino como anillo al dedo, puesto que venia notando los síntomas que habla el articulo; entre otras cosas pasaba que cuando un miembro del equipo hablaba, el resto está mirando la hora y pocas veces se sabe en que anda el otro.
Inmediatamente a la primera aplicación de esta alternativa frente al sprint backlog el equipo empezó a participar de forma ordenada; el cual era mi principal miedo. Esto además acortó la distancia entre devs y QAs, quienes comenzaron a interactuar mucho más. Consecuentemente todo el equipo apuntaba en una misma dirección.
Luego de recorrer todas las historias, venia la pregunta "¿algún impedimento?".
Una desventaja que le encontré es que muchas veces la reunión se pasaba de los 15 minutos establecidos y eso se hizo notar en la siguiente retrospectiva, por lo cual comenzamos a limitar el tiempo que se hablaba por historia.

Resumen de la experiencia
Pros

• Todo el equipo se involucra.
• Aumenta la interacción/integración del equipo
• Crece el interés/compromiso alrededor del sprint.

Contras

• Se puede extender mucho y pasa a ser improductivo.
• Algún miembro tímido puede perder su oportunidad de hablar.

Fuente

Articulo de Gabriel Ledesma

Agile Open Space 2014

El 17 de mayo de  2014 se realizó en el Aula Magna de la Universidad Católica, la segunda edición del Open Space organizado por la comunidad Agile-Uruguay. En este post voy a escribir un resumen de lo que pude aprender de las charlas a las que asistí.

¿Qué es un Open Space?

Un Open Space es un formato de conferencia o reunión abierta, donde la principal característica es que la agenda se genera de manera dinámica entre todos los participantes de la reunión. En general constan de 4 partes: Apertura, Mercado de ideas, Sesiones y Clausura.

http://agiles.uy/

Durante el Mercado de Ideas se propusieron diferentes charlas, todas muy interesantes, por lo cual la elección se me hizo bastante difícil.
Finalmente luego de mover algunas charlas para acomodarme elegí asistir a las siguientes charlas:

• Kanban: Resultados (charla que yo propuse).
• Coach Agile. Diego Caballero.
• Salarios en equipos agiles. Valeria Viera.
• Pagando la deuda tecnica. Diego Sapriza.

Kanban: Resultados

En esta charla presenté brevemente Kanban, por qué utilizarlo, una idea de como adaptarlo/implementarlo y los resultados que obtuve. Luego se generó un debate en base a experiencias personales de los otros agilistas y pudimos concluir lo siguiente:

Conclusiones

https://twitter.com/Eaven_uy

• El sentido de pertenencia influye en la motivación del equipo.
• Pivotal Tracker y Trello son herramientas sencillas para el manejo de boards virtuales, que compiten contra Jira.
• Si el equipo y los objetivos cambian mucho Scrum no sirve.

• Kanban es una buena alternativa siempre y cuando tenga objetivos claros y desafiantes.
• Una implementación de Kanban sin objetivos claros o metas a corto plazo quita motivación.
• El trabajo ágil requiere de equipos fijos, puede fomentar competencia sana contra otros equipos y por lo tanto aumenta la productividad. Algo a investigar!
• Silicon Valley es una serie que hay que mirar :)

Coach Agile

https://twitter.com/Eaven_uy

Esta charla en particular me pareció muy interesante dado que era un tema que venía investigando.

Fue presentada por Diego Caballero y si bien no se mencionó/definió exactamente qué es un coach agile, se mencionó qué hace un Coach agile.

El siguiente video puede ilustrar más o menos lo que se habló:

Literatura recomendada: Agile Coaching de Rachel Davies y Liz Sedley.

Salarios y equipos ágiles 

Literatura recomendada:

• Valve Handbook
• Buffer Open Salaries

Conclusiones, entre otras:

• Scrum no dice nada acerca de este tema.
• Una posibilidad es que todo el equipo tenga un sueldo base y a partir de eso la empresa premia aquellos empleados que cumplen con ciertos objetivos que la empresa considera necesarios (por ejemplo: antigüedad, expertise, etc).
• Agile propone dividir ganancias.
• Personas del equipo premiando a otros miembros del equipo.
• Sueldo variables.
• Un sueldo bajo desmotiva, pero los bonos no son motivantes.

Este tema quedó abierto ya que es algo muy amplio, pero entre algunas de las cosas interesantes que pude oír es que dividir la ganancia aumenta la participación.

Deuda técnica

Me quedé con tres cosas de esta charla:

• No pude escuchar una definición clara de deuda técnica.
• Si se puede hacer bien, hay que hacerlo bien. El cliente no tiene por  que pagar un producto de baja calidad.
• Es bueno negociar de antemano un porcentaje de tiempo para solucionar deuda técnica.

Conclusiones

Si bien no concurrió la cantidad de gente que esperábamos, todas las charlas fueron de gran nivel. aprendí y quedé entusiasmado para seguir investigando en Agilismo. Algo que definitivamente voy a seguir investigando es acerca del perfil de Coach Agile.

Y por último... gracias a toda la gente que participó y a la gente de Synchronit por aportar llevar el Oculus Rift :D.