sábado, agosto 17, 2013

Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum

Hace unos días en Ceiba (empresa donde trabajo como Scrum Master)  filosofábamos en equipo la siguiente pregunta:


¿qué era necesario hacer para lograr mayor velocidad (puntos por sprint)?



Nota aclaratoria: no fue presión mía como Scrum Master hacia el equipo, pero si es cierto que yo lancé la inquietud (realizando la Inception :-) como en la película el Origen, de Nolan y Di Caprio)


La respuesta a esta inquietud ha llegado gradualmente, y pienso que es  uno de los interrogantes obligatorios que tiene que plantearse un Scrum Master y que debe plantearle al equipo.

Dentro de las responsabilidades del SM están:

  • el seguimiento del proceso
  • el coach al equipo
    • y dentro de ese coach llevarlo a una productividad mayor (a un doble de productividad según Sutherland - padre de scrum-  [1] )


Hay que reconocer que Scrum nos ha permitido ser muchos más veloces y productivos debido a:

  • Involucramiento y compromiso del dueño del producto, que permite resolver inquietudes rápido
  • Visibilidad y resolución rápida de impedimentos
  • Retrospectivas bien hechas, que nos llevan a la mejora continua
  • Empoderamiento del equipo, de forma que este por si mismo se auto-organiza y encuentra la mejor forma de entregar el producto
  • Los valores de coraje y compromiso, que han permitido querer ir más allá y poder enfocarnos mucho más en como ser mejores
  • Atención a la excelencia técnica, que ha hecho que nuestra deuda técnica cada vez sea menor, lo cual mejora nuestra velocidad. "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad" [2] (principio del manifiesto ágil). (este punto lo retomaré más adelante)
  • Teniendo el equipo motivado y feliz,  equipos motivados son más ágiles "Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo." [2] (principio del manifiesto ágil).

Pero luego de estar allí, es necesario plantearse ¿es posible ser mejores? a continuación entonces, enumero en orden de importancia (según mi criterio) las formas en las que considero y he encontrado que podemos ser más veloces:

1. Seguir el patrón Scrumming the Scrum 

En la conferencia de Jeff Sutherland | "Scrum: The Future of Work" [3], presenta este patrón de scrum como una de las formas de llegar "hiper-productividad" en los equipos

Patrón: Scrumming the Scrum [4]

Este patrón se basa en:

  • Identificar y priorizar la(s) mejora(s) (kaizen) a realizarle al proceso de Scrum  en la Reunión de Retrospectiva. Recordemos en la retrospecttiva debemos enfocarnos en:
    • cómo mejorar el proceso de elaboración del producto,  el cómo que Scrum no resuelve y deja en libertad a los equipos).
    • cómo mejorar la calidad y el producto
    • cómo mejorar la felicidad del equipo
  • Enfocarse  en la(s) mejora(s)  más importante(s) y críticas. He leído por ahí que máximo 3 cosas muy importantes a mejorar (1, 3 ó 4 no recomiendo ningún número en especial - yo prefiero pocas cosas a muchas -  intenten una opción y concluyan - recordemos que lo que funciona en un equipo no tiene por que funcionar en otro)
  • Ponga el Kaizen en el primer lugar del sprint backlog con criterios de aceptación cuantitativos.
  • Revise la mejora Kaizen en el Sprint Review como si fuera otra historia.

Beneficios:
  • terminar antes
  • solicitar mas backlog para el sprint
  • incrementar la métrica de "el clima de ayer" para el próximo planning.

2. Seguir el patrón de Interrupción 

Otro de los patrones expuestos en esta conferencia Jeff Sutherland | "Scrum: The Future of Work" [3] para llegar a la  "hiper-productividad", es el presentado a continuación:.


Este patrón es útil cuando el producto ya se encuentra en producción y se requiere atención inmediata a temas específicos.

El patrón se basa en:
  • Luego del Kaizen determine una cantidad de puntos disponibles para tareas inmediatas que requiere el Product Owner.
  • Si identifica que no se van a consumir úselos en más historias.

Beneficios:
  • Equipo dispuesto para atender urgencias con un tiempo asignado para ello, sin que les quite velocidad y compromiso..
  • Product Owner contento con su equipo, debido a que pueden atender temas urgentes.

3. Hacer Sprints más cortos 

Esta recomendación nos la dió Ricardo Colusso (@rcolusso) de kleer.la en donde nos sugería realizar sprints de 1 semana.


Beneficios:

  • Poder fallar más rápido, debido a ciclos de retroalimentación más cortos.
  • Despliegue de producto más rápido

