Siguiendo la línea de mi post anterior: ¿Conoces las diferencias entre gestión tradicional y agile? os traigo este nuevo artículo.
Hoy analizaré los principales puntos de fallo de las implementaciones de Scrum en las empresas.
Como sabrás (en caso contrario lee el artículo anterior) Scrum es un marco de referencia agile.
Scrum nos permite una adecuada gestión de la complejidad en proyectos donde el alcance/requisitos y/o tecnología no es tan bien definidos o sujetos a alta variabilidad.
Estos son entornos denominados «complejos» tal y como se puede observar en el esquema siguiente:
La pregunta es, si Scrum es un marco de referencia ideal para estos entornos ¿por qué muchas empresas están fallando en su implementación?
Hay muchas variables y factores que pueden afectar, a continuación os comento las más comunes:
Entender la agilidad y comunicarla adecuadamente
Este es el punto principal, antes de hacer cualquier cambio que impactará a la forma de trabajar de la organización hay que invertir tiempo en la gestión de este cambio.
Esto supone comunicar y formar a las diferentes capas de la organización, al nivel que le corresponda.
Implementar con éxito un marco de referencia como Scrum, supone que la empresa ha de «abrazar» la agilidad, compartir los valores del manifiesto agile y contar con equipos preparados para ello.
Formar adecuadamente a las personas responsables
Además de comunicar el cambio adecuadamente a todas las capas (desde dirección, mandos intermedios, equipos), será necesario formar a las personas involucradas.
Con formar no me refiero a apuntarles a un curso online o comprarles un libro, sino acompañar a la plantilla en el proceso del cambio.
Lo ideal para comenzar sería realizar formaciones presenciales de calidad (si son «in-company» mejor que mejor) donde se establezca un marco de conocimiento homogéneo a la plantilla que sirva como punto de partida.
Importante que en esta formación se hablen de temas claves sobre lo que supone ser agile, valores, «soft-skills», técnica de estimación agile, prácticas ágiles (scrum, Kanban, xp, etc)
El problema con este punto es que muchas empresas creen que con apuntarse a un curso de Scrum de 2 días o descargar y leer la guía oficial ya es suficiente para implementarlo con éxito.
Desde mi punto de vista y por mi experiencia personal, considero que hacer únicamente una formación de Scrum, te deja una visión sesgada de lo que supone ser agile.
Dicho lo anterior sería interesante recibir una formación más amplía donde se trabajen otros aspectos esenciales y se comenten otros marcos de referencia/implementaciones ágiles que muchas veces son complementarios.
Hacer correctamente el ejercicio de «Tailoring»
Con esto quiero decir, que aunque Scrum puede ser un marco de trabajo perfecto para muchos entornos (especialmente los complejos) no siempre tiene por que ser la mejor opción.
Debemos tener la capacidad y experiencia necesaria para saber elegir el mejor el conjunto de herramientas y técnicas para cada proyecto, adecuándolas a la realidad del mismo (duración, criticidad, cultura de la organización, nivel de definición de los requisitos, tamaño del equipo y sus habilidades, etc)
Esto es conocido como «tailoring» o «hacer un traje a medida» para el proyecto según las necesidades.
Si quieres profundizar en estos temas, conocer que supone ser Agile, los marcos y métodos de referencia como Scrum, Kanban, XP y mucho más no dejes de revisar nuestro Curso Agile: PMI ACP + ScrumMaster, posiblemente el curso más completo del mercado para dar el salto a la agilidad.
¿Añadirías alguna causa más? ¿Algún consejo para aquellas empresas que están en pleno proceso de transformación? ¿Quieres compartir alguna experiencia personal?
No dejes de aportar valor a la comunidad, compartiendo tus opiniones y experiencias abajo en la sección para comentarios.
6 respuestas
¡Totalmente de acuerdo! ¡Y gracias por este interesante artículo, Alejandro!
Me gustaría hacer énfasis en el punto “Entender y comunicar la agilidad adecuadamente” recogido en este artículo.
A mí me gusta representar la agilidad como una pirámide en nuestras formaciones de Ceolevel. Es decir:
– La base son sus valores (4).
– Sobre ella se construyen sus principios (12).
– Y sobre todo esto culminan unas prácticas, unas implementaciones ágiles (ya sea XP, Kanban, Scrum, etc).
Y aquí nos aplica el clásico ejemplo de no empezar construyendo la casa por el tejado, pues esta, lógicamente, necesita unos cimientos, una estructura segura para que sea fiable y cumpla con su propósito. Lo mismo pasa con la agilidad y sus implementaciones en las organizaciones.
Podremos decir que una organización es ágil si ha interiorizado los 4 valores y 12 principios firmados en el manifiesto ágil, compartiéndolos y haciéndolos explícitos.
Será solo entonces cuando la organización esté preparada para poder poner en práctica la agilidad usando los marcos de XP, de Kanban o Scrum, o incluso una mezcla de ellos, entre otros, según necesidades o conveniencias. Ya en este punto podremos decir que una organización está “haciendo agilidad”.
Como veis, no podemos hacer agilidad sin ser ágiles ya que no pueden aplicarse correctamente ciertas prácticas si no se cree en los valores y los principios que las sustentan. En todo caso, si esto se diera (y desgraciadamente se da) estaríamos haciendo otra cosa, pero NO agilidad, con los riesgos que esto conlleva.
Saludos,
Javi
Gracias Javi por tu aportación. Saludos!
Es muy cierto, hay que saber seleccionar las herramientas que se han de implementar, ya que no siempre se puede hacer todo como está en los libros.A veces es necesario hacer ciertas adaptaciones, y aquí radica el concepto de «flexibilidad».
-Saludos
Gracias Christopher por tu aportación. Saludos!
Creo que otra causa por la que falla la implementación de scrum es la falta de definición de indicadores. Muchas veces se confunde el principio de entrega por sobre documentos, no obstante es necesario tener buenos registros de la salud los proyectos. En mi criterio falta profundizar ahí y trabajar en el entendimiento y establecimiento de KPIs que permitan poder compartir con todos los involucrados el resultado del proceso.
Gracias Mónica por tu aportación al debate. Saludos!