Fuente original http://www.diegosalama.com/2009/08/21/scrum-funciona/

SCRUM funciona!

En esta oportunidad quiero compartir mi muy agradable experiencia de implementar Scrum como metodología de gestión de proyectos en OLX.

ScrumCycle

Introducción

Empezaré presentando algunas definiciones para ponernos en tema:

  • Scrum es un proceso ágil de desarrollo de software, iterativo e incremental. En cada iteración se hacen variadas actividades de análisis, diseño, desarrollo, testing, implementación.
  • Scrum está enfocado a la gestión de los procesos de desarrollo y puede o no estar implementado en conjunto con otras prácticas ágiles como ser Extreme Programming (XP), Continuous Integration, Test Driven Development, etc.
  • Scrum suele vincularse al desarrollo de software, pero su aplicación es adecuada dentro de las especialidades más variadas que podamos imaginar.
  • Scrum es “liviano”, presenta simplemente un modelo de referencia que describe un conjunto de prácticas y roles que puede tomarse como punto de partida para definir el proceso de desarrollo.

Roles que Scrum propone:

  • El Scrum Master: Se asegura que se sigan los procesos, trabajando de forma similar al director de proyecto.
  • El Product Owner: Representa a los Stakeholders (clientes internos o externos).
  • El Team: Incluye a los desarrolladores, testers, diseñadores, analistas, etc.

Prácticas que Scrum propone:

  • Se realizan ciclos (o iteraciones) de duración fija llamadas Sprints. Se recomienda que la duración de un Sprint sea de 2, 3 o 4 semanas.
  • Durante el Sprint el objetivo del equipo es generar un incremento visible, utilizable, entregable.
  • Al inicio de cada Sprint se realiza una Planning Meeting durante la cual se revisa el Backlog de proyectos (listado de requisitos de alto nivel pendientes, previamente priorizados por el Product Owner). En esta reunión el Product Owner identifica los proyectos que quiere resolver y los describe al equipo. Entonces, el equipo determina cuáles de estos proyectos pueden ser comprometidos para el Sprint.
  • Durante el transcurso del Sprint no se puede modificar el alcance del mismo, es decir, se intentará mantener congelados los requisitos hasta que el mismo finalice. En la práctica, nos hemos reservado parte de nuestro tiempo para lidiar con urgencias que no pueden esperar un ciclo para ser resueltas.
  • Diariamente se realiza una Daily Meeting que no debe durar más de 15 minutos, donde cada persona del equipo comparte las tareas realizadas, lo que piensa hacer hasta la reunión del día siguiente y si se ha topado con algún impedimento que no le permita avanzar de acuerdo a lo comprometido.
  • Al final del Sprint, luego del Deploy / Release / Incremento en el producto, se realiza una Retrospective Meeting durante la cual el equipo comparte libremente opiniones sobre las cosas que salieron bien (y desean repetirse a futuro) y las cosas que salieron mal (y deben evitarse a futuro).

Ahora si, pasemos a mi historia…

Junto a Edu en OLX NY

Aprendiendo Scrum

Tras varios meses de investigar sobre el tema, leer papers, comprar libros y consultar experiencias de otros profesionales, finalmente en Agosto de 2008 decidimos junto con Eduardo Rivara, Senior Manager de Integraciones en OLX, ir a capacitarnos formalmente a Boston. Buscando entre las propuestas de Danube rápidamente pudimos definir la fecha.

Ir junto a Edu fue una de las mejores decisiones que podríamos haber tomado. Básicamente tenemos formas muy distintas de gestionar proyectos. Entre los dos debemos sumar casi 40 años de experiencia, y sin embargo antes de compartir esta actividad nos parecía extremadamente difícil coincidir en cuál era la forma más conveniente de llevar adelante nuestros proyectos.

Yo soy amigo de los procesos, estándares y herramientas que nos ayuden a gestionar el caos y a Edu el exceso de reglas le resulta asfixiante. Y como mencioné en este otro post, en muchas situaciones él está en lo cierto!

Edu ha logrado desarrollar mecanismos de integración en su equipo que hacen que no necesiten herramientas ni procesos para guiar su trabajo. Simplemente todos parecen saber qué hacer en el momento oportuno… y los proyectos salen funcionando.

Comento esto porque nuestra experiencia de capacitarnos en scrum se potenció indudablemente, dado que cada aspecto que aprendíamos durante el curso lo discutíamos luego desde posturas distintas, y sin embargo los dos encontramos un punto de coincidencia sobre que scrum era potencialmente una buena forma de llevar adelante los proyectos. Finalmente acordamos en que el método no es lo importante, sino la forma en la cual se lo usa.

Scrum bien implementado nos ayuda a hacer que el trabajo sea más divertido, emocionante, desafiante. Scrum mal implementado puede ser parecido al infierno… pero la ventaja es que esto se notará rápidamente y el equipo deberá evolucionar hasta que funcione.

