Cuando Agile sale mal [cerrado]

Estoy escribiendo un curso de Agile para algunos de los chicos nuevos que estamos incorporando recientemente, y quiero agregar una historia de advertencia para que entiendan que Agile no está destinado a todos los proyectos.

Mi problema es que, debido a la naturaleza de los proyectos en los que trabajo con Agile, ha funcionado bastante bien hasta ahora, honestamente no puedo señalar qué puede salir mal y por qué cuando lo usa en el tipo de proyecto equivocado.

¿Qué cosas hay que tener en cuenta cuando un proyecto Agile sale mal?

El mayor fracaso con los equipos "ágiles" es el resultado de lo que se llama Cargo Culting . Esencialmente, los equipos quieren los efectos de los equipos ágiles exitosos, por lo que imitan las acciones visibles

• Standups diarios (que duran aproximadamente una hora)
• Romper el trabajo en sprints
• Historias de usuarios (que generalmente son poco más que una oración pero se espera una estimación)

Esos son los tres que verá consistentemente "aplicados" en estos entornos, pero muy poco compromiso para ser realmente ágil. De hecho, escuchará a la gerencia decir que estamos "haciendo ágilmente". (Huir con esas dos palabras es una mala señal).

También escuchará mucho acerca de la deuda técnica, pero su definición de deuda técnica es "hágalo rápido y sucio y tal vez lo solucionaremos más adelante". (Traducción: vamos a hacer que parezca que estamos preocupados por la mantenibilidad, pero en realidad mantendremos la misma mentalidad de sala de calderas porque eso es lo que nos funcionó en el pasado).

Otras frases clave: "Sé que estas historias no están completamente definidas, pero lo estamos haciendo ágilmente para poder solucionarlas a medida que avanzamos".

"Estamos haciendo un desarrollo ágil, por lo que deberías poder acomodar lo que necesito dentro del sprint cuando lo identifique".

"No podemos bloquear nuestras historias comprometidas al comienzo del sprint porque las necesidades siguen cambiando a mitad del sprint".

El indicador clave sobre si un proyecto ágil será exitoso es si el líder del proyecto (scrum master o cualquier otro rol) ha tenido experiencia o capacitación formal para liderar un proyecto ágil. Con demasiada frecuencia, he visto a personas leer sobre Agile en un libro o tomar un curso de dos días sobre ser un maestro de scrum y pensar que tienen las habilidades para implementarlo con éxito. Lo siento, no está sucediendo capitán.

Las personas que no entendieron qué es ágil (¿qué era?) Y lo aplicaron a:

• clientes que no están disponibles para comentarios hasta la fecha límite
  ... y amenazan con acciones legales después;

• gerentes que mantienen a los desarrolladores alejados del cliente (probablemente porque están un poco mal pagados y podrían saltar barcos, ir a trabajar para dicho cliente) y jugar un juego del " teléfono roto " en un intento desesperado (aunque a menudo exitoso) en parecer ocupado y útil,

  Ver también: manejo de hongos , también conocido como "guardado oscuro, alimentado con estiércol" y jefes de pelo puntiagudo . :)

• equipos que son demasiado grandes para ir a cualquier parte;

• empresas que mantienen en su nómina una vez reconocidos diseñadores arquitectura de sistema que están desviando desesperadamente atención del hecho de que perdieron de vista por completo la nave de codificación real, por overdesigning magnífica, poco prácticas, UML, de difícil darse cuenta de Familias sagrada .

Agile no es adecuado para contratos de plazo fijo o precio fijo. Una vez que te hayas registrado para una bestia así, tienes que entregar. Agile es muy bueno en el desarrollo continuo para siempre, ya que los clientes cambian de opinión y "aclaran" sus requisitos. Eso no te ayuda el día que se acaba el dinero, pero aún así tienes que terminar el trabajo.

Sin embargo, Agile es muy bueno para la fase posterior al proyecto cuando realiza actualizaciones incrementales y correcciones de errores.

El otro aspecto en el que Agile falla no es culpa de Agile, es culpa de las personas que insisten en todo lo viejo, como la documentación completa del proyecto, los diseños iniciales y las malas líneas de comunicación. (El manifiesto ágil medio arsed ).

Aquí hay algunas preguntas que pueden ser útiles para buscar una respuesta en términos de encontrar un ejemplo donde un intento de Agile puede ir mal:

• ¿Es Agile la nueva microgestión?
• El proceso ágil: ¿cómo y qué debe documentarse?
• Combinación correcta de planificación y programación en un nuevo proyecto

¿Alguna vez has oído hablar de "pseudo Agile"? Aquí hay un par de entradas de blog al respecto:

• De pseudo-ágil a cascada: el camino de una pequeña y nueva compañía de software
• Pseudo ágil!

