Más allá del Sprint 0: una alternativa para integrar equipos

Scrum es la metodología de gestión de proyectos más popular del mundo con más del 72 % de los equipos que utilizan Scrum o un híbrido de scrum. Es muy probable que, si trabaja en desarrollo web, esté utilizando Scrum de alguna forma.

Una tendencia actual en Scrum es el “Sprint 0” o su primo más artístico el “Design Sprint”. Mucho se ha escrito sobre si estos son verdaderos sprints (no lo son), pero se ha dicho menos sobre por qué existen en primer lugar, por qué se quedan tan tercamente y qué alternativas existen.

Personalmente, amo Scrum y siempre estoy buscando formas de mejorar gradualmente la forma en que lo implemento. En este artículo, me gustaría compartir los métodos que incorporé a mi flujo de trabajo y uno que encuentro útil cuando fusiono UX/UI y desarrollo, así como también para crear visiones de proyectos más sólidas.

Algunas definiciones rápidas antes de comenzar:

• carrera 0
  El esfuerzo inicial de un equipo para crear los documentos guía necesarios para los proyectos de scrum: una visión, una acumulación de productos y estimaciones de lanzamiento de productos.
• Sprint de diseño
  El esfuerzo inicial de un equipo para crear un diseño guía para el resto del lanzamiento.
  

Por qué Sprint 0 y el Design Sprint existen

Está muy bien decir: "Sprint 0 no es un sprint real, no lo hagas". Pero estas adaptaciones de sprint-ish existen por una razón. Muchos equipos los adoptan porque su proyecto tiene una necesidad insatisfecha más allá del alcance inmediato de Scrum. Mi observación es que Sprint 0 y los sprints de diseño se usan con mayor frecuencia para abordar las siguientes situaciones:

1. Falta de una fuerte visión orientadora;
2. Falta de integración del diseño en el flujo de trabajo de desarrollo.

El proceso Scrum asume que el propietario del producto ha desarrollado y comunicado una visión clara. Pero levante la mano si ha trabajado en proyectos donde la visión es débil, incorrecta o invisible. ¡Yo también! Sprint 0 es un intento del equipo de desarrollo de llenar el vacío de visión. No es la peor idea, así que ¿cuál es el problema? Desde una perspectiva ágil, Sprint 0 no es iterativo, no utiliza los talentos de todo el equipo y ofrece resultados confusos. Y antes de señalar: "Oye, el verdadero problema aquí es que los equipos de scrum no deberían tener que hacer el trabajo del propietario del producto", en realidad creo que un equipo ágil interdisciplinario es uno de los mejores entornos para desarrollar un equipo sólido y realista. visión y objetivos.

Propongo un método más ágil para construir una visión que he usado con éxito en proyectos sin traspaso. Exploraré ambas situaciones en las que se utilizan estas adaptaciones similares a las de un sprint y describiré cómo este primer sprint alternativo admite mejor el flujo de trabajo ágil.

Visión y el prototipo Sprint

En la primera situación, donde hay una falta de visión sólida, la documentación guía o las ideas son demasiado débiles para realmente comenzar un proyecto Scrum. Para cualquier proceso (incluido Scrum), necesita orientación antes de comenzar el viaje. Agile es excelente para descubrir la mejor manera de alcanzar un objetivo, pero generar la visión inicial no está dentro de su alcance. De hecho, lo que falta en Scrum es una descripción de la visión requerida para que comience el proceso de desarrollo. Ya sea que se trate realmente de Scrum o no, Sprint 0 es solo un equipo web en primera línea, que usa las herramientas que tienen, tratando de descubrir qué deben hacer antes de comenzar a hacerlo.

El inconveniente real de Sprint 0 es que construir el documento guía para el proyecto en el momento en que se tiene la menor cantidad de información proporciona poco valor al proceso de desarrollo que sigue.

Las visiones de proyectos rectores que no se alinean con la realidad emergente iterativa deben pasar por el costoso proceso de otro Sprint 0 o, más a menudo, simplemente se ignoran.

Una mejor alternativa es el prototipo de sprint: un primer sprint que involucra a todo el equipo mientras construye el prototipo inicial en sí.

El Proceso Prototipo Sprint Vision

