7 ideas para mejorar tu equipo con Scrum y UX

7 ideas para mejorar tu equipo con Scrum y UX

¿Quieres ideas que saquen lo mejor de Scrum y el diseño de experiencias de usuario (UX) para mejorar el valor de los productos que desarrolla tu equipo? Y de paso, también aumentará el nivel profesional de sus miembros.

🤝 Crear equipos para solucionar problemas

Dice Marty Cagan en su libro Inspired [1] que los equipos de producto deberían crearse para solucionar problemas del usuario de maneras que sean viables para la empresa (el fin), y no para desarrollar productos (el medio). La diferencia puede parecer irrelevante, pero no lo es.

Cuando un equipo se concibe para solucionar problemas de los usuarios, se le está empoderando para tomar decisiones de negocio y se les responsabiliza de sus resultados.

Mr Wolf - I solve problems
  • Se les empodera para que identifiquen, validen y prioricen qué problemas solucionar. Ya no hacen «lo que les pide negocio» sino «lo que necesita el cliente». Se crean equipos de «misionarios» y no de «mercenarios». Esto motiva a sus miembros y reduce la falta de alineamiento de quienes trabajan en las iniciativas. 
  • Se les responsabiliza de los resultados de su trabajo. El éxito no se mide en entregar una funcionalidad a tiempo, sino en conseguir evidencias que han solucionado los problemas.

Tener clara la misión del equipo es importante para la Dirección (quienes les empoderan), para los stakeholders (p.e. otros roles del negocio) y especialmente para los miembros del equipo. Saber la cultura del equipo y la mentalidad que se requiere a sus miembros es importante antes de entrar (o no) en el equipo.

 

 

🤖 Dejar de hacer mecánicamente los eventos del Scrum

Utilizar los eventos de Scrum como «ceremonias» que realizar de manera procedimentada es un golpe «debajo del bañador» al enfoque empírico, de autogestión y orientado al valor del framework.

Los eventos con un (cierto) orden son más efectivos, pero lo importante no es el proceso sino la motivación de sus participantes y especialmente el resultado al que se llega. Veamos dos ejemplos:

En el Daily Scrum, las preguntas «qué hice ayer», «qué voy a hacer hoy para cumplir la Meta del Sprint» y «cuáles son los problemas del equipo» son meramente una plantilla para que todos los desarrolladores aporten y se piense en la meta del Sprint. Hagamos lo que hagamos en el Daily, será bueno si salimos del evento con la sensación de:

  • Hemos hablado de lo importante para entregar un buen Sprint como Equipo.
  • Hemos pensado en lo que realmente importa a la empresa y al usuario.

En el Sprint Review, hacer una «demo» es meramente un vehículo para obtener feedback de que es lo mejor que podemos hacer en los siguientes Sprints, y NO para validar que las funcionalidades entregadas son correctas. Hagamos lo que hagamos en el Review, será bueno si salimos del evento con la sensación de:

  • Hemos hablado de todo lo importante para añadir el máximo valor posible al producto en los siguientes Sprints.
  • Hemos tomado decisiones según las evidencias que tenemos (p.e. resultados de entrevistas a usuarios, analítica de uso del producto, etc.)
Scrum Robot
Nosotros también hacemos eventos mecánicos en el Sprint. 🤖

👉 Delegar más del Product Owner a los Developers

Es muy habitual que al Product Owner le vean como un interlocutor del Equipo Scrum que además se encarga de gestionar a los Desarrolladores. Es una herencia del rol de jefe de proyecto con «gorro ágil» de un departamento IT, el nivel «Proxy Product Owner». La «prueba del algodón» es la pregunta «¿va el Product Owner a los Daily Scrum?», si la respuesta es «sí» muy probablemente los developers no se estén autogestionando.

El Product Owner se encuentra frecuentemente como el queso en un bocadillo, atrapado entre los developers a los que no delega y el negocio que no le empodera.

