Flujo, Cadencias de desacoplamiento y Sprints de longitud fija

Actualización: Creé un video aquí para acompañar esta publicación

Últimamente he estado bajo el fuego por sugerir que los equipos renuncien a los sprints de longitud fija. La desventaja es que los sprints de longitud fija son más apropiados para los equipos menos experimentados, y lo que se conoce como "flujo continuo" es una mejor opción para los equipos de alto rendimiento.

En este post, voy a tratar de llegar al meollo del asunto discutiendo la variabilidad, los objetivos significativos, y "independiente y valioso" frente a "pequeño y comprobable".

Espero mostrar que hay un espectro de enfoques que se pueden usar en conjunto, y que incluso los equipos menos experimentados pueden beneficiarse de la experimentación con lotes de tamaño variable, flujo, extracción Y cadencias fijas . Esta no es una pregunta cualquiera.

Variabilidad

Los Sprints se interrumpen por varias razones: abordar problemas de producción, días de enfermedad, días libres no planificados, reuniones de empresa al azar, problemas con herramientas / tuberías, etc. Junto con la naturaleza impredecible de "el trabajo" y la naturaleza impredecible de "la trabajadores ", y usted tiene muchas cosas que" pueden salir mal ". En cualquier sprint dado, solo mucho está bajo nuestro control (aunque podemos trabajar duro para eliminar impedimentos a lo largo del tiempo).

Esto se complica aún más por las dependencias. "Autoorganizarse" y "multifuncionales" son buenos en teoría, pero pocos equipos, especialmente los que comienzan, tienen ese nivel de autonomía. Entregas a QA, UX compartidos, operaciones compartidas, cumplimiento, cronogramas de clientes, horarios de partes interesadas … ninguna de estas cosas es ideal, pero suceden (mucho más a menudo de lo que quisiéramos).

El punto aquí es que en el mundo real las cosas son complicadas. Hay una gran cantidad de variabilidad, incluso en un sprint corto, y los equipos rara vez actúan en el vacío. Esto puede hacer que los tiempos de pronóstico y los "objetivos de carrera" sean extremadamente difíciles. Tanto para equipos principiantes como experimentados, especialmente con dependencias, esto se convierte en una dura prueba de Sísifo. Una respuesta es hacer el sprint aún más corto … y voy a llegar a eso a continuación.

Objetivos Significativos e Incrementos de Producto

Los objetivos significativos no siempre vienen en la misma caja ordenada de N-semana / día. Claro que puedes "rellenar" artificialmente un objetivo para hacerlo más grande, y reducir el objetivo para hacerlo más pequeño, pero a veces necesitarás tres días (o tres horas) para validar una suposición importante, y en ocasiones necesitarás quince días para unir un flujo de trabajo complejo. Así es como es. A menudo veo que los equipos cocinan metas "falsas" (sus palabras) debido a las limitaciones del horario.

Como todas las historias son independientes, incluso los objetivos "falsos" estarán bien … ¿no? El valor aún se entrega, incluso si el equipo no logra "el objetivo". Hmmm. Ese sería el caso si todas y cada una de las historias fueran independientes con respecto al objetivo de Sprint. Sin embargo…

Aquí hay un espectro cuando se trata de "Independiente" y "Valioso" en INVEST. Una historia puede ser independiente y valiosa desde el punto de vista del aprendizaje, y ayudar a un usuario a lo largo de un flujo de trabajo, pero no es independiente desde el punto de vista de un objetivo significativo. Aquí es donde el Yo y el V pueden entrar en conflicto con lo Pequeño y Testable. Sería maravilloso si cada historia de usuario representara un objetivo de usuario orientado a resultados (u objetivo de negocio) de extremo a extremo, pero a menudo no funciona de esa manera.

La Guía de Scrum describe el sprint de longitud fija como un tipo de proyecto de longitud fija:

Cada Sprint puede considerarse un proyecto con un horizonte no mayor a un mes. Al igual que los proyectos, Sprints se utilizan para lograr algo. Cada Sprint tiene una meta de lo que se construirá, un diseño y un plan flexible que guiará su construcción, el trabajo y el incremento resultante del producto.

Operativo aquí es la idea de "lograr algo", que es genial en teoría. Lo que sucede en realidad, sin embargo, es que los equipos comienzan preguntando "cuánto podemos hacer en [la duración del sprint]". Ellos "llenan" el sprint, en lugar de comenzar desde un "incremento de producto resultante" hacia atrás. El argumento es que 1) si todo es valioso e independiente, 2) todo está ordenado, 3) hay un historial de velocidad, y 4) hay transparencia … bueno, todo saldrá bien, y si algunas cosas quedan "sobrantes" al final … no es gran cosa.

¿Qué pasa después en la práctica? Un sprint finaliza sin un incremento de producto resultante (o un incremento que realmente no alcanza la meta), hay una gran cantidad de canciones y bailes mientras que las historias se "lanzan" al siguiente sprint y un nuevo objetivo: una extraña amalgama de el objetivo anterior y un nuevo objetivo: está establecido.

Trabajo pequeño vs. "valor"

Una vez más, existe una tensión entre los beneficios de trabajar pequeñas historias pequeñas, integrando y demostrando con frecuencia, y entregando en producción con frecuencia, y entregando valor (a diferentes escalas y resoluciones). Los sprints cortos son extremadamente valiosos ya que nos ayudan a inspeccionar / adaptar / integrar / realidad con más frecuencia. Pero no siempre podrás encajar metas significativas en esa caja de tiempo. Lo que ejerce presión sobre los equipos para que amplíen el intervalo de tiempo … lo que da como resultado carreras de velocidad demasiado largas.

Aquí está mi opinión. Estamos hablando de dos cadencias diferentes: los objetivos significativos (los valiosos incrementos de producto) Y los ciclos de retroalimentación valiosos, apretados y frecuentes … que son muy valiosos, pero no del mismo tipo. No hay forma de que una sola longitud de iteración fija pueda acomodar la variedad de objetivos significativos. A veces estamos haciendo un montón de pequeñas optimizaciones. A veces estamos probando la viabilidad central de un nuevo producto. A veces pivotamos día a día.

Resumen hasta el momento

Para resumir.

  • Nos encontramos con una gran cantidad de variabilidad (incluida la variabilidad que está fuera de nuestro control).
  • Nuestros objetivos significativos a menudo no se alinean con nuestras historias independientes y valiosas. Ambos son importantes.
  • Los objetivos significativos no vienen todos en el mismo tamaño / forma
  • Hay beneficios increíbles para "trabajar en pequeño", y hay beneficios sorprendentes para tener un objetivo significativo (y flexible).
  • Hay beneficios increíbles para inspeccionar y adaptar con frecuencia.

Escenario híbrido

¿Cómo podría un equipo abordar estos desafíos? Usaré los acuerdos de trabajo de un equipo real:

El equipo:

  1. tiene una lista priorizada de objetivos significativos (la acumulación se describe en objetivos, no en historias individuales)
  2. establece metas significativas que duran entre 1 día y 30 días (el equipo acuerda una duración máxima de 30 días, después de lo cual se vuelve a evaluar el objetivo completo)
  3. aborda estos objetivos en serie en una base de atracción (uno a la vez, comenzando un objetivo solo después de que se haya logrado el último objetivo)
  4. visualiza las dependencias tal como son y visualiza el impacto de las interrupciones no planificadas (por ejemplo, problemas de producción)
  5. pronostica la duración de "objetivos significativos" usando datos históricos (especialmente útil si hay mucho ruido, interrupciones, dependencias, etc.)
  6. aborda la planificación de objetivos en una base just-in-time (mapas de historias, etc.)
  7. limita el tamaño de la historia individual a <3 días con emparejamiento frecuente
  8. se reúne semanalmente para realizar una retrospectiva y discutir el progreso
  9. obtiene un nuevo trabajo en producción detrás de una bandera de función semanal (automatizada, semanal)
  10. lleva a cabo demostraciones y pruebas de usabilidad siempre que sea posible (usando etapas y / o producción)

Este es un híbrido. Algunas cosas suceden semanalmente, algunas cosas suceden justo a tiempo, y algunas cosas suceden en lotes automatizados y "siempre que sea posible" (por ejemplo, el tren de lanzamiento semanal y las pruebas frecuentes).

¿Por qué? Beneficios …

¿Que está sucediendo aquí? Los sprints de longitud fija son un tipo de juego. Juegas el juego, y hay beneficios para jugarlo. El equipo puede llegar tan lejos, y si lo haces "por el libro" terminarás con un incremento de producto liberable al final de cada carrera. Si te quedas corto, bueno, todo fue independiente de todos modos (con suerte). O simplemente lanzas cosas al siguiente sprint.

Hay habilidades involucradas para hacer que funcionen. Pero, sinceramente, también hay mucha suerte en juego. También pueden, en algunos casos, oscurecer lo que realmente está sucediendo, especialmente cuando usted es parte de un sistema más grande, tiene dependencias y es responsable de un sistema de producción.

El modelo que compartí arriba goza de algunos de los elementos de los sprints de longitud fija. Pero en lugar de la canción y el baile al final de cada carrera, el equipo se centra en los objetivos que importan. Al mismo tiempo, y esto es importante, también se comprometen a trabajar a pequeña escala y con frecuencia inspeccionar, adaptar y probar. Cuando se ven afectados por una variabilidad inesperada, siguen adelante y trabajan en la mejora continua para minimizar esas interrupciones.

Trabajar en pequeño + Trabajar con sentido + Inspeccionar / Adaptar.

Para concluir

No digo que los sprints de longitud fija sean malos. Ellos pueden trabajar para usted. De hecho, digamos que decidió hacer un lanzamiento mensual de "algo nuevo". Bueno, está tu incremento fijo. ¡Pero un mes es mucho tiempo! Por lo tanto, aún así se beneficiaría de trabajar pequeñas, retroactivas semanales y, tal vez, funciones de demostración / publicación justo a tiempo (tan a menudo como sea posible) para un% de clientes.

Mi punto es que no es ni o. Debe tener en cuenta que no todos los equipos hacen Scrum según el libro con sprints de longitud fija, retrocesos al final de cada sprint y planificación de una cadencia, etc. Existe un amplio espectro de enfoques que podrían funcionar para usted.

Hagas lo que hagas:

  1. Visualiza tu trabajo como realmente sucede
  2. Inspeccionar y adaptar
  3. Trabajo pequeño
  4. Integrar e inspeccionar / adaptar con frecuencia
  5. Y hacer un trabajo significativo / valioso