Las ideas de la lluvia de ideas se traducen en un prototipo de baja fidelidad visual que funciona lo más rápido posible. El prototipo está escrito en un marco HTML y CSS de front-end funcional, es decir, el lenguaje compartido del equipo. No todo el mundo puede entender una hoja de especificaciones o una declaración de visión. Todo el mundo puede entender un sitio web y la comunicación es más fácil e incorpora una gama más amplia de disciplinas.

Al final del primer sprint, el prototipo está listo para las pruebas iniciales en varios frentes, incluida la usabilidad general, la accesibilidad y la capacidad de respuesta móvil. En mis equipos, este es un incremento hecho válido e importante. El prototipo de sprint también produce una cartera de productos inicial. A medida que los elementos de la cartera de pedidos se completan en futuros sprints, el prototipo gana en fidelidad. El prototipo no es un código desechable, es fundamental.

En algunos proyectos, se genera una visión escrita a medida que se produce el prototipo. Pero en muchos proyectos, el prototipo es la visión. Habla en el idioma compartido del equipo y, por supuesto, nunca está fuera de sintonía con el producto.

Ejemplo

El siguiente ejemplo es de un prototipo de trabajo para una aplicación de comercio electrónico, completado a partir del esquema general en la RFP inicial. A pesar de lo tosco que es, fue fundamental para concentrar las energías del equipo en una dirección productiva, saltando muchas posibles distracciones y escollos para enfocarse en criterios funcionales.

Un prototipo inicial a menudo dará como resultado cambios en los requisitos, que son simplemente las mejores conjeturas hasta que se muestran a la luz de la experiencia del usuario. Como ejemplo, una de las ideas que obtuvimos del sprint prototipo que se muestra arriba es que el precio y el botón "comprar" originalmente estaban demasiado bajos en la página. La solicitud inicial fue colocarlos debajo de la información del producto y arriba de las recomendaciones, pero un prototipo funcional mostró rápidamente que la jerarquía no era muy funcional.

Otra funcionalidad que salió a la luz fue que originalmente se solicitó que las imágenes de la galería fueran grandes y se extendieran por todo el ancho de la página. En lugar de exponer razones hipotéticas a las partes interesadas por las que eso no funcionaría, el prototipo pudo demostrar los problemas en un idioma compartido que todo el equipo entiende. En una sesión de poder con las partes interesadas, reorganizamos rápidamente esta página a una jerarquía acordada universalmente.

Debido a que el prototipo nace accesible y receptivo, podemos comenzar a probar en múltiples dispositivos y tecnologías de inmediato. Aunque el diseño (si es que se le puede llamar así en esta etapa temprana) se mantiene intencionalmente en baja fidelidad, se hizo evidente de inmediato que la mensajería del conmutador de año en el escritorio era demasiado grande en el móvil e interfería con la usabilidad (izquierda). Rápidamente actualizamos el prototipo para usar un conmutador más pequeño en el encabezado (derecha).

Algunos otros problemas salieron a la luz rápidamente durante este sprint de prototipo:

• El cliente, después de hacer clic en la navegación funcional, se dio cuenta de inmediato de que se había perdido un componente funcional importante en su especificación: un blog. Esto afectó la estimación y el tiempo, pero pudimos ajustarnos rápidamente.
• Era evidente para el equipo de interfaz de usuario que la visualización de precios era demasiado compleja y confusa. Exploramos otras posibilidades con el cliente y pudimos crear rápidamente prototipos y probar varias soluciones durante el sprint del prototipo.

En lugar de que la visión sea potencialmente un impedimento o se vuelva obsoleta tan pronto como comience el desarrollo, en un sprint de prototipo, la visión y los criterios funcionales se desarrollan juntos y se apoyan mutuamente. Y debido a que la visión es generada por el equipo, no hay traspaso al equipo y evita fácilmente ese período riesgoso en el proceso de desarrollo.

El diseño y el prototipo Sprint

En la segunda situación, la falta de integración del diseño con el desarrollo, es a menudo cuando verá que se utiliza un "diseño rápido". Esta dirección me parece aún más contraproducente que un Sprint 0. Los desafíos de integrar el diseño en un proceso de desarrollo complejo son reales, pero un Sprint de diseño es un enfoque contraproducente. El sprint de diseño es una curita para el síntoma, el desafío de construir equipos integrados, pero no aborda el problema subyacente, el desafío de comprender y satisfacer las necesidades de los usuarios. La carga frontal del diseño en un sprint evita el desafío de la integración, pero los beneficios de un proceso de diseño integrado e incremental y la ventana que abre para comprender y llegar a los usuarios se pierden por completo.

El prototipo de sprint que uso en proyectos sin traspaso es una alternativa productiva y completamente ágil al sprint de diseño. Es colaborativo y combina UI/UX y desarrollo desde las primeras etapas del proyecto. Incluso el equipo de diseño más experimentado puede beneficiarse de la participación de otras disciplinas y, lo que es más importante, garantiza que los objetivos del código y del diseño no se contrapongan.

A menudo, también se espera que el diseño sprint desarrolle la visión. Este es un movimiento desesperado basado en una comprensión vaga pero perspicaz de que el proceso de diseño está mejor equipado para generar visión que desarrollo. Sin embargo, una visión generada por el diseño es un pobre sustituto de un esfuerzo real, colaborativo y de todo el equipo.

Los diseñadores deficientes tienen que generar un producto final para impulsar el desarrollo sin la información interdisciplinaria necesaria para que ese esfuerzo sea realmente valioso. Aunque un diseñador con conocimientos técnicos y más experiencia tendrá más posibilidades de hacerlo bien, sigue siendo muy arriesgado. Sin ningún producto potencialmente entregable al final de la fase para probar contra las conjeturas, continúa el desarrollo. Si el diseño no dio en el blanco, o si las especificaciones cambian, puede ocasionar largas demoras a medida que regresa al equipo de diseño. Agile es, en esencia, un proceso de gestión de riesgos, y podemos hacerlo mejor que comenzar nuestros proyectos ágiles con un sprint de diseño inherentemente arriesgado.

El proceso de diseño de prototipos Sprint

El cambio más importante con respecto a un sprint de diseño más tradicional es que durante el sprint de prototipo, el equipo pasa directamente del papel al prototipo y omite el uso de Sketch, InVision, Photoshop u otros programas de diseño digital. Actúan como una muleta visual en esta etapa y parecen aportar valor muy rápidamente (porque los buenos diseñadores hacen cosas atractivas), pero el valor real de una maqueta de alta fidelidad tan temprana es muy bajo, mientras que el peligro potencial que presenta: casar a las partes interesadas con las soluciones equivocadas es alto.

Estas herramientas son mejores en maquetas planas de alta fidelidad, pero el prototipo inicial no es ni de alta fidelidad ni plano. La pizarra, el lápiz y el papel permiten que el equipo trabaje con ideas rápidamente sin estar atado a ellas. Luego convierta ese pensamiento en un prototipo funcional lo antes posible.

Todos los miembros del equipo, incluidos los diseñadores, deben familiarizarse con el prototipo y poder trabajar en él directamente durante las fases de baja fidelidad. Pero si eso no es posible (o es un objetivo a más largo plazo y necesita avanzar ahora), entonces es bueno un enfoque combinado en el que un diseñador y un desarrollador trabajen juntos. Los bocetos pueden ser descritos por el diseñador e interpretados por el desarrollador juntos, ampliando su comprensión compartida de cada punto de vista.

Ejemplo

El siguiente ejemplo muestra nuestro proceso de destilación de un análisis en profundidad de un sitio web existente directamente en un prototipo funcional. Permitió evaluar los hallazgos del informe en un entorno web nativo, una experiencia muy diferente al análisis intelectual de las recomendaciones en un documento impreso:

Además, a diferencia del documento de análisis en profundidad (tan útil como fue), el prototipo funcional está libre de jerga y utiliza un lenguaje verbal y visual compartido que todos pueden entender. Abre la conversación en pantalla visual a todos los miembros del equipo y disciplinas.

Nuestra pregunta principal al crear esta plantilla fue cuántos detalles de diseño incluir. Debido a que teníamos un documento rico y lleno de análisis para extraer, podríamos haber llevado el prototipo más allá. Pero, teniendo en cuenta que las imágenes pueden pasar rápidamente (y sin querer) del ámbito de la idea al ámbito de los hechos, mantuvimos el diseño sin compromisos y destilamos el documento a sus elementos esenciales y su significado.

Las pruebas internas nos llevaron al estadio de béisbol de una solución más centrada en el usuario, superando muchos problemas potenciales, pero evitamos conscientemente tomar decisiones de diseño refinadas tan temprano en el proceso. Es importante sopesar continuamente todas las ideas y sugerencias, incluidas las del cliente, con los datos conocidos y recordar que nuestro conjunto de conocimientos es más pequeño en este punto que en cualquier otra etapa del proyecto.

