8
2015
La agilidad esta condenada a la extinción, solo la puede salvar el CLIENTE
Léelo aprox. en 4:03 minutos.
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.
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.
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.
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?
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
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.
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.
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.
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
Últimos artículos de Pablo Soneira (ver todos)
- El Haiku: Nunca subestimes el corazón … (Rudy Tomjanovich) - hace 5 años
- Video del Viernes: Retrospectiva y la mejora continua - hace 5 años
- El Haiku: No nos atrevemos a muchas cosas porque… (Séneca) - hace 5 años
Otros artículos que te pueden interesar
3 Comentarios+ Escribir Comentario
¿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.
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.