Soy un desarrollador que trabaja en una nueva aplicación móvil para Android e iOS con un gran componente de back-end. Hemos estado en tres sprints de este proyecto, y usamos Scrum con todas sus ceremonias (refinamiento, planificación, diarios, retrospectivas, etc.).

En dos de los sprints, el equipo tuvo que trabajar horas extras (no remuneradas) y fines de semana, porque la gerencia estaba muy alarmada de que no completáramos el compromiso del sprint a tiempo. Todos trabajaron duro, pero algunas dependencias externas y estimaciones optimistas nos hicieron luchar para lograr todas las historias de sprint.

En mi experiencia, tener un pequeño porcentaje de historias no completadas durante algunos sprints es algo normal, y pueden abordarse en la próxima. Pero nuestro gerente de proyecto dice que es nuestra culpa, ya que hicimos la estimación nosotros mismos, por lo que debemos completar todos los elementos en el sprint.

1. ¿Es esta una variación aceptable / común de Scrum que no conozco?

2. ¿Cómo sugieres que actúe sobre esto?

Algunas cosas me destacan.

La idea de que la gerencia tiene que el equipo se compromete con un conjunto de trabajos es inconsistente con las últimas versiones de la Guía Scrum. La palabra "compromiso" o "compromiso" solo se usa dos veces en la versión más reciente (noviembre de 2017) de la Guía Scrum, una vez cuando se enumeran los Valores Scrum y otra vez para indicar que "las personas se comprometen personalmente a lograr los objetivos del Equipo Scrum". ".

La idea de los objetivos es importante para Scrum. No solo las organizaciones y los equipos tienen objetivos amplios, sino que en Scrum, cada Sprint tiene un Objetivo Sprint que se define en Sprint Planning como una colaboración entre el Propietario del producto y el Equipo de desarrollo. El objetivo de Sprint se cumple mediante la implementación de elementos del Backlog del producto, pero no es simplemente "terminar este trabajo" y, a menudo, no representa el Backlog completo de Sprint. Es decir, debe ser capaz de alcanzar el objetivo de Sprint sin completar todos los elementos del Backlog del producto seleccionados para el Sprint o cada uno de los elementos del Backlog del Sprint. Mi opinión actual es que el trabajo necesario para lograr el Objetivo Sprint debe estar en algún lugar alrededor del 60-70% de la capacidad de su equipo, sin embargo, usted tiene en cuenta la capacidad. Sin embargo, diferentes organizaciones serán diferentes, pero eso '

Trabajar horas extras y fines de semana también es una práctica de desarrollo de software anti-ágil. Uno de los principios subyacentes es que todas las partes interesadas de un esfuerzo pueden trabajar a un ritmo sostenible. Los días largos y los fines de semana, incluso si se pagaran, no son sostenibles para un equipo.

En este punto, hay algunos pasos siguientes. El Scrum Master del equipo debe educar a la gerencia sobre los valores y principios del desarrollo de software ágil y Scrum (como el "compromiso" y el "ritmo sostenible"). El equipo debe trabajar en su capacidad de pronosticar el trabajo y negociar el alcance con el Propietario del producto. El equipo también debe identificar y trabajar para resolver o prevenir los impedimentos que llevaron a esta situación (eliminar o reducir el impacto de las dependencias externas).

La situación que usted describe, donde la administración requiere que el equipo trabaje horas extras para completar todas las historias planificadas, es una de las razones por las cuales la literatura de Scrum ha dejado de usar el término "compromiso". Solo se puede dar un verdadero compromiso cuando se elimina toda la incertidumbre, incluida la incertidumbre sobre las dependencias de terceros, cuánto trabajo es cada elemento, cuánto tiempo estarán disponibles todos teniendo en cuenta la enfermedad, etc.

Una de las ideas básicas de Scrum es que el equipo trabaja a un ritmo sostenible, lo que esencialmente significa trabajar horas normales sin horas extras (remuneradas o no). Esto significa directamente que está no experimenta una variación aceptable de Scrum.

