,

Comparando Equipos Scrum

Los Equipos Scrum son como los guijarros, similares pero diferentes dentro de sus similitudes.

Los Equipos Scrum tiene elementos fácilmente identificables que les hace parecer iguales, un Product Owner, un Scrum Master, unas cuantas personas formando el equipo de Construcción, un Product Backlog, sus ceremonias Scrum, sus tablero del Sprint, etc… Es muy fácil caer en la tentación de verlos como iguales.

Mirando más de cerca cada Equipo Scrum es un micro ecosistema: personas diferentes, habilidades distintas, diferente compromiso, productos distintos. Y sin embargo tendemos, por el hábito y costumbre que traemos de modelos no Agile, a compararlos y tratar de establece “cuál es mejor”.

La realidad

Supongamos que tenemos 2 Equipo Scrum que van a participar en la construcción del mismo Producto, con la misma tecnología, el mismo número de personas, ambos multidisciplinares y con todo el conocimiento que necesitan, y utilizando la misma escala de estimación de complejidad del producto. Probablemente en algún momento los responsables jerárquicos inconsciente o conscientemente empezarán a comparar el “número de puntos que hacen”:

JEFE – Oye, Product Wopper, ¿por qué tu equipo hace menos puntos que el otro? Deberíais estar haciendo más, por que tu parte es más fácil.

Product Wopper – Si, bueno es probable – Mientras piensa “Mañana multiplicamos por 5 las estimaciones y listo”

La respuesta es un sinsentido, al nivel de la pregunta; aunque cualquier Product Owner que tenga un mínimo de entendimiento de su rol nunca se lo plantearía. Es más le daría unos cuantos argumentos sobre por qué no puede comparar la velocidad de su Equipo Scrum con el otro:

  • El nivel de conocimiento de las personas que participan es diferente
  • El concepto sobre qué es complejo o sencillo es diferente en cada equipo
  • La capacidad de los P.O. para preparar y escribir PBIs es diferente
  • Los criterios para decidir que un PBI está listo para construir o para entregar son diferentes

Simplemente es que son personas diferentes, con conceptos, mecanismos, ideas, entendimientos, motivaciones, objetivos, etc… distintos, y por lo tanto la complejidad de los PBIs, incluso usando la misma escala, es diferente.

El aporte de valor

Pudiéramos creer que utilizando como métrica el aporte de valor al producto final, nos sería más “sencillo” determinar que equipo scrum es “mejor”. En realidad tenemos el mismo problema. ¿Quién decide cuánto valor aporta una parte del producto? Personas que tienen necesidades distintas, objetivos distintos, ambiciones diferentes, etcétera… por lo que ese valor estará “contaminado” por su propia percepción.

Es cierto que al ser algo ajeno a los propios equipos scrum, puede que nos acerque más, pero seguirá sin ser fiable.

¿Por qué?

La pregunta que deberían hacerse aquellos que quieren comparar equipos scrum es “¿Por qué quiero saber cual es mejor? ¿Qué necesidad cubre tener esa información? ¿Qué razón me empuja a ello?”. Y cuando encuentres la respuesta entonces pregúntate “¿Cómo consigo que esa medición sea objetiva?”.

Conclusiones

Los equipos scrum disponen de métricas muy sencillas, como el Burn Down y Burn Up, para medir velocidad y avance del producto, de mecanismos de revisión y adaptación constantes, basados en la experiencia y en las métricas, que les permiten sprint a sprint evidenciar que están cumpliendo los acuerdos que se establecen o detectar las desviaciones que estén ocurriendo.

No necesitan que se les trate de comparar constantemente con el resto. Lo que necesitan es un espacio de confianza, en el que puedan equivocarse a veces y ganar experiencia, con el objetivo de ser más “precisos” en sus estimaciones respecto a los recursos necesarios, ya sean financieros o temporales o materiales, para construir un producto. Necesitan un espacio que les permita ir creciendo como equipo, y de una forma natural, aumentará su velocidad de construcción de producto entregable a nuestros clientes.

Es muy lícita, y comprensible, la necesidad de las organizaciones de entender y disponer de información sobre el cuánto y el cuándo; es además algo muy habitual, el tener esa inquietud o sensación de falta de información, mientras estamos inmersos en un proceso de transformación. Así que tendremos que buscar una manera que nos dé tranquilidad como organización, y que permita la mejora continua de nuestros equipos scrum, sin bloquear su crecimiento ni la transformación a modelos Agile.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *