Uno de los libros que más recomendamos para la gente que quiere aprender más sobre Scrum y, especialmente, cómo implementarlo de forma efectiva es el magnífico “Scrum&XP from the trenches” de Henrik Kniberg. En este libro Henrik no se dedica a profundizar en los conceptos teóricos de Scrum, su procedencia y su relación con las metodologías ágiles o las ventajas de este tipo de metodologías frente a los enfoques más tradicionales o pesados. En su lugar, Henrik pasa directamente al meollo de la implementación de Scrum con un enfoque eminentemente práctico y holístico: qué hemos probado, qué fue mal, que hicimos en su lugar, por qué nos funciona mejor…

El libro está disponible de forma gratuita en InfoQ, un magnífico recurso para los interesados en las metodologías ágiles y el desarrollo de software en general. Dada su naturaleza abierta, hace unos meses contactamos con Henrik y le contamos que utilizábamos gran parte de su libro en la preparación de nuestros cursos o en los proyectos de consultoría e implantación de Scrum en empresas, y como agradecimiento nos ofrecimos a traducirlo al castellano. Henrik nos ofreció su colaboración y visto bueno desde el principio, y fruto de dicho ofrecimiento queremos poner a vuestra disposición el primer borrador de Scrum y Xp desde las trincheras en castellano.

Dado que hemos realizado este trabajo robandole horas al día y que no somos en absoluto traductores profesionales es posible que algunos párrafos resulten un poco literales o sean mejorables en estilo. Por eso hemos decidido que la mejor manera de perfeccionarlo era editar este borrador y pediros vuestra colaboración para mejorar el manuscrito. Os pedimos que dejéis vuestros comentarios en esta página para incorporar las correcciones al manuscrito final.

También os agradeceremos cualquier tipo de feedback sobre cómo estáis empleando Scrum en vuestras empresas o qué necesidades tenéis en ese sentido. Podéis dejar un comentario en este artículo o escribirnos a info (arroba) proyectalis (punto) com. Os esperamos

En esto de Scrum y las metodologías de gestión de proyectos en general existen dos corrientes de pensamiento principales. Una es la encabezada por Jeff Sutherland, co-creador de Scrum y gurú de las metodologías Ágiles: según él, para que Scrum funcione hay que ceñirse estrictamente a las reglas, y todo lo que no pase el checklist completo no puede llamarse Scrum (y de hecho debería estar perseguido por la iglesia y garantizarte una buena temporada en los fuegos del infierno).

Otra la forman los que piensan que no hay una policía del Scrum que vaya a venir a detenerte si decides formar equipos de 14 personas cuando la norma es de entre cuatro y diez personas por equipo, o que rodeen el edificio con sirenas y megáfonos si llegáis a la conclusión de que los Sprints de duración fija no son para vosotros.

Durante mucho tiempo me he contado entre los segundos, y sin embargo conforme voy ayudando a más empresas a adoptar Scrum y progresar en la búsqueda de una mejor forma de hacer las cosas me voy dando cuenta de que, al final, resulta que los primeros tenían razón. Por lo menos una parte importante de la razón.

Me encuentro con frecuencia con empresas a las que estoy explicando lo que hacemos y me dicen “sí, bueno, nosotros ya hacemos Scrum”. Entonces utilizo el test de Nokia que el propio Sutherland ha enunciado muchas veces. Normalmente basta con preguntar “Ah, perfecto…Oye, ¿Y cuál es la velocidad de vuestros equipos?” para que se te queden mirando como si les estuvieses hablando en Sánscrito. Otras preguntas típicas incluyen “¿Puedo ver vuestro tablón de tareas?” o “¿Dónde guardáis la pila de producto con su prioridad y sus estimaciones?”. Una muy buena es “¿tenéis una persona identificada como Dueño de Producto, la única persona autorizada a incluir historias y cambiar sus prioridades?”. A la tercera o la cuarta las empresas comienzan a reconsiderar seriamente aquello de “nosotros ya hacemos Scrum” y lo cambian por “hemos tonteado un poco con las reuniones diarias y las entregas parciales”.

Lo peligroso de Scrum es que es muy atractivo leer un folleto sobre los rudimentos de Scrum en cinco minutos y a continuación decir “vamos a implantar esto” sin pararse a considerar qué es lo que hace que Scrum funcione y cuál es la mejor estrategia para implementarlo en su empresa concreta.

Porque al final implantar Scrum es un proceso de cambio, y uno además bastante serio. Scrum es sencillo, pero duro como una piedra, y encontraréis mucha resistencia. Los Jefes de Proyecto no querrán comenzar los proyectos sin tenerlo todo perfectamente identificado, acotado y planificado. Los desarrolladores no querrán la responsabilidad de estimar las historias y demostrar el producto. Los gerentes no querrán dejar tranquilo al equipo durante los Sprints. De hecho, hay en torno a un 40% de empresas que no lo consiguen en absoluto y un 20% que solo consiguen un modelo híbrido de Scrum, que les permite mejorar en su trabajo pero queda lejos del auténtico poder de Scrum desencadenado.

Por eso es importante, al menos en los comienzos, ceñirse a los principios de Scrum. Son reglas holísticas, empíricas, fruto de la experimentación en cientos de miles de equipos haciendo Scrum diarios por todo el planeta. Lo que ha funcionado para ellos bien puede funcionar para vosotros. Y luego, aplicad la regla del Shuhari: aprended la regla, experimentad con la regla y, cuando hayáis encontrado lo que realmente funciona para vosotros, disolved la regla.

Así que si estás entre las empresas que afirman “hacer Scrum”, piénsalo un par de veces y revisa tu proceso. Al fin y al cabo, de eso van las metodologías ágiles: empezar con algo aunque sea imperfecto y luego mejorarlo constantemente.

Como era de esperar, la visión de proveedor, organización y cliente no siempre era la misma, por lo que la realización de grupos de trabajo separados permitió obtener una visión global de la situación y evaluar aspectos de mejora no contemplados originalmente por la organización. En este caso, Proyectalis aportó la metodología para la realización de las sesiones de trabajo, la dirección de dichas sesiones y el análisis final de los resultados obtenidos, incluyendo una propuesta de plan de actuación que incluía los principales puntos de mejora detectados en función de su urgencia e impacto final en los proyectos realizados.