Lo que puede hacer al respecto depende de su función.

Si eres desarrollador, entonces lo mejor que puedes hacer es

• (colectivamente como equipo de desarrollo) se niega a "comprometerse" a realizar más trabajo del que está absolutamente seguro de que puede entregar en un sprint. Esto probablemente será mucho menos de lo que la gerencia quiere que haga.
• concéntrese en terminar el trabajo, en lugar de comenzar en nuevas tareas. Si ve que parte del trabajo no se puede completar, indíquelo lo antes posible para que los planes se puedan ajustar.

Si eres un maestro de Scrum, entonces puedes demostrar tu valía educando a la gerencia sobre Scrum. Algunos puntos que me destacan:

• Como se indicó en el primer párrafo, el equipo no se compromete durante la planificación del sprint, pero dan un pronóstico del trabajo que esperan haber terminado.
• Aunque el equipo debe evitar tener un trabajo inacabado al final de un sprint, esta situación es casi inevitable al comienzo de un proyecto (o después de un cambio en la composición del equipo). La cantidad de trabajo que el equipo puede realizar de manera realista en un sprint solo puede determinarse en función de las cifras históricas de los últimos sprints del equipo en esta composición. Al principio del proyecto, tales figuras históricas simplemente no existen, por lo que un equipo que logre en los primeros 3 sprints exactamente lo planeado para cada sprint es más un accidente que una buena planificación. Después de aproximadamente 5 sprints a un ritmo sostenible, hay suficientes datos para tener una idea razonable de cuánto trabajo puede terminar el equipo de manera realista dentro de un sprint.

Su primer ministro no tiene nada que ver con su scrum.

Su primer ministro no tiene por qué pedirle horas extra sin pagar.

Lo obvio es hacer una estimación de todas las tareas de tal manera que pueda garantizar que se completarán a tiempo. Entonces deberías poder ir al pub de la segunda manera, ya que claramente si subestimar una tarea significa que la terminas gratis, entonces sobreestimar significa que tienes tiempo sin trabajo.

Hay varios aspectos de esto, pero a un alto nivel, sí, el primer ministro querrá entender claramente por qué el trabajo planificado no se ha completado. Sin embargo, esto debería mencionarse (y resolverse) en la retrospectiva. Desde el lado del desarrollador, hay muchos factores que pueden contribuir a las fallas de sprint.

Algunas cosas que puede considerar:

Demasiado en el sprint

Si regularmente te comprometes a demasiado trabajo, los sprints fallarán. La velocidad del sprint debe rastrearse con el tiempo para averiguar cuál es el número óptimo de puntos (o días).

Asignación de recursos

Asegúrese de que la planificación de sprints tenga en cuenta adecuadamente las actividades que no son de desarrollo, como las ceremonias, los días festivos, la capacitación, la administración, el apoyo y otros proyectos, etc. ponerte en el pie trasero desde el principio.

Variación estimada

Estás refinando, pero ¿hay ciertos tipos de tareas que siempre se desbordan? Por lo general, estos se deben a requisitos vagos o faltantes. Si los requisitos son imprecisos, la historia ni siquiera debería llegar al sprint a menos que se haya refinado adecuadamente o se haya planeado un pico.

Velocidad

Si la velocidad se rastrea adecuadamente, la verdadera cantidad de historias debería quedar clara. Eso no quiere decir que siempre se harán a tiempo, pero debería facilitar las cosas.

Buena voluntad

En cualquier proyecto, la buena voluntad es limitada. Si constantemente está trabajando fuera de las horas para entregar, la moral se verá afectada y los desarrolladores se agotarán, esto es un error de gestión del proyecto . Como ya lo describí, asegúrese de que la planificación de sprints solo programe un número realista de historias usando velocidad y picos para ayudarlo en el camino.

Picos

