En algunas ocasiones se puede ver a los especialistas de UX como los que descubren las necesidades de los clientes, definen las soluciones, las validan y luego entregan a los equipos Scrum toda la información para que realicen el desarrollo de aquello que ya fue definido. Bajo este enfoque el equipo de desarrollo podría no conectarse con el cliente mismo y sus problemas, se convierte en un equipo que toma pedidos limitando su auto organización, crecimiento y motivación hacia un objetivo. Los especialistas de UX no son un equipo separado cuya responsabilidad es descubrir lo que el equipo debe desarrollar, esa labor es responsabilidad de todo el equipo Scrum.
En un proceso empírico no existen etapas, no hay una etapa obligatoria de Discovery o de Research que preceda al desarrollo del Sprint, así como tampoco hay etapas de análisis o diseño, las actividades de descrubrimiento, refinamiento, research son actividades continuas que se deben realizar durante los Sprints. No se tienen que terminar todas las actividades de “Research” para validar todas las suposiciones. En un entorno empírico hay que planificar pensando en lo inesperado, aceptando que las cosas pueden cambiar en cualquier momento y para manejar ese riesgo inspeccionamos y adaptamos continuamente. Esto implica que cada hipótesis puede tener una estrategia distinta de validación, la curva de la verdad es un buen inicio para establecer la forma de realizar los experimentos y validar las hipótesis, podríamos definir experimentos a ser realizados en un día, una semana, dos semanas, un mes u otros espacios de tiempo de diferente manera, pero esto no será necesariamente igual para cada hipótesis y cada experimento permite aprender para definir lo siguiente más valioso a aprender, lo que puede implicar cambiar los experimentos proyectados. El trabajo de UX es emergente y nunca termina.
En Scrum todo el trabajo del equipo de desarrollo es “Development”. Este trabajo puede incluir UX, Arquitectura, codificación, pruebas, Research, etc. Pero nunca deben reflejar etapas predefinidas, el trabajo y el orden necesario deben ser parte de las decisiones del equipo para lograr el Sprint Goal.
El aspecto principal del desarrollo de un producto debe ser el Impacto en el negocio y el “Outcome”. Un “Outcome” es un cambio medible en el comportamiento de un cliente que al suceder permite lograr el impacto en el negocio. Por ejemplo, si una empresa bancaria tiene como objetivo incrementar en 5% las ventas, los Outcomes asociados pueden ser que se incremente el porcentaje de usuarios que usa la aplicación, o que un mayor porcentaje de usuarios realice transacciones, o que los clientes incrementen el envío de transferencias inmediatas.
El Lean UX Canvas facilita la divergencia y convergencia para fomentar la colaboración, co-creación y definir un entendimiento compartido a partir de hipótesis iniciales como un equipo. Estas definiciones no requieren una etapa de research previa ya que el objetivo no es modelar una definición precisa sino empezar a trabajar como un equipo Scrum incluyendo a los especialistas de UX. La principal preocupación de Lean UX no es el diseño de la interfaz de usuario.
Scrum con UX inicia con la definición del problema de negocio y los criterios de éxito de negocio. La estrategia para lograr estos impactos se da a través de los “Outcomes”. Estos Outcomes deben ser medibles continuamente para ir adaptando el trabajo de desarrollo incluyendo la experiencia de usuario. El problema de negocio define el alcance del problema a resolver y le da al equipo el foco y contexto para plantear una solución. El peligro de iniciar la definición de la experiencia de usuario sin tener foco en Outcomes e Impacto es que los experimentos no tengan el contexto de negocio adecuado y se descubran necesidades que no aportan valor al negocio.
Scrum con UX refleja el enfoque Build-Measure-Learn. Este enfoque se logra lanzando continuamente producto y analizando las métricas continuamente orientadas a lograr los Outcomes. Una forma de validar la adopción de producto son las métricas piratas que son métricas para StartUps. Estas métricas se basan en un Outcome e impacto y permiten validar las implicancias de la experiencia de usuario en el uso de producto y validar las hipótesis cuando el producto es lanzado.
El trabajo de “Research” puede hacerse dentro del Sprint y es responsabilidad del equipo de Scrum. Este trabajo puede llevar más de un Sprint pero debe aportar continuamente al objetivo del Sprint. Una forma es ayudar al Product Owner a priorizar, ordenar y refinar el Product backlog. En Scrum todo el equipo es responsable de entregar el incremento de producto. Es importante que los especialistas del equipo Scrum como los de UX realicen coaching, mentoring y enseñen al equipo para que puedan mejorar sus competencias. No hay títulos ni roles en el equipo de desarrollo, todos son miembros del equipo de desarrollo.
El trabajo de UX dentro de Scrum habilita, mejora y potencia la inspección, adaptación y transparencia ayudando a establecer una conversación continua con los clientes incrementando los “feedback loops” siempre con el foco en impacto y en Outcome usando el empirismo y la auto organización. Nadie es dueño de un ítem dentro del Sprint Backlog, todos son responsables de los ítems dentro del Sprint Backlog. En el caso de las entrevistas por mencionar una actividad que usualmente es realizada por los especialistas de UX, estas no deben ser conducidas necesariamente por el Product Owner o estos especialistas de UX, todos los miembros del equipo de desarrollo deberían participar de alguna manera.
El trabajo de UX dentro de Scrum y asociado a una caja de tiempo como el Sprint, ayuda a reducir el riesgo de negocio al permitir validar las suposiciones más importantes y riesgosas para el negocio. Considerar que esta validación nunca termina, aprendemos continuamente del cliente, del mercado, de la competencia, etc. Reducimos el riesgo aprendiendo lo más rápido posible para tomar decisiones sobre lo siguiente más importante a aprender, mientras entregamos incremento de producto en cada Sprint para continuar aprendiendo. Aprender es valioso, pero más valioso es recibir feedback de los clientes cuando usan el producto. La combinación y la distribución del trabajo para definir como aprender y experimentar debe ser decidido por el equipo de desarrollo en conjunto con el Product Owner, teniendo en cuenta que cada hipótesis puede tener un contexto diferente y con ello el tipo de trabajo necesario también puede ser diferente.
Los criterios de terminado en Scrum deben reflejar la calidad del producto. Estos criterios pueden incluir aspectos asociados a UX como que se cumpla como estilos de branding corporativos o incluir aspectos de la organización de desarrollo que se incorporen al producto para mantener la consistencia de la implementación. Los criterios de terminado deben reflejar un producto lanzable al mercado en cada Sprint. Aspectos de los criterios de terminado como desplegado en ambientes y con pruebas realizadas ok son muchas veces necesarias. Sin lanzamiento de producto no hay validación de los Outcomes.
Considerar nuevas formas de describir los Product Backlog Items dentro del Product Backlog como hipótesis o experimentos que reflejan el valor de negocio y que expresen las suposiciones para lograr el impacto y los Outcomes.