¿Cómo se puede inculcar una cultura de pirateo o sprint dentro de un equipo de desarrollo sin correr el riesgo de agotamiento?

En la mayoría de los lugares donde he trabajado, los equipos no son la fuente de la mayoría de las dificultades para llegar a resultados antes. Por lo general, es el sistema en el que trabajan los desarrolladores lo que causa más demoras, más errores y más tiempo entre la implementación.

Mire su sistema, las políticas y procesos en torno al equipo. ¿Es un camino de tierra o una carretera suave? Transformación ágil: vaya más rápido, pero no por la razón que piensa

Hay algunas buenas respuestas aquí, pero no abordan totalmente la pregunta.

La cultura se inculcará si logra la aceptación del equipo y las partes interesadas.

Hay muchas maneras de alentar la compra utilizando métodos ágiles, pero creo que está fuera de este alcance.

Eso nos lleva a evitar el agotamiento,

• Fomentar un ritmo sostenible
• Tenga sprints de IP (innovación y planificación) donde las tareas que se han desbordado de sprints anteriores puedan ponerse al día.
• Dar prioridad a las tareas de mantenimiento y cosas que los desarrolladores ven como valiosas, no solo centradas en los requisitos de los clientes.
• Revise que sus técnicas de estimación son el equipo sobre la estimación de cuánto pueden entregar de manera realista con la calidad requerida.
• Revise las expectativas de sus clientes: ¿son realistas o demasiado ambiciosos y, en última instancia, perjudican su negocio?
• Revise sus comunicaciones con los clientes si está haciendo compromisos que son muy difíciles de cumplir
• Aumente su ciclo de entrega pero disminuya su alcance de lanzamiento.
• Mapa de flujo de valor y busque retrasos que perjudiquen a sus equipos y causen estrés regularmente

Esperemos que estas ayuden

Buena suerte

Oliver Dolan

Veo tres temas importantes de la consulta aquí: longitud de iteración, velocidad y cultura. Me gustaría abordarlos, según mi experiencia, antes de abordar los detalles específicos de la consulta en sí.

Iteración / longitud del sprint. En gran medida, hay 3 parámetros que deciden la duración ideal de su iteración

1. ¿Cuánto tiempo puede el propietario del producto (PO) después de dar una historia de usuario y antes de ver la demostración? El PO idealmente quisiera verlo lo antes posible.
2. ¿Qué tan pronto puede el equipo de desarrollo demostrar una característica después de comprometerse con el PO? Idealmente, al equipo le gustaría tomar el mayor tiempo posible.
3. ¿Cuál es el período mínimo de tiempo en el que el alcance acordado para la iteración se mantiene constante sin cambiar?

Por lo tanto, la duración de una iteración es un compromiso alcanzado a partir de estos factores que beneficia a todos. Uno tiende a realizar iteraciones más cortas cuando la probabilidad de un cambio en el alcance es alta. Del mismo modo, una iteración de un mes no es necesariamente mala si satisface todos los parámetros anteriores.

Velocidad. La velocidad del equipo depende tanto del equipo como del resto de la organización. Inicialmente, la velocidad mejora a medida que los equipos confían cada vez más en los métodos ágiles que practican y a medida que se vuelven más precisos con sus estimaciones. Pero después de esto, la velocidad aumenta al “suavizar el camino”, es decir, al eliminar más y más impedimentos que ralentizan al equipo, al invertir más en las herramientas y prácticas que suavizan y aceleran el flujo desde el concepto hasta el despliegue y la retroalimentación. Por lo tanto, la velocidad se ve afectada tanto por el equipo como por la integración del equipo con el resto de la organización.

Cultura. Esto es más vago y difiere en cada organización, pero tiene algunos elementos comunes y muy poderosos: un compromiso de colaboración, apertura y retroalimentación honesta, un compromiso con la adaptabilidad y, en general, un compromiso con los principios del manifiesto Agile. Por lo tanto, la cultura juega un papel importante en la mejora de la productividad del equipo y cualquier error también lo obstaculizará dramáticamente.

Ahora, cómo ajustar estos parámetros para obtener un equilibrio depende de usted. Es probable que lo beneficie solo mientras sea sostenible. Más importante aún, esto es sostenible solo si tiene la aceptación del equipo y de la organización. Cualquier cosa que simplemente “caiga desde arriba” no tendrá éxito y también puede causar daños graves.

Ahora llegando a su consulta específica. Me gustaría enumerar algunos puntos que puede considerar.

• Dices que quieres mantener sprints de 1 semana y también propones que el lunes sea un día de pirateo cuando el equipo trabaja en ” algo” fuera del ámbito normal de lo que nos estamos enfocando; Una nueva idea, independiente de las otras áreas de enfoque del negocio. “. Por lo tanto, supongo que ahora le quedan 4 días para que el equipo tenga que volver a enfocarse en ” el ámbito normal de lo que nos estamos enfocando ” y usar los 4 días para planificar, hacer, hacer una demostración y retrospectiva. Esto me suena muy preocupante.
• ¿Por qué querrías que un equipo haga dos cosas radicalmente diferentes en un lapso de solo 40 horas (5 días hábiles)? Algo el lunes y algo más por el resto de una iteración ya corta.
• ¿Por qué desea que los equipos se centren en áreas que son ” independientes de las otras áreas de enfoque de la empresa? “? Puedo estar equivocado, pero esto parece prioridades fuera de lugar y hacer un trabajo que claramente no agrega valor. Sin embargo, puede crear equipos diferentes para trabajar en esas prioridades a largo plazo, en lugar de molestar a los equipos existentes que ya están trabajando en prioridades comerciales clave.
• Suponiendo que sigues a Scrum, ¿por qué quieres mantener solo Sprints de 1 semana? Eso es un poco preocupante. He manejado equipos practicando sprints de 1 semana y he visto que 40 horas no son suficientes. Si bien mostró una ilusión de velocidad, definitivamente no era sostenible. El tiempo extra no pagado era la norma y el sprint de 1 semana en realidad duraría más de 80 horas. La duración de 2 semanas fue definitivamente el punto ideal. Sin embargo, su experiencia puede variar. Prefiero mantener la duración del sprint en 2 semanas y organizar una visibilidad y comentarios más frecuentes para la OP y otras partes interesadas durante el Sprint.
• “ Alrededor de esto, normalmente siempre trabajamos en términos de sprints de 1 semana; nunca emprenda ningún proyecto o adición de funcionalidad que demore más de 4 o 5 días. “Esta es en gran medida una función de administrar el tamaño del alcance. El PO puede dividir las epopeyas en historias de usuarios tan pequeñas que cada historia se puede ejecutar en 5 días, por ejemplo. Con suficiente colaboración entre el PO y el equipo de desarrollo, esto es realmente posible.
• “ ¿Cómo puedo reestructurar nuestros esfuerzos de tal manera que veamos nuestro negocio como un proyecto de ‘pirateo’, enfocándonos en un montón de trabajo más pequeño de un día o una semana, en lugar de proyectos de varias semanas, sin agotar el equipo de desarrollo? “Le pediría que se concentre en el flujo y el alcance. Observe atentamente el flujo de software desde los requisitos hasta la implementación y trate de eliminar el siguiente bloque más grande en este flujo. Eso mejora la velocidad. Trabaje en el alcance para hacer que las historias de los usuarios sean lo suficientemente pequeñas como para que incluso los equipos novatos puedan hacerlo dentro de una semana. Eso ayuda a mejorar la precisión de la estimación en el tiempo y, por lo tanto, la velocidad.