Si un artículo está mal refinado o es simplemente lanoso, no tengas miedo de poner un pico para proporcionar una mejor estimación de los sprints posteriores. Sí, algunas personas son malas en la estimación, pero la mayoría de las veces, los hechos completos simplemente no se conocen en ese momento. Idealmente, esto debería haber sido cubierto en el refinamiento o recogido temprano por el PO, pero a veces pueden deslizarse en un sprint. Los desarrolladores deberían estar presionando estos duros ya que pueden torpedear fácilmente un sprint que de otra manera iría bien.

No, esta no es una forma reconocida de Agile , por una razón muy importante: si te comprometes a entregar todo , no estás haciendo Agile, estás haciendo Waterfall, y si crees que estás haciendo Agile , probablemente estés haciendo Waterfall mal , en eso. Estoy seguro de que has escuchado la vieja sierra "buena, rápida, barata, elige dos", ¿verdad? Con el desarrollo de software, es más como "todas las funciones entregadas, a tiempo, dentro del presupuesto, elija la primera o las otras dos". Waterfall elige el primero, y Agile elige los segundos dos.

Si va a ser ágil, necesita la flexibilidad para eliminar historias del Sprint que no puede completar a tiempo. Una posible forma de hacerlo es pedirle a su propietario del producto que evalúe las historias utilizando la priorización MoSCoW. Esto implicaría seleccionar no más del 60% de las historias (por el total de puntos de la historia) como Debe tener que se completará, 20% como debería tener que debe completar al concluir el proyecto y se lanza el Producto mínimo viable, 20% como Podría Haves que podría completarse si tiene el tiempo, y cualquier cosa fuera del alcance de la versión actual como Won't Haves. También es importante tener en cuenta que, cuando se combinan, los Must Haves deben tener suficiente carne en sus huesos para crear el Producto mínimo viable sin necesidad de incluir ningún elemento de las otras categorías.

Determinar si se deben dejar caer o no los artículos de la reserva de Sprint es responsabilidad del propietario del producto, después de que el equipo lo haya solicitado, y cualquier artículo que se haya caído de la reserva de Sprint sea evaluado por el propietario del producto, y luego caído del proyecto por completo, o colocado en el Backlog del proyecto en una posición debidamente clasificada.

En este caso, supongo que el propietario de su producto es su gerente de proyecto, ¿verdad? Sería su trabajo determinar qué tareas abandonar, por lo que ciertamente no debería culparlo por comprometerse demasiado, ya que sería su trabajo abandonar las tareas para compensar eso, y parece que no lo está haciendo.

Él tiene razón, que no debería haber ningún traspaso entre sprints. Los equipos Scrum que tienen una transferencia entre sprints es un antipatrón y no es algo que Scrum canónico acepte como resultado válido.

Pero, su enfoque no es bueno.

Durante un sprint, el equipo debe monitorear constantemente el trabajo que se realiza y si pueden mantener su compromiso de planificación de sprint para terminar las historias seleccionadas. Si el equipo identifica que no puede terminar todas las historias, debe reunirse con PO y seleccionar una historia para eliminar del sprint. Al hacerlo, todos DEJAN DE TRABAJAR EN LA HISTORIA y se concentran en completar las historias restantes. Recuerde: siempre es mejor terminar una historia por completo que tener dos historias a medio terminar.

Los problemas de las dependencias externas y la estimación imprecisa es exactamente por qué existen las retrospectivas. Durante Retro, el equipo debe reflexionar e identificar estos problemas. Y el equipo debe encontrar e implementar soluciones a esos problemas. Las estimaciones pueden hacerse más precisas al conocer mejor el sistema y la experiencia simple. Las dependencias externas son más difíciles, pero no imposibles de solucionar.

Scrum Master no debería permitir que tu PM ( ¿qué está haciendo incluso PM en un equipo Scrum? ) Te obligue a terminar todas las historias. En cambio, si tiene quejas, debería guardarlas para Retrospectiva. Y aún mejor, debería ser parte de la resolución de los problemas que impidieron que las historias se terminaran a tiempo.

¿Es esta una variación aceptable / común de Scrum que no conozco?

