¿Cómo convences a un cliente para que use métodos ágiles?

Gradualmente

Si trata de convencer a su cliente (o jefe, gerente, colegas, etc.) para que haga algo totalmente diferente a lo que solía hacer, reaccionará de una de las formas típicas en respuesta al cambio : aceptación. , pánico, rechazo, etc. Por lo tanto, recomiendo una adopción gradual de métodos ágiles hasta que esté allí, por ejemplo:

1. Comience por tener reuniones semanales con el cliente para discutir los "requisitos prioritarios" ( Características pendientes ). Asegúrese de que el cliente establezca las prioridades y que estén en unidades de Story Points (con su orientación).

2. Cuando agregue elementos a la lista, escríbalos en un lenguaje de ' Historia de usuario ', pero lo suficientemente familiar para no confundir/alienar al cliente. Si ya tiene algún tipo de especificación o casos de uso, adáptelos, pero no caiga en la tentación de volver a escribirlos por completo; es probable que el cliente no pueda dar el salto.

3. Tenga entregables regulares para que el cliente pueda ver el progreso y los beneficios de la nueva forma de trabajar. Asegúrese de que sepan lo que acaban de recibir, cómo llegar a él (URL, sitio de descarga, etc.) y haga un seguimiento para asegurarse de que lo hayan probado.

4. Obtenga comentarios sobre estos entregables en la próxima reunión semanal para que el cliente pueda refinar la Lista de funciones de acuerdo con lo que quiere ver a continuación. Tómese el tiempo para delinear este mecanismo de 'elegir historias de usuarios principales, implementar, entregar, revisar' para presentar el concepto de una ' iteración ' o sprint .

5. Asigne estimaciones de costos a cada historia de usuario para que el cliente pueda comprender el esfuerzo requerido para lograr cada historia de usuario y pueda aprender cuánto se puede lograr en una iteración. Sea abierto con el cliente sobre el juego de planificación que se utilizó para obtener las estimaciones.

6. Asegúrese de que el cliente pueda ver cuántas historias de usuario se han logrado hasta ahora (presupuesto utilizado) y obtenga una comprensión clara de cuántas de las historias restantes se pueden completar en el tiempo/presupuesto restante.

He hecho esto con éxito con varios clientes y descubrí que después de cumplir sus promesas durante unas semanas, confiaron totalmente en nosotros a partir de ese momento y se centraron más en las funciones que querían con más urgencia que en si las íbamos a cumplir o no. No necesariamente los expusimos a toda la terminología, pero 'recibieron' las actualizaciones periódicas y una discusión abierta y honesta sobre qué características se implementarán a continuación.

No hay nada aterrador, incorrecto o extraño en las metodologías de proyectos iterativos (como Agile, XP o Scrum), simplemente no es el método de cascada 'tradicional'. Tener una buena explicación humana ayuda:

En la construcción tradicional, no se pueden modificar los cimientos sin derribar primero una casa, un bloque de oficinas o un puente. Esta es una de las razones por las que primero debe tener los cimientos correctos antes de pasar a las paredes y el techo.

En otras industrias, puede cambiar cualquier parte del sistema sin tener que empezar de nuevo. Por ejemplo, en la Fórmula Uno, puede levantar el automóvil para cambiar las ruedas; no necesita desmontar todo el automóvil.

Por lo tanto, algunos proyectos son muy adecuados para un enfoque iterativo/cíclico donde la solución inicial se refina muchas veces hasta que es la correcta.

He sido deliberadamente vago con la terminología ágil para transmitir el mensaje más fácilmente y he tenido un día largo, por lo que puede que me haya confundido un poco.

Una de las buenas respuestas es "simplemente no".

Es perfectamente posible ejecutar un proyecto ágil sin mostrarle al cliente la forma exacta en que trabaja el equipo. Además, muy a menudo el cliente no estará interesado en eso. El truco es que tampoco estarán interesados ​​en ser parte del equipo. No participarán activamente en la priorización o demostración del producto al final de la iteración. Por lo general, el mejor método aquí es emular al cliente dentro de un equipo de proyecto. Muy a menudo, la mejor persona para hacer esto es un gerente de proyecto que conoce bien al cliente y los méritos del proyecto.

Otra respuesta es: haz que todos ganen

Durante algún tiempo pensé que era muy, muy difícil construir algún tipo de contrato ágil que sea beneficioso para todos y limite los riesgos en ambos lados: el cliente y el proveedor. Esta presentación de Paul Klipp (las diapositivas están aquí ) es el mejor enfoque del tema que he visto hasta ahora. Brinda incentivos a ambas partes para terminar más rápido y comparte el dolor de lidiar con el desliz infligido por los cambios de alcance.

También puedes intentar mostrarles

Este es complicado ya que asume que puedes convencer al cliente para que lo pruebe. Sin embargo, un argumento bastante bueno que escuché que puede cambiar la opinión del cliente aquí es dejar que el cliente abandone el proyecto después de las primeras dos o tres iteraciones sin costo alguno. Luego, tiene tiempo para mostrar el valor de su enfoque, posiblemente presentando cómo el compromiso del cliente ayudó a mejorar el resultado de estas primeras iteraciones.

Las dos respuestas ya dadas son excelentes y las apoyo. Solo quería agregar una fábrica de modificación. En un panel Agile reciente, uno de los oradores hizo una muy buena observación. "Si las cosas funcionan y funcionan bien, conseguir que alguien cambie a un sistema completamente nuevo será muy difícil de vender. Presentar un cambio a Agile tendrá una mejor tracción si las cosas ya no funcionan".

Luego, debe adaptar su respuesta ágil a lo que realmente no funciona. No solo se lanza en picado y "se vuelve ágil", tiene que ver lo que ha estado sucediendo y migrar a partir de eso.

Mark, como consultor/entrenador, no puede querer cambiar más que su cliente. Tienen que querer cambiar y eso puede significar que tienes que esperar y dejar que fracasen. Tal vez ya están fallando pero simplemente no pueden verlo. Puede intentar señalar esto, pero es una pendiente complicada que a menudo conduce a la fragmentación de la relación. Es mejor alejarse y recibir una invitación más tarde cuando estén listos para cambiar.