Los pilares de Scrum según Scrum.org

En el ámbito de Scrum existen dos iniciativas: Scrum Alliance (Scrum Master) y Scrum.org (Scrum Manager). Resumiendo mucho, la primera está orientada a la "procedimentación" de la aplicación de Scrum, definiendo prácticas, roles y reuniones, mientras que la segunda, sin embargo, es menos "académica" y se centra en la aplicación práctica de Scrum y está orientada a garantizar la flexibilidad del proceso (tenéis más información al respecto en el siguiente artículo: Scrum Manager y Scrum Alliance: dos estilos diferentes de hacer Scrum).

Gustos a parte, si es cierto que la mayoría de la documentación que existe está más orientada al Scrum Alliance, probablemente porque para aplicar Scrum desde cero en una organización este es el planteamiento más asequible ya que nos aporta pautas más concretas.

Sin embargo, en este post me gustaría centrarme en el primero de los aspectos que Scrum.org trata en su guía, los tres pilares fundamentales en los que se apoya Scrum, y ofrecer algunas recomendaciones para mantener nuestra aplicación de Scrum acorde con estos pilares obteniendo el máximo beneficio:

Transparencia

Todo lo que afecta al resultado del trabajo debe ser conocido y visible para todo el mundo.

Algunas recomendaciones para mejorar la transparencia:

• Disponer de un panel tipo Kanban para el seguimiento del trabajo. Este puede ser físico o virtual. Los paneles físicos tienen la ventaja de que puede ser más cómodo interactuar con ellos y tener una visión global del estado del trabajo. Los paneles virtuales, utilizando herramientas informáticas (generalmente sobre plataformas web), tienen la ventaja de que está disponible para todo el mundo sin restricciones de ubicación física y que es posible disponer de "niveles" de visualización adecuados al rol del usuario.

Panel físico (Fuente: Agile Bacon)


Panel virtual de la herramienta iceScrum

• Invitar a todos los involucrados posibles a las Review, de forma que todo el mundo esté informado del estado del proyecto. Además, cuando el proyecto cubra algún hito especialmente relevante, se recomienda extender la convocatoria a más personas de la organización aunque no estén involucradas en el proyecto.

• Hacer un uso correcto de la definición de hecho. Esto supone crear la definición de hecho al inicio del proyecto, consensuarla con el equipo y dejarla a disposición de los interesados. De esta forma, todo el mundo podrá tener la misma interpretación sobre el significado de "trabajo realizado".

Inspección

Es necesario realizar un seguimiento de la evolución del trabajo para detectar desviaciones con respecto a lo previsto.

Algunas recomendaciones para guiar los procesos de inspección:

• Mantener gráficos de evolución del trabajo actualizados a medida que se van cerrando trabajos, lo que permite tener una perspectiva del ritmo al que se está trabajando y la realización de proyecciones futuras que permitan determinar si será o no posible alcanzar los objetivos comprometidos para el Sprint. El tipo de gráfica más concreta y sencilla es la que se basa en los puntos de las historias terminadas, pudiendo ser de tipo "burnup", si en la gráfica acumulamos puntos hasta con el fin de llegar a los puntos comprometidos en el Sprint (límite superior de la gráfica), o de tipo "burndown", si la gráfica parte del número total de puntos comprometidos para el Sprint y va decreciendo a medida que se cierran las historias.
  
  Ejemplo de gráfico burndown físico (Fuente: http://www.cs.fsu.edu/~baker/swe1/restricted/notes/scrum.html#(14))
  
  
  
  Ejemplo de gráfico burnup de la herramienta iceScrum
  
  

  Independientemente de como se presente esta gráfica, la información aportada y la interpretación de la misma es clara: tomando como referencia el número de puntos comprometidos, a medida que avanza el Sprint se van contabilizando los puntos de las historias cerradas y se tiene una visión de cuanto trabaja falta para alcanzar el objetivo.

  Aun siendo la gráfica más realista, tiene el problema de que puede no verse modificada en varios días si las historias abordadas tienen muchos puntos, por lo que su uso puede complementarse con otras gráficas que muestren información relacionada con las tareas en vez de con las historias: contabilización de tareas cerradas, horas consumidas con respecto a las previstas en la descomposición de tareas (claro está, siempre que las tareas se estimen en tiempo), etc.

  
  Ejemplo de gráfico de tareas identificadas (línea amarilla) con respecto a las terminadas (línea verde) de la herramienta iceScrum
  
  
  
  Ejemplo de gráfico de consumo de horas (línea azul) con respecto a la media de consumo previsto (línea negra) de la herramienta iceScrum
  
  
  

• Realizar en forma y tiempo las reuniones diarias. Lo recomendable es que estas reuniones sean siempre a la misma hora (por nuestra experiencia, mejor a primera hora), en el mismo sitio, limitada a un máximo de 15 minutos y ceñidas a las tres preguntas: ¿Qué hice ayer? ¿Qué tengo previsto hacer hoy? ¿Existe algún impedimento que limite mi trabajo?

  Además, cuando todos los participantes han hecho su aportación, es recomendable revisar las gráficas indicadas anteriormente y analizar la situación.

Adaptación

En el momento en el que se detecta alguna desviación o se tienen indicios de que esta se puede producir, es necesario actuar en consecuencia para adaptarse a las nuevas circunstancias.

La detección de las desviaciones está íntimamente relacionada con las acciones de "Inspección" del punto anterior y las acciones correctivas pueden ser de varios tipos, algunos ejemplos son:

• Redefinir los objetivos del Sprint junto con el Product Owner. Esto puede ser tanto para sacar historias del Sprint en caso de que el trabajo se esté desarrollando más despacio de los esperado o también se pueden introducir nuevas historias si el ritmo de trabajo es más rápido. En todo caso, lo que se busca es que el Sprint Backlog sea siempre abordable y se aproveche el tiempo disponible del equipo.
• Repriorizar las historias. Si se indicios de desviación con respecto a lo planificado, pero que aun no está confirmada, se puede informar al Product Owner y estudiar la posibilidad de repriorizar el trabajo pendiente.
• Mantener la planificación. Si nos fiamos únicamente de los resultados arrojados por las gráficas de seguimiento pueden surgir circunstancias en las que se presenten desviaciones con respecto a lo previsto de tipo "falso positivo". En todos los casos es necesario analizar estas desviaciones con los miembros del equipo para determinar su verdadera magnitud para la posterior toma de decisiones. Incluso se puede dar es caso de que lo más correcto sea mantener la planificación puesto que las desviaciones detectadas están controladas.

En resumen, el objetivo es que el trabajo dentro de un Sprint esté "Gestionado", es decir, ante ciertas señales se deberá recopilar información del porqué de esta señal y se deberá actuar en consecuencia para mantener encauzado el Sprint.