Si el Product Owner no delega en los Desarrolladores y éstos no pueden/quieren asumir responsabilidades como el desglose de los PBI, el análisis de las historias de usuario y la definición de las pruebas funcionales, difícilmente tendrá el tiempo para asumir decisiones más estratégicas del producto y de negocio. Para poder delegar, se tienen que dar condiciones como:

  • El Product Owner (de acuerdo con el management) entiende que su misión va más allá de gestionar requisitos en Jira.
  • Los developers son suficientes y tienen capacidades para ser autónomos, incluyendo especialmente la posibilidad de definir y validar requisitos con los usuarios.
  • Los developers tienen proactividad y experiencia para tomar decisiones por si mismos.
  • Existe transparencia en las responsabilidades de cada uno. Un tablero de delegación al estilo Management 3.0 puede ser muy útil.
Los niveles del Product Owner- Gunther Verheyen
Tipos de Product Owner según su mandato. Fuente: Curso PSPO de Scrum.org

 

🔎 Tomar las decisiones basadas en evidencias

¿Tomamos las decisiones del producto según nuestra intuición o basándonos en datos y evidencias?

En ocasiones invertimos en desarrollar funcionalidades que no se usan. Esto es un desperdicio de recursos e impide dedicar el tiempo a necesidades más importantes. Si además vamos sobrecargados de trabajo, es casi una crueldad.

¿Cómo nos ayudaría correr menos y pensar más, tomando las decisiones basadas en evidencias? Veamos un ejemplo:

HiPPO - highest paid person's opinion. Animales preligrosos del product management.
Las decisiones HiPPO son las de aquel responsable que impone su intuición a los demás.

Estamos desarrollando una funcionalidad costosa en nuestra web para los clientes. Durante el Sprint Review, los interlocutores internos están contentos con el aspecto que va tomando la funcionalidad. El diseño en mockup de las siguientes funcionalidades tiene una pinta estupenda. Despues de seis Sprints y tres meses de trabajo de un equipo de cinco personas, se han invertido 120.000€ y se lanza la aplicación a producción.

En los primeros días de uso no parece que la funcionalidad tenga mucha aceptación y empiezan los nervios. Se intenta replantear la funcionalidad durante cuatro semanas y 40.000€ más de inversión, y aunque las métricas de uso mejoran ligeramente, resulta una iniciativa ruinosa. Entonces comienza el reparto de culpas entre las partes, sin sacar conclusiones claras.

En una retrospectiva, el Equipo Scrum intenta averiguar el motivo y descubren (sin demasiada sorpresa):

  • La iniciativa de añadir la funcionalidad surgió del director de un departamento y como se invertía «su dinero», decidieron contratar la iniciativa a un proveedor externo que no arriesgo su facturación cuestionando el proyecto.
  • No se habían realizado actividades para testear la necesidad real de la funcionalidad. Ni entrevistas a los clientes, ni observación de su conducta, ni análisis de las analíticas actuales de la aplicación.
  • Durante el desarrollo de la funcionalidad, no se mostró su diseño a clientes reales para obtener feedback, ni se desplego una versión inicial de la funcionalidad a un grupo piloto para obtener métricas de uso. Aún así, se continúo invirtiendo dinero a ciegas, sin contar con evidencias.

Usar Scrum sin tomar decisiones basadas en evidencias es como jugar al fútbol sin pelota.

🤔 Todos el equipo puede hacer algo de UX

La primera idea para mejorar la efectividad de los equipos era «Crear equipos para solucionar problemas» y no equipos que tengan como objetivo principal «desarrollar software». Esta misión orientada a dar resultados a los usuarios debería influir en la percepción de los propios miembros del equipo: a pesar del rol que desarrollen, todos deberían saber (y hacer) algo de actividades de diseño de experiencias de usuario (UX).

