martes, abril 03, 2018

¿Cómo desbloquear el miedo de tu cliente hacia la Agilidad? o ¿Cómo vender la Agilidad?




Hola a todos

A continuación les comparto una conversación que puede ayudar a desbloquear los miedos hacia la agilidad en tu interlocutor, ya sea PMO, Gerente, Director o Vicepresidente de IT, o alguien similar:

- [Promotor de la Agilidad]¿Cuánto del software que crees que actualmente y/o produces es usado?
- [Cliente] (Por lo general responde) entre el 50 % al 60%
- [Promotor de la Agilidad] El número generalmente es del 50% o menos (muestras como el Principio de Pareto también se cumple en Software(1)), pero que implica eso:
  • que el 50% del tiempo del ultimo año lo pudiste no haber trabajado y el resultado sería el mismo,es decir, se pudo haber trabajado 6 meses o solo medio tiempo y el resultado obtenido es el mismo.
  • al menos el 50% de tu dinero fue desperdiciado
  • que te esta pasando lo contrario a lo que querías controlar con tus contratos y fue construir lo que no era.
  • que el control predictivo no ha servido y ha generado un 50% de desperdicio (una de las razones es la inestabilidad actual de los requisitos (2))
  • que tuviste al menos 50% de reuniones innecesarias de requisitos, 50%  de software en el servidor (si no es más) que no funciona,  50% de pruebas innecesarias, 50% de reuniones de aceptación y pruebas UAT que no era necesarias.
  • que ese 50% de desperdicio es costo y tiempo de oportunidad que estas dejando de ofrecer a tus clientes externos e internos por hacer cosas que no servían.
-[Promotor de la Agilidad] por lo tanto en ágil tienes
  • Software de valor cada dos semanas 
  • Transparencia
  • Si el proveedor no da la talla, a lo sumo se perdió dos semanas o máximo un mes
  • puedes parar cuando quieras, o cuando una linea adicional de código no genere el ROI que compense su creación.
  • Llegas más rápido a la solución, no porque la gente codifique más rápido, sino porque construyen menos desperdicio, implicando llegar más pronto a la solución buscada
  • Liberas capacidad operativa que puede ser usada en innovación o en mejora operativa.
-[Promotor de la Agilidad] Si lo deseas comenzamos con un piloto pero debemos generar las condiciones que funcione la agilidad:
  • Acompañamiento en el proceso, pues no puedes gestionar ágil bajo la misma mentalidad de cascada o tradicional
  • Un Product Owner al menos un 50% del tiempo con el equipo
  • Un contrato ágil para el proveedor, o al menos tiempo y materiales.
  • Unas métricas de seguimiento ágil distintas a las de cascada
  • Un piloto con condiciones para ser exitoso (3)
  • Ambientes de desarrollo, pruebas lo más parecidos a producción y listos desde el inicio del primer sprint
  • Un equipo de desarrollo competente
  • Liberarse de los ANS o SLA, pues en Ágil no tienen mucho sentido (4)
-[Cliente] ¿Pero es que me han dicho que ágil es más costoso que cascada?
-[Promotor de la Agilidad] Pues sino te ha parecido muy costoso construir el 50% o más de software desperdicio durante los últimos años, no te va a doler hacer agilidad, además a cascada ya le has dado muchas oportunidades y en ocasiones no has ni entregado el proyecto, ¿por qué no te das el lujo de hacer bien ágil y ver que resultados obtienes?

-[Promotor de la Agilidad] ¿Cuando comenzamos?

Cerrando

La verdad no fue tanto un diálogo, fue más un monólogo, pero espero encuentres en este post elementos para ayudarte avanzar hacia la agilidad con tu interlocutor.

Bienvenido el feedback y éxitos en tu intención.

Saludos ágiles
Jorge Abad

Referencias

  1. Pareto se cumple en software, clic aquí 
  2. Los requisitos son más inestables hoy que en el pasado. clic aquí
  3. Condiciones para selección del proyecto piloto, clic aquí.
  4. Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones, clic aquí.

2 comentarios:

  1. Hola, cada vez estoy mas animado como consultor a ofrecerme encarnar el papel de maestro Scrum. Sin embargo confieso que siempre se me hace difícil promover un servicio cuyos beneficios no haya comprobado por mi mismo previamente y en este caso mas aún pensando en el breve período en que la propia metodología promete mostrar resultados positivos (entregas frecuentes y de calidad); me pregunto si se dispone de datos públicos donde se midan los beneficios del Scrum como modelo para la gestión de proyectos. En el ejemplo de este artículo mi mente me induce a indagar primero por qué no se usa ese 50% de código, aplicaciones, esfuerzo, etc. Saludos y gracias. AR

    ResponderEliminar
    Respuestas
    1. te animo a tener la experiencia de acompañar a un equipo Scrum. es la mejor forma de ganar argumentos . Respecto al desperdicio simplemente se piden cosas que no se usan y que se creían necesarias pero al momento de la verdad no lo fueron.

      Eliminar