Scrum Team ¿Y el negocio pa cuando?

Hace tiempo comencé en una organización que quería avanzar en Agile. Lo primero que me pidieron era medir el estado actual de la organización con respecto a Scrum en los equipos. Para ello partimos del checklist de Kniberg que mide el nivel de Scrum de un equipo. Kniver propone dividir el checklist por la importancia de las preguntas, entre ellas tiene las críticas y una de ellas dice “entregamos lo que el negocio necesita”.

Cuando he ido a equipos a lanzar esta pregunta el 99% decían que sí, que ellos hacían lo que les pedía el Product Owner y por tanto estaban entregando lo que pedía el negocio. ¡Pero si no lo saben!

¿Entramos lo que el negocio necesita?

Para saber si entregamos lo que el negocio necesita, primero tendremos que definir lo que el negocio necesita y añadirle unos medidores que corroboren nuestras hipótesis, y después comprobar que se cumple. Por ejemplo, si lo que buscamos con nuestro producto es que aumenta el % de conversión del 1 al 1,5 pues ya tenemos un dato de negocio puro. Además, podemos añadir otros medidores que nos ayuden a descubrir lo que el negocio necesita; un ejemplo puede ser medir el tiempo que tarda un usuario en completar un proceso ya que con el nuevo producto queremos que tarde menos y que eso nos ayude a mejorar la tasa de conversión.

Otros medidores secundarios pero que nos aportan información puede ser el time-to-market del Scrum Team. Puede que todavía no hayamos dado con la clave para mejorar el % de conversión pero si tenemos un time-to-market bajo podremos llevar más rápido funcionalidad que nos permita inspeccionar y adaptar hasta que acertemos. Y algunos medidores que nos den información de la deuda técnica para no crear un producto que a la larga sea muy costoso de mantener.

Conversaciones con los usuarios

Tener conversaciones sobre lo que el negocio necesita ocurre pocas veces bajo mi experiencia. El motivo es básico, usamos Scrum para hacer proyectos, lo que supone que nuestra felicidad se basa en entregar software en una fecha (a veces a trocitos); si después de esa fecha ningún usuario quiere nuestro software eso no es nuestro problema, el problema es de la persona que lo definió. Y este es otro motivo más para usar técnicas como el Sprint 0, para que lo que vayamos hacer esté muy claro y no nos equivoquemos, pero, ¡Scrum no está pensado para esto!

Cuando Jeff Sutherland y Ken Schwaber hablan de que Scrum está cambiando el mundo no hablan de hacer lo mismo de siempre con post-its de colores y retrospectivas en un bar, se trata de cambiar el paradigma en el que hacemos software. Principalmente, trayendo el negocio al equipo, y no nos vale solo con que venga el Product Owner que es de negocio, esto se queda cojo si nunca tenemos conversaciones sobre el negocio.

Un pequeño experimento que podéis hacer con vuestros equipos, hacedles a cada miembro esta pregunta, que la anoten en un postit y después leer las respuesta de manera anónima. ¿Para qué construímos este producto?. Si la respuesta es parecida a “tenemos que tener X en Navidad” entonces estamos en mentalidad proyecto y no en la mentalidad de producto que propone Scrum.

Scrum Team con falta de atención a los resultados

Patrick Lencioni en su libro “las 5 disfunciones de un equipo” nos contaba que una de ellas es “falta de atención a los resultados”. Evidentemente estamos preocupados por entregar ese software en Navidad, pero los resultados no son esos, los resultados son que de verdad entreguemos valor a la organización. El software sirve para cambiar el mundo, cuando desarrollamos un nuevo software cambiamos el día a día de muchos usuarios y por tanto cambiamos el mundo.

Por tanto tenemos que descubrir lo que el negocio necesita. Hay mil y una técnica para hacer eso, quería aportar un par de ellas. Si vas a construir un producto que sustituye a uno existente, por ejemplo, cambiar una web por otra nueva y moderna con microservicios que escala y es responsive. Trata de definir medidores y de implantarlos en el producto antiguo de manera que puedas contrastar con el nuevo desde el minuto 0. Es la mejor manera de averiguar si estamos acertando o tenemos que pivotar nuestro nuevo producto. Por ejemplo, si lo que quieres es reducir el tiempo total invertido por un usuario en la compra, mide ese tiempo hoy y con el nuevo producto.

Otra técnica que considero muy buena es el Impact Mapping. Esta herramienta sirve para mapear los objetivos que nos hemos marcado con el producto contra las funcionalidades que vamos a desarrollar. Entremedias encontramos lo que llamamos “impactos” que sirven para poder alcanzar dichos objetivos. Esta herramienta no se centra en el alcance, en el ¿Qué hay que hacer? sino se centra en ¿Qué le vamos a dar al usuario para que nuestros objetivos de negocio se hagan realidad? Tener estas conversaciones con el Development Team es clave, ellos son los que crean el software y hay que involucrarlos en el negocio.

