Como comenté en la entrada anterior, uno de mis objetivos para el curso de CSM era terminar de convencerme si Scrum era la solución para el equipo de desarrollo en el que trabajo o no. Después de lo aprendido concluí que sí, que era la solución. Este post está basado en un mail que envié al grupo foro-agiles, contando cómo empezamos con la implementación de Scrum.
Muchas de las recomendaciones y prácticas sugeridas por Scrum ya las veníamos implementando. El equipo cuenta con 7 programadores y yo, que asumo el rol de Scrum Master. El perfil general del equipo apuntaba a que Scrum era una buena idea.
En un momento del proyecto, llegamos a una etapa de re organización de nuestra forma de trabajo. En esta reunión abierta del equipo de desarrollo, sugerí utilizar Scrum y argumenté las razones. Estaba convencido que era una solución conveniente para este proyecto en particular. En ese mismo momento surgió una charla sobre Scrum para transmitir lo aprendido en el curso. Para esto, se llamaron a los distintos encargados de departamento y se juntó al equipo de desarrollo.
En aproximadamente una hora y media, intenté transmitir la mayor cantidad de conocimientos e ideas adquiridos en el curso. Me enfoqué más en la filosofía, espíritu, e ideas de Scrum, que en la implementación misma, aunque esto también fue mencionado. La meta era que los programadores entendieran la filosofía de trabajo, la esencia de Scrum, y la confianza que se les tiene para implementar correctamente la metodología. Estuvo bueno porque tanto los desarrolladores como el resto de la empresa estuvieron de acuerdo en la implementación de Scrum y lo encontraron beneficioso para el proyecto.
Así que de a poco empezamos a usar las herramientas de Scrum para llegar a implementar lo que consideremos necesario. En un principio, hicimos un working agreement. El working agreement, o acuerdo de trabajo, es una serie de reglas, o normas a seguir por el equipo. El compromiso y disciplina de los miembros del equipo es una parte importante de la implementación de Scrum. Así que se realiza este documento, con la participación y aceptación de todos, y luego se imprime/escribe en algún lugar que sea visible para todos. En nuestro caso lo imprimimos y colgamos en la cartelera del departamento de desarrollo, además de publicarlo en el blog interno de la empresa para darlo a conocer al resto. El documento está abierto a modificaciones (ya agregamos un ítem más desde su creación… tengo que imprimir eso de nuevo!).
El segundo paso fue definir la visión del equipo de desarrollo. Conocíamos la visión de la empresa, y del proyecto, pero debíamos definir una visión propia. Llegamos a algo nuestro y compatible totalmente con la visión del proyecto y la empresa.
Para la gestión de tareas veníamos usando Trac. Como Project Manager tenía que obtener las tareas a partir de la documentación, y asignársela a cada programador. Implementando Scrum, esto ya no es tan necesario, ya que el equipo auto organiza el trabajo. Además se evita el cuello de botella que generaba el hecho de que todo pasara por una persona. De todas formas, Trac puede ser una opción como herramienta para gestionar el trabajo del Sprint.
Empezamos un martes, e hicimos un «mini-planning» para definir el trabajo en los siguientes días de la semana, definiendo el viernes como final de Sprint, con la respectiva reflexión y review del cliente. Esa misma semana caí enfermo, y tuve que faltar los días jueves y viernes. Me perdí tanto los daily meetings como el review y reflexión del viernes. La reflexión no se hizo muy detalladamente, simplemente se repasó lo que se hizo y lo que quedó pendiente.
El lunes siguiente arrancamos con un planning más detallado. Como recién venimos empezando, estamos haciendo todo cada una semana.
Una de las particularidades de nuestro caso es que el Product Owner se encuentra actualmente fuera del país, por lo que llevamos la comunicación entre el Scrum Master y él a través de correo, mensajería instantánea, skype, etc. , apoyado con documentación post-planning y los reviews online. Actualmente, el no participa en el planning del Sprint. La idea que estamos implementando para solventar su ausencia en los planning es:
Definimos Sprints con comienzo el lunes, y review y retrospección el viernes. Comenzando con Sprints cortos creemos que tenemos más posibilidades de hacer una estimación precisa. Probablemente a la larga los extendamos a dos semanas, arrancando un lunes y terminando el viernes de la siguiente semana. Los jueves, el Scrum Master agrupa las «user stories» que van a ser planteadas en el planning del lunes. Este mismo día se realiza una videoconferencia con el Product Owner, y se definen las prioridades y tareas a incluir en el Sprint. Y así lo venimos llevando por el momento.
