¿Tener fechas de entrega fijas para los elementos es una forma de trabajo “ágil”?

La alta gerencia nos dice que vamos a trabajar de manera ágil en un nuevo proyecto. Han establecido stand-ups, planificación de sprint, retrospectivas, etc. Sin embargo, ahora han elaborado un plan que detalla todo el trabajo que quieren que entreguemos con fechas para cada elemento y mostrar fechas nuevamente con lo que se mostrará en cada uno. Este plan sale al segundo trimestre de 2017.

Para mí, esto parece una cascada en el peor de los casos, se ha elaborado un plan sin aportes del equipo técnico donde ciertas historias sobre el plan son muy poco claras y el equipo de desarrollo no ha estimado ninguna.

Sin embargo, sé que su argumento será "las partes interesadas principales deben tener fechas y debe haber un plan, no podemos simplemente trabajar desde una cartera". Para mí, esto parece que las partes interesadas principales no han comprado Agile y, por lo tanto, estamos condenados a fallar al implementarlo en un nivel inferior.

¿Es un juicio justo o estoy exagerando con este plan?

Hay una diferencia entre cumplir con la fecha límite y cumplir con todos los requisitos. Es como el viejo adagio "rápido, bueno o barato, elige dos".

Entonces, aquí tiene fechas fijas para la entrega; eso es bueno, significa que tiene un límite de tiempo en que lo que entregue al final de su último sprint será el producto final. Recuerdas que siempre tienes que lanzar software de trabajo al final de cada sprint, ¿no?

Lo que puede suceder es que al software final le faltarán algunas características. Bueno, esto sucede con todas las metodologías de desarrollo, incluida la cascada. Todo lo que sucederá es que se le encargará la producción de un lanzamiento de parche después, o una versión 2. ¡Eso supone que su entrega final es lo suficientemente buena, por supuesto!

Por lo tanto, las fechas fijas no son una forma de trabajo no ágil. Agile no significa que haya un presupuesto ilimitado para que juegues con tus nuevas herramientas de planificación. Significa que tendrá que centrarse en la entrega, eso nunca es malo.

No. Este es el tipo exacto de cosas que las compañías que no son de software tienden a hacer. Hay planes, plazos y presupuestos. E inevitablemente fallará, ya que los humanos apestan al predecir el futuro.

Veamos los diversos puntos aquí:

La alta gerencia nos dice que vamos a trabajar de manera ágil en un nuevo proyecto.

Si fueras ágil, estarías teniendo equipos auto organizados, sin que la gerencia te dijera cómo trabajar.

Sin embargo, ahora han elaborado un plan que detalla todo el trabajo que quieren que entreguemos con fechas para cada elemento y mostrar fechas nuevamente con lo que se mostrará en cada uno.

No. Esa es más o menos la antítesis del desarrollo iterativo. Algo sucederá (alguien se enferma, alguien se va, se olvidó algún requisito, sus servidores mueren, lo que sea) y luego se pierde uno de estos objetivos. Ahora la gerencia puede recalcular todo el plan o descifrar el desarrollo.

ninguno ha sido estimado por el equipo de desarrollo.

Entonces, ¿cómo sabe que la gestión de este plan es viable en absoluto ? En Agile, el trabajo es una negociación. El negocio dice: nos gustaría esto. Ingeniería dice: está bien, suponiendo XYZ, eso tomará 3 semanas. No hay colaboración del cliente en lo que está describiendo. No hay individuos e interacciones.

Para mí, esto parece que las partes interesadas de alto nivel no han comprado Agile y, por lo tanto, estamos condenados a no implementarlo en un nivel inferior.

No estás necesariamente condenado, pero si no, es solo una coincidencia. Cuando todo el trabajo aparece porque la gerencia no puede ver el futuro, perderá sus fechas (o producirá un código de mala calidad, o requerirá más recursos de lo esperado). Entonces será tu culpa. Es probable que la administración lo presione a trabajar más horas para llegar a la fecha, o tal vez arroje a las personas al problema.

En el mejor de los casos , la administración es realmente ágil y es lo suficientemente inteligente como para reducir el alcance. Lo que significa que simplemente pasaron todo este tiempo construyendo un gran plan detallado que no tiene valor.

Si existe la expectativa de que se entreguen conjuntos específicos de características en fechas específicas, entonces no, esto no es una gestión de proyectos ágil. La gestión ágil de proyectos es de naturaleza empírica. Las proyecciones no se basan en los deseos de los ejecutivos, sino más bien en el análisis del desempeño anterior.

Su descripción coincide con lo que considero ágil de culto de carga. La atención se centra en los procesos y ceremonias específicos y no en los conceptos centrales de la gestión de proyectos basada en evidencia. Es posible que tenga suerte para que la gente de negocios comprenda si relaciona esto con Lean o TPS . El verdadero problema que debe resolver aquí es lograr que la administración supere su miedo a lo desconocido. La respuesta correcta para los ejecutivos es "no podemos decirle ahora cuándo se harán las cosas, pero una vez que comencemos a ofrecer valor, podemos construir proyecciones basadas en nuestra experiencia". Los desarrolladores tienden a decir cosas como "se hace cuando se hace" y "No sé cuándo se hará". Los gerentes no dirán cosas así a los ejecutivos, les hace sonar como nincompoops.