No se . Está completamente mal. Tal vez podría simpatizar con las horas extras pagadas , si la OP cometió el error de entregar las estimaciones como hechos antes del final del sprint, pero las horas extras no pagadas son completamente ridículas y me harían buscar otro trabajo lo antes posible.

¿Cómo sugieres que actúe al respecto?

En mi experiencia, las personas que son tan ferroviarias no escucharán argumentos lógicos. La única forma de que vean qué tan roto está es mostrar , no contar. Entonces, la próxima vez que haga una estimación y se comprometa, comprométase con la menor cantidad posible . Comprométete a terminar un pequeño boleto al final del sprint. Uno que podrías hacer en un día. Vea cómo reacciona su PM. Luego comience una discusión desde allí sobre para qué se utiliza el sistema y para qué se debe utilizar.

En general, al comienzo del proyecto, cuando decidimos la velocidad del equipo, buscamos un número conservador (más bajo de lo habitual) considerando el hecho de que es un equipo nuevo, tomaría un poco de tiempo para que el equipo se calme , nos entendemos, entendemos los requisitos funcionales y NFR, etc. Básicamente, después de los primeros sprints optimizamos la velocidad del equipo y obviamente la velocidad solo mejorará a partir de ese punto.

No tiene sentido cometer una velocidad más alta al principio y estirar al equipo para lograrlo.

Una cosa más es que, en un escenario único, donde hay un compromiso de entrega que no se puede perder, los gerentes de proyecto pueden presionar al equipo para que se estire, trabaje hasta tarde y trabaje los fines de semana. Pero eso debe considerarse como una excepción y no como la norma de trabajo. Trabajar así podría aumentar la velocidad a corto plazo, pero a largo plazo sería contraproducente, ya que podría generar problemas de calidad del código, problemas de agotamiento del equipo, equipo descontento con poca motivación, etc.

Compromiso FAQ

¿Es normal este comportamiento?

No estoy seguro.

¿Es sorprendente?

No. Algunas personas siempre entenderán que "compromiso" significa que todo en el compromiso debe completarse.

¿Es una buena idea?

No. El desarrollo ágil tiene la sostenibilidad como tema central: trabaje solo tanto / largo / duro como pueda hacer indefinidamente. Esa es una idea sensata en la mayoría de los casos. (Si su gerencia no acepta esto, no deberían llamar a su organización ágil).

¿Qué debemos hacer?

• Explique que el contenido del sprint se basa en una estimación . "Estimación" significa que solo algunas veces será correcto, y generalmente estará equivocado. Cuando está mal, a veces es demasiado bajo y a veces demasiado alto.
• Explique que es mucho más fácil cambiar el comportamiento de estimación que la velocidad de trabajo.
• Explique que cuando el equipo es castigado por estimar demasiado alto, solo estimará más bajo y la gerencia perderá mucho más progreso de esa manera que al pasar ocasionalmente parte del contenido de un sprint al siguiente.

Lo bueno es que su gerente de proyecto ya sabrá todas estas cosas y las reconocerá como correctas. Es solo que a corto plazo uno puede preferir ignorarlos.

No estoy de acuerdo con su equipo de gestión. No deberían haberte hecho trabajar horas extras para terminar el sprint.

Sin embargo, la idea de que los compromisos no son posibles proviene de un malentendido del desarrollo de software. He visto a muchos equipos tratar de predecir las historias que pueden completar en un sprint por la cantidad de puntos de historia que han completado en sprints anteriores. Si eso fuera posible, diría que el desarrollo de software es lineal, es decir, si trabajo dos horas, hago el doble que en una hora.

El desarrollo de software es creativo y, por lo tanto, no lineal. Es una mejor práctica para el equipo contarle a la gerencia lo que pueden hacer en un sprint y luego entregar esas historias. Si constantemente pierde sus compromisos, no tenía idea del alcance de la historia para empezar o el propietario de su producto lo presiona para asumir más.

En el primer caso, debe asegurarse de comprender el alcance de la historia antes de aceptar seguirla. Si es lo último, tiene un problema cultural y hay poco que se pueda hacer.