¿Cómo llegar a este estado en equipos donde no sé hace diseño de UX, o bien los diseñadores son externos? En el artículo How to increase UX Design maturity for Scrum teams [2] doy algunas claves: 

  • En primer lugar, los beneficios de integrar el UX en los equipos debe quedar claro a la dirección, incluyendo a los líderes de desarrollo y de diseño. Sin esto, será difícil que se puedan tener suficientes diseñadores para colaborar de manera estable con los equipos, y además que se vea deseable que lo hagan.
  • En segundo lugar, se debe vencer la inercia de iniciativas donde no se realiza UX, o donde el UX se realiza antes del desarrollo y por diseñadores externos. Esto de nuevo implica la concienciación de los líderes, los desarrolladores y los diseñadores.
  • En tercer lugar, se debe posicionar y empoderar a los diseñadores como líderes de UX que luchen por difundir la mentalidad de diseño centrado en las necesidades del usuario, y por formar al resto del equipo para que puedan entender y colaborar en las actividades de UX. Esto no quiere decir en general que los diseñadores de UX ya no sean necesarios, que ningún UX se asuste 😱, las organizaciones difícilmente tendrán la mentalidad y nivel suficiente de UX por si mismas.

  

Yes, we do Scrum with UX and...

⬅ Comenzar el análisis desde el usuario

Es habitual que se decida invertir en una iniciativa para responder a una oportunidad de negocio o a una necesidad del cliente (p.e. vender más a los clientes con una APP de móvil) . Posteriormente hacemos el «caso de negocio», estimando la inversión y el beneficio que esperamos para la organización. A continuación hacemos el desarrollo en rigurosos Sprints y finalmente lanzamos la APP a los usuarios. Sorprendentemente las métricas de uso son decepcionantes.  Después de indagar con algunos usuarios, descubrimos que muchos de estos no necesitaban realmente la APP por muchos motivos, p.e.

  • Prefieren seguir interactuando como siempre con nuestra organización, que es por teléfono,
  • No les gusta tener que aprender como usar la una aplicación de móvil,
  • Usar la APP no les da el beneficio que suponíamos, el ahorro de tiempo y esfuerzo.

El error principal en este caso ha sido suponer que desarrollar un producto para los clientes iba a producir automáticamente un beneficio para el negocio. Nos hemos saltado entender que beneficio iba a producir a los usuarios, y validar progresivamente que esta asunción era cierta.

Como se ve en el diagrama posterior, suponemos que el trabajo del equipo (activities) generá el producto (output) que requiere el cliente, y que los requisitos entregados proporcionarán beneficios reales para el cliente (outcome), y finalmente que obtener estos beneficios incentivarán a este a comportarse como le conviene a la empresa, p.e. haciendo más compras (impact).

Posiblemente nos habríamos evitado una inversión innecesaria de tiempo y recursos si hubiéramos hecho la exploración al revés:

  • ¿Qué beneficios del usuario (outcomes) le podrían motivar a comprar más (impact)?
  • ¿Cómo podemos darle esos beneficios al cliente? Puede ser mediante una APP (output) o de una manera diferente (p.e. mediante descuentos o un servicio telefónico automatizado las 24 horas).
Outcomes over outputs

La técnica del Impact Mapping [3] nos permite explorar un árbol de hipótesis que ir testeando (validando) de una maner rápida y barata antes de decidir hacer grandes inversiones. No es una técnica infalible, pero desde luego permite encontrar las asunciones incorrectas mucho antes y gastando menos.

Impact Mapping
Ejemplo de Impact Mapping. Como los actores pueden ayudar a conseguir un objetivo de negocio.

🏃‍♂️ Haz tus refinamientos eficientes

Para que los refinamientos sean eficientes, algunas ideas que pueden ayudar son:

  • Dar autonomia a los Developers para refinar sin el Product Owner todo lo que puedan.
  • Se debe refinar la parte mínima del Backlog que se va a realizar en los próximos Sprints.
  • Deben asistir las personas necesarias y paralelizar el máximo posible.
  • Se puede dividir entre refinamiento de alto nivel (orientado a la planificación) y el de bajo nivel (preparación de los siguientes Sprints).