Lo más probable es que el plan falle y necesite ser revisado. El mayor riesgo para el equipo es que habrá un gran impulso para cumplir con los plazos y la calidad se verá afectada. En algún momento no estará en el objetivo (lo más probable, será la primera fecha límite) y habrá un impulso para alcanzar esa fecha. Se esperarán horas extras y habrá presión para cortar esquinas (omitir prueba de unidad, revisiones de código, etc.) Esta es una pendiente resbaladiza y una vez que comience por este camino, es una espiral descendente y las cosas se pondrán feas. La productividad empeorará a medida que el proyecto continúe de esta manera.

Si puede lograr que el equipo de desarrollo presente un frente unificado, realmente debería retroceder y mantener la línea de la calidad. Mi experiencia es que los gerentes de proyecto tienden a pensar que la salida del software es lineal. Es decir, cada período X producirá Y 'porcentaje completo'. Es decir, si no está "completado al 50%" a la mitad del tiempo permitido, los klaxons comienzan a sonar. En realidad, si lo está haciendo bien, la primera característica tiende a tomar mucho más tiempo que la característica 50 (de tamaño similar). Si puede superar ese período inicial de crisis de peligro ("¿qué está pasando?", "No lo hago" ¡No veo que se haga nada! ") probablemente estarás bien.

Bienvenido a negocios reales.

Hay un estilo de negocios más antiguo, que suelo llamar burlonamente "desarrollo tradicional" y luego hay un nuevo estilo, "desarrollo ágil". Si trato de tratar estos como ideales opuestos, vemos una división directa en el medio: los planes y requisitos van en la columna tradicional, el descubrimiento y la evolución van en la columna ágil. Está ordenado, ordenado e incorrecto.

En realidad, los negocios son una búsqueda del medio feliz entre los dos. Es fácil demostrar que cualquiera de los extremos en realidad cae de bruces. Los que amamos a Agile demostramos ansiosamente todos los problemas del ideal puro del desarrollo tradicional, y hay muchos que pueden mostrar las muchas formas en que Agile puro se desmorona. Las compañías ágiles exitosas son las que encuentran su equilibrio particular entre las dos. Las compañías tradicionales exitosas son las que encuentran su equilibrio particular entre las dos. No puedes tener uno sin el otro.

Incluso nuestro bendito proceso SCRUM muestra un equilibrio entre los dos. Si bien hay un claro intento de maximizar la agilidad, se realizan algunas compensaciones clave. Por ejemplo, el propietario del producto tiene el poderoso trabajo de abogar por todos los clientes. SCRUM intencionalmente no especifica cómo funciona esa interacción. Intencionalmente ignora el hecho de que todos necesitan que se les pague al final del día. El trabajo del propietario del producto es crear la ilusión de que eso no importa.

(Es interesante notar que el ágil puro funciona muy bien, siempre y cuando no le paguen hasta que produzca un producto, y no tenga acceso a información patentada hasta que esté investido. Creo que los únicos ingenieros de software que se sienten cómodos con este comercio son los emprendedores)

Por lo tanto, la administración ha dictado qué características estarán allí y cuándo deben estar allí. Esta bien. Una frase que he escuchado es "el cliente elige qué y cuándo, el productor elige quién y cómo". Te has registrado para el "qué" y el "cuándo". No han dicho nada sobre quién o cómo, aparte de ofrecerle la oportunidad de usar "Agile" como su cómo. Todo lo que queda es ayudar a la gerencia a comprender cuántas personas van a necesitar contratar para satisfacer sus necesidades.

En un mundo perfecto, su empresa es ágil desde el exterior. Interactúa con sus clientes de manera ágil, permitiendo que los desarrolladores se desarrollen ágilmente para ellos. Sin embargo, muy a menudo la empresa debe interactuar con el exterior mientras se desarrolla con agilidad en el interior. En el medio siempre hay un conjunto complejo de compensaciones, exclusivo de cada empresa.

Personalmente, trato esta situación como un caso de prueba para cualquiera que piense que comprende el desarrollo ágil. En algún momento en el futuro, tendrá que desarrollar un producto para una fecha límite, y ese par producto / fecha límite será relativamente fijo. Si un producto / plazo fijo rompe su proceso, ¿puede realmente decir que fue Agile en primer lugar?

Mi consejo: no pienses en esto como una cascada. Aún controlas el "cómo". Todavía puedes hacer todo el sprint rápido y los prototipos flexibles por los que Agile es tan famoso. Simplemente debe tener en cuenta que la goma se encuentra con la carretera y debe cumplir. Este es el mundo real, no el mundo ideal. ¿Hubiera sido mejor para ellos preguntarte en primer lugar? Seguro. Puede que no haya sido tu decisión. Puede haber miles de razones comerciales para hacerlo a su manera que simplemente no comprende completamente. Siéntase libre de rechazarlos, pero comprenda que pueden tener una muy buena razón para lo que hicieron.

Agile no le impide planificar hitos (por ejemplo, lanzaremos V 1.0 en 3 meses), pero lo que se incluye en cada hito no se puede solucionar.

Creo que cómo debe reaccionar depende de la naturaleza del proyecto. Si el proyecto es enviar a un hombre a la luna para el segundo trimestre de 2017, todos estarían de acuerdo en que está condenado al fracaso. Si crees que puedes entregar un MVP para fines del segundo trimestre de 2017, deberías trabajar en ello sprint por sprint.

Si la gerencia cree que su equipo está haciendo su mejor esfuerzo y usted puede mostrar progreso con cada sprint, debería poder negociar por más tiempo.

CADA proyecto comercial relevante tiene limitaciones:

• Hora
• Recursos
• Un conjunto mínimo de características esperado

Esto no es nada más. Desarrollar ágil no significa "la gente nos paga dinero, para que podamos desarrollar lo que queramos cuando esté listo", siempre tendrá un marco de tiempo. Siempre habrá una fecha con algunos requisitos mínimos y, si no se cumplen, el proyecto se cancelará y se considerará un fracaso. A veces pueden ser implícitos, por lo que el gerente sabe "Si no tengo una interfaz de usuario funcional con estas características después de 4 semanas, este proyecto está condenado al fracaso", o puede haber accionistas que establezcan una meta.

Hay muchos proyectos resultantes de la legislación. - Si el gobierno decide que debe implementar la característica X hasta 2017 para respetar una nueva ley, tendrá un plazo no negociable y un conjunto de características que deben estar listas. La única variable es la cantidad de recursos que la administración puede asignar a la tarea. - Y en estos proyectos, donde la fecha límite es una decisión externa, deberán vigilar su progreso, escuchar su pronóstico y contratar a los equipos o subcontratar parte del trabajo para cumplir sus objetivos.

Todo esto no se opone al desarrollo ágil. Aún tendrá sus sprints, desarrolle sus características en su propio marco de tiempo. Siempre obtendrá sus prioridades de características de un cliente, y trabajará para ofrecer tantas de estas características como sea posible hasta la fecha límite.

Si el plazo realmente se cumplirá con los recursos disponibles es un problema de gestión. Puede dar su pronóstico y actualizaciones de estado semanales / diarias y ellos pueden decidir si necesitan más recursos. De lo contrario, continuará trabajando en sprints y entregará ejecutables, lo mismo que cualquier proyecto.

Como alguien ya ha señalado antes, el manifiesto dice:

Individuos e interacciones sobre el proceso

Le sugiero que eche un vistazo al plan presentado y le sugiera cambios. Recuerde que el Manifiesto dice que la cartera de pedidos nunca es final, sigue evolucionando.

Para que pueda llevar sus sugerencias al equipo. Si tiene un razonamiento válido y el equipo lo acepta, cualquier propietario de un producto que valga la pena lo considerará y evitará la acumulación de pedidos para reflejar la opinión de todo el equipo.

Este es el punto donde podría ir de dos maneras.

1. El propietario del producto y la empresa están de acuerdo con su razonamiento y pueden aumentar los recursos para cumplir con la fecha límite si esa es una opción O pueden optar por abandonar algunas funciones para cumplir con la fecha límite.

2. Es posible que aún quieran apegarse a su propia versión contra la opinión colectiva del equipo.

Si el resultado es # 2, entonces esto no es Ágil.

Si terminas con el # 1, entonces diría que el equipo está en el camino correcto, porque Agile no se trata solo de los desarrolladores "Respondiendo al cambio", también se trata de que la empresa pueda responder al cambio.

Imagine pedirle a alguien que le pinte una pared, una casa y luego una calle entera, ¿cuánto tiempo le daría a esa persona para que lo haga?

Cualquiera sea su respuesta, se equivocará. Eso es.

No hay forma de que tengan razón acerca de las fechas si no le preguntan a las personas que necesitan hacer el trabajo lo que piensan.

Por cierto, si usted (como equipo) acepta estas fechas, está equivocado allí.

Debe pedir un tiempo para trabajar en esta planificación junto con las partes interesadas, de modo que pueda establecer prioridades dependiendo de lo fácil y rápido que sea hacer las cosas.

Por ejemplo, tal vez el trabajo final tomará el doble de lo que pensaban, pero podrían usar una versión beta mucho antes de lo que esperaban.

Con todo, no puede dejar que la gente piense que podrá hacer X en tiempo Y si no puede o podría ser más rápido, es su responsabilidad dejar en claro lo que necesita en términos de detalles y tiempo.

No está aglie planeando no.

Pero si finges no sabes el plan y solo trabajas sprint por sprint. Podría ser aglie trabajando.

Siempre habrá fechas y presupuestos. Siempre existe el riesgo de que se los pase por alto o que los invadan, y cuando eso suceda, siempre tendrá que recurrir a un plan B.

Si ha estado trabajando de manera ágil, entonces el plan B es, con suerte, la última demostración de Sprint