En el artículo de hoy quiero profundizar en algunos conceptos o ideas erróneos que circulan por las redes.
Antes de nada el concepto «moda» lo he puesto entre comillas, ya que no considero la Agilidad una moda (lleva muchos más años en el mercado de lo que muchos piensan), pero si que está de moda.
Como toda tendencia ha generado un «boom» de formaciones, certificaciones, proyectos de cambio en las organizaciones, PMO Agiles, etc
Pues bien, si todo lo de arriba ha servido para que nuestros proyectos aporten más valor y se hayan optimizado los procesos y herramientas de trabajo, entonces nada más que decir, adelante con ello si te funciona.
Pero si no es el caso, si no te está aportando valor, ¿tiene sentido continuar con ello simplemente por que es tendencia y a otros les funciona? Creo que esta pregunta es fundamental y muchos ni se la plantean.
¿Que está sucediendo en el mercado? Pues como lo Agile está de moda y es tendencia se está saturando y desvirtuando, aquí es donde aparece el concepto de «fake agile»
Es fácil encontrarse con lo siguiente:
- Proyectos ágiles con contratos a precio fijo (llaves en mano)
- Quien afirma que Scrum es Agile y Agile es Scrum o no distingue la diferencia entre ambos conceptos
- Quien considera que Project Manager = Scrum Master independientemente de los skills o aptitudes que pudiera tener
- Scrum Masters de titulín que hace 6 meses eran programadores y ahora son «excelentes gestores emocionales» sin formación alguna, más que un curso de día y medio con el certificado de turno.
- Agile Coaches que predican el cambio en las organizaciones a base de PPTs, juegos y mucho LEGO, sin aportar experiencia, lo que suele dejar más problemas que soluciones.
- Ofertas de trabajo que buscan «Project Managers Juniors Agile»
- Empresas que dicen que aplican Scrum y luego te das cuenta que no hacen seguimientos, ningún tipo de daily , ni retrospectivas.
Y un sin fin más de afirmaciones erróneas o con conceptos aberrantes.
A mi personalmente lo que mas me «duele» es escuchar cada dos por tres la frase de «El PMP está obsoleto, ahora los proyectos se gestionan todos con Scrum»
Esta simple afirmación tiene tantos errores conceptuales juntos, que si te paras a pensar te puede explotar la cabeza..
- El PMP no es más que una certificación del PMI, ni es un método de trabajo, ni una filosofía, ni un estándar: es un examen. En tal caso se debería hablar del estándar en el que se basa mayormente esta certificación: el PMBOK.
- Se compara un estándar internacional reconocido en gestión de proyectos como es el PMBOK que recoge desde hace muchos años las mejores prácticas del sector, con un marco de referencia agile como es Scrum (es decir están mezclando peras con manzanas)
- Ni mucho menos todos los proyectos se gestionan con Scrum, ni tan siquiera tiene sentido aplicar Scrum en muchos casos.
- El PMBOK ya en su Sexta Edición reconoce la utilidad de las prácticas ágiles bajo ciertas circunstancias y aparece el concepto de «tailoring» donde se indica que dependiendo de las circunstancias tendrá más sentido aplicar un enfoque u otro.
Yo personalmente recomendaría a cualquier profesional del área de gestión de proyectos, independiemente del sector, conocer el estándar PMBOK, aunque luego vayas a trabajar como ScrumMaster.
Esta recomendación anterior la hago desde mi experiencia, teniendo en cuenta que el PMBOK te habla de integración, te habla de gestión de costes, te habla de gestión de riesgos, de la calidad en el proyecto, el proceso contractual y de adquisiciones, etc
Conceptos los anteriores que son básicos para cualquier profesional del sector y sin los cuáles vas a ir muy perdido en un ambiente empresarial (a no ser que los hayas ido adquiriendo a base de experiencia a lo largo de los años).
En un curso de Scrum, te van a explicar el marco de referencia Scrum y de lo de arriba en muchos casos ni se va a mencionar.
Esto nos deja con perfiles sin experiencia en gestión, que hacen una formación de Scrum, y al día siguiente ya están aconsejando a empresas en como hacer la gestión del cambio de entornos tradicionales a ágiles sin tan siquiera haber gestionado nada en toda su carrera profesional.
Y lo peor, las empresas que los contratan a ciegas con la esperanza de poder ponerse cuanto antes el «sello Agile» en sus proyectos y estar «a la moda».
Precisamente un ScrumMaster debería ser un perfil con cierta experiencia, con sólidos conocimientos de gestión y sobretodo y por encima de todo esto, un buen nivel de «habilidades blandas» o «soft skills» para poder acompañar al equipo y desbloquear problemas.
Dicho lo anterior ¿Qué opinas de la «moda» Agile? Te has encontrado en tu día a día con situaciones similares a las que describo en este artículo?
Como siempre tus opiniones y comentarios serán bien recibidos.
Es muy exacto el panorama que planteas. En primer lugar, se vende Agile como solución mágica para aumentar la productividad de los equipos y bajar costes. Gerentes que quieren resultados demostrables en un año deciden convertir al agilismo a su área de IT. En el mejor de los casos contratan cursos, en el peor elijen a algún desarrollador destacado y le dicen «averigua de qué va esto de Scrum, que todo el mundo lo está haciendo y les va muy bien». Te encuentras con niños certificados -tanto SM como PO- que son incapaces de gestionar su rol. Los PO no entienden nada ni tienen formación comercial mínima, porque son técnicos. Los SM, influenciados por sus jefes, juegan a la gestión asamblearia: el grupo siempre puede decidir lo que quiera si es por mayoría, aunque elija barbaridades. Y los Agile Coaches que mencionas, son en su mayoría gente que jamás gestionó nada, que no sabe lo que es la presión de tener que cumplir con objetivos, y que como bien dices, te hacen muchos juegos y te recalcan que Scrum democrático, que las viejas prácticas autoritarias ya no son aplicables. Entonces si un Equipo decide que no quiere hacer daylies o retrospectivas porque consideran que no aportan valor, no se hacen. El SM sólo puede opinar. Respecto a las definiciones incorrectas que pones de ejemplo, te agrego una: Agile-Scrum legacy. «Ah, lo que tú planteas de orientarnos por la Guía es Scrum legacy, aquí hacemos lo más moderno». Saludos
Muchas gracias Pedro por aportar tu opinión y experiencia a la discusión. Un saludo!
Excelente artículo, de verdad, hemos entrado en una época en la que, por acuñar términos sobre tal o cual experiencia ya eso pretende hacernos «expertos» en esas técnicas. Muchas empresas te contactan para ofrecerte un proyecto a desarrollar y a veces ni tan siquiera se preocupan por tus conocimientos en el lenguaje de desarrollo a utilizar sino que lo primero que salta a la palestra es si utilizas metodologías ágiles, todo ello es importante pero no hay que pasarse.
Hola Carlos,
Gracias por participar, muy de acuerdo con tu frase «todo ello es importante pero no hay que pasarse» 🙂 Saludos!
Hola Alejandro. Soy ingeniero informático PMP, CSM y mas y llevo en la informática unos 18 años estando en todas las trincheras y en muchos tipos de negocios y teniendo en cuenta que cada vez me encuentro más “gestores”, expertos en “coaching”, gurus de pacotilla, chamanes y cosas por el estilo que ni siquiera son titulados en algo parecido a la informática y que básicamente lo único que han visto de informática es PowerPoint, Excel y Word pues no es de extrañar lo que comentas. Además lo que aquí importa es como sucede en muchos campos, la apariencia y la fachada es lo importante aunque dentro sea un desastre. A veces echo de menos cuando mi padre llegaba con las tarjeteas perforadas y sin tantas chorradas y se centraba en hacer lo que se envía que hacer.
Gracias David por compartir tu opinión, un saludo!
Hola Alejandro,
Por un tiempo dejé de leer tus post por «falta de tiempo» y ahora me pregunto, ¿Cuanto tiempo he perdido en no leer tan buen material que publicas?.
Estoy de acuerdo con gran parte de lo que comentas y me siento identificado al leer que en el afán de comparar PMP con SCRUM, de alguna u otra forma «la moda» sobresale y terminando menospreciando lo que realmente una persona adquiere al obtener el PMP.
Para que mi comentario no sea extenso, resalto este parrafo de tu publicación. ¡¡ Cuanta verdad !!
<>
Saludos,
Jean Pierre
Gracias Jean Pierre por tu amable comentario, ciertamente lo que más me molesta personalmente es el afán de algunos por desprestigiar la gestión tradicional de proyectos sin tan siquiera entenderla o tener experiencia en el sector. Un saludo!
Como siempre, me encanta el artículo Alejandro. Has dado en la diana de pleno. Bajo mi punto de vista, solamente te falta un caso, las empresas que deciden introducir las metodologías ágiles pero no dejan que los equipos de desarrollo se autogestionen, sino que pretenden realizar el mismo seguimiento que en una metodología tradicional, porque según ellos, autogestionarse significa hacer lo que te de la gana y no trabajar….. Vamos una incoherencia con todas las letras.
También estoy muy de acuerdo en que como el tema de las metodologías ágiles está tan de moda, muchos pretenden que todo se haga bajo ese prisma y no tiene ninguna lógica. Hay que estudiar cada proyecto para poder decidir que tipo de metodología se debe aplicar, no la que se quiera aplicar.
Muchas gracias por estos artículos y muy buena semana!!!!
Gracias Carmen por tus positivos comentarios sobre el artículo. Tienes toda la razón en el caso que apuntas: empresas que se autodenominan ágiles pero que no dejan que los equipos se autogestionen, otra «aberración» más para la colección 🙂
Tienes toda la razón (y por fin alguien lo publica): las empresas intentan aplicar Scrum porque han oído por ahí que es la leche y creen que de esa manera no se les van a «escapar» los proyectos en tiempo o coste. Tenemos un cliente con el que siempre realizamos proyecto de precio cerrado que se empeña en que los hagamos bajo metodología ágil. ¿Y sabes realmente lo único que quiere? Que se le vayan realizando entregas parciales para no dejarlo todo para el final. ¡Solo eso! Y aún así siguen diciendo que sus gestiones son «ágiles». Una pena.
Hola Sergio, gracias por tu amable comentario, lo cierto es que situaciones como estas dan mucho que pensar. El daño que hacen las «etiquetas» y las modas en las organizaciones..
Alejandro, muy interesante!
Ademas si que hacen faltan publicaciones objetivas que no se enfoquen en promover una y denigrar de la otra.
Es claro, que por la necesidad de hacer un post que no sea extenso se te quedan cosas por fuera.
1. Hay empresas que no quieren pagar salarios adecuados a los especialistas en proyectos.. Basta hacer una consulta rápida en elempleo.com u otros sitios de empleos para encontrar vacantes cono:
«Gerente de proyectos bilingüe – SCRUM – PMP
Salario COL$ 3,500,00»
2. Las metodologías (tal vez mejor GUÍAS o Estándares) serias siempre dejan planteada la necesidad de ajustarse (Tailoring) a las características del proyecto.
3. Un aspecto importante de las fallas / fracasos de aplicar cualquier metodología (guía o estándar) somos las personas:
– Gerentes de proyectos sin experiencia… como bien lo has planteado, que se limitan a tener un cronograma y a tratar de coordinar las actividades.
– Directivos de empresas que no valoran lo que se plantea hacer… un ejemplo muy frecuente es la gestión de riesgos. Se desecha o se menosprecia y basta con que se disponga de una matriz de riesgos y nada mas.
4. De otra parte, Existen y también están evolucionando enfoques denominados HÍBRIDOS, que tratan de recoger e integrar los conceptos, principios,herramientas, artefactos, técnicas, etc. de las diversos enfoques.
Muchas Gracias Hernando por tu amable comentario y por compartir tu experiencia/aportar valor a la conversación. Saludos!
Me parece bien el artículo, creo que casarse con una forma de hacer las cosas no es lo más conveniente. Antes de seguir hay que reconocer que PmBok es un estándar que normalizó, estandarizó y sencillamente estableció las mejores prácticas frente al alto % de artesanía que se aplicaba en la gestión de los proyectos. También, es cierto que los entornos de trabajo ágiles son un aporte. Sin embargo, para tener una metodología adecuada a la naturaleza y resultado del proyecto, se debe tener presente el marco conceptual de dirección de proyectos y complementar con prácticas ágiles u otras.
Gracias Fernando por compartir tu opinión y experiencia. Saludos!
Excelente artículo, refleja el presente en algunas empresas donde el Scrum Master a veces tiene cero experiencia en el campo del proyecto que está liderando y está experiencia no es soslayable con ninguna metodología de agilización, en mi humilde opinión los PM deberían capacitarse en metodologías ágiles para mejorar su gestión pero no al revés.
Gracias Mauricio por compartir tu punto de vista y opinión. Saludos!
No podemos desmeritar uno u otro enfoque, «Agile» llegó porque sencillamente era necesario (en el caso del desarrollo de software por ejemplo) hacer entregas iterativas que demostraran el avance, dando más valor al producto que a la documentación, o adecuarse al cambio en lugar de seguir un estricto plan. ¿Cuántos millones se han tirado a la basura?; por simplemente hacer una sola toma de requerimientos, iniciar el desarrollo y luego llegar con una solución que, o ya no era aplicable al negocio o, que estaba fuera de la expectativa del cliente, existen miles de historias de terror, muchas de ellas en nuestros gobiernos (sector público). Por otro lado, no puedo imaginar concretar un proyecto de construcción de manera «agile», cosas como, -ya no queremos los desagües por este lado, los queremos por este otro-, -mejor usemos porcelanato en vez de esa cerámica-, serían una pesadilla. Allí es donde una gestión usual de proyectos (basada en el Pmbok por ejemplo) da justo en el clavo, con gestión de costos, tiempo, adquisiciones, riesgos, calidad, y todas las demás áreas que puedan aplicar. Así entonces, esto no es una guerra de qué es mejor, pero si es un reto saber seleccionar lo más adecuado.
Hola Jorge,
Estoy 100% de acuerdo contigo y es lo que plasmo en el artículo, se trata de hacer un «traje a medida» para cada proyecto, seleccionando los enfoques y herramientas más adecuados para cada caso. Gracias por comentar y compartir tu opinión. Saludos!
Alejandro,
No podría estar más de acuerdo con tu artículo. En verdad, uno se topa cada tanto con personajes que asumen el rol de expertos en Scrum luego de una charla grupal de una hora, y pretenden desacreditar el estándar del PMBOK o similares bajo la falsa premisa de que el agilismo es la nueva panacea.
Sin duda, un Project Manager debe conocer las técnicas aplicables a su proyecto y usarlas con el mix correcto. Eso incluye por supuesto a las técnicas ágiles como herramientas útiles, dependiendo de qué proyecto sea.
Felicitaciones, has dado en el clavo.
Gracias Roberto por tu amable comentario, me alegra saber que te ha gustado el artículo. Saludos!
Excelente post y concuerdo plenamente con lo expuesto.
Al conversar con un ScrumMaster que se certificó en mi empresa con un curso de 2 semanas, le pregunté como manejaba los cambios y los costos asociados a este en su proyecto… No tuve respuesta. Para mi,claramente se deben complementar los conocimientos en ambos sentidos.
Gracias Alvaro por tu comentario y por participar en la conversación. Saludos!
Clarísimo. Y ni hablar del “zombie agile” donde se repiten prácticas y ceremonias en forma mecánica sin considerar la esencia de la agilidad
Gracias Marcelo por tu comentario. Saludos!
Muchas gracias por el aporte, excelente artículo.
Gracias a ti Carlos por seguir mis artículos. Saludos!
Increíble nota la que acabo de leer, no porque sea la realidad que estoy viviendo si no porque nos demuestra una vez más, que las modas impactan no siempre para bien o no siempre de la forma correcta, justamente en el pmbok dice que no se administra con el poder ni con la fuerza, es con los sentidos y con la empatía, eres agile, scrummaster, pmp, pm, el título que tengas, por favor me encantaría ver que eres empático antes que jerárquico, gestión de proyectos como lo dice no es ni reuniones diarias de 15 minutos ni un libro de 600 páginas, pero es más cercano al libro de 600 páginas que cumplir con la obligación de tener un ritual de 15 minutos diarios, ambas partes tienen su razón de ser, sin buscar algo mal en alguna de las dos o algo mejor en alguna, me gustaría primero que voltearan a ver cualidades y soft skills en los administradores de proyectos que la bandera que traemos cargando
Gracias Clemente por tu amable comentario y aportación. Saludos!
Hola Alejandro,
Creo que señalas muy bien varias incongruencias de uso de metodologías de gestión de proyectos que reflejan ya sea ignorancia, inexperiencia o mala fe.
Particularmente relevante es el primer punto que estableces de proyectos «llave en mano», que usualmente se convierten en contratos a precio y plazo fijo pero sin alcance bien acotado. Es una trampa que hay que evitar por todos los medios, porque te expone legalmente como cliente y como proveedor. Todo mundo pierde en esa danza.
Sobre la sexta edición del PMBOK, te comento que la versión más reciente disponible en el sitio del PMI, incluye un documento llamado «Agile Practice Guide», de cerca de 170 páginas, muy enfocado en dar guías de tailoring de procesos (capítulo 3, Life Cycle Selection»), pero también de cuales son las características organizacionales para establecer un ambiente ágil (capítulo 4 «Creating an Agile Environment»).
Creo que esto es un reflejo de una tendencia que por cierto no es nueva: la necesidad de administrar proyectos en ambientes de mucha incertidumbre con la necesidad de entregar valor lo más pronto posible.
Un saludo.
Gracias Alex por tus comentarios y aportación. Efectivamente en la web del PMI está disponible desde hace ya bastante tiempo la Agile Practice Guide, que no forma parte del propio PMBOK pero si que se puede descargar conjuntamente en un mismo «pack».
Justamente el PMI ha renovado hace unos días el «exam content outline» de la Certificación PMP, reforzando la parte Agile, por lo que se espera que a partir del 15 de Diciembre, el examen refleja esta tendencia del mercado.
Saludos!
Como siempre muy atinados artículos Alex. Un desvirtuación e indiscriminada generación de «certificaciones» sobre las metodologías ágiles. El manual de PM2 Alliance, de Agil específicamente, menciona en la descripción de ágil muy claro: » ‘Ágil’ es un término colectivo que se utiliza para referirse a un conjunto de prácticas (impulsadas por un conjunto de valores y principios centrales), especialmente en el desarrollo de software, en el que los requisitos y las soluciones evolucionan a través de la colaboración entre equipos multifuncionales autoorganizados».
Por otro lado, me pegaste en el corazón con lo de LEGO. Vamos por partes. Al igual que las certificaciones indiscriminadas, existen técnicas varias en el uso lúdico de los LEGO. Pero en especifico, LEGO Serius Play es un técnica desarrollada para CREATIVIDAD, no funciona como técnica de aprendizaje de proyectos. Además, ya existen una cantidad desmedida de «certificadores certificados» sobre dicha técnica, y no hay control sobre sus enseñanzas, ni hay actualizaciones o re certificaciones que comprueben el uso correcto de la misma. A mi experiencia, LEGO funciona como simulador de proyectos, con sets específicos y con instructivos de armado muy claros, como aviones, autos, edificios, etc. No se debe integrar creatividad por medio de una técnica diseñada para otros objetivos, como herramienta para desarrollarse en la Dirección de Proyectos. Un saludo Alex!!!