¿Qué necesitas para tener éxito con Agile?

La adopción ágil puede fallar en algunas organizaciones, incluso trabajé para una empresa donde la cascada era la única (la verdadera) forma, pero solo porque probaron Agile en un proyecto y fallaron.

Cuando le pregunté a las personas que aún recordaban que (yo era un junior) me cerraron fuertemente, como si les estuviera recordando una pesadilla que realmente sucedió.

No sé por qué falló el proyecto. Hay recursos encontrados en la web por los cuales Agile falla en algunas compañías, pero la razón es principalmente económica. Así que pensé en preguntar aquí para recibir algunos comentarios.

¿Cuáles son las razones por las cuales la adopción ágil falla en algunas organizaciones? O, otra forma de decirlo ... ¿Qué necesitas para tener éxito con Agile?

Necesita gestión, clientes y desarrolladores cada uno para comprender y apoyar la forma de pensar ágil y los métodos ágiles. Con más detalle:

• La gerencia debe sentirse cómoda escuchando la verdad, en oposición a lo que tradicionalmente esperan escuchar (es decir, "sí, el proyecto está en camino" durante 11 meses ... luego, de repente "¡Uy! Tenemos que retrasar el plazo unas semanas ... erm, meses ... erm ... "al final). También deben sentirse cómodos dejando que cada parte haga (y se responsabilice) de su trabajo. Lo más destacado es que los desarrolladores deben tomar decisiones técnicas y estimaciones. Así que no hay controles estrictos ni microgestión.
• Los clientes deben comprender que Agile requiere su participación profunda y continua en el proceso de desarrollo, no solo "hacer el pedido", y luego recoger la entrega unos meses después. También deben sentirse cómodos por la falta de una especificación de requisitos fijos grandes y la aparente falta de compromiso del equipo de desarrollo para entregar lo que inicialmente se les solicitó.
• Los desarrolladores deben sentirse cómodos asumiendo la responsabilidad, tomando decisiones, comunicándose abiertamente y trabajando en equipo. Es decir, sin "propiedad de código", sin "vaqueros solitarios" y sin culpar infructuosamente a otros por problemas que el equipo mismo puede resolver.

En mi experiencia, es el primer punto que con mayor frecuencia se encuentra detrás de los proyectos ágiles fallidos, pero los otros dos también pueden causar problemas.

Actualizar

Por "gestión" me refiero no solo al gerente directo del proyecto, sino también a los niveles superiores. Como @Michael señaló muy acertadamente, algunas partes más o menos externas (por ejemplo, QA o un asignador de tareas externo) también pueden afectar el éxito / fracaso de los proyectos Agile, pero supongo que solo puede ser posible si su líder respectivo lo permite, y / o si las responsabilidades y las líneas de comando no están claras dentro de la organización.

Necesitas:

• Gente que está dispuesta a ser muy abierta y honesta . La visibilidad lo es todo porque necesita confianza en todo tipo de límites de capa.
• Clientes y gerentes que realmente quieren escuchar la verdad.
• Personas que están dispuestas y pueden redefinir sus roles para adaptarse a lo que se necesita en este momento .
• Libertad para cambiar procesos que no están funcionando en este momento .
• Personas que están dispuestas a admitir errores y revertirlos .
• La capacidad de unir entornos de construcción y prueba a voluntad . (Esto es más importante y más caro de lo que la gente le da crédito).
• Tantas pizarras blancas como puedas llenar tus paredes.

Parece muy simple, pero muchos de estos son grandes pedidos en esta industria.

Un proyecto ágil fallará con mayor frecuencia cuando un jugador clave se niega a ser ágil, o (peor) cuando alguien no está honestamente interesado en el éxito del proyecto o lo sabotea directamente. Este último puede matar cualquier proyecto (como una serie de otras cosas), pero los procesos ágiles le dan a las personas más flexibilidad, y eso incluye la flexibilidad para jugar políticas destructivas.

Ejemplos:

• QA insiste en que los clientes no pueden ver el software a menos que haya pasado un ciclo de prueba manual de un mes
• La administración impone plazos poco realistas
• El cliente se niega a priorizar los requisitos ("¡ todos tienen la máxima prioridad!")
• Alguien que no es un actor inmediato pero que tiene influencia política sigue asignando tareas largas y no relacionadas a un miembro clave del equipo, y el gerente del proyecto no puede evitar esto.

Solo puedo dar mi consejo desde mi propia experiencia personal.

Un empleador que había fallado totalmente en Agile. El trabajo se realizó sobre una base ad-hoc, las pruebas no existían y los requisitos se documentaron en correos electrónicos y actas de reuniones. El único método de desarrollo utilizado fue la anarquía, o 'codificación de disparar y olvidar'. La implementación de algún tipo de método de ingeniería de software habría sido imposible ya que los desarrolladores estaban demasiado sobrecargados para configurar algún tipo de software de gestión de proyectos de seguimiento de historias.

En otro empleador, nuestro equipo tenía un miembro heroico que intentaba desesperadamente establecer algunas de las mejores prácticas de Agile: teníamos un tablero de Kanban, rastreo de problemas, usábamos TDD y BDD (aunque no eran Agile en sí mismos, tienden a estar presentes en grupos Agile) . Desafortunadamente, nos faltaron cosas como puntos de la historia, sesiones de estimación, planificación de capacidad, gráficos de quemado, gráficos de velocidad, el tipo de material útil de gestión de proyectos ágiles que permite que el trabajo fluya sin problemas. Como síntoma clásico de que Agile está yendo mal, cuando nuestro tablero Kanban se llenó demasiado, compramos un tablero más grande: /