Scrum Team que piensa en negocio tiene métricas

De ambas maneras es esencial que tengamos definidos los medidores o KPIs que nos digan el éxito de nuestro producto. Así cuándo nos pregunten si entregamos lo que el negocio necesita podremos dar una respuesta con datos e irrebatible. No esperes al final del desarrollo para saber si lo que haces lo quiere alguien, eso es mentalidad de proyecto y hemos venido a cambiar la manera de hacer las cosas.

Cuando decimos hablar del negocio y no del alcance nos referimos a lo siguiente. En un equipo de una aseguradora en la que trabajé como Scrum Master tuvimos una conversación interesante en una de las pantallas del producto que construíamos. Era una pantalla un poco rara, solo aparecía en ciertas ocasiones por un motivo que no entendíamos ya que lo sí sabíamos que cuantas más pantallas y datos tuviera que rellenar el usuario menos opciones habría de que contratara un seguro. ¿Para qué sirve esta pantalla?. El Product Owner nos explicó cómo funcionaba el negocio: “este dato es vital porque nos dice si queremos que el usuario se venga con nosotros, o preferimos que no se venga salvo que pague un precio alto, este dato lo queremos localizar en personas que vivan en esta comunidad autónoma que es donde abunda y por eso no queremos que aparezca siempre”. Una vez que entendimos el negocio, todo fue más fácil. Recuerdo que un miembro del Development Team dijo “bueno pues en ese caso en vez de usar un elemento select podemos poner el dato en forma de tabla y que el usuario seleccione el suyo”. Para mí este fue el ejemplo claro de lo que significa “unir negocio y tecnología”.

¿Qué elemento de Scrum se utiliza para el negocio? ¡La Sprint Review!

La Sprint Review es la reunión de negocio por excelencia, por eso el Product Owner presenta el producto y tratamos de inspeccionarlo para poder adaptarlo en el siguiente Sprint y mejorar nuestro negocio. Y por eso no es un demo.
Imagina que eres una startup y que vienen unos posibles inversores de tu producto a verte a una reunión. ¿De qué les hablarías? Cosas que seguramente no harías: enseñarles pantallas para resaltar lo bonitas que han quedado, decir el número de puntos que ha quemado un equipo, describir los enormes esfuerzos del equipo o mostrar diagramas burndown. Estoy convencido de que si fueras el Product Owner en una situación así tratarías de hablar del negocio, de cómo tu producto funciona, de que es capaz de hacer y de lo próximo que va a incorporar y escucharias a esos inversores para que te den las claves que necesitas para mejorar tu producto. Es más, si puedes, los involucrarías al máximo en la definición de tu producto para que funcione mejor.

Bien, pues ahora olvida lo de la startup, ¡Eso es una Sprint Review!. Hablar del negocio, de cómo nuestro producto mejora nuestro negocio, de cómo atrae usuarios o de cómo resuelve problemas por los que nuestros clientes pagarían. Tener conversaciones de negocio con las personas que van a fabricarlo es esencial, necesitan entender cómo su trabajo ayuda a las personas y la organización a la que sirven. Los desarrolladores tienen que sentirse bien por cómo aportan a su organización y no ser felices porque llegaron a una fecha X que les impusieron y que luego nadie quiera lo que hicieron o el call center esté frito de llamadas por la calidad a la que renunciaron para poder llegar a la fecha.

Scrum Team pensando en negocio como elemento de cambio

Si aún no has tenido conversaciones de este tipo en tu Scrum Team piensa cuánto beneficia Scrum en tu organización. ¿Realmente hacemos las cosas de otra manera o seguimos haciendo proyectos a base de iteraciones?. El verdadero Scrum sirve al negocio de la organización para aportar valor. Por eso decimos que no es para proyectos, esa mentalidad de entrega en fecha ha creado mucha infelicidad en el mundo software. Los profesionales quieren hacer cosas con sentido, quieren ayudar a las personas, quieren que su trabajo sirva para cambiar el mundo de verdad. ¿Cuántas veces hemos desarrollado algo que nadie quiere?

Cuándo decimos que Scrum viene para cambiar el mundo, hablamos precisamente de esto. Al mercado y los usuarios les importa un pimiento tu Jira, tus Sprint Review, tus Daily Scrum, tus Análisis Funcionales o tu Product Owner. Lo que le importa es que le resuelvas problemas: quieren escuchar música en cualquier parte, comprar un vuelo barato, leer las noticias o saber si mañana llueve. Así que, tenemos que dejar de pensar que los Scrum Team hacen Software, porque no hacen eso, generan valor a través de un software. Tenemos que medir el valor, porque sino no sabremos si hacemos un buen trabajo.

Y en tu Scrum Team ¿Cuándo aparece el negocio?