Aplicando Scrum

El siguiente post es solo una idea, que pienso probar de poner en práctica, y ver si me funciona. Estoy retomando los estudios en la Facultad de Ingeniería. Además de eso, estoy trabajando y tengo unos cuantos proyectos más en la lista de cosas para este año. Si bien pienso dedicarle tiempo a la facultad, soy conciente que con la cantidad de cosas que tengo arriba, no voy a poder dedicarle una cantidad importante de tiempo.

Por esto, tengo que exprimir el tiempo que le dedique a los estudios, usándolo de manera efectiva y aprovechando cada minuto. Se necesita una buena gestión de la cantidad de trabajo, priorizándolo según el retorno de inversión de tiempo que tenga cada tarea. Así que sin pensar demasiado el tema, puedo perfectamente aplicar Scrum para organizar de manera efectiva mis estudios.

Esto sería una aplicación de Scrum personal, donde yo mismo ocuparía el rol de Scrum Master, Product Owner y equipo. Como Product Owner, voy a saber cuáles son las tareas que me interesan más, según su retorno de inversión, poniéndolas por delante de aquellas que me resulten más fáciles o simples. Como Scrum Master voy a ser responsable de que mi Scrum se realice de manera positiva, y como equipo, voy a estar encargado de realizar mis tareas.

Es algo que estoy considerando, debería probarlo por un tiempo. Tendría además que obligarme a cumplir las instancias de Scrum: Sprint Planning, Daily Meeting, Retrospectiva y Reflexión.

Sprint – Debería hacer los Sprints de corta duración: 1 semana; ya que de a poco voy a ir viendo qué hay por estudiar por cada materia. Además, podré priorizar los temas a estudiar según los resultados que vaya obteniendo: “En esta materia me fue mal en el parcial, tengo que dedicarle más tiempo”. El Sprint Planning debería hacerse todos los lunes o domingos, ya que es cuando comienza la semana de clases. Incluso podría hacer un burn chart, donde detectaría qué materias me cuesta más estudiar basado en los resultados que obtenga.

Daily Meeting – Como en un equipo de trabajo, se trataría de verificar la cantidad de tareas estimadas contra las realizadas, detectar problemas, y comprometerse con nuevas tareas.

La retrospectiva y reflexión serían bastantes personales, ya que yo mismo estaría revisando si los resultados obtenidos son satisfactorios.

Es importante tener un backlog, donde pueda ir pegando tareas “por realizar”, para ir incluyendo en Sprints siguientes.

Todo esto requeriría un compromiso personal con el trabajo (el estudio), y demandaría bastante disciplina de mi parte. Es algo bastante complejo, creo, pero sencillo a la vez. Me mantendría fuera de la zona de confort, y como siempre digo: usar Scrum para gestionar el trabajo es mejor que no usar nada.

En fin, realmente lo estoy considerando aplicar. Voy a ver si consigo un pizarrón, unos post-it, y empiezo. También voy a incluir tareas de otros proyectos, reuniones y demás, para gestionar el tiempo completo de forma realista. Al igual que en los proyectos de software, en la vida diaria aparecen muchas tareas no planificadas. Por esto, estoy pensando si usar una referencia de colores de post-it según el área a la que involucren: estudio (incluso por materia), trabajo, otros, etc. o según tareas planificadas, no planificadas, etc.

Creo que podría usar post-it amarillos para tareas que se desprenden de la planificación y post-it rojos para tareas que surjan de apuro. Como referencia, puedo usar los post-it más chicos que hay de distintos colores, para identificar a qué área pertenecen. En fin, por ahora esto es solo una idea, pero creo que por lo menos voy a probarlo…

El lunes pasado tuvimos el primer Sprint Planning de la reimplementación de Scrum. Estuvo bastante bueno, como siempre, una de las principales ventajas de Scrum es que se comience una nueva etapa en la comunicación y colaboración del equipo. Ese cambio de cabeza, de perder el rol de “jefe”, y pasar a que el trabajo de cada uno sea responsabilidad del equipo hace a un cambio general en el ambiente, no tanto en el plano personal del trato entre los miembros del equipo, sino la forma de encarar el trabajo en sí. Se hace mucho más dinámico y efectivo, además de organizado. Estoy hablando de un equipo donde anteriormente no se usaba una metodología específica de desarrollo, sino que se iba sacando el trabajo.

Va costando un poco, uno de los temas complicados es que un equipo pase de no tener horarios a cumplir con el timeboxing. Si bien los horarios de las reuniones se eligen en equipo, a algunos les sigue costando, por lo que a veces caemos en el error de esperar 5 minutos a que llegue un miembro u otro al Daily Meeting.