Otra razón por la que es fundamental mantener el prototipo inicial de baja fidelidad y no incluir ningún elemento de "diseño" es que la aceptación del equipo puede descarrilarse debido a elementos visuales irrelevantes que provocan reacciones viscerales no deseadas. Nos alejamos del color y ni siquiera incluimos el logotipo del cliente (en su lugar, usamos un espacio en blanco o un cuadro gris claro como marcador de posición). La conversación debe orientarse continuamente hacia criterios funcionales como la jerarquía del contenido, la accesibilidad, la usabilidad, el lenguaje y el significado. Asegúrele al equipo que las "cosas divertidas" llegarán, pero no en esta etapa inicial.

De hecho, un objetivo importante de un sprint de prototipo exitoso es tomar la menor cantidad posible de decisiones de diseño por adelantado. El diseño exitoso se alimenta de la experiencia del usuario, por lo tanto, permita tiempo para que el conocimiento emergente del proyecto informe la interfaz de usuario.

¿Cuándo se completa el Prototype Sprint?

El sprint se completa cuando el prototipo y los artefactos que lo acompañan son aprobados por todo el equipo (incluido el cliente), y el prototipo se considera listo para las pruebas iniciales de usabilidad y accesibilidad.

Un prototipo funcional temprano da vida a la visión del proyecto a través de la escala (número de páginas, alcance de la navegación y otros elementos principales de la interfaz de usuario), la complejidad futura (contenido de marcador de posición con descriptores útiles, posiblemente alguna funcionalidad temprana codificada) y la identificación de necesidades (tecnologías específicas necesarias , dónde se implementarán, cualquier dependencia). Las decisiones con respecto a las herramientas, el entorno de trabajo y la pila de código se tomarán con el aporte de todo el equipo.

Alcanzar este incremento de hecho puede tomar tan solo un día para un equipo experimentado con un cliente receptivo, pero generalmente dura alrededor de una semana y no más de dos semanas. Los sprints de prototipos deben moverse a un ritmo rápido y superar el marco de tiempo de dos semanas puede ser una señal de alerta. Puede significar que hay otros problemas en juego.

Algunos problemas comunes a tener en cuenta durante un prototipo de Sprint

Algunos problemas comunes a tener en cuenta al implementar el prototipo de sprint incluyen:

• Adopte el valor de la baja fidelidad y evite enfatizar las imágenes. Esté atento a este punto, ya que los equipos que son nuevos en este enfoque pueden necesitar ayuda y tranquilidad a medida que avanzan más allá de "dónde está el logotipo" y se centran en cuestiones más profundas de funcionalidad y jerarquía.
• Una faceta diferente de lo anterior, también esté atento a no apegarse a sus propias ideas de diseño/diseño. Es útil recordar durante los sprints de prototipos que no se está generando nada valioso y permanecer desconectado de los resultados finales. Además, es otra razón más para mantener los prototipos mínimos y, francamente, bastante feos. Tiene el propósito de mantener a los usuarios separados.
• La aceptación temprana del proceso por parte del liderazgo es fundamental . Debido a que todo el equipo está involucrado, su cliente, su jefe y los desarrolladores deben apoyar y nutrir el proceso con su compromiso, creatividad y tiempo. ¡No seas una animadora solitaria, todo tu equipo necesita agitar sus pompones!
• La mala comunicación es el talón de Aquiles de todo trabajo en equipo . El prototipo de sprint no resolverá los problemas de comunicación persistentes, pero los sacará a la luz más pronto, ya que todo el equipo se sumerge en un flujo de trabajo colaborativo casi de inmediato. Cualquier problema de comunicación ya existente surgirá temprano y, a menudo, en un sprint de prototipo a medida que trabaja hacia el consenso y su primer incremento realizado. Aproveche la oportunidad de mejorar la comunicación e involucre a todo el equipo en la búsqueda de soluciones.
• Elija el marco frontal correcto . Si aún no tiene uno, es posible que deba probar varios marcos front-end antes de encontrar uno que encaje con el flujo de trabajo de su equipo. Recomiendo buscar marcos mínimos como Fomantic o Bulma y no empantanarse con campanas y silbatos. Sin embargo, el marco correcto siempre es el que funciona para su equipo.
• El equipo de UI/UX necesita desarrollar un nivel de comodidad y acceso al marco frontal. Idealmente, trabajarán directamente en el prototipo, evitando transferencias innecesarias y la necesidad de traducir de un medio a otro (es decir, de Sketch al prototipo). Si su equipo front-end no está familiarizado con CSS y HTML, entonces un enfoque combinado (con un diseñador y un programador trabajando juntos en el marco) también funciona bien.
• Por último, pero no menos importante, ¡recuerda que mejorarás y serás más rápido como equipo ! Ejecutar un sprint de prototipo productivo es una habilidad que crece con la práctica.

