Top
TAKTICTAKTIC Desmintiendo los mitos de Scrum más recurrentes
tablero scrum

Desmintiendo los mitos de Scrum más recurrentes

No hace mucho, charlando con un antiguo cliente, hablábamos de Gestión de Proyectos de software, en concreto, de implantaciones de ERP. Comentaba que Scrum es lo que hemos hecho toda la vida pero con un nombre más elegante: “Vamos haciendo y haciendo y, en la medida que salgan los problemas, los arreglamos y, cuando me pidan modificaciones, pues las hago. Vamos, lo que hacemos siempre”. ¿Eso es Scrum? ¿ir haciendo y arreglando? ¡Nada más lejos de la realidad! Scrum, como cualquier otra forma de Gestión de Proyectos Ágiles, requiere de una serie de conocimientos y habilidades que es necesario dominar. Si no lo haces, tienes dos opciones: aprenderlas para poder llevar a cabo proyectos de este tipo o no meterte para evitar que el proyecto sea un desastre. En este post desmentimos algunos de los mitos de Scrum más recurrentes. ¿Quieres saber cuáles son?

No pretendo definir Scrum ni entrar en aspectos de su aplicación en el Project Management, pero sí me gustaría destacar una serie de valores que prioriza:

  • Los resultados sobre la documentación
  • La Gestión del Cambio sobre la Planificación
  • Las personas sobre los procesos
  • La colaboración con el Cliente por encima de la Negociación

Mitos de Scrum

Los principios del manifiesto ágil, en los que Scrum se basa, mal utilizados pueden llevar a confusión. Hay gente que asemeja gestionar un proyecto con Scrum a ponerse un cuchillo entre los dientes y saltar en paracaídas sobre las líneas enemigas. No pueden estar más equivocados.

Algunos de estos mitos de scrum más recurrentes, que intentaré “desarmar”, son:

En Scrum no se documenta

Scrum prioriza los resultados del proyecto gestionado por encima de la documentación del mismo. El error es pensar que entonces no hace falta documentar. En Scrum se deben documentar, de forma clara y concisa, aquellos aspectos (historias de usuario) que conforman el producto final. Sin esta documentación no es posible determinar el alcance final de la solución. Por supuesto, se prioriza el resultado, pero este resultado va a estar cimentado en una buena definición (y, por tanto, documentación) de lo que se desea realizar.

En Scrum no se planifica

Los Sprints en los que se divide el proyecto deben tener una duración corta y cualquier incidencia en su desarrollo puede derivar en una desviación inmediata en plazo o coste. Es necesario un control exhaustivo (control sutil, si nos ajustamos a los principios) del avance de los Sprints (con herramientas como el burndown chart) y tener la flexibilidad necesaria para no provocar desviaciones en el devenir del proyecto.

El equipo se auto-gestiona

Una de las claves del éxito de Scrum radica en la eficiencia del equipo de trabajo. Un equipo multidisciplinar de unas 4 o 5 personas es lo óptimo en proyectos Scrum, pero para que la sinfonía suene como es preciso hace falta un director de orquesta (en este caso, el Scrum Master). Cada componente del equipo es, presumiblemente, especialista en su área, pero es necesaria la visión global del producto final y del avance del proyecto.

Cualquiera puede llevarlo a cabo

Cualquiera puede dirigir una stand-up meeting, ¿verdad? Pongámonos en situación: reunión de 5 personas en las que cada una de ellas en unos 3 minutos de tiempo debe contar lo que hizo ayer, su plan para hoy y lo que necesita resolver para poder avanzar. Todo esto de forma diaria, de pie, sin tardar más de 15 minutos y, por supuesto, disponiendo del conocimiento y capacidad suficientes para conseguir solventar aquellos problemas que tiene el equipo. Suena fácil, ¿no?

Los proyectos Scrum son más “caros” para el cliente

Parece razonable pensar, desde el punto de vista del comprador del proyecto, que el coste de un proyecto está más controlado que un proyecto Scrum, en el que iterativamente se va mejorando el producto. Personalmente, me resulta difícil justificar en términos monetarios que no es así, pero para hacerlo basta leer el artículo del gran José Barato en relación a los Contratos Ágiles, en el que se aclara cómo definir una relación contractual cliente-proveedor en el ámbito de la agilidad.

¿Agilidad o predicción?

Después de todo esto, ¿es mejor aplicar en los proyectos la agilidad o la predicción? Lo primero es analizar el tipo de proyecto que vamos a abordar. Sería descabellado pensar en construir un edificio sin tener los planos de dicho edificio (que parezca descabellado no quiere decir que algún insensato no lo haya hecho), y las metodologías predictivas de proyectos de software funcionan de forma similar.

De otro modo, elaborar un traje tiene varias fases: primero te toman las medidas, después confeccionan el traje y posteriormente te lo vuelves a probar una, dos, tres o las veces que haga falta antes de llevártelo a casa. Entre prueba y prueba puedes haber engordado, adelgazado o incluso haber perdido un brazo. Pero, con cada nueva prueba, el traje va a ser ajustado a tus circunstancias, para que en el momento en el que lo vayas a estrenar se adapte lo máximo posible a lo que quieres y necesitas.

Un proyecto de implantación de ERP, ¿tiene un alcance cerrado o se trata de un proyecto de mejora continua? ¿Conozco a priori el producto final que necesito o en la medida en la que voy conociendo el producto y mi negocio va cambiando necesito continuos cambios? Los principios del desarrollo agile están basados en un supuesto:
“En el software, el cliente no sabe lo que quiere, pero sí sabe lo que no quiere”.

En este entorno cambiante, en el que tanto el negocio como la tecnología se transforman a ritmos vertiginosos, implantar un ERP es como hacerte un traje. Y el sastre debe ser ágil y adaptarse a lo que necesitas.

Ahora que conoces los mitos de Scrum más recurrentes, ¿ha cambiado tu opinión acerca de esta metodología Agile? Si deseas conocer nuestro curso Scrum, contacta con nosotros.

Carlos Fiol Ayala
Carlos Fiol Ayala

cfiol@taktic.es