A finales de febrero de este año tuve la gran oportunidad de asistir a un curso de Scrum con 2 figuras muy relevantes en el tema: Jeff Sutherland y Mitch Lacey.
Jeff Sutherland es uno de los firmantes del manifiesto ágil y co-inventores de Scrum y Mitch Lacey es un consultor independiente con una larga experiencia en Scrum.
Puesto que los 2 son norteamericanos, el curso se impregnó con ese espíritu característico suyo, los norteamericanos tienen “otra” manera de vender y hacer las cosas, son vendedores natos, imprimen mucha energía en todo lo que hace, lo viven y buscan siempre el lado “práctico” de las cosas mediante ejemplos, experiencias.
Además, hacían muy buena pareja, complementándose: Jeff daba una visión empresarial, más cercana a las prácticas Lean aunque sin abandonar la gestión de proyectos, mientras que Mitch se centraba en la parte más técnica, más de desarrollo de software, más del día a día con Scrum.
Me gustó mucho también la forma de dar la charla, con el enfoque ágil. Prepararon un Scrum Board donde colocaron los temas que iban a dar (Product Backlog) junto a una grafica (Burndown chart) para controlar el cumplimiento de cada tema y por tanto, la evolución total de la charla. En cada descanso hacíamos una revisión de lo que habíamos visto (retrospectiva) para reorientar y adaptar la charla, los temas, etc, según nuestra opinión e intereses. Ajustes que se reflejaban en su lista de temas (Product Backlog) y consecuentemente en la gráfica de control (Burndown chart), convirtiendo la formación en algo “nuestro”. Aquí ya se dejaba entrever el potencial de Scrum en su adaptación al cliente y la búsqueda de su satisfacción.
Un aspecto que me ayudó mucho a aclarar y comprender los conceptos de Scrum son los ejercicios, como resulta lógico. Entre ellos, destacaría 3. Uno en el cual se demostró la mejora de la productividad de un trabajador cuando este tiene la tarea encomendada suficientemente clara como para que sea autónomo y no necesite de un jefe en todo momento. Esto es sentido común pero es un error en el que se incurre constantemente, la microgestión. Otro ejercicio, muy sencillo, demostró como el salto constante entre tareas (multitasking) es una práctica muy ineficiente frente a la ordenación y focalización adecuada en cada una de ellas (priorizando). El tercer ejercicio, fue el más didáctico de todos (XP Game), porque puso en práctica las técnicas de Scrum. Aquí es donde realmente me percaté de las ventajas de esta técnica, como te permite mejorar con cada Sprint e irte adaptando en cada uno de ellos según las circunstancias.
Además, un gran valor añadido aportado por los docentes, fueron sus consejos, su experiencia y buenas prácticas. Esta parte era lo que más riqueza daba al curso, tenían historias para todo, ¿sabían que la mujer de Jeff Sutherland gestionaba parroquias con Scrum o que su hijo había fundado una empresa basada en Scrum y gracias a su gestión y el éxito cosechado se había retirado a los 33 años? Y así, unas cuantas.
Si nos centramos en el contenido de las sesiones, debemos empezar por destacar la forma en que se realizan las estimaciones de las denominadas historias de usuario, ítems del Product Backlog, que definen el producto. Consiste en tomar una historia de usuario como referencia, la más sencilla que puedas encontrar para minimizar el error cometido y asignarle un valor mediante lo que denominan puntos, que no es tiempo, es una medida inventada relativa al trabajo requerido para completar esa historia de usuario. El resto se estiman comparándolas con esta de referencia, es más fácil comparar 2 cosas entre si que hacerlo de forma independientemente. Esto la convierte en una técnica muy robusta porque a parte de obtener estimaciones más fiables, la experiencia que te aporta la consecución de cada una de ellas te permite corregir el resto de estimaciones puesto que todas están relacionadas entre si. Una pauta importante es no asignar la puntuación mínima a la historia de referencia porque evitaríamos la posibilidad de tener historias más pequeñas y dado que debemos suponer que estamos en un entorno cambiante, eso puede suceder.
La velocidad es otro punto muy importante. Se trata de la medición del número de puntos por sprint, entendido como las historias que están completadas, nunca se cuentan las que están medio hacer. La medición de la velocidad en cada sprint es un indicativo muy bueno de como va el equipo, de si surgen problemas y de cuanto tiempo va a costar terminar lo propuesto. Esto se traduce en la gráfica del Burndown chart cuya lectura aporta valiosa información. Esta velocidad, además, está relacionada con la actividad de retrospectiva, clave en Scrum. Actividad que sirve para detectar los problemas y consecuentemente tener la posibilidad de resolverlos, lo que incide en un incremento de la velocidad del equipo. La velocidad también sirve para estimar cuantos trabajo (puntos) se van a acometer en los siguientes sprints.
Uno de los aspectos que mas fuertes me parecen de Scrum, es que define un marco que permite aprender y evolucionar. La forma de llevar a cabo los sprints combinado con 3 ideas muy simples como son los puntos, la velocidad y la retrospectiva, te permite rápidamente ir aprendiendo y mejorando en cada sprint.
Hay un par de conceptos relevantes que quizás no se suelen tener muy en cuenta, como son la definición de LISTO y la definición de HECHO (o terminado, terminado). Aplicar de forma correcta la definición de HECHO (criterio por el cual una historia se considera completada) puede duplicar el rendimiento de un equipo (su velocidad). Esta definición de HECHO no se limita a la prueba de aceptación de la historia de usuario, sino a cosas adicionales que habitualmente se dejan de lado (documentación por ejemplo) y que aumentan lo que se denomina “deuda técnica”, todo aquel trabajo que se va acumulando con los siguientes sprints y lastran el avance del trabajo. Esto habitualmente lo aplican correctamente el 50% de los equipos de Scrum, así que hacerlo ya supone un diferenciación importante. Luego está la definición de LISTO, que es el estado óptimo de una historia de usuario a ser introducida en un sprint y comenzar su desarrollo. Este estado incluye la correcta priorización, estimación, atomización, entendimiento por parte del equipo, valor de negocio, etc. Implica que una historia de usuario está plenamente preparada y desarrollada para que el equipo la acometa de forma autónoma y sin mayores aclaraciones. Esto vuelve a duplicar el rendimiento de un equipo y tan solo el 1% de los equipos de Scrum lo emplean, lo cual es aún más asombroso y otra oportunidad para poder destacar frente a otros. Añadido a todo lo anterior, la auto-organización del equipo, llevada de forma estricta, vuelve a doblar el rendimiento del equipo. Esta quizás es la más complicada de cumplir de todas, puesto que supone un cambio de mentalidad en la forma de trabajar, sobre todo desde el punto de vista del jefe de proyecto y de la organización. Por tanto, con estos 3 parámetros se puede llegar a multiplicar la velocidad y por tanto, el rendimiento, en 8 veces!
Otro aspecto importante era las características de lo que llaman “equipos altamente productivos”:
- Todo el mundo debe estar formado en Scrum
- El Backlog debe estar LISTO antes de empezar un Sprint
- El software debe estar HECHO al final del Sprint
- Empareja inmediatamente si solo una persona puede realizar una tarea
- No hagas varias tareas a la vez (multitasking)
- Scrum Board físico
- Sprints de 1 semana
- Usa únicamente puntos en el Burndown chart
- Todo (incluyendo el soporte) es priorizado por el Product Owner (representante del cliente)
- Liderazgo servil – no se trata de ti
Estas características no son obligatorias, pero las cumplen todos los equipos altamente productivos. Se supone que si no cumples alguna de ellas significará que trabajaras bien, porque haces Scrum, pero no todo lo eficiente y productivo que puedes llegar a trabajar. Esto es lo que suelen denominar Scrum malo o Scrum Butt. El Scrum correcto es aquel que cumple todo lo anterior, que sigue las reglas que marca Scrum, introduciendo, además, sentimiento de equipo.
No obstante, no todo es un camino de rosas en Scrum. Suele exponer de forma muy visible los problemas existentes. Habitualmente esto provoca que estos problemas se achaquen a Scrum, cuando no es así, Scrum tan solo los visualiza de forma muy rápida. Si los eliminas (impedimentos), que es otra de las partes más complicadas porque supone implicarse y realizar cambios, conseguirás convertir al equipo en uno muy eficiente.
La priorización de los trabajos, por último, es clave. Ayuda por una parte a centrarte en las actividades que son importantes, que realmente aportan valor y permite adicionalmente evitar el ineficiente hábito de dedicarte a varias tareas a la vez (multitasking).
Espero que haya sido un resumen provechoso de la experiencia. Se trata de 4 conceptos muy simples que aplicados correctamente pueden ayudar enormemente a mejorar la productividad de un equipo.