Nuestra versión de Agile no funciona. ¿Consejos?

Trabajo en un pequeño equipo de 4 desarrolladores. Estamos implementando una versión de Agile que parece proporcionarnos continuamente las mismas dificultades, semana tras semana, y estoy buscando sugerencias que puedan ayudarnos a mejorar nuestro proceso.

El fondo:

Generalmente hacemos sprints de 2 semanas, y cada sprint tendemos a subestimar nuestro trabajo, y nos metemos en problemas con nuestro gerente porque estamos retrasados.

Comenzamos cada sprint repasando las historias que nuestro gerente crea para nosotros. A veces él también incluye las tareas y las estimamos. No usamos puntos de historia. Usamos el software Urban Turtle para "administrar nuestros sprints", que es esencialmente solo historias y tareas, y la quema asociada. No planeamos un lanzamiento al final de un sprint.

El problema más común que ocurre es que planeamos una tarea al comienzo de un sprint solo para descubrir que es mucho más grande en alcance, pero aún tiene una alta prioridad, por lo que debemos trabajar horas adicionales en ella. El segundo problema más común es que uno de nosotros se encuentra con un problema técnico que ralentiza las horas quemadas, causando un obstáculo.

La única sugerencia que se nos brinda es ser más proactivos al ajustar nuestras estimaciones y proporcionar actualizaciones durante las paradas en la mañana para que podamos ajustar el tiempo extra necesario.

Sin embargo, parece haber algo fundamentalmente incorrecto en la forma en que hacemos las cosas. Quizás haya una desconexión entre las expectativas del gerente a nivel de proyecto y las expectativas a nivel de sprint. Debido a que estamos haciendo estas iteraciones de sprint de acuerdo con un plan de proyecto, y por lo tanto, extender un sprint o diferir elementos arruina el plan del proyecto. Por lo tanto, como desarrolladores, se nos alienta a realizar Agile ampliando las estimaciones cuando sea necesario, pero también completamos el sprint a tiempo, lo cual es confuso.

Esto no puede ser un problema poco común, así que espero que aquellos más sabios que yo tengan una sugerencia o dos sobre cómo podemos dejar de encontrar este mismo problema en cada sprint. Es frustrante.

porque estamos atrasados

Este tipo de pensamiento es tu problema. No estás retrasado, el horario es demasiado apretado. Debe comenzar a estimar historias en puntos abstractos en lugar de horas y luego, en el transcurso de 2-3 iteraciones, calcule su velocidad. Tu velocidad es cuántos puntos sueles hacer en cada iteración, no cuántos puntos quiere encajar tu manager.

Después de esto, no importa si constantemente subestimas las tareas, tu velocidad ya lo explica.

Obviamente, esto es imposible si usas horas en lugar de puntos.

Parece que los problemas son la incapacidad de su equipo para hacer estimaciones precisas y la incapacidad de prever los problemas que surgen inevitablemente.

Las tareas pequeñas son mucho más fáciles de estimar con precisión que las tareas grandes, así que intente dividir sus tareas en trozos mucho más pequeños.

No permita que nadie haga una estimación de ninguna tarea, a menos que sepa EXACTAMENTE cómo lo hará. Para cualquier tarea que el desarrollador no sepa qué completar, dedique un tiempo al cronograma de ESTE sprint para que el desarrollador investigue y diseñe, y obtenga una estimación precisa. Nunca menos de medio día. Pero mueva la tarea a NEXT sprint. Luego, cuando planifiques el próximo sprint, tendrás una buena estimación. Tenga en cuenta que este tiempo extra no se desperdicia, porque es tiempo de que el desarrollador termine gastando en cualquier caso.

Y no tenga miedo de volver al gerente del proyecto y decirle que necesitará más sprints para completar la lista de tareas. Es mejor hacer eso, que comprometerse con objetivos imposibles.

¿Estás tratando de asignar el 100% de tu tiempo? Si es así, deja de hacerlo. Comience sumando todas las horas que su equipo tiene para contribuir durante el sprint. Haga esto asumiendo que cada trabajador empleará, en el mejor de los casos, 6 horas al día para el proyecto. Esto se considera un "día ideal". ¿Esas otras dos horas? Aspirado por reuniones, descansos, tareas administrativas, esa hora de la mañana cuando estás leyendo un correo electrónico y planificando tu día, etc. Esto no es "cubrir tus apuestas" o "embolsarse", es ser realista.

Segundo, multiplique esas 6 horas / día por 80% . ¿Por qué? Porque como humanos apestamos al predecir cuánto tiempo llevará una tarea. Esto explica los errores a nuestro juicio. Una vez más, no es un saco de arena, está siendo realista.

Ahora tiene un número que representa un número realista de horas que espera aplicar directamente a sus tareas. Cuando esté estimando, deje de agregar historias cuando la próxima historia lo detenga.