Bien… Nos certificamos en Boston como Scrum Masters y Product Owners, y regresamos a Buenos Aires. Yo convencido de que haría el intento de implementar la metodología para mis equipos de desarrollo en OLX.

Diploma ScrumMaster

La Implementación

Ya sabemos que ningún cambio es simple… mucho menos cuando involucra modificar comportamientos que tenemos arraigados, inclusive si no estamos contentos con los mismos!

Mi primer paso – y se lo recomiendo a cualquiera que intente implementar scrum en su organización – fue buscar el apoyo del equipo y de mis jefes. Uno podría pensar que la mayor resistencia en general proviene del equipo, que es quien más duro deberá trabajar para adecuarse al cambio. Pero no hay que ser confiados… En algunas ocasiones es necesario duplicar la apuesta y esforzarse mucho en convencer a nuestros jefes sobre los beneficios que se obtendrán al llevar adelante el proceso. Eso es lo que me pasó a mi.

Finalmente lo logré 🙂 con lo cual el segundo paso fue conseguir aliados activos que me ayudaran con la cruzada. Los líderes de equipo recibieron capacitación como Scrum Masters y dediqué mucho tiempo a charlar con quienes no pudieron asistir a una formación formal, con el fin de estar todos lo más alineados posible. Realmente el cambio que se proponía no era simplemente usar un template de documento por otro… estábamos por despedazar la forma en la que se trabajaba hasta ese momento y replantear un esquema nuevo desde cero.

El tercer paso fue asegurarme de hacer una comunicación lo más clara posible sobre el proceso nuevo, las ventajas sobre el existente, los pasos que se llevarían adelante para lograr el cambio, y la flexibilidad que se tendrá para adecuar lo que sea necesario en beneficio del resultado general. Además de dar presentaciones personalmente a distintos equipos, se confeccionaron documentos que fueron enviados a todos los sectores para que entendieran el cambio que mi sector estaba por atravesar.

Voy a extraer parte del contenido de la presentación que realicé al equipo, para que se entienda el enfoque de la propuesta:

Todo lo que tenemos que hacer es:
Desarrollar el sistema adecuado
Hacerlo de la forma adecuada
Implementarlo en el momento adecuado
… y lograr que la organización esté contenta mientras lo hacemos

Fácil, no?

Deberemos ajustar nuestros procesos y respetar una serie de valores que serán clave para lograrlo.

Estos son los valores que vamos a defender en todo momento:

  • Apertura
  • Enfoque
  • Compromiso
  • Coraje
  • Respeto
  • Colaboración – Trabajo en Equipo
  • Honestidad
  • Humildad
  • Paciencia
  • Empatía

Alguien desea proponer uno adicional?

Puesta en Marcha

Considero que el cambio fundamental respecto a la manera en la cual veníamos trabajando fue de composición de equipos.

Nuestro enfoque hasta el momento se basaba en distintos grupos (producto, desarrollo, QA, infraestructura) desarrollando proyectos y yo quería que nos transformáramos en un equipo desarrollando productos.

Tenía a mi cargo al área de QA, dos equipos de Desarrollo – Core y Mobile -, una persona que me ayudaba con Producto, otra con diseño y maquetación y un sector de Infraestructura que me reportaba parcialmente… cada uno de estos grupos tenía sus objetivos y sus responsabilidades parciales sobre la “línea de montaje”. Resultaba complicado lograr que el equipo viera el panorama general.

Nuestro ciclo habitual implicaba que durante 1 semana los grupos de desarrollo trabajaban en una serie de proyectos, que luego se pasaban al ambiente de QA para que los testers realizaran las pruebas de aceptación mientras los desarrolladores avanzaban sobre el siguiente release – y si era necesario corregían bugs de lo que QA estaba probando -. Luego los cambios se implementaban en producción, donde a su vez podían volver a surgir bugs que requerían ser corregidos y testeados. Obviamente una demora en una etapa implicaba tiempos muertos en la siguiente.

En conclusión, mientras en producción teníamos la versión X del producto, QA estaba enfocado a testear la versión X+1 y Desarrollo ya avanzaba sobre la versión X+2. Descontando que Producto estaba analizando versiones X+3 o posterior… todo en paralelo. Cada vez que había un bug en QA o en Producción, los developers debían suspender lo que estaban haciendo, cambiar de entorno, corregir el bug, luego volver a sus desarrollos… la gente de QA no contaba con el tiempo y atención necesarios de los desarrolladores para cumplir con las fechas de los releases, y en definitiva en un momento puntual los equipos estaban dedicando su atención a distintas cuestiones.

Este esquema de trabajo es uno de los más adoptados en la actualidad, sin embargo yo tenía una visión diferente. Debíamos trabajar todos como unidad, siendo un solo equipo. Programadores, Testers, Analistas, gente de Infraestructura, Diseñadores, Producto, todos. Comenzar una iteración todos involucrados en los mismos proyectos al mismo tiempo, y considerar terminada nuestra tarea recién cuando el cambio se hubiese implementado y funcionara correctamente en producción.