Algo que me dió la impresión durante esta primera planificación, es que el Product Owner cayó en la idea que su trabajo no es para nada trivial, sino que acarrea una responsabilidad bastante grande. Si bien demuestra que se nutrió bastante con la metodología, leyendo varias documentaciones y recursos, dió la impresión de que en ese momento realmente asimiló la cantidad de trabajo. Recordemos que el rol del Product Owner conlleva muchas funciones. Debe actuar como filtro y representante de los stakeholders, así como negociar y priorizar elementos del backlog. En fín, al igual que el resto de los integrantes, irá aprendiendo en el camino.

Y es que Scrum es una metodología ideal para ir aprendiendo sobre la marcha. Hemos estado pasando enlaces con documentos y demás y transmitiendo la idea, pero es un proceso evolutivo. Somos dos los que venimos oficiando de Scrum Master, retroalimentándonos en el rol, y tratando que los demás asimilen la esencia de Scrum para aplicarlo en armonía con el ideal que lo hace tan efectivo y productivo.

Todavía falta transmitir algunos conceptos fundamentales, y el equipo se va a ir amoldando. Algunos puntos importantes que quedaron en el tintero para ir mechando durante las reuniones fue la visión del equipo y el working agreement. Si bien no son imprescindibles para implementar la metodología, creo que sirven para afianzar la confianza y el respeto entre los miembros del equipo, y permite concretar un primer proyecto en común.

Pero ya estamos usando la gestión visual del proyecto con un task board. Usamos un pizarrón con 4 columnas:

• Backlog: En esta columna pegamos post-its amarillos grandes, con varias tareas (a alto nivel) que se fueron determinando en el primer planning. Obviamente está abierto a más post-its en el futuro, ya que es el backlog general del producto.
• Sprint Backlog: Es el “TO DO”, lo que hay por hacer, las tareas comprometidas para este Sprint.
• En proceso: Las tareas en las que se está trabajando.
• Terminado: Tareas prontas.

Como referencia, ya que no estimamos esfuerzo por cada tarea, vamos marcando un punto rojo por día transcurrido de la tarea en la columna “En proceso”. Al no haber estimado, no tenemos todavía un Burndown chart, pero los puntos rojos van a ayudar a empezar a estimar más adelante.

Este primer Sprint, como experiencia, lo hicimos de corta duración. Empezamos el lunes y terminamos el viernes. El lunes siguiente haríamos una retrospectiva y review del sprint, y un nuevo planning. Dependiendo de cómo nos vaya, lo haremos de una o dos semanas de duración. Iré comentando nuevas experiencias y observaciones a medida que vayan surgiendo.

Parte del espíritu de Scrum es la colaboración entre los miembros que asumen cada rol de la implementación. Así que es lógico que esto se cumpla. Pero además de esa “teoría” que nos dice Scrum es colaborativo, está bien compartir experiencias que dan valor de verdad a estas definiciones.

Trabajo colaborativo

Como comenté en una entrada anterior estoy trabajando en un nuevo equipo. El pasado lunes hubo una reunión general de todos los integrantes, donde pasamos a explicar varios temas y cambios en la forma de trabajar. Scrum implica un cambio tanto en la estructura y metodologías de trabajo, como en la forma de encarar el trabajo por parte de cada individuo.

En esta reunión, comentamos sobre algunas herramientas que usamos y vamos a integrar en nuestra metodología de trabajo: Subversion, Trac y Scrum. Subversion (además de ser mi sistema de control de versiones preferido) es el servidor que se viene usando para mantener los fuentes versionados. Trac es un sistema de gestión de tickets (bugs, arreglos, etc.) y un gestor de proyectos con integración con Subversion. Y Scrum, va a ser el framework que englobe todo el trabajo.

Comprobamos que el simple hecho de reunir a la gente, hacerla participar y contar apenas unos conceptos clave de la nueva forma de trabajo (roles, horizontalidad, participación, auto organización, etc) logró cambios en la interacción del equipo. En estos pocos días que han pasado desde el lunes, la comunicación entre todos los miembros del equipo ha sido mucho más fluída. Se escuchan conversaciones del proyecto entre varios miembros, todos participan. Y la colaboración ha sido un punto fuerte también. Hay más personas del equipo trabajando en equipo, pidiendo ayuda y ayudando.

Basado en esta experiencia, puedo afirmar con total seguridad:
Scrum fomenta la comunicación y colaboración de forma orgánica. Esto sin siquiera haber comenzado formalmente la implementación, sin task board, ni daily meetings. Solo un planning improvisado, y una introducción a algunos conceptos en una nueva forma de trabajo.