Muchas organizaciones entienden Scrum como un proceso exclusivo de desarrollo software. Visto de esa manera, es normal que muchas empresas aseguren que trabajan con Scrum: tienen Daily, Posits, Retrospectivas y Tableros. Sin embargo, Scrum es mucho más que una manera de hacer software, es un proceso de trabajo en el que nos centramos en maximizar valor. Para maximizar valor debemos definir qué es valor en nuestro contexto, cómo genera valor nuestro producto. En las organizaciones con ánimo de lucro el valor es dinero, de manera directa o indirecta, reduciendo costes en algún proceso de la empresa.
Por tanto, dos equipos similares aplicando Scrum pueden tener resultados muy diferentes, según dónde ponen el foco. No es lo mismo poner el foco en que el equipo trabaje mucho, que en los resultados que el equipo obtenga. ¿Y si el equipo haciendo la mitad de trabajo genera el doble de valor? Es mejor hablar de efectividad que de velocidad en un equipo Scrum.
¿En qué consiste Scrum?
Muchas empresas utilizan Scrum como técnica de desarrollo de software. Y es cierto que nació ahí, quizás por eso está tan extendido en el área de tecnología de las empresas. Gran parte del “fracaso de Scrum” es que se ha vendido como técnica de desarrollo, y lo usamos para garantizar las fechas (ya que no somos capaces con el modelo tradicional o waterfall). Pensar que Scrum nos permite hacer desarrollo software más rápido, es quizás uno de los grandes errores.
Tenemos malas noticias, Scrum no es para desarrollar software. Scrum es un marco para generar valor en los equipos de trabajo dentro de las organizaciones. En Scrum no pensamos en proyectos (entendidos como alcance-coste-tiempo definidos en una etapa temprana) sino que creamos productos (dar servicio). Un producto trabaja desde la mentalidad iterativo (inspeccionamos y nos adaptamos cada poco tiempo) e incremental (cada vez generamos más valor).
Cada vez que un amigo o un colega me dice que hace Scrum, siempre le hago la misma pregunta: ¿Cómo mides valor?
Muy pocos equipos con los que haya trabajado saben medir valor, casi todos se centran en una entrega en fecha. Conocer las métricas ágiles es vital para un agilista. En algunos casos, se mide la calidad de alguna manera. No medir valor, supone trabajar con Scrum como un procedimiento donde se siguen unos pasos concretos (como una receta), es lo que conocemos como Scrum Zombie. Sin embargo, un Scrum profesional es el que usan las empresas que miden el valor en sus equipos y toman decisiones para maximizarlo de manera contínua.
Scrum Profesional
En implementaciones de Scrum básicas o amateur empezamos midiendo punto de historia, velocity o, peor aún, horas hombre. Una vez estuve en una empresa que habían desarrollado su propia herramienta digital para las equipos Scrum. Está herramienta definía etiquetas para los diferentes miembros del Development Team. Cuando se planificaba el Sprint, tenías que introducir las horas estimadas de cada una de las tareas y a qué perfil corresponden. De esa manera, el programa te decía automáticamente cuál era tu capacidad actual y qué perfiles no estaban ocupados. Por ejemplo, si ya habías definido muchas tareas que solo implican a Back, el programa te avisaba para que no metieras más tareas y de que el resto de etiquetas no tenían trabajo suficiente.
La idea no era mala, salvo que en Scrum no tenemos etiquetas, no buscamos que las personas estén ocupadas y tratamos de medir el valor que entregamos y no hacer mucho software.
Todos hemos pasado por esa fase, pero cuando aprendes Scrum profesional todo cambia. En ese punto nos centramos en valor y en construir productos que aporten a nuestros customers.
Dime lo que mides… ¡te diré de lo que careces!
En función de lo que midamos, podemos saber en qué grado nuestro equipo es ágil, o desde luego tiene un enfoque a resultados. Si medimos métricas como horas trabajadas y estimación en horas, estaremos en un nivel bajo. Nos preocupa más una productividad y rendimiento individual. Este tipo de medidores muestran que nos centramos más en trabajar mucho, pero no medimos si trabajamos bien.
Otro nivel bajo, pero muy extendido en Agile es la velocidad. El primer problema es cuando lo aplicamos a nivel individual. Sería una situación similar a la anterior, buscamos el rendimiento individual y no el colectivo. Aplicado a nivel de equipo, la velocidad sigue siendo una métrica con una gran carga de subjetividad. Por eso, sigue sin ser una métrica muy ágil, ya que se sigue centrando en el performance y no en resultados ni en impacto.
Hay métricas centradas en la cantidad de trabajo que obtenemos: número de pantallas desarrolladas, de features o de Product Backlog Items por Sprint. Estas métricas ayudan a ser predecible en la cantidad de trabajo que podemos llegar a obtener. Métricas de este estilo son más objetivas que la velocidad y nos dan mejores resultados de predictibilidad. Ahora bien, si las usamos como métricas de éxito, volvemos a pecar en poner foco en el rendimiento del equipo, por encima de dar resultados de valor. No obstante, disponer de esta métrica para una Retrospectiva o una Sprint Planning es muy útil.
Hay datos que son interesantes como satisfacción del equipo o de nuestros customers. Las métricas de felicidad, también son subjetivas, y se suelen medir mediante encuestas. Medir ambas nos dicen la salud de nuestro producto y la salud de nuestro equipo, pero tampoco pueden ser métricas de éxito. Un customer puede estar muy contento porque le regalemos la versión premium, y eso haga que no sea rentable. La felicidad del equipo tampoco puede ser el único parámetro, pueden ser muy felices porque solo trabajan dos horas al día, y no obtengamos suficiente incremento de producto para que sea rentable.
Las métricas más valiosas son aquellas que se relacionan con el valor que aportamos. Si estamos en un comercio electrónico pueden ser las ventas. Otras métricas como los costes son interesantes de transparentarse, ya que nos muestran la realidad de nuestro producto y si somos rentables. Si estamos desarrollando productos internos, las métricas de uso ganan relevancia: número de usuarios que entran, porcentaje de tiempo que invierten para realizar una determinada acción, o uso horario en el que se conectan. Estas métricas, en productos que venden, pueden ser menos relevantes (aunque interesantes) pero ganan importancia cuando desarrollamos productos para mejorar nuestras operaciones internas.
Hay muchos ejemplos de métricas de éxito, de alguna manera debe estar relacionados con el motivo por el que existe nuestro equipo y producto. Además, si nuestro producto está alineado con la estrategia de la compañía mejor. En general, debe ser el Product Owner el que conozca todo esto, y que en la Sprint Review hable de ello. Ahora bien, un Scrum Master que detecte que su Product Owner no lo hace, debe facilitar esta conversación.
Próximos pasos
Para hacer esto, mi consejo es que nos sentemos a hacer la pregunta: ¿para construímos esto? Una vez respondido, definamos métricas que nos digan si vamos por el buen camino, y otras métricas que nos ayuden a entender el estado del producto. Métricas como cycle-time o satisfacción del equipo nos ayudan a saber la salud de nuestra entrega, y las métricas de negocio nos dicen que lo que construímos funciona y da valor.
Uno de los retos de un Scrum Master, es cambiar el foco de métricas de vanidad a métricas de valor. Esto parece sencillo, pero muchas organizaciones no están preparadas y estas conversaciones pueden llevarnos a caminos sin salidas.
Y tú, ¿qué mides en tus equipos?