Yo sería el Product Owner y cada líder de desarrollo sería Scrum Master de su equipo, con personas de QA formando parte del mismo y no como un sector externo.

Esto implicó que personas que sentían su “pertenencia” al equipo de QA, por ejemplo, hicieran un duelo y se despidieran de ello. Ser alguien de QA es ahora una especialidad, pero el equipo es el scrum y está conformado por programadores, testers, gente de producto, etc. También se generó cierta resistencia la primera vez que un programador debió testear el trabajo de otro, porque si no el equipo no llegaba a termina con el sprint en fecha.

Hoy en día, hemos logrado que durante los primeros días de cada sprint, mientras los developers comienzan a desarrollar funcionalidades, los testers escriban y documenten los casos de prueba. Durante los últimos días del sprint, cuando se encuentran bugs, los programadores son los más interesados en resolveros a tiempo y no están preocupados desarrollando cosas del sprint siguiente. Solo se cambia el alcance del sprint si surge un error crítico en producción y en la medida de lo posible, el equipo no recibe presiones externas más allá de intentar cumplir con la iteración del momento.

En definitiva, trabajamos sobre los mismos temas con el fin de subir una nueva versión del producto al final del sprint, comprobar que todo funcione como corresponde, hacer nuestra reunión de retrospectiva para aprender de nuestros errores y luego volver a enfrentar los requerimientos del release sprint.

El resultado

Habiendo transcurrido ya un buen tiempo, considero que los resultados han sido asombrosos.

No he logrado el 100% de lo que me proponía. Incorporar al equipo de Infraestructura como parte del mismo Team, finalmente no sucedió. Si bien la comunicación con otros sectores ha mejorado, hay ocasiones en las cuales falta sumar a la mesa de reuniones a personas de otros equipos.
También queda pendiente cambiar la duración de los sprints. Solo 2 semanas no nos da tiempo a encarar proyectos más grandes, que indefectiblemente son separados en múltiples etapas, y tampoco logramos relajarnos unas horas entre sprint y sprint. Pasar a períodos de 3 semanas es algo que sin duda debería ser encarado  eventualmente, pero no he logrado aún convencer a mis jefes 🙂

Testers y programadores han podido integrarse, si bien es cierto que siguen existiendo conflicto de intereses ocasionalmente, pero ha sido maravilloso ver a un programador completando un test de regresión porque el tester no llegaba a tiempo a terminarlo, o un tester consiguiendo definiciones porque desde producto no se habían logrado confeccionar las mejores especificaciones para un proyecto.

Incluso si levanto la mirada, veo que están sentados físicamente uno al lado del otro de forma intercalada. En el pasado cada grupo tenía una isla de escritorios particular, y estando a dos metros uno del otro se seguían manejando las comunicaciones por email. Ahora la gente habla entre si, la mayoría de las veces, lo cual es bueno.

success_keyDurante los últimos 15 releases en OLX, nos hemos demorado una sola vez. La demora fue de 1 día. Esto no lo logran todos los equipos, verdad?

Desde lo personal, implementar scrum junto a mi equipo ha sido para mí una de las mayores satisfacciones dentro de OLX. Sentir el apoyo de la gente la mayoría de las veces, sentir su desacuerdo respetuoso y profesional en otras oportunidades, ver su constante esfuerzo por intentar el cambio y superar las frustraciones, incluso mientras continuábamos trabajando bajo presión, son recuerdos que tendré atesorados para siempre.

Todavía hay cosas por mejorar, la magia consiste en no acostumbrarse ni conformarse y siempre avanzar. No estamos usando a fondo algunos instrumentos que nos permitirían tener más visibilidad del estado del sprint en todo momento, y algunas veces la comunicación con otros grupos de la empresa no son lo fluidos que deberían ser. Sin embargo la semana pasada algunas personas del equipo me han venido a proponer la creación de un comité que se encargue de seguir mejorando los procesos de forma continua. Es maravilloso haber mostrado un camino, que me hayan seguido y ver como ahora el equipo está en condiciones de definir por si mismo los próximos pasos. Para mi esto es misión cumplida.

Mis gracias a los líderes: Pablo, Paola, Marcela y Mike.

Mis gracias al team: Adrián, Ale B., Ale C., Diana, Dirk, Emiliano, Franco F., Franco M., Griselda, Guille, Hernán, Javier M. Javier S., Jonas, Jony, Magalí, Martín, Mauricio, Natalia, Nico, Pako y Peter.

Gracias a todos por su Apertura, Enfoque, Compromiso, Coraje, Respeto, Colaboración, Honestidad, Humildad, Paciencia, Empatía. Gracias por su confianza.

Hoy en día considero que han dejado de ser personas llevando adelante proyectos, para convertirse en un equipo que desarrolla productos. Estoy orgulloso de ustedes.

Anuncios