Archivo de la etiqueta: Planificación

Reimplementación de Scrum: Perfeccionando la planificación de Sprint

Planificación del Sprint,

En primer lugar, tras una intervención en la forma en como veníamos haciendo las planificaciones de Sprint, las hemos optimizado mucho. Un error que tuvimos era comenzar la reunión sin ningún tipo de «agenda». Si bien no es necesaria la formalidad, desde el último Sprint Planning comenzamos a seguir un hilo conductor. El Sprint Planning se puede dividir  en dos partes:

¿Qué se tiene que hacer?
Participan el Product Owner y el equipo. Definimos qué objetivos queremos lograr en este Sprint. En esta instancia el Product Owner participa definiendo las prioridades como siempre. Los objetivos son definidos y explicitados de manera que todos seamos concientes del objetivo del Sprint.

¿Cómo se tiene que hacer?
En esta etapa, el equipo granula un poco más las historias de usuarios de manera de obtener tareas específicas. Parte de este trabajo se hace en esta etapa inicial, pero otra gran parte se va realizando en los Daily Meeting, a medida que se van definiendo bien las tareas.

El error más grande que tuvimos en nuestro primer Sprint, fue la estimación de las tareas. Siendo ésta la segunda aplicación de Scrum, puede identificar un patrón. Es muy difícil para un equipo estimar el tiempo que le va a llevar realizar el trabajo, si nunca lo hizo antes. Además, se cae en dos errores aparentemente comunes:

  • No definir el alcance de una tarea: Las tareas se definen a muy alto nivel. Por ejemplo «Alta, baja y modificación de Usuarios» puede sonar a tarea sencilla. Pero puede afectar varias áreas: el análisis del modelo de negocios, la interfaz, el acceso a base de datos, etc. Por esto, uno de los primeros aprendizajes fue definir el alcance y limitaciones de una tarea, y tratar de definir todo el trabajo que abarca que un ABM de usuarios esté terminado.
  • Sobrestimar capacidades o subestimar tareas: Esto sucede sobretodo en equipos nuevos o con poca experiencia. El equipo con el que contamos se consolidó recientemente (aproximadamente cuando comenzamos a implementar Scrum) y la arquitectura y tecnologías con las que trabajamos deben ser asimiladas y comprendidas por cada integrante del equipo.

A medida que el equipo se va introduciendo en el ritmo, todo se va mejorando de a poco. Todavía queda trabajo por hacer, pero es bueno ver que no nos estamos quedando en la zona de confort.

Primer planificación de Sprint

Planificación del Sprint, ,

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.

Sprint heroico – Planificación y Task Board

Scrum, ,
Task Board Scrum
Task Board Scrum

Como comenté en una entrada anterior (Implementando Scrum: Cómo empezamos), nuestro Product Owner se encontraba hasta hace poco fuera del país. Recientemente volvió a trabajar desde nuestra oficina, lo que nos permitió realizar una primera planificación de Sprint con el Product Owner presente. Las ventajas de contar con su presencia saltaron a la vista, ya que la priorización y negociación de tareas se hizo de una forma muy fluída, así como también se despejaron algunas dudas instantáneamente durante la planificación misma.

Además de eso, este Sprint tuvo varias características que lo hicieron único respecto a los anteriores:

  • La planificación se realizó fuera de horario. Debido a complicaciones varias del lunes, nos juntamos en la tarde, mientras que los Sprints anteriores se hacían lo más temprano posible. Esto no cumple con el espíritu de Scrum en cuanto al enfoque de time-box, mantener el ritmo, la disciplina y compromiso. Sin embargo, hay que tomar lo que sirve, y en este caso nos sirvió hacerla tarde.
  • El equipo constaba de 7 programadores. Ahora se sumaron a la planificación los 2 diseñadores gráficos del proyecto. Estamos en etapa de maquetación e integración del código PHP con el diseño, por lo que volvimos a juntar a todos los responsables del desarrollo del proyecto. Además, el Scrum Master (yo) abandona temporalmente su puesto de director en el equipo, por razones planteadas en el siguiente punto, y se integra como un programador más.
  • Nos encontramos muy cerca a una fecha de entrega, dos semanas. Teníamos varias características del producto definidas para esta entrega, que veíamos difícil de implementar. Por esto, hicimos una planificación bastante profunda, para tratar de meter todas las tareas importantes en un Sprint que por primera vez contaría con dos semanas de duración. Esta era la idea inicial, pero al estar empezando con Scrum, decidimos que una semana permitiría estimaciones más precisas. Desde mi punto de vista, el equipo ya se encuentra en condiciones de planificar los Sprints a dos semanas. Además la presencia del Product Owner facilita las cosas.
  • Implementamos el Scrum Task Board. Como comenté, usábamos el pizarrón como Task Board. Ahora usamos un espejo que hay en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida de Scrum. Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint. Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo. También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre. Todos los movimientos en el Task Board se realizan únicamente en el Daily Meeting, de manera que todo el equipo esté al tanto de lo que sucede, y por el compromiso que implica llevar una tarea a la columna de «finalizado»
  • En lo personal, es un Sprint más «feliz», ya que dejé mi puesto de Project Manager y Director, para meterme de lleno en el código. Así que ahora estoy cumpliendo el rol de Scrum Master así como de desarrollador del equipo.

Lo interesante de la planificación fueron las etapas . En un principio se sentía mucha tensión, presión, nervios, miedo, stress… Pero la presencia del Product Owner (también jefe del equipo), se hizo notar, y las cosas llegaron a una buena conclusión. Demoramos algunas horas en definirlo, pero llegamos a una planificación completa de las dos semanas siguientes de trabajo. Esto fue el lunes de la semana pasada, y a más de una semana, puedo decir que ha resultado. Hoy el Task Board tiene mucho más tareas naranjas agregadas, así como algunas amarillas más (mayor granulación de algunas tareas), pero la columna de «terminado» está colmada.

Un Sprint muy especial, por todo lo comentado. En teoría, tendríamos un review y reflexión de este «Sprint heróico» el día 3 de agosto, así que ya comentaré cómo estuvo eso. Mientras tanto, ¡a programar!