En Scrum, al igual que en la mayoría de métodos y marcos de trabajo, disponemos de valores sobre los que pivota el propio método. En Scrum, se definen cinco valores que son necesarios para que los equipos Scrum funcionen y que, a su vez, se fomentan gracias a las diferentes prácticas y reglas que incorporan. Los valores son: foco, coraje, apertura o franqueza, respeto y compromiso. En este caso, analizamos lo que supone compromiso para un equipo Scrum.
Estar comprometidos o tener un compromiso
El desarrollo software ha usado la predicción como herramienta de gestión: teníamos que dar fechas en etapas muy tempranas para poder gestionar las expectativas de nuestros clientes o de nuestros jefes. Cuando comunicábamos una fecha, se generaba un vínculo de compromiso con el que la persona que había dado esa fecha adquirían un “contrato”. Por el camino, pasaban muchas cosas imprevistas, y la mayoría de las veces se ponía en riesgo alcanzar esa fecha, con lo que se generaba una tensión elevada en los equipos. En estas situaciones, se toman decisiones muy similares en todos los sitios: meter a más personas en el equipo, echar horas, reducir el alcance comprometido o reducir la calidad (ya lo arreglaremos más adelante). Durante todo este proceso, nos recordaban de manera contínua que nos habíamos comprometido con dicha fecha.
Asumimos que tener un compromiso es el camino que seguimos para que el equipo esté comprometido. Sin una fecha, las personas no lo darán todo. Y aunque estoy de acuerdo en que, a veces, funciona, no es el tipo de compromiso que buscamos en Scrum. De hecho, en muchas empresas, las personas acaban haciendo muchas horas extras como un símbolo de compromiso.
En Scrum, buscamos que los miembros del equipo estén comprometidos. Mi jefe me puede pedir que tenga una tarea terminada dentro de 10 días, lo que supone que tengo un compromiso, pero seguramente no esté comprometido al no ser mí decisión. Solemos confundir obediencia con responsabilidad. Si estamos comprometidos y consideramos que no es una buena idea esa fecha, lo haremos visible. El motivo por el que no trabajamos con fechas comprometidas es porque el software emerge, aparecen nuevas oportunidades y tener compromisos nos resta efectividad para pivotar.
En la Sprint Planning no hay compromiso
Muchas personas piensan que el resultado de la Sprint Plannig es un compromiso que el equipo adquiere con el Product Owner. Por eso, hablan de puntos comprometidos o de historias comprometidas. Esta acepción de compromiso fue eliminada de Scrum en el año 2011, el motivo es que durante la ejecución del Sprint pueden aparecer imprevistos. Por eso, se cambió la palabra compromiso por previsión (forecast en inglés). Es decir, al finalizar la Sprint Planning, disponemos de una previsión del trabajo que creemos que seremos capaces de acometer.
Durante el Sprint, pueden aparecer nuevos requisitos o evoluciones sobre los que estamos trabajando. Un equipo Scrum comprometido es aquel que entiende cómo queremos aportar valor a nuestros usuarios, y no aquel que se ciñe al plan original. ¿Por qué no implantar esa features que acabamos de descubrir que mejorará la experiencia de nuestro usuario?
Cuando un equipo Scrum entiende cómo su producto ayuda a sus usuarios, es capaz de enfocarse en lo que de verdad aporta. Pero para que esto funcione, tenemos que eliminar conversaciones del estilo: no has hecho lo que pone aquí. Debemos pivotar las conversaciones de “hay que hacer X” hacia “hemos hecho X, ¿qué impacto ha tenido en nuestros usuarios?”.
El Sprint Goal: nuevo compromiso del equipo Scrum
A pesar de que hemos cambiado compromiso por previsión, muchas personas siguen pensando que, sin tener un compromiso, las personas no se esforzarán. Y para ello, se utiliza el siguiente argumento: “en el Sprint, tenemos una previsión, y un compromiso, con el Sprint Goal”. Es decir, el Sprint Goal es el nuevo compromiso, ¡seguimos en el mismo paradigma de trabajo bajo presión!
Dado que para muchos equipos el Sprint Goal es un conjunto de elementos del Product Backlog, tratamos de asegurarnos de que se finalizará el trabajo que el equipo dijo que iba a tener hecho. ¿Realmente hemos implantado el cambio de mentalidad que propone Scrum?
El Sprint Goal no es “el nuevo compromiso”, es un artefacto que fomenta el foco para poder tomar decisiones durante el Sprint, es una guía. Si lo analizamos, el Sprint goal no se inspecciona en el Sprint Review, ya que su función termina cuando acaba el Sprint, en ese momento lo que inspeccionamos es el incremento. El objetivo de un Sprint es generar un incremento que aporte valor, no saber si cumplimos con lo que dijimos que íbamos a hacer. Se trata de entregar valor, no de ver el futuro, y el Sprint Goal debe ayudarnos a ello, es un medio y no en un fin.
Es muy mala métrica el medir el número de Sprint Goal completados con éxito, esa no es la función del Sprint Goal.
El auténtico compromiso de un equipo Scrum
Un equipo Scrum comprometido es aquel que le dice a su cliente “esto no sé cuándo lo voy a tener”, si realmente piensa que no lo sabe. La transparencia es parte del compromiso, la alternativa es engañar al cliente. Muchas empresas prometen a sus clientes fechas imposibles para conseguir una venta y, cuando hay retrasos, “lo gestionan”.
Cuando un equipo Scrum está realmente comprometido, le importa el resultado de su trabajo. Por ejemplo, cuando una feature no funciona correctamente, o presta un mal servicio, asume la responsabilidad y se preocupa por resolverlo. Cuando está comprometido, la retrospectiva es un ejercicio real en busca de conseguir mejoras. No es solo hacer el evento, es comprometerte con que las acciones resultantes ocurrirán ya que están comprometidos con mejorar su trabajo.
Los equipos Scrum que están comprometidos dan lo mejor de sí mismos, no a nivel individual, sino como equipo. De esta manera, durante el Sprint se ayudan unos a otros para sacar adelante el trabajo. La Daily Scrum es un ejercicio de escucha hacia los compañeros para que no se bloqueen y puedan ser efectivos.
Entender las necesidades de los usuarios y cómo su producto presta servicio es esencial en equipos Scrum comprometidos. Esto lo observamos cuando un equipo propone mejoras para su producto.
Un equipo Scrum comprometido es aquel que acude al refinamiento para colaborar con el Product Owner en la gestión de las futuras fechas de release y de las expectativas de los stakeholders. Es importante sacar el trabajo, pero también lanzar mensajes que permitan al producto dar un buen servicio.
Cuando las personas de un equipo Scrum están comprometidas, dispondrán de métricas de valor reales que les permitan inspeccionar el resultado de su trabajo y adaptar el Product Backlog para dar el mejor servicio posible. En las conversaciones con el Product Owner, harán preguntas para entender las necesidades de los usuarios para lograr ser efectivos, no es cuestión de hacer software es cuestión de entregar valor a través del software que desarrollamos.
La libertad y la transparencia son claves para generar compromiso en un equipo Scrum
Debemos huir de la mentalidad tradicional de compromiso basado en fechas y presión. El compromiso se suele adquirir cuando tenemos libertad en la toma de decisiones. Las personas se comprometen con aquello que deciden. Cuando una persona cumple una fecha que ha decidido otra persona, eso se llama obediencia y no genera responsabilidad. La responsabilidad y el compromiso emanan de la capacidad de decidir que tiene una persona o un equipo.
Si te preocupa que tus equipos se comprometan, hazles partícipes de las decisiones que se tomen sobre ellos. Cuando puedes decidir cómo trabajar, el resultado de tu trabajo solo depende de tus decisiones, y entonces es cuando de verdad te importa.
Y tú, ¿tienes compromisos o te comprometes?
