En el artículo de hoy y en línea con otros artículos que ido publicando a lo largo de este año sobre Agile, me gustaría revelarte algunos «secretos» sobre las prácticas ágiles que posiblemente nadie te haya contado.
En los últimos años, la presencia de la agilidad en las empresas ha aumentado de manera exponencial.
Actualmente hay pocas empresas y aún menos profesionales que no hayan escuchado hablar de las virtudes de las prácticas ágiles y sus diferentes frameworks de trabajo (Scrum, Kanban, XP, etc)
Nadie lo puede negar: La «Agilidad» está de moda, y esto positivo y a la vez es negativo.
Me explico, es positivo, dado que la filosofía de trabajo subyacente en la agilidad puede ayudar a muchas organizaciones y a profesionales de diferentes sectores a ser más eficientes en su trabajo.
Pero como ya comenté en mi artículo: «Scrum está de moda, pero cuidado, no lo cura todo» hay también mucho «humo» detrás de todo este movimiento.
¿Que significa ser Agile?
Los frameworks de trabajo agile surgen del desarrollo de software como respuesta a entornos cambiantes, competitivos y con un grado importante de incerteza.
Los denominados contextos VUCA (Volatile, Uncertain, Complex, Ambiguous).
La gestión agile permite que las organizaciones y sus equipos se adapten, consiguiendo la flexibilidad necesaria para conseguir la satisfacción de los clientes en estos ambientes cambiantes.
Podríamos definir el ser ágil como la capacidad de adaptación al cambio con la menor fricción posible.
El manifesto Agile (firmado en el 2001 y donde se recogen los valores los principios y valores ágiles) está centrado sobre todo en las personas, los individuos que componen los equipos de trabajo, y que ahora tienen más libertad y poder de decisión.
Hablamos de equipos auto-organizados con capacidad para impactar directamente en la experiencia de los clientes, entregando valor de manera continua y adaptándose al cambio de manera constante y efectiva.
¿Entonces cuál es el problema?
Como con cualquier otra práctica que se pone de moda (ya pasó hace unos años con el «coaching»), surgen muchos autodenominados «expertos» que venden sus conocimientos y experiencia, con el único objetivo de aprovechar el tirón del momento.
Con esto no quiero decir, que no haya excelentes profesionales consolidados en el sector, pero si que es cierto que cada mes aparecen de 2 a 3 nuevos «gurus» de la agilidad.
El intrusismo unido a la «perversión» del propio concepto, está provocando que en muchas empresas, los resultados no están siendo los esperados.
Como ya comenté en su momento, para que una organización pase de un modelo de gestión más tradicional a uno Agile, se requiere de una importante gestión del cambio a nivel de empresa, equipos, personas.
No es algo que vamos a conseguir de una semana para otra.
En una organización con un modelo de gestión tradicional, jerárquico y de control, no vamos a conseguir nada positivo en certificar a algunos empleado como «Scrum Masters» o «Product Owners» sin antes hacer una inversión importante en gestionar el cambio a nivel interno.
Si no están alineadas todas las capas organizativas (Gerencia, Mandos Intermedios, Equipos Técnicos,etc) no vamos a llegar a buen puerto.
Pues bien el recientemente etiquetado como «postureo agile» ha logrado que muchas empresas y sus equipos se autodenominen ágiles, sin muchas veces entender que significa el propio concepto.
Lo que está de moda se vende bien, pues todo proyecto o empresa innovadora ha de llevar el sello «Agile» en algún lugar, y si puede ser que se vea bien.
Luego nos encontramos con los técnicos, que de un día para otro pasan a ser «Scrum Masters» sin tener las aptitudes ideales para ello (eso sí, tienen un papel impreso que dicen que saben de eso) y cantidad de «Agile Coaches» en LinkedIn que se autodenominan expertos cuando hace unos meses no sabían ni lo que significaba la expresión, pero que tras hacer un curso de 1 semana, son los mejores coaches del sector.
La gestión de proyectos, sea con métodos más tradicionales o ágiles es un camino de aprendizaje continuo, y que abarca un abanico completo de áreas de conocimiento (gestión de alcance, riesgos, calidad, costes, cronogramas de tiempo, equipo, etc).
Conocimientos que lógicamente no vamos a conseguir únicamente con unos días de formación.
Con esto no quiero decir que no sea útil la formación, todo lo contrario es fundamental y es parte de la solución al problema, pero no va a funcionar si nos quedamos únicamente en este punto.
¿Cuál es la solución al problema?
La solución pasa por informarse bien antes de iniciar ningún procedimiento de cambio a nivel de organización y entender que el cambio se ha de dar a nivel en todos los niveles y no únicamente a nivel del equipo técnico.
Se ha de comunicar adecuadamente, se ha de formar al personal y se ha de «acompañar el cambio».
Aquí hay dos elementos importantes: formación y acompañamiento (coaching).
Por un lado hay que buscar cuál es la formación más adecuada, buscar acompañamiento externo (consultoría/coaching) de profesionales (de verdad, no de los de «tengo un papel que lo dice») que faciliten el cambio, al menos en sus fases iniciales, para luego ya seguir el proceso con personal interno bien formado y cualificado.
Finalmente recordemos también que no en todos los proyectos aplica usar prácticas ágiles, nada es negro o blanco, será pues el gestor de proyectos quien deba decidir dependiendo del contexto y su propia experiencia, que herramientas, prácticas o frameworks aplicar en cada escenario.
¿Qué opinas sobre lo expuesto? ¿Has tenido alguna experiencia positiva o negativa en relación a implementar Agile en tu organización o equipo?
Como siempre, espero vuestros comentarios, ideas y sugerencias en la sección de comentarios.
Creo que lo mejor es primero entender bien los 10 areas del PMBOK y crear un base de «Project Management». Una que vez que esto se logra, es ideal a proceder a un sistema hibrido.
Gracias Marco por tu aportación. La verdad es que el PMBOK es una muy buena base de conocimiento sobre la cuál luego montar otras prácticas y frameworks de trabajo. Saludos!
He trabajado muchos años con el paradigma tradicional del PMBOK, pero los últimos 2 años estuve trabajando con AGILE. Comparando ambas metodologías lo que percibo es que con AGILE da la sensación de obtener resultados mas rápido desde el punto de vista de los usuarios, en particular en proyectos no muy grandes. Coincido que para proyectos grandes parece mas apropiado utilizar un método hibrido.
Por otro lado con AGILE no se puede fijar muy precisamente el tiempo de duración del proyecto. Otro punto que me parece importante es que al no encarar algo global al principio obliga de alguna manera a realizar modificaciones seguidas al modelo de datos y eso puede ocasionar que no resulte el mas óptimo sino se analiza profundamente
Gracias Estela por tu aportación al debate. Saludos!
Considero que integrar ágil en una compañía debe ser con orden y con una estrategia, probablemente con un proyecto pequeño, platicar con el grupo elegido el objetivo de empezar con estrategias ágiles, entrenar a los futuros POs y SM, cuando se utiliza SCRUM, probablemente realizar algunos templates y difundirlos.
Si se cuenta con una PMO, creo que sería sensato crecerla con todo el tema ágil, agregandole el Scrum Guidance Body. y en general deberían tener criterios institucionales para determinar si se utliza un predictivo o uno ágil. Controlar los estándares de templates… así como se controlan la forma y herramientas para el project charter o lecciones aprendidas o la matriz de riesgos, también tener su sección para layouts de los product backlogs o los srpint backlogs. existen herramientas sencillas que ayudan.
Creo que es un proyecto interesante para dejar una mesa bien puesta con predictivos y ágiles, porque no todo es posible resolverlo con ágil.
Ahora bien, si se quiere implementar metodología ágil para uso eventual, sería complicado entrenar a los Products Owner, porque creo que estos deberían de ser los Gerentes Fucnionales y que en determinado momento, dependerá del área donde se quiera crear el producto o servicio para determinar cuál Product Owner es el indicado para el proyecto?
en fin, creo que todavía hay mucho por hacer.
Muchas gracias Gerardo por tu interesante aportación al debate. Un saludo!
Vengo de trabajar en una época que la metodología era del «Programador en Jefe» o «Superprogramador» como se llamaba. Luego de trabajar impulsando CMM-I y como complemento las prácticas del PMI.
Hoy me encuentro impulsando procesos ágiles, y coincido en que cuando nos desgarramos las vestiduras por la «metodología» tenemos a «Superprogramadores» Jr, haciendo tremendos Gantts sin disponer de requerimientos, u hoy «siendo ágiles» simplemente porque «no documentamos» o por que compramos que el proyecto de 6 meses, lo podemos hacer en un Sprint de 15 días.
En todos los casos el desafío no es la metodología, sino los que se conoce como la «Teoría de Control». ¿Puedo tenerlo TODO controlado?.
El software nos has demostrado (Pueden leer «No hay balas de plata») que es una construcción que tiene características que dificultan su control. La modalidad Ágil propone no un esquema de control, sino de aprendizaje. Ahí es que el cambio cultural requiere reconocer que lo que venimos haciendo no nos sirve (está claro si lo que están haciendo, les sirve, sigan haciendo mas de lo mismo, y esto es un aprendizaje de loa Ágil, y el coaching). Las empresas van a lo Ágil, a los Microservicios, a Docker, y otras modas, cuando persiven que lo que tienen no les está funcionando. Y esa es la parte mas dura, poder mirar desde un ángulo distinto para dar espacio a nuevas posibilidades, nuevas formas de trabajar. El dilema no PMI o Ágil, sino «Control» o «Aprendizaje».
Gracias Carlos por tu comentario y aportación al debate. Un saludo!
Sólo tengo de conocimiento de SCRUM teórico de SCRUM pero no he tenido ocasión de aplicarlo a nivel práctico; sí tengo práctica con metodologías waterfall; mi opinión, si puede servir de alguna ayuda, es que Scrum o esa metodología proporciona herramientas a lo que programadores y usuarios con el apoyo de los jefes de proyecto, veníamos haciendo al lograr entablar relaciones informales. Desde ese punto de vista me parece un avance que beneficia a ambas partes, pero insisto en que hablo desde un punto de vista teórico en cuanto a aplicación practica de metodologías ágiles. Seguiré atenta a la evolución de su aplicación práctica.
Gracias María Belen por tu aportación al debate. Saludos.
Buenas,
Primero darte las gracias por compartir tu punto de vista.
Solo quiero añadir que dentro de una tranformacion hay que abordar: cultura como bien mencionas, Tecnologia, Negocio (esto nos lleva a un cambio de mindset de gestión proyecto a gestión de producto) y Agile (referiendome a metodo, marcos de trabajo etc.).
De nuevo gracias por abrir este debate.
Un saludo
Gracias Youssef por tu aportación. Saludos!
Muy revelador su artículo @Alejandro Pérez Ruiz, PMP, PMI-ACP Gracias por publicarlo.
Me gustó mucho las siguientes expresiones
“para que una organización pase de un modelo de gestión más tradicional a uno Agile, se requiere de una importante gestión del cambio a nivel de empresa, equipos, personas. No es algo que vamos a conseguir de una semana para otra”.
“En una organización con un modelo de gestión tradicional, jerárquico y de control, no vamos a conseguir nada positivo en certificar a algunos empleado como «Scrum Masters» o «Product Owners» sin antes hacer una inversión importante en gestionar el cambio a nivel interno”.
¿Cuál es la solución al problema?
“Por un lado hay que buscar cuál es la formación más adecuada, buscar acompañamiento externo (consultoría/coaching) de profesionales (de verdad, no de los de «tengo un papel que lo dice») que faciliten el cambio, al menos en sus fases iniciales, para luego ya seguir el proceso con personal interno bien formado y cualificado”.
Para nosotros la solución se llama “Liderazgo con Inteligencia Emocional para la Gerencia”, donde el gerente y su equipo de trabajo se preparan para este nuevo mundo VUCA y se incluye desarrollar las capacidades emocionales de agilidad y adaptación, y otras 29 que nos llevan al liderazgo. Luego están los cursos de Scrum, Kanban, XP, etc, que también hay que hacerlos.
Dr. FERNANDO MARTÍNEZ (WhatsApp +58 416 7217462) [email protected]
Profesor Titular de la Universidad Central de Venezuela
Presidente de la Fundación Gerencia de Proyectos en Venezuela
Gracias Dr. Fernando por tu aportación al debate 🙂
Comparto, con estudiar unas semanas no te da experiencia y conocimientos en gestión. Solo el empirismo te puede entregar la experiencia para dirigir y gestionar.
Si creo que en ocaciones es mejor una que la otra, también la aplicación de ambas a proyectos determinados. Como bien dices nada es blanco o negro, un buen gestor debe matizar con las herramientas adecuadas para lograr el éxito.
Gracias Héctor por tu comentario. Saludos!