¿Es válido y posible hacer frente a plazos fijos e inamovibles en Scrum?
Supongo que es confuso para mí porque pensé que uno de los principios básicos de la gestión de proyectos es ayudar a identificar estimaciones realistas de una fecha de finalización basada en información limitada. ¿Existe una rama de la gestión de proyectos, específicamente Agile o Scrum Project Management, que se ocupe de lo contrario, comenzando en la fecha de finalización y trabajando hacia atrás para encontrar formas creativas de encajar todo?
Estoy tratando de entender la metodología y la estrategia de gestión de proyectos en mi empresa actual. Es una gran institución financiera y hay cientos de proyectos en curso en un momento dado. Hay una gran oficina de gestión de programas que recopila información de estado sobre muchos hilos de trabajo en curso diferentes para la comunicación del estado hasta el nivel ejecutivo. Los Gerentes de Proyecto mantienen los planes del proyecto y coordinan la información del estado del proyecto desde los recursos del proyecto hasta los Gerentes de Programa.
Lo extraño que no puedo entender es que cuando un proyecto está en concepción, no hay un esfuerzo técnico real para determinar estimaciones de esfuerzo o tiempo en los hitos del proyecto. En esta fase, parece ser completamente insignificante, porque los ejecutivos de TI o el LOB establecen cada fecha límite del proyecto, sin que nadie lo vea.
Después de que se nos dice cuál será la fecha, se nos dice que hagamos una estimación formal del esfuerzo (puntos de la historia) en lugar del tiempo porque la organización tiene el mandato ejecutivo de ser Agile y Scrum. Lo extraño es que después de que identificamos todos los Epics y el tamaño de la camiseta, aún se requiere que el Gerente de Proyecto descubra cómo encajar todo esto en el plazo predeterminado. Para hacer esto, dividimos y hacemos una estimación detallada de los puntos de la historia de una sola epopeya, generalmente de tamaño pequeño, luego los puntos totales de la historia se usan comparativamente para calcular los puntos totales de la historia asumidos. A partir de ahí, el Project Manager determina la velocidad y prueba si todos los hitos del proyecto se pueden lograr antes de la fecha límite.
El concepto de Producto Mínimo Viable es inexistente. El PM debe mostrar cuántas personas se necesitan para que este plazo sea posible y, si es demasiado costoso, el proyecto podría cancelarse incluso antes de que comience.
La cuestión es que durante los últimos años, casi todos los proyectos podrían considerarse un fracaso porque casi nunca alcanzan estos plazos independientemente. Lo que no entiendo es que a pesar de fracaso tras fracaso, nada sustancial parece cambiar. Ciertamente, no parece que llegar tarde al proyecto realmente importe a largo plazo. Cuando el proyecto se retrasa, las reuniones de estado aumentan y la ansiedad general parece aumentar, pero casi todos siguen trabajando como lo hacen normalmente.
Otras personas que llevan mucho tiempo en la empresa me han dicho que en realidad son dos citas. El plazo formal que figura en el papel y la fecha que los ejecutivos realmente anticipan cuando el proyecto se realizará en la realidad. Cuando les pregunté por qué no hacer realidad la fecha límite, casi todos estuvieron de acuerdo en que el liderazgo ejecutivo siente que cuando los proyectos se retrasan en el papel, las personas "trabajan más".
No veo que esto funcione por varias razones. Los veteranos de la empresa no sienten la presión porque creen que hay un intento de manipularlos para que trabajen más duro. Las personas más nuevas se desmoralizan y dejan de intentarlo. Todo el mundo pasa más tiempo en reuniones de estado con gerentes de programas ansiosos en lugar de centrarse en el trabajo del proyecto y, finalmente, la naturaleza del trabajo se basa más en el conocimiento y en la gestión de dependencias externas que en el trabajo duro con filas de personas escribiendo furiosamente en los teclados hasta las 2 am. La mayoría de las personas trabajan un sólido 40 y se van a casa sin importar la presión porque, a menudo, quedarse hasta tarde no hará que se solucionen los obstáculos reales antes.
¿Es válido y posible hacer frente a plazos fijos e inamovibles en Scrum?
Sí. Hicimos un proyecto relacionado con las Olimpiadas usando Scrum. Naturalmente, el plazo se fija inamovible. No hay nada malo en esto. Pudimos ajustar el alcance para encajar en lo que se podía lograr para lanzar a tiempo para la ceremonia de apertura. En su caso, sus gerentes de proyecto también parecen tener flexibilidad para obtener recursos que coincidan. Puede ver la presentación de Mike Cohn sobre la aplicación de Agile a "proyectos de fecha fija, alcance fijo y arreglo de todo" .
luego se nos dice que hagamos una estimación formal del esfuerzo (puntos de la historia) en lugar del tiempo porque la organización tiene el mandato ejecutivo de ser Agile y Scrum
Hacer la estimación en puntos de la historia es el enfoque correcto. Si necesita una buena referencia, lea Puntos de la historia de Jeff Sutherland: ¿Por qué son mejores que las horas?
dividimos y hacemos una estimación detallada de los puntos de la historia de una sola epopeya, generalmente de tamaño pequeño, luego los puntos totales de la historia se usan comparativamente para calcular los puntos totales de la historia asumidos.
Esto no es inusual en esa etapa del proyecto. A medida que avanza el proyecto, todos (equipo de desarrollo y propietario del producto) aprenderán más sobre el proyecto. Y el propietario del producto puede hacer ajustes a la prioridad en consecuencia.
El PM debe mostrar cuántas personas se necesitan para que este plazo sea posible y, si es demasiado costoso, el proyecto podría cancelarse incluso antes de que comience.
Este es el enfoque comercial correcto. Si el Retorno de la Inversión (ROI) no está ahí, ¿por qué hacer el proyecto?
A partir de ahí, el Project Manager determina la velocidad.
Si el Project Manager está evaluando la velocidad empíricamente (basándose en la velocidad real alcanzada por el equipo en 3 sprints o más), entonces está bien. De lo contrario, podría estar muy lejos.
Más allá de eso, se desvió hacia muchas especulaciones, sin cubrir información esencial que puede ayudarnos a comprender mejor su proceso:
Agile admite el concepto de plazos fijos. Prioriza su trabajo pendiente y llega lo más abajo posible en la lista cuando se alcanza la fecha límite.
Lo que no puedes hacer es arreglar tanto el tiempo como el alcance.
Puede, en teoría, variar los recursos y mantener el tiempo y el alcance fijos. Sin embargo, eso ignora la dificultad de aumentar los recursos. Como dice la famosa ley de Brooks: "agregar mano de obra a un proyecto de software tardío lo hace más tarde". Por lo tanto, para fijar el tiempo y el alcance y simplemente variar los recursos, necesitaría poder predecir con mucha anticipación cualquier posible retraso.
También podría argumentar que el tiempo y el alcance se pueden arreglar si arroja una gran cantidad de recursos en el proyecto. Pero incluso eso puede fallar, ya que la producción puede disminuir potencialmente a medida que aumenta la cantidad de personas en el proyecto y la comunicación se convierte en un problema (el problema n+1).
La idea de fijar plazos para que la gente "trabaje más duro" ha sido refutada en gran medida en las industrias basadas en la información. El problema es que hay muchas formas diferentes de resolver cualquier problema de codificación y las soluciones más rápidas suelen ser las peores en términos de calidad y capacidad de expansión futura.
Quizás su mejor enfoque en esta organización sería proponerles que ejecuten un pequeño proyecto de prueba siguiendo principios ágiles en lugar de su enfoque actual. Acuerde algunas métricas que medirán el éxito del proyecto antes de que comience. A veces, solo se necesita una demostración de éxito para convencerlos.
Agregando a esto, yo altamenterecomiende hacer un seguimiento de las cantidades y las fuentes de "trabajo emergente" (lo que no estaba en el cálculo inicial de la acumulación versus la velocidad) a medida que avanza, y tener esto en cuenta continuamente en su planificación o alcance previsto. Con esto me refiero a puntos por "incógnitas desconocidas" o nuevos elementos de la cartera de pedidos que surgen en cada sprint, puntos por comentarios, puntos por pivotes debido a las pruebas de los usuarios, puntos por "vaya que era más grande de lo que pensábamos" estándar. En mi experiencia, esta es, con mucho, el área individual más grande que se pasa por alto y pone a los equipos en una mala posición con la gerencia cuando llega el momento de alcanzar su estimación de alcance original. Muchos agilistas dirán que si mide la velocidad con estas cosas sucediendo, simplemente "saldrá en el lavado", pero eso no es
No estas solo. Muchas empresas se llaman a sí mismas ágiles, pero solo unas pocas lo son realmente. Lo que suena extraño es que su empresa requiere puntos de historia universales que se aplican a todos. Los puntos de historia son una métrica relevante útil cuando un equipo tiene algo de historia y conoce su velocidad. De lo contrario, los puntos de la historia son solo números aleatorios. Trabajé para una empresa similar a la suya y traté de educarlos sobre SCRUM. Después de un par de meses de frustración, me rendí y renuncié. A veces, la mentalidad corporativa o de "siempre lo hemos hecho" es inmutable.
Sklivvz