Hay algo que decir para las empresas que pueden tener su propia visión de lo que es ágil y convertirlo en otra cosa.

Trabajé en un equipo ágil altamente exitoso, así como en algunos que intentaron Agile, pero no pude hacerlo funcionar.

El exitoso tenía los siguientes elementos:

• Requisitos verdaderamente "ágiles". Hubo historias de usuarios y las codificamos.
• Disponible propietario del producto. Si una historia de usuario de la que estaba codificando estaba incompleta, podría ir fácilmente al propietario del producto, preguntarle qué debería estar allí, agregarla y completar el código.
• Compromiso con el proceso y darse cuenta de que era una curva de aprendizaje.
• Equipo enfocado
• Gerentes que conocían y entendían la forma ágil de hacer las cosas y se comprometieron a hacerlo funcionar.

El exitoso equipo hizo Agile, y lo hizo muy bien. Creo que si no tiene ninguno de esos puntos anteriores, podría fallar con bastante facilidad. La primera y la segunda cosas van de la mano, y si no tienes eso, entonces Agile no funcionará.

El equipo en el que estaba que no le fue bien a Agile también tenía algunos elementos:

• Falta de compromiso de la gerencia. La gerencia no creía en la filosofía y, como resultado, dudaba en comprometerse.
• Requisitos documentados en otros lugares que no sean historias de usuarios. Ver arriba sobre el compromiso de gestión. Además, teníamos analistas de requisitos altamente pagados y herramientas de requisitos grandes y costosas que alguien necesitaba para justificar el uso.

Agregaré a las excelentes respuestas ya publicadas que, por mi experiencia, ágil y específicamente Scrum solo funcionará si la gerencia Y el equipo están dispuestos a dar mucha visibilidad a lo que está sucediendo.

Esto significa que en las empresas públicas (gobiernos, por ejemplo), será muy difícil hacer que funcione correctamente.

Ágil en mi opinión se trata de la cultura del equipo que está practicando. Si la cultura apesta, los miembros del equipo no se llevan bien y las personas no están colaborando para cumplir con los compromisos de sprint, entonces la cultura o el equipo es deficiente.

Sin embargo, no diría necesariamente que Waterfall funcionará necesariamente en un entorno así, no es una situación en blanco y negro, muy poco es realmente en blanco y negro.

Un buen equipo ágil es comunal. Tienen un espíritu tribal de comunidad donde todos los miembros están trabajando para lograr los mismos objetivos. El equipo tiene éxito o falla juntos. Trabajan juntos para resolver problemas. Un miembro del equipo detendrá lo que está haciendo con sus tareas para ayudar a un miembro del equipo con dificultades. Todo es hundirse o nadar.

Cuando este no es el caso, rápidamente se hace evidente lo que está mal. Si los miembros del equipo están sentados, escribiendo en sus computadoras portátiles o enviando mensajes de texto, o dividiéndose en zonas durante el standup diario, entonces no tienes un buen equipo ágil. Si sus gerentes de proyecto están aplicando todos los procedimientos, definiciones y terminologías de Scrum, pero todo el mundo solo mantiene la cadencia y presta servicios, entonces esto es solo una farsa bastante evidente de lo que realmente es Agile, y esto de muchas maneras conduce a la disfunción del equipo, la ineficiencia , plazos vencidos y proyectos fallidos.

Failing Agile está en muchos aspectos peor que un equipo de Waterfall moderadamente exitoso y probablemente tenga tasas de éxito de proyecto más bajas.

No lo sé por experiencia personal, pero hipotéticamente, hay muchas circunstancias en las que ágil no es la mejor opción.

• Proyectos cuyo producto es crítico para la vida o la propiedad: por ejemplo, no desea utilizar Agile para desarrollar el software que ejecuta su marcapasos. ¿Por qué? Porque tiene una tolerancia cercana a cero para los errores. Considere un ejemplo clásico de error de programación dentro de la medicina con respecto al Therac 25 . De acuerdo, no fue construido con agilidad, pero el punto es este: desarrollar vida o propiedad crítica no es un lugar para decir, "limpiaremos eso en el próximo sprint" o "no necesitamos grandes, solo buenos suficiente."

• Proyectos con demasiados desarrolladores junior: Agile espera una cierta cantidad de autonomía dentro del grupo participante. Si no hay suficiente experiencia en el equipo, esa autonomía puede funcionar en su contra.

• Proyectos que requieren un mayor grado de control o planificación que lo que tradicionalmente se ofrece con Agile.

Supongo que alguien más intervendrá y ayudará con mejores ejemplos, o rechazará este bocado que he escrito ;-).

Solo recuerda que cuando la única herramienta que tienes es un martillo, cada problema parece un clavo. No todos los proyectos son uñas.