El lugar en el que estoy actualmente usa los puntos de la historia como una forma de planificar la capacidad con iteraciones de dos semanas, TDD, standups diarios, retrospectivas iteradas por iteración y programación de pares en la mayoría de las cosas. Esto se debe a la aceptación total de la administración y la educación del cliente.

Cree que para que Agile tenga éxito en una empresa, necesita lo siguiente:

• Gerentes de proyecto que entienden a Agile y que usarán las herramientas de manera adecuada.
• Desarrolladores que entienden a Agile, que son abiertos y honestos, con la disciplina que Agile requiere
• Compra del cliente. Deben reconocer los beneficios de Agile y estar dispuestos a escuchar los consejos de sus desarrolladores con respecto a lo que se puede desarrollar en un marco de tiempo determinado.

EDITAR: También es vital asegurarse de que comprende bien, por qué, cosas como las paradas diarias y las iteraciones cortas son útiles.

Mis experiencias con el fracaso ágil no han tenido nada que ver con la economía sino con la política corporativa / departamental / personal.

A nivel personal, simplemente hay algunas personas cuyas personalidades chocarán. Forzarlos a un equipo ágil, o peor aún a un equipo de programación emparejado, aumentará su aversión mutua hasta un punto de ebullición. Esto puede volverse muy desagradable, muy rápido y resultar en actos de sabotaje dignos de un reality show, convirtiendo las reuniones de scrum en un pelotón de fusilamiento circular o incluso peor.

Por encima de eso, hay gestión del desarrollo. He visto que esto sale mal de dos maneras diferentes.

Primero es 'Cargo Cult Agile', donde el gerente insiste en seguir el manifiesto y cualquier clase / libro / sitio web que lean exactamente sin comprender la razón y cuándo usarlos y cuándo improvisar. Es como si el administrador Ágil estuviera esperando que ocurriera la magia porque están siguiendo exactamente el hechizo. Esta implementación procrustean de Agile puede dar lugar a una serie de problemas que conducirán al fracaso del proyecto.

El otro es 'Agile In Name Only', donde se usa la terminología como sprints y scrum, pero en realidad son solo etiquetas sobre prácticas antiguas como la microgestión, la deshonestidad que sube y baja por la cadena de mando, largas reuniones de estado inútiles y otras cosas similares . Los proyectos fallan como solían hacerlo, pero ahora se puede culpar a Agile por ello en lugar de una mala gestión.

Por encima de eso hay una falta de aceptación por parte del cliente / cliente del proyecto. Estas personas tendrán sus propias prioridades departamentales y pueden resistirse a trabajar con un equipo de desarrollo, a menos que su gerencia haga una parte esencial de su trabajo. Esto puede empeorar por la política departamental o las políticas corporativas. Por ejemplo, tanto las operaciones como el marketing tienen aportes en un proyecto y su equipo termina haciendo girar sus ruedas ya que las dos partes no pueden ponerse de acuerdo en nada. Otro ejemplo es cuando la política corporativa sobre gestión del tiempo y facturación causa conflictos. De hecho, he descubierto que los clientes externos eran más fáciles de tratar que los internos. Les gustó la atención que obtuvieron del proceso y sabían que estaban obteniendo el valor de su dinero.

La OMI "Agile" falla cuando no hay una aceptación total de las prácticas. Lo que quiero decir es que Agile confía en que el "cliente" (generalmente otro departamento o gerente) entiende que:

1. No saben al 100% qué quieren que haga el software, incluso si piensan que sí.
2. No tienen idea de cuánto tiempo llevará completar, incluso si piensan que lo hacen
3. Se les informará cuánto tiempo llevará y deben aceptarlo o reducir las características para cumplir con una fecha límite
4. Tendrán que elegir características cada iteración y no obtendrán la aplicación completa y 100% completa de una sola vez.

Todas esas cosas son muy difíciles de tragar para la mayoría de los gerentes, y la OMI es la razón # 1 por la que es difícil hacer Ágil: los gerentes están acostumbrados a decir "Se hará por fecha x" y que se haga "Mágicamente" para esa fecha (después de que los desarrolladores hayan dedicado 80 horas a la semana) y es 180 darse cuenta de que el equipo de desarrollo le dirá que este proyecto se realizará en 3 meses, y que la única opción que tiene es aceptarlo o reducir los requisitos para obtener Lo hizo antes.

En segundo lugar, debe haber confianza en el equipo de desarrollo. Yendo de la mano con el número 1 anterior, muy pocos gerentes parecen confiar en la opinión de las personas contratadas como expertos; si un desarrollador dice que un proyecto tomará x cantidad de tiempo, y x es más de lo que la gerencia cree que tomará, nunca se trata de "No sé cómo escribir software, por lo que el desarrollador probablemente tenga razón" es más " Esos desarrolladores que no sirven para nada quieren burlarse en el trabajo, por lo que dijeron que tomará 3 meses ".

Tercero, su equipo de desarrollo necesita estar detrás de Agile; eso significa no cortar esquinas y no ignorar la retroalimentación constante y las preguntas de "¿Es esto correcto? Cuando sucede x, ¿qué debería hacer Y?". Incluso si no sigue TDD o programación de pares, su equipo de desarrollo debe ser lo suficientemente competente como para seguir los procesos ágiles (por ejemplo, sprints, iteraciones). Esto implica tener un líder / gerente que pueda estimar adecuadamente las tareas y comprenda que no es necesario que cada función sea una prioridad, está bien tener una acumulación de trabajo, y no debe sobrecargar a las personas.