Refinamiento del Backlog con UX
Ejemplo de mapeo entre el modelo del Doble Diamante y un ciclo de vida de Ítems del Product Backlog

El Product Owner puede convertirse en un cuello de botella si no delega y cree que ha de estar en todas las reuniones de refinamiento. Otra cosa es que el Product Owner disponga del tiempo y conocimientos para poder participar en esta actividad como un Developer más.

Para que los Developers puedan asumir el refinamiento al máximo, deben tener:

  • Las habilidades y conocimientos para hacerlo.
  • El empoderamiento por parte del Product Owner.
  • Y la voluntad de responsabilizarse de ello.

Como todo proceso de delegación, suele funcionar mejor cuando existe la transparencia clara en los beneficios esperados, se definen las responsabilidades de todas las partes y se hace un seguimiento de los resultados.

El refinamiento no es una actividad monolítica, podemos ver sus actividades a dos niveles:

  • Refinamiento de alto nivel (más asociado al «Product Discovery»), más parecido al evento de Release Planning, donde se planifica el trabajo para los siguientes Sprints. Es frecuente que este tipo de refinamiento se estructure respecto a las actividades de «Research UX» de los problemas del usuario, y como abordarlos, p.e. en forma de épicas a entregar, los Sprints necesarios, y los riesgos e incognitas a trabajar.
  • Refinamiento de bajo nivel (más asociado al «Product Delivery»), donde se tiene habitualmente un horizonte de Sprints y épicas a entregar, que se analizan para definir el diseño técnico y funcional a alto nivel de las épicas, descomponiéndolas en historias de usuario. Entonces se estima el esfuerzo de las historias, se buscan sus dependencias y se definen los criterios de aceptación, 

El refinamiento se vuelve ineficiente cuando todo el Equipo Scrum decide estar presente en todas las actividades. Si los miembros del equipo son capaces de coordinarse en el alto nivel del refinamiento y trabajar en paralelo el bajo nivel, puede resultar en un refinamiento eficiente y rápido. En caso contrario, tendremos a una parte del equipo que dirigirá el refinamiento y otra parte que no podrá aportar mucho, hecho que representa una pérdida de tiempo.

💪 ¿Quieres sacarle aún más partido a este artículo?

Como bonus, me gustaría compartir con vosotros una Estructura Liberadora [5] llamada What, So What, Now What (o W3). Las Estructuras Liberadoras son patrones de colaboración y pensamiento que ayudan a sacar más valor de eventos y actividades de análisis.

W3 nos permite aumentar el aprendizaje a través de la reflexión y de un proceso estructurado.

Os propongo que dediquéis 5 minutos a releer el artículo y rellenar la siguiente tabla:

  • ¿Qué ideas he descubierto al leer el artículo?
  • ¿Qué nuevas opciones aportan estas ideas en mi trabajo para ser más efectivo?
  • ¿Qué cosas concretas puedo hacer a corto plazo para llevar a cabo estas opciones?

 

  1. Idea 1
  2. Idea 2
  3. Idea 3
  4. · · ·
  1. Nueva opción 1
  2. Nueva opción 2
  3. Nueva opción 3
  4. · · ·
  1. Intentaré hacer… 1
  2. Intentaré hacer… 2
  3. Intentaré hacer… 3
  4. · · ·

¿Quieres recibir más información y recursos de calidad?

¡Sigue a Alex en las redes sociales!

Alex Ballarin

Alex Ballarin es Professional Scrum Master y Business Agility Coach. Además de este blog, publica contenido frecuentemente en las redes sociales

¡Suscríbete a nuestra newsletter mensual!

Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.

¡Sácale más partido a este artículo!

Comenta en Linkedin

Continúa la conversación en Linkedin citándome (@alexballarin).

Comparte con tus conocidos

¡O comparte este artículo con otras personas a las que les pueda interesar!

Continua aprendiendo

En nuestro blog encontrarás otros artículos clasificados por rol y por nivel,
y además podrás irlos guardando tal y como los leas. 👇

Scroll al inicio