Jan
8
2015

La agilidad esta condenada a la extinción, solo la puede salvar el CLIENTE

Parece que los términos de agilidad son una novedad en el mercado y que van a ser la salvación de los problemas en el mundo del software. Pero nada más lejos de la realidad, en la Cronología de la Historia de las Metodologías Ágiles, encontramos que Kanban se empezó a utilizar después de la II Guerra Mundial en Japón (Toyota) y que el primer método incremental e iterativo se aplicó en el desarrollo de software en los años 50, incluso son anteriores a la definición del modelo en cascada.

Las metodologías ágiles tienen muchas ventajas y hay que saber cómo y cuándo utilizarlas, pero mi recomendación es que te cases antes con el cliente, para poder establecer un marco de trabajo colaborativo.

Extinción de la agilidad
Extinción de la agilidad

 

Método incremental e iterativo


Lo más sencillo para explicar un concepto o una idea es recurrir a un ejemplo y que mejor forma que la experiencia sufrida por uno mismo o por un “amigo”.

Resulta que un “amigo” se cambió de casa y en general como la casa nueva era más grande que la anterior, no hubo ningún problema en colocar todos los muebles en la casa. Pero resulta que el salón, aun siendo más grande, tenía una forma diferente, era más rectangular y este fue el inicio de la puesta en marcha de un método incremental e iterativo para recolocar todos los muebles en la casa nueva.

 

Agilidad, siempre con el cliente


El “Product Owner” no tenía demasiada visión espacial y unos planos con todas las medidas exactas de los muebles y las paredes del salón no eran suficiente para tomar la decisión de que mueble poner en cada posición. El método de desarrollo en cascada, directamente se catalogó como no viable, “no-go”.

La decisión era clara, en cada uno de los “sprints” planificados se iba a entregar una versión del producto real y terminado. El “Product Owner” no paró de cambiar los requisitos, hasta que vio un producto que cumplía sus necesidades.

Agilidad: En ocasiones… no me cambian los requisitos


Pulsa aquí para tuitear la frase

Resumiendo un poco las acciones realizadas por “el equipo de desarrollo”: los sofás (uno de tres plazas y otro de dos, con pesos y dimensiones considerables) modificaron su disposición en cada uno de los sprint, lo mismo sucedió con la librería (tres módulos de dos metros de largo), los cuadros, la mesa del comedor, la alfombra…

 

¿Quieres llevar tus Proyectos a otro nivel?

En tu mano tendrás 15 Lecciones sobre liderazgo, equipo, motivación, planificación, éxito,... extraídas de Juego de Tronos y explicadas de forma sencilla y práctica.
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
¡Las quiero!

En mitad de uno de los sprint, se me ocurrió la idea (quiero decir a mi amigo) de hacer fotos a la disposición de los muebles, lo que finalmente ayudó a no tener que repetir movimientos de elementos y dicha mejora consiguió que mis huesos (los de mi amigo) no terminaran en el hospital o al menos en la cama de un fisioterapeuta.

Agilidad, coste del cambio
Agilidad, coste del cambio

 

Necesitamos al cliente cerca


Es evidente que en este caso la labor del cliente es muy importante y su dedicación es mayor que si hubiéramos elegido un “método en cascada” para desarrollar nuestro proyecto. En primer lugar para definir y validar los requisitos, pero no menos importante es su participación en la validación de la solución.

Agilidad: Cliente más cercano, más participación, más cariño


Pulsa aquí para tuitear la frase

Por último y no menos importante, ya que estamos ante un “matrimonio” con el cliente, lo que lleva asociado un contrato, es contestar a la siguiente pregunta:

¿Quién paga los costes de los cambios de requisitos?

Si me tienes moviendo muebles todo el día, facturamos por los trabajos realizados. Hay proyectos que no son previsibles y por lo tanto “jugamos a prueba y error”. Ni el cliente, ni el proveedor pueden establecer un precio fijo (proyecto cerrado), por un producto que no sabes ni como lo quieres.

 

Un verdadero cambio


La agilidad está condenada a la extinción si el cliente no está involucrado en el cambio. Un cambio con todas las letras, un cambio real, no valen pequeños ajustes, es necesario un cambio de mentalidad, un cambio de organización, hay que creer en el cambio. Y para hacer esto, el cliente debe estar convencido y en muchos casos hay que demostrar las bondades de la forma de trabajo y lo que va a ganar con él, solo así conseguiremos el “SÍ QUIERO”.

Hay que saber construir un equipo, como el ejemplo que presentamos en el artículo Construir un equipo. Los Angeles Lakers 80s sobre una idea, que es la agilidad. Cada uno debe aportar al proyecto lo que mejor sabe hacer, todos debemos trabajar para lograr el objetivo, el mismo objetivo para todos, un único objetivo.

 

Consigue Más de 100 Libros gratis

Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo


The following two tabs change content below.
Senior IT Consultant | Digital Transformation | Agile | PMO Manager | Blogger | SMC, PMP. Si quieres conocerme en más detalle consulta mi biografia

3 Comentarios+ Escribir Comentario

  • Hola Pablo,

    Como he comentado varias veces en los últimos días en Twitter, PMP y agilismo están condenados a entenderse. Las metodologías ágiles resuelven problemas que la gestión clásica de proyectos no puede (ej, escenarios con gran incertidumbre en el alcance), y viceversa (a mi entender, fallan para proyectos de “gran tamaño”, pero es una opinión personal). Como decía Aristóteles, “la virtud está en el término medio”. El agilismo es un enfoque posible más para la planificación y ejecución de un proyecto, y hay que saber coger, para cada caso, lo mejor de cada paradigma.

    Por lo demás, me solidarizo con tu amigo 🙂 Yo tengo “otro amigo” que ha vivido una situación parecida este verano: habitaciones más grandes y forma distinta de las mismas. La “Product Owner” ha sido inflexible, pero al final el proyecto ha sido un éxito (salvo para los lumbares de mi amigo 🙂 )

    Un abrazo,
    Ängel

    • Totalmente de acuerdo con tu visión. Si tu amigo necesita un fisio, te envío el teléfono de uno muy bueno :).

      Sobre proyectos de gran tamaño tenemos en cartera un par de artículos y un vídeo del viernes que estoy seguro de que te va a gustar.

      Muchas gracias por tus comentarios Ángel.

      Un abrazo y feliz año

      Pablo

  • Comparto en comentario de Angel, y tomando como referencia un post anterior del laboratorio, cada proyecto tiene características únicas, y siempre las metodologías a utilizar se deberían adaptar a estas características, me inclino también por el termino medio.

    Además de esto, muchos departamentos de sistemas infortunadamente perciben el agílismo mas como moda.

    Saludos.

¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

No te pierdas nada de lo que publiquemos…

Comparte lo que te gusta…

¡Síguenos en Twitter!



¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 15.246 suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 15.246 suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 15.246 suscriptores

Leer entrada anterior
lo mejor de 2014
Lo Mejor de 2014 (y II)

Continuamos con nuestra lista de lo mejor de 2014. Ahora vamos a ver los 5 mejores artículos del año. ¡Acompáñanos!...

Cerrar