El pasado viernes tuvimos la primera reflexión o retrospectiva de Sprint. Por lo menos la primera «formal», ya que el viernes anterior faltó el Scrum Master (ver entrada anterior para leer más sobre como vamos implementando Scrum ). No he leído de técnicas específicas para la reflexión, así que me basé en la teoría, y debatimos los problemas que habíamos tenido durante el proceso de trabajo.
Este viernes marcaba el final del primer Sprint. Los problemas que saltaron y que se plantearon durante la reunión fueron los siguientes:
- Subestimamos o sobreestimamos tareas.
- No granulamos lo suficiente como para hacer estimaciones más precisas.
- No detectamos falta de documentación en tiempo lo que puede atrasar un poco el trabajo.
- Tuvimos un deploy desordenado.
Como conclusión llegamos a una serie de implementaciones que pueden ayudar a reducir el impacto de los problemas encontrados:
- Análisis inicial más extenso: extender la duración de la reunión de planning, para entrar más en detalles de análisis de las tareas a realizar, para poder estimar mejor. Esto también permite detectar faltas de documentación sobre el proceso a trabajar.
- Formalizar deploy, con la posibilidad de implementar un servidor de Integración Continua para el proyecto.
El lunes de esta semana ya arrancamos dedicándole un poco más de tiempo. Además tomamos en cuenta implementaciones que traían mucha documentación nueva. Para estas, se ingresó como tarea el análisis y posterior diseño de lo escrito en la documentación, y el martes se hizo un nuevo sub-planning para estas tareas específicamente.
Se notó una diferencia en densidad de análisis respecto al anterior el lunes:
El martes se agregaron muchas tareas más seguidas del sub planning. Todavía tenemos pendiente la implementación del Task Board en reemplazo del pizarrón.
Que bueno que ya hayan podido hacer una retrospectiva! Fernando, muchas gracias por compartir la experiencia, el blog es muy interesante.
@Ariel
Por suerte ya hicimos la primer retrospectiva formal, aunque hoy ya se nos complicó un poco la cosa, y la tuvimos que dejar para el lunes por otras prioridades… Ya lo comentaré más adelante.
Gracias por leer el blog, me alegro que guste.
¡Saludos!
Hola Fernando,
Disculpa que no haya podido leer hasta ahora tu blog desde que lo anunciaste en foro-agiles. He dudado si comentar aquí en el blog o en foro-agiles, pero al final he pensado que aquí era el mejor sitio.
Lo que os está pasando me recuerda mucho a lo que nos pasaba a un equipo en el que estuve hace algún tiempo y no quería por menos que solidarizarme con vosotros y aportaros mis opiniones.
1) Ser ágil implica también ser disciplinado. Si no respetáis los ritos y los ritmos os costará mucho más. La retrospectiva no se puede hacer muy tarde o no tendrá utilidad. Respetaos a vosotros mismos como equipo y si el SM no puede estar, pues la hace el resto del equipo y ya está. Lectura recomendada: «Agile Retrospectives»
2) Ya lo habéis intuido en vuestra retrospectiva, pero necesitáis la Integración Continua ¡YA!. El objetivo es tener un producto ponencialmente entregable al final de cada sprint, esto es muy difícil de conseguir si confiáis el proceso de despliegue a un proceso manual. De paso, id pensando en cómo automatizar vuestras pruebas (unitarias, de integración y de aceptación). No sé cuál es la cualificación de vuestro equipo, por lo que no les pediría hacer todo en una semana. Trazad un plan y buscad ayuda si lo necesitáis: formación, seniors que se unan a vuestro equipo aunque sea para hacer algo de mentoring…
3) En la entrada anterior me llamó mucho la atención que en vuestras estimaciones planificábais incluso la hora estimada de inicio-final de las tareas. Esto es MUY peligroso. Por dos razones: porque crea expectativas en quien lea el tablón (la gerencia) y porque crea frustraciones en el equipo si no se cumplen. Es mucho mejor aceptar que no tenemos una bola de cristal y esperar al final de la iteración para saber cuál ha sido nuestra velocidad (no en número de horas sino en puntos de historias de usuario acabadas).
4) ¿Dónde está vuestro gráfico de trabajo realizado (burndown chart)? Tenerlo público y bien a la vista os dará (al equipo y a los que pasen por delante del tablón) una visión mucho más clara de cómo vais y podréis reaccionar a mitad de semana si fuera necesario. No os preocupéis en demasía si estimáis por encima o por debajo: lo que realmente interesa es ir consiguiendo un ritmo de desarrollo sostenible y para ello necesitáis además acostumbraros a estimar.
5) En la entrada anterior he leido sobre el backlog pero no sobre el dueño del producto (que es quien prioriza las historias que allí se ponen por valor de negocio). Es curioso que no hayáis citado al dueño de producto.
6) El análisis extenso y las reuniones de preparación del sprint tienen mucho que ver con el punto anterior. Tengo la sensación de que estáis haciendo «casi scrum» pero muy desde el punto de vista técnico (con subplanes para realizar el análisis y todo eso). Parece como si intentárais encajar vuestras viejas costumbres y procedimientos y esto es muy difícil. Las tarjetas en el backlog son meras representaciones físicas de una conversación con el dueño del producto. Si necesitáis una discusión de varias horas para analizar, documentar, diseñar y volver a documentar una funcionalidad, probablemente os estéis olvidando de que es el dueño del producto el que conoce cómo debe ser el resultado final (o al menos es el que lo tiene más claro). Yo intentaría involucrarlo lo más posible y que estuviera muy disponible para aclarar las dudas que surjan durante el desarrollo (que surgirán).
7) No os preocupen que os surjan tareas imprevistas durante un sprint, pero tened cuidado en si deben entrar o no en el mismo. En muchas ocasiones, el SM puede evitarlo simplemente negociando con el PO (dueño de producto) si alguna de las tareas se puede dejar para sprints posteriores sin afectar a la calidad del resultado a entregar. En ocasiones el propio equipo identifica tareas que parecen imprescindibles pero que realmente no aportan valor al cliente. Hay que recordar siempre que es el cliente el que paga y el que debe recibir valor al final de cada iteración.
De todos modos, no os agobiéis porque ya os digo que otros hemos cometido esos errores y muchos más. Lo importante es que seais conscientes de que (como dice mi maestro) «no es posible pasar de 0 a Agile en un mes». 🙂
@Jose M Beas :
Muchas gracias por leer el blog, y sobretodo muchas gracias por compartir tu experiencia. Te respondo por puntos:
1) La disciplina está costando un poco, de a poco vamos moviendo los horarios de las cosas a modo que nos quede bien a todos. Todavía tenemos por mejorar en este aspecto. La retrospectiva la terminamos haciendo hoy lunes junto a la planificación de esta semana. La primera vez quedó pendiente, ya que el equipo ni siquiera tenía muy claro de qué se trataba. Yo como SM todavía no he estudiado mucho al respecto tampoco, es una de las cosas donde me falta leer más. Muchas gracias por la recomendación del libro, está a un precio bastante accesible en Amazon, voy a descargar algún capítulo para ojear, y si me convence lo consigo.
2) Sí, integración continua lo tengo pendiente desde que empezamos a implementar Scrum… Seguimos con problemas con el deploy, pero de a poco lo vamos mejorando. El equipo está conformado por programadores con poca experiencia. Ese es uno de los factores por los cuales estas implementaciones llevan tiempo. No es mala idea buscar formación de afuera, ya hemos hecho algunas capacitaciones, pero podríamos usarlo para esto en particular.
3) En verdad, planificábamos el día de finalizada una tarea, no la hora. De todas formas sigo viendo que las estimaciones se pueden mejorar todavía mucho más, y no hemos implementado ningún sistema. Personalmente me gustó mucho el Planning Poker, a lo mejor se podría implementar también.
4) Tampoco hemos hecho los burndown charts. Por ahora nos venimos manejando dibujando puntos rojos y verdes en las tareas como expliqué en mi entrada anterior (http://www.aplicandoscrum.com/usando-el-pizarron-como-task-board/). De esta forma los miembros del equipo pueden detectar cuellos de botella (muchos puntos rojos), y quién viene atrasado/adelantado con su trabajo. De todas formas pienso implementar el gráfico de trabajo también.
5) El tema del dueño del producto es bastante particular ya que se encuentra fuera del país por el momento. Comenté cómo venimos manejando eso en la entrada sobre como empezamos implementando Scrum. http://www.aplicandoscrum.com/implementando-scrum-como-empezamos/
6) En cuanto al análisis, generalmente en los daily meetings o plannings de sprint definimos reuniones de análisis, pero en cuanto a la implementación en sí. Esto se debe a que el equipo cuenta con poca experiencia y para problemas complejos generalmente confiamos en el trabajo en equipo para llegar a la mejor conclusión posible. Sí se nota de todas formas el obstáculo que representa el hecho de no tener al Product Owner presente en las reuniones.
7) Nos han surgido algunas tareas imprevistas más, pero se puede decir que el Product Owner ya está «educado», ya que comprende la metodología de trabajo, y trata de evitarlo a menos que sea imprescindible o extremadamente necesario.
Nuevamente te agradezco mucho tu aporte, ese es el objetivo de este blog, compartir mi experiencia, enriqueciéndola con la ayuda de otros. De a poco vamos progresando con la implementación de Scrum, y agregándole elementos a medida que nos vamos acostumbrando. Seguiré contando cómo nos va yendo..
Saludos y gracias por leer!