Qué sucede después

El incremento realizado del primer sprint, el prototipo funcional de baja fidelidad, prepara el escenario para todos los sprints que siguen. Con un prototipo en funcionamiento, las pruebas de usabilidad, accesibilidad y capacidad de respuesta pueden comenzar de inmediato, lo que garantiza que los sprints futuros estén informados por UX.

El prototipo de sprint es un gran comienzo para cualquier proceso de scrum, pero en mis proyectos, nuestro siguiente paso es pasar a un flujo de trabajo de doble vía donde UI/UX funciona la mitad o todo el sprint antes del desarrollo, descubriendo y actualizando visualmente el prototipo para reflejar nuevas percepciones.

El prototipo se desarrolla orgánicamente y se vuelve cada vez más refinado, alimentado por la investigación de UX y necesidades funcionales realistas. Esa información, que no está disponible durante el sprint del prototipo, solo emerge gradualmente a medida que avanza el proyecto. UI/UX y el desarrollo se alimentan de los flujos de trabajo de cada uno a través del proceso ágil de doble vía.

No hay traspaso del diseño al desarrollo para construir, o una aplicación desarrollada para diseñar a la piel. En cambio, el sprint del prototipo involucra a todo el grupo desde el principio y forma una base sólida para un flujo de trabajo ágil y colaborativo a lo largo del proyecto.

La visión guía que resulta de un sprint de prototipo no será perfecta y probablemente cambiará a medida que se aprenda más, pero el reconocimiento de que sabemos menos al principio que en cualquier otra fase de un proyecto es el corazón del flujo de trabajo ágil. Cuando aplicamos esta misma filosofía al surgimiento de la visión y el diseño del proyecto a través de un sprint de prototipo, el resultado es un incremento accionable, artefactos genuinamente útiles, aceptación compartida y un patrón de trabajo en equipo y colaboración que puede mantenerse a lo largo del proyecto. .

Una nota sobre la configuración de la agencia

Si trabaja en una agencia, es posible que esté pensando que este enfoque será difícil de vender. Desafortunadamente, probablemente tengas razón. Muchas agencias son intrínsecamente poco ágiles y luchan activamente por la transferencia total del proyecto, a menudo con aprobación oficial y repercusiones cuidadosamente documentadas para realizar cambios en el futuro. Abogar por un prototipo de sprint en una organización no ágil es imposible: simplemente no está en su ADN. Una vez que una organización adopta equipos ágiles e interdisciplinarios, puede considerar fácilmente si el prototipo de sprint sin traspaso mejorará su proceso.

Conclusión

Sprint 0 y los sprints de diseño abordan desafíos reales que enfrentan muchos equipos de scrum: falta de visión, falta de diseño integrado o ambos. Son respuestas comprensibles y lógicas, pero no brindan un gran valor ni contribuyen a equipos ágiles fuertes.

Reemplazarlos con un prototipo de sprint es una forma práctica de abordar los inconvenientes de Sprint 0 y diseñar sprints y, al mismo tiempo, sentar las bases para una colaboración ágil más fuerte durante futuros sprints.

Un sprint prototipo utiliza los talentos de todo el equipo, genera la visión necesaria, da como resultado el primer incremento del equipo y evita la transferencia del proyecto. A través de este proceso, los equipos construyen una propiedad compartida de la visión del proyecto y una base más sólida para la cooperación interdisciplinaria en el espíritu ágil.

Lectura adicional en SmashingMag:

• Convertirse en un mejor facilitador
• Adaptación de Agile para equipos a tiempo parcial
• La importancia de las retrospectivas de proyectos
• Llevando un mejor proceso de diseño a su organización