Es de esas cosas que nunca dejarán de “maravillarme”, llegar a una empresa, grande generalmente, y ver pegado en la pared un flamante poster de casi dos por dos metros, LA METODOLOGÍA, repleto de cajas de colores, flechas, líneas, letras pequeñitas, etc. Normalmente, además, se usa un acrónimo rimbombante para nombrarla, para ser precisos, algo así como “La NUME”, “esta es la NUME (NUestra MEtodología)”.
La cosa puede ir incluso más allá, y que alguien te diga con orgullo… “Nos la hizo Potatoes Consulting Group”. Pon el nombre en inglés de la consultora grandota que se te ocurra. O peor… “Se la compramos a Tomatoes Consulting Group”. Por cierto, no puedo reprimirme y evitar decirlo: estoy hasta el gorro de ir a sitios para que alguien me pida consejo para solucionar una solución absurda que previamente le había dejado una consultora tipo “Cucumber Consulting Group”, eso si, habiendole esta cobrado previamente cantidades estratosféricas.
Volviendo a lo nuestro, lo de pensar que puede, debe, haber una única e inamovible metodología para todos y cada uno de los proyectos, es uno de esos errores que sobre todo se veían más en los 90, cuando se buscaba la metodología universal (RUP, Métrica 3, etc., aquello de las 3 metodologías más importantes en los 80 y los 90).
Si no te es suficiente con tu experiencia y sensaciones para reafirmarse en que es muy difícil, imposible, tener una única e inamovible metodología para todos los proyectos, no te hace falta buscar mucho para encontrar multitud de estudios que hablan de ello. Fíjate que hasta las “metodologías” ágiles son mal llamadas así, ya que, realmente, son y se autodenominan “frameworks”, que deben adaptarse a las circunstancias (ya hablamos de este tema en concreto en Las metodologías ágiles no existen).
Quizá uno de quienes con más fuerza hablaron de este tema fue Cockburn, uno de los firmantes del manifiesto ágil, y al que tuvimos la oportunidad de entrevistar por aquí, en Entrevista en el blog: Alistair Cockburn. Decía él que había múltiples variables clave para la selección de una metodología, que hacían que no hubiera una única ni por empresa ni por proyecto: el tamaño del equipo / distribución, la criticidad del proyecto, las prioridades del proyecto y valores culturales del equipo. De hecho, para argumentarlo y guiar en la elección de una metodología, expuso 4 principios:
Principio 1. Se necesita una metodología más grande cuando más personas están involucradas.
Principio 2. Más exactitud visible es necesaria para proyectos con mayor criticidad, donde más dañino puede ser un defecto no detectado.
Principio 3. «El peso cuesta»: un aumento relativamente pequeño en el tamaño de la metodología añade una cantidad relativamente grande de costes al proyecto.
Principio 4. La forma más eficaz de comunicación es la interactividad cara a cara.
Dicho lo cual, además, aparece hasta la opción de que no sólo no haya una única metodología universal, dependendiendo la metodología final del proyecto en concreto, sino que además existe la posibilidad de que esa metodología del proyecto… cambie según avanza la vida del mismo.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier, permíteme antes de nada felicitarte por tu blog.
En segundo lugar no he podido empezar evitar una carcajada en el segundo párrafo puesto que creo que somos muchos los que hemos vivido situaciones así… Rehacer un sistema que habían dejado a medias y por el que había pagado por adelantado y cuando das tu precio (inferior al que ya han pagado) se escandalizan o venir a buscarte después de haber rechazado tu propuesta para que arregles lo que ´ha hecho el que se quedó con el trabajo por menos dinero…
En cuanto al tema que comentas en el post, si me permitís la comparación un proyecto de desarrollo es como un niño… A todos no les viene bien los mismos métodos de aprendizaje y cada uno tiene sus propios vicios (clientes)… Intentar adaptar LO MISMO siempre es como girar el volante a la derecha siempre que te encuentras un problema en el coche… En función de la situación hay que decidir… No puedes implantar una metodología ágil en un cliente que se desentiende del proyecto, del mismo modo que no puede usar una metodología clásica con un cliente que está encima «colaborando» e involucrado en el proyecto.
Lo mismo se puede aplicar a las empresas… No tiene porque funcionar igual una metodología para un departamento de RRHH que para uno técnico o uno financiero… Cada uno tiene sus vicios sus formas y «su cultura del trabajo»… Por no hablar de intentar hacerlo de forma global en la empresa…
<> es básico para aplicar cualquier tipo de metodología o framework ágil.
Salu2
«La forma más eficaz de comunicación es la interactividad cara a cara.» es básico para aplicar cualquier tipo de metodología o framework ágil.
Siempre he pensado que uno de los criterios fundamentales para elegir una metodologia es el grado incertidumbre de los requerimientos
Aspecto que influye y cambia todo, cómo se harán las pruebas, cómo se harán las entregas, cómo será el ciclo de vida…