Cómo incorporar un design sprint en Scrum

Vamos a hablar de cómo incorporar un design sprint en Scrum, ya que no hay sprints especiales.

Sin Sprint 0, sin sprints de lanzamiento, sin sprints de arquitectura o testing y absolutamente sin sprints de diseño.

Las enseñanzas de Frederik Winston Taylor conducen a una revolución industrial exitosa, pero hoy son inadecuadas para los principales trabajadores del conocimiento que resuelven problemas creativos.

La idea de que necesitamos equipos especializados de codificadores, probadores, operaciones, arquitectos o UX se basa en esas ideas y debe rechazarse por completo.

Como tal, la idea de que necesitaría un Sprint especial para obtener algún resultado especializado también se basa en estas ideas y es antagónica con el resultado deseado del software de trabajo de alta calidad.

Todo el trabajo de los miembros del Equipo de Desarrollo que parecen caer en una especialización (por ejemplo, UX) se realiza en uno de dos lugares.

Actividades que deben completarse dentro del Sprint, orientando el trabajo hacia el Objetivo Sprint actual

Este es el trabajo que cada miembro del equipo debe contribuir durante el Sprint para cumplir con el Objetivo Sprint.

Si bien no hay especialidades, siempre habrá miembros del equipo que tengan más habilidades para ejercer esa actividad en particular.

El equipo de desarrollo debe aprender a aprovechar esas habilidades para construir un mejor producto.

Entonces, si necesitamos reelaborar una interacción o crear una nueva interacción que no sabíamos que necesitábamos, entonces podemos hacer este trabajo en Sprint.

Actividades relacionadas con el trabajo que se entregarán en futuros Sprints

El trabajo para el futuro en Scrum se llama Refinamiento y ocurre constantemente en todo el Sprint.

Si bien queremos minimizarlo como trabajo, no hagamos algo demasiado lejos en el futuro que nunca llegue a la cima de la cartera de pedidos, es un desperdicio.

Necesitamos equilibrar eso con la necesidad de tener todos los bits en su lugar justo a tiempo para que se complete la actividad para el Objetivo Sprint.

Entonces, si necesitamos tener una estrategia UX desarrollada y probada con usuarios reales que incluyan Prototipos, entonces ese trabajo debe hacerse temprano.

No tengas miedo de construir algo lo mejor que pueda, dada la información que tiene, e iterar a medida que obtiene telemetría de usuarios reales.

Todo ese trabajo que es UX se divide en 2 categorías:

Actividades de UX que se realizan dentro del Sprint para las actividades actuales del Sprint

Este es el trabajo del Equipo de Desarrollo con UX incluido en esa definición.

Actividades de experiencia de usuario que pertenecen al trabajo que viene en futuros sprints

Este es un trabajo de refinamiento y se realiza según sea necesario y debe incluir a todo el equipo Scrum según sea necesario.

En última instancia, ningún trabajo debe hacerse en el vacío o lejos del escrutinio de todo el equipo involucrado en el trabajo.

A escala, tiene sentido que una de las actividades requeridas por la Comunidad de Práctica de UX sea reunir a las personas adecuadas para trabajar en la creación de interacciones reutilizables y consistentes como parte de un marco que luego pueda usarse como parte de un DoD de productos.

Este grupo no debe ser dedicado y debe estar compuesto por representantes de todos los equipos para asegurarse de que la información disminuya en el escalado.

Vincular el equipo de equipos y las comunidades de práctica son fundamentales para incorporar todas las habilidades necesarias para crear un software increíble.

Si bien no hay respuestas correctas, hay algunas respuestas que son mejores que otras.

Para su situación dada, seleccione la respuesta más correcta e itere a la mejor versión de la misma. Vaya, inspeccione y adaptase usando Scrum.

Hemos hablado de cómo incorporar un design sprint en Scrum.