La agilidad provee un contexto para el aprendizaje continuo. Scrum a través del uso de Sprints, eventos y valores de Scrum crean un espacio para que ese aprendizaje pueda tener lugar. El diseño UX aporta técnicas, herramientas y las bases para integrar el aprendizaje en la entrega de software. En Scrum el reto es entregar un incremento de producto con valor y mejorar el aprendizaje de los clientes a través de lanzamientos continuos durante el Sprint balanceando el trabajo de descubrimiento y de entrega de producto para lograr el objetivo del Sprint. Los valores y pilares de Scrum y el empirismo proveen un entorno ideal para la experimentación continua en cada Sprint. El Product Backlog provee visibilidad y transparencia e idealmente el trabajo de UX puede ser asociado dentro de cada Product Backlog Item para evitar crear silos al tener un backlog de UX y un backlog de desarrollo por separado. El Equipo Scrum es un equipo multidisciplinario considerando en este caso las competencias de UX dentro del equipo.
En algunas ocasiones se podría entender que los especialistas de UX son los únicos responsables que descubren las necesidades de los clientes, definen las soluciones propuestas, las validan y luego entregan los requerimientos a los equipos para su desarrollo, pero 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 forma colaborativa.
En un proceso empírico no existen etapas, no hay una etapa obligatoria de descubrimiento o de investigación que preceda al desarrollo del Sprint, así como tampoco hay etapas de análisis o diseño, las actividades de descubrimiento, refinamiento, son actividades continuas que se deben realizar durante los Sprints. No se tienen que terminar todas las actividades de descubrimiento o de investigación para recién luego de ello iniciar los Sprints.
En Scrum todo el trabajo del equipo es para producir un incremento de producto. Este trabajo puede incluir trabajo de UX, arquitectura, codificación, pruebas, descubrimiento, etc. No hay etapas predefinidas en un Sprint, el trabajo y el orden necesario deben ser parte de las decisiones del equipo para lograr el Sprint Goal.
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 en el negocio es que los experimentos no tengan el contexto adecuado y no se descubran necesidades que aportan valor.
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 o cambios en el comportamiento de los clientes que generen valor.
El trabajo de investigación y descubrimiento es parte de las actividades que se hacen durante el Sprint y es responsabilidad del equipo de Scrum. Es importante que los especialistas del equipo Scrum como los de UX realicen coaching, mentoría y enseñen al equipo para que puedan mejorar sus competencias. 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 especialistas de UX, todos los miembros del equipo de desarrollo deberían participar de alguna manera.
Aprender con experimentos sin producto es valioso, pero no es suficiente, es necesario recibir comentarios 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 Scrum, 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.
Les comparto el enlace donde pueden adquirir mi libro Notas de Scrum Profesional: https://www.amazon.com/dp/B082S26DLH
Pueden ver la siguiente programación de los cursos oficiales que brindo en:
https://www.discoveryfast.com/certificaciones
Me pueden contactar en jfrancia@discoveryfast.com
Te invito a mi siguiente Webinar sobre las Posturas del Product Owner:
https://www.scrum.org/resources/spanish-edition-scrum-pulse-posturas-del-product-owner-product-owner-stances