Requerimientos
  • Más compromiso del Product Owner
  • Más historias de usuario refinadas y cumpliendo el criterio de Ready.
  • Historias de usuario más pequeñas

Nota: No he intentado esta sugerencia



4. Tener un backlog refinado y con el criterio de ready

Otra de las recomendación que nos la daba Ricardo Colusso (@rcolusso) de kleer.la y que también remarcaba Sutherland era la necesidad de tener un backlog refinado y con el criterio de ready, esto indiscutiblemente proporciona una visión clara hacia donde va el producto.




Beneficios:

  • Visión de producto
  • equipo enfocado

Requerimientos
  • Más compromiso del Product Owner
  • Realizar la reunión de refinamiento al la mitad del sprint
  • tener al menos 2 sprints más con historias de usuario cumpliendo el criterio de Ready.

5. Resolviendo la deuda técnica

La deuda técnica es uno de los elementos que termina frenando la velocidad de los equipos y va en contra de la atención a la excelencia técnica (que es uno de los principios del manifiesto ágil).  Recomiendo el post de Henrik Kniberg - The Solution to Technical Debt . Aunque pienso que es un tema de estudio y de compromiso con el cliente, producto, product owner y mismo equipo.

Presento dos gráficas de este post, que muestran la necesidad de detener la deuda técnica y comenzar a "pagarla" antes de que la velocidad de nuestro equipo se vea frenada radicalmente.

Efecto de programar con código apestoso (crappy code) (en español no encuentro una palabra polite para crappy) [4] 



Efecto de trabajar con código limpio (clean code) [4]

Beneficios:

  • Velocidad
  • entendimiento del código
  • excelencia técnica
Requerimientos
  • Equipo con coraje y conocimiento técnico
  • Equipo y Scrum Master que sepan vender la idea de resolver la deuda técnica el Product Owner.
  • Hacer la deuda técnica como parte del kaizen y darle prioridad e  importancia en el proyecto.

Recomendación
  • Tener lineamientos técnicos que se cumplan desde el inicio del proyecto.


6. Teniendo una holgura (Slack) cada cierto tiempo

Por último, la holgura o Slack es un tiempo intencional dejado entre sprints para cubrir cualquiera de las siguientes tareas:

  • Innovación técnica
  • transferencia de conocimiento entre equipos
  • realizar ajustes pendientes de soporte y mantenimiento



Algunas de las formas de implementar el Slack son:

  • dejar un tiempo pequeño entre sprints de 1 a 2 días 
  • 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
  • El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
  • Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
  • etc..


Recomiendo visitar este post: Cutting Slack in Scrum

En conclusión

Si seguimos estas directrices, no dudo que podremos mostrar gráficas de velocidad similares a la que presenta Jeff Sutherland

Incremento de velocidad aplicando los patrones 1 y 2 [4]

 Y pronto estaremos escribiendo artículos y recomendaciones de como ser mejores en Scrum.



Consideración importante respecto a la puntación de historias

Cuando se mejore la velocidad y encontremos qué cosas que antes nos tomaban más tiempo, pero ahora luego de la mejora nos  toman mucho menos,  debemos de tener una consideración importante respecto a la puntuación:

  • si tus puntos fueron diseñados poniendo un pivote de  funcionalidad conocido (ejemplo una pantalla con un formulario de 8 campos), no hay lio, ese pivote y las demás funcionalidades las hará  el equipo más rápido y la puntuación seguirá siendo la misma.
  • Si tu pivote esta basado en días felices/productivos (ver [7]) (yo uso esa técnica), considera que si haces algo más rápido debes puntuarlo de la misma forma que usabas al principo del proyecto, como si no tuvieras hiper-velocidad o hiper-productividad, ejemplo:
    • si una pantalla tipo a= te tomaba  2 días felices (2 puntos).. .pero luego de la mejora te toma un dia feliz (un punto) síguela puntuando como antes, pues esa es la referencia inicial con la que se dimensionó el proyecto y permitirá visualizar la velocidad y la mejora.



Hasta ahora he encontrado estas 6 formas, talvez hayan más o sean realmente menos, si alguien conoce, aprende, o ensaya más y las puede/quiere compartir bienvenidas sean, es importante todos aprender de todos.


Queda abierto el espacio para sus comentarios y experiencias.


Saludos

Jorge Abad


---
Referencias:






3 comentarios:

  1. Abad súper que estés tan activo compartiendo tus experiencias!

    Te dejo mis comentarios…

    La mejor manera de incrementar la velocidad es multiplicando todos los user points por 10 o por 100 o por cualquier numero, mientras más grande mejor, así ante los ojos de los confundidos PMs se tendrían velocidades del orden de 500 o de 1000, así los confundidos PMs podrían ir a cocteles y alardear ante los otros confundidos PMs; mis equipos tienen una velocidad de 1000, dirían, con un orgullo desbordante, mientras los otros confundidos PMs extrañados se preguntarían; cómo es posible mis equipos solo tienen la miserable velocidad de 45 o 50?…

    La pregunta debería ser: como lanzamos a producción más funcionalidades que impacten positivamente a nuestros usuarios rápidamente de una manera continua, que sea confiable y repetible una y otra vez?

    La velocidad es una herramienta de calibración, supremamente útil cuando se usa en combinación con la técnica del clima de ayer para planear la capacidad de la siguiente iteración, que no debe ser usada como herramienta para medir la productividad de los equipos.

    Los PMs generalmente son víctimas de cometer el error de usar la velocidad como herramienta para medir la productividad. Cuando se comete este error se abre la puerta para conversaciones erróneas, que van como:

    • Mi equipo A es más productivo que tu equipo B, la velocidad de mi equipo es 100 y la de tu equipo es 50… esta comparación es absurda sin saber la escala usada para calcular los story points que uso cada equipo y si existe algo que recuerdo desde mis primeros años estudiando matemáticas es que manzanas y naranjas no se mezlcan. Es posible que el equipo B este logrando mejores resultados que el equipo A, pese a que su velocidad sea menor, es posible que lo que el equipo B considera 3 puntos, el equipo A lo considere 6, es un tema de escala/calibración como dije anteriormente… el peso de un story point generalmente varía entre proyectos, ahora entre equipos la escala puede ser totalmente diferente e imposible de comparar
    • Mi equipo tenía una velocidad de 50 ahora es de 35, entonces nuestra productividad está cayendo dramáticamente!. Yo diría No, es posible que cuando se tenía una velocidad de 50 se estaban generando más errores que con una velocidad de 35. Es importante encontrar un balance entre la implementación de nuevas funcionalidades y el diseño. La atención a la excelencia técnica afecta la velocidad de hoy en miras de la velocidad del mañana para generar una velocidad sostenible.
    • Debemos incrementar la velocidad para ser más productivos. No, La velocidad no mide la productividad, menos la satisfacción de nuestros usuarios. La velocidad no proporciona valor al negocio, son las funcionalidades, las nuevas capacidades las que producen valor.

    La velocidad es una herramienta de calibración y en esa área es donde brilla con más fuerza, tratar de usarla como herramienta para medir productividad envía un mensaje equivocado a los miembros del equipo y usualmente los enfoca en asuntos que no son útiles.

    Ahora la productividad en áreas de conocimiento es una métrica subjetiva y es imposible medirla usando una sola variable, sobre todo en software: quien es más productivo?, Juan que implemento 7 funcionalidades en una semana o Felipe que desarrollo 3… a primera vista parece que Juan es más productivo, pero que pasa si las 7 funcionalidades de Juan tienen errores y son más difíciles de mantener que las de 3 de Felipe, o que tal si las 3 funcionalidades de Felipe son mas útiles para el negocio y generan más dinero?

    Algunos enlaces interesantes acerca del tema:
    http://jimhighsmith.com/velocity-is-killing-agility/
    http://agilepainrelief.com/notesfromatooluser/2010/02/misuse-of-velocity-in-agile-projects.html
    http://www.infoq.com/news/2012/12/stop_points_velocity
    http://www.industriallogic.com/blog/stop-using-story-points/

    ResponderEliminar
  2. Valde...

    super tu retroalimentación pues coincido con vos. Cuando escribí el artículo se me olvido presentar esos puntos, pero es cierto:

    1. no podemos caer en el juego de las comparaciones entre equipos. La velocidad es una métrica propia de cada equipo y lo que significa un punto para uno, no es lo mismo para otro, aun cuando los traten de manejar los días felices o productivos.

    2. no podemos omitir la calidad, ni caer en el juego de hacer software de forma indiscriminada...

    La pregunta que nos plateamos como equipo era;

    ¿cómo hacemos para ser mejores?

    Manejando:
    - la misma felicidad (somos un gran equipo y hemos evolucionado a un punto de visión y compromiso compartido)
    - sin sacrificar nuestra vida personal. Saliendo a las 5 pm, ojalá antes.
    - produciendo más software de valor para el cliente sin sacrificar la calidad,

    Gracias por tu comentario y los links!!!

    seguimos en contacto

    un abrazo


    ResponderEliminar
  3. Excelente artículo y retroalimentación, gracias por compartir.

    ResponderEliminar