Finalmente, no permita que el propietario del producto agregue tareas. La planificación de Scrum es para el equipo , el PO no es parte del equipo que hace el trabajo. Por supuesto, en el mundo real, si la OP tiene más conocimiento que nadie en el equipo, su aporte puede ser muy útil. Aún así, si el equipo está tomando el calor por estar detrás, el equipo necesita apropiarse de las tareas que harán exactamente. Su objetivo es poder cumplir con los criterios de aceptación; Si una tarea no conduce directamente a eso, no lo haga.

Recuerde, Scrum no se trata de ser más productivo. Se trata de ser más abierto y comunicativo. El trabajo tomará lo que sea necesario para hacerlo. Scrum está ahí para facilitar la estimación, la comunicación con las partes interesadas y el compromiso de su equipo.

¿Criterios de aceptación mal definidos al comienzo del sprint?

Las estimaciones iniciales son a menudo demasiado bajas porque las tarjetas de historias tienen criterios de aceptación deficientes (si las hay) cuando se estiman. ¿Qué pasa con el cambio al desarrollo basado en pruebas de aceptación (ATDD), también conocido como prueba de historia, para ayudar al equipo a tener realmente claro qué es la tarjeta?

¿Historias demasiado grandes?

Otra razón por la que descubres a mitad del sprint que tus historias tardan más de lo esperado puede ser que son demasiado grandes. ¿Has visto el mazo de tarjetas flash Agile in a Flash ? Tienen una tarjeta de memoria llamada "Historias Shrink XL para encajar". Ofrece estrategias para dividir historias como diferir casos extremos, efectos secundarios, aspectos no funcionales o manejo de errores para historias posteriores.

¿No puede estimar porque no tiene suficiente información?

@sleske hace una buena sugerencia sobre los picos . Intente e identifique incógnitas técnicas en el tiempo estimado. Si los hay, ver si se puede aplazar la historia en un sprint más adelante y en lugar de hacer un tiempo en caja investigación (pico) de este sprint a tratar de aprender lo que se necesitaría para ser capaz de estimar. No te dejes llevar y resuelve la historia original: el pico se realiza cuando sabes lo suficiente como para estimar la historia.

Falla más rápido

Y estoy de acuerdo con @Patrick Hughes: considere pasar a sprints de 1 semana para que pueda ver los problemas más rápido.

Además de las buenas sugerencias de @Kevin y @Patrick ...

Los enfoques ágiles no son "talla única", pero este comentario me llamó la atención:

Estamos implementando una versión de Agile que parece proporcionarnos continuamente las mismas dificultades.

Es mejor comenzar con una metodología "por libro" (parece que Scrum es dominante en estos días), y hacer EXACTAMENTE lo que hizo otro equipo exitoso ... Hacer eso por unos pocos sprints ... Y solo entonces comenzar a considerar cambios necesarios para optimizar las condiciones locales.

Alquilar un entrenador Scrum experimentado (por algunas iteraciones) puede ser una verdadera diferencia. Hay sutileza en ser ágil.

Primero recomiendo el siguiente libro scrum-xp-from-the-trincheras . Mire la página 26 sobre los cálculos de velocidad. La idea es definir un factor de enfoque y decirlo para el próximo Sprint:

días-hombre disponibles * factor de enfoque = velocidad estimada

la velocidad estimada es la suma de las estimaciones de las historias que planeas implementar durante el próximo Sprint.

Y después de un Sprint, calcula el último factor de enfoque de Sprint como:

factor de enfoque = velocidad real / días-hombre disponibles

donde la velocidad real es la suma de las estimaciones de las historias que has implementado durante el sprint.

Luego, reutilizas este factor de enfoque real para el próximo Sprint, y después de algunos Sprint podrás ser más preciso con lo que realmente puedes lograr durante un Sprint ...

Hasta que obtenga sus estimaciones para acortar sus sprints a una semana, de esta manera reconocerá el exceso más rápido y podrá reaccionar en incrementos más pequeños.

Dedique más tiempo por adelantado al diseñar tareas para obtener un poco de espacio para respirar para reconocer los efectos secundarios que probablemente sean los que causan que el alcance sangra por todas partes. También podría ser que las tareas en sí mismas sean demasiado largas para una estimación ágil adecuada, vea si las tareas se pueden dividir en pasos más cortos que sean más fáciles de tragar.

Haga que todos se sientan cómodos enviando una bandera roja tan pronto como lleguen a un obstáculo en lugar de quedar atrapados en un problema durante unas horas. Intenta separar el ego y la culpa de este proceso, eso es más fácil para algunos que para otros =)

Y como lo mencionó @Kevin, en realidad nunca programas el 100% directamente para las tareas porque siempre hay gastos generales como las reuniones, etc., que quizás no reconozcas como comedores de tiempo.

Cuando todo esté bien en el frente de la programación y luego vuelva a las dos semanas, mágicamente tomará un poco de tiempo de las pocas reuniones nuevamente.