¿Cómo hacer funcionar Scrum? ¿Cómo saber si Scrum está funcionando?
Uno de los lectores de mi blog me planteaba estas cuestiones hace poco. La verdad es que Scrum es simple, pero caminar también es simple y a menudo tropezamos. Que algo sea simple no implica automáticamente que sea fácil de llevar a cabo. Todas las actividades, incluso las más simples, necesitan un periodo de aprendizaje. Muchos equipos de desarrollo fracasan al implementar una metodología y esto no es ajeno a Scrum. Ya he hablado en alguna otra ocasión de las tácticas que podemos tomar para para implantar una metodología. Pero hoy voy a hablar sobre las dificultades que he visto en los equipos en los que he intentado implatar Scrum y como saber si Scrum está funcionando, desde el punto de vista de saber si estamos usando adecuadamente Scrum o no.
Las principales dificultades que encuentran los equipo que tratan de implementar Scrum tienen que ver con:
La falta de atención a los detalles: Muchas equipos fracasan en la implantación de Scrum porque desatienden los detalles. Los detalles son vitales en Scrum. Sin Daily Scrum, no hay Scrum. Sin Product Backlog, no hay Scrum. Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. Sin Sprint Planning Meeting, no hay Scrum. Sin Sprint Review, no hay Scrum. En definitiva, sin seguir a rajatabla las liturgias y las reglas de Scrum, no hay Scrum. El antídoto para este problema es claro: seguir con disciplina monacal las reglas de Scrum. Es fácil caer en hacer 'adaptaciones' a Scrum para 'pulir' los aspectos que no nos gustan, pero siempre que he visto este comportamiento en algún equipo sin mucha experiencia en Scrum, ha sido contraproducente. No hagáis adaptaciones, la probabilidad de dañar Scrum, sin no se tiene experiencia, es mucha.
Entender y formar el equipo multidisciplinar: Construir un equipo es muy difícil y construir uno multidisciplinar aun más. Es más una meta, un proceso que algo que se logra en un momento. Pero la recompensa es muy jugosa. Un equipo multidisciplinar es sumamente productivo y además minimiza los riesgos asociados a la rotación de personal y las 'parcelitas' de conocimiento, por todos conocidos. Hace casi treinta años se escribió Peopleware, la obra definitiva en lo que se refiere a comprender como funciona un buen equipo.
Crear y mantener un product backlog: Construir el product backlog y estimarlo es algo complejo. Se trata de capturar los requisitos del sistema y esto siempre ha sido problemático para los implicados en el desarrollo de software. Pero por mi experiencia, la mayor dificultad no surge de construir el product backlog. La mayor dificultad surge a la hora de mantenerlo actualizado e ir refinándolo de manera continua. Casi todos los Product Owner con los que me he cruzado desatienden su obligación. Aquí el antídoto pasa por que el Scrum Master 'persiga' al Product Owner para conseguir su implicación total en el mantenimiento del Product Backlog.
Recursos no dedicados: Muchas empresas no son capaces de mantener recursos dedicados a un proyecto. Si no mantenemos recursos dedicados, a un número finito y relativamente bajo, la productividad se ve dañada por los continuos cambios de contexto. Muchas organizaciones sistemáticamente obvian el coste de los cambios de contexto excluyéndolo de sus planificaciones . Los cambios de contexto son el problema silencioso de muchos equipos de desarrollo. Cuando un equipo es sometido a continuos cambios de contexto, a continuos cambios de enfoque, difícilmente será productivo. En este caso el antídoto es difícil de aplicar, pues pasa a menudo por un cambio de cultura en la empresa, a menudo acostumbrada a tratar todas las tareas de manera prioritaria, atendiendo en cada momento el asunto que más 'ruido' provoca y renunciando con este comportamiento a la posibilidad de establecer una planificación razonable. La ausencia de una planificación razonable siempre lleva a mermas de productividad relacionadas con la ausencia de objetivos a corto plazo.
Integración de las tareas de soporte y mantenimiento: Muchos equipos tienen dificultad a la hora compaginar las tareas de mantenimiento de versiones o productos anteriores con el desarrollo de nuevos proyectos. La problemática es similar a la comentada para los recursos no dedicados. La idea es, en este caso también, perseguir el minimizar los cambios de contexto. En esta línea la mejor táctica es que sean equipos diferentes los que hacen mantenimiento y los que desarrollan nuevos productos. Pero esto no es siempre posible. Otra táctica habitual es repartir el día entre actividades, por ejemplo utilizar las mañanas para desarrollar un nuevo producto y las tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores. Evidentemente a la hora de planificar un Sprint tendremos que restar de la capacidad de nuestro equipo el esfuerzo que estimamos que tendremos que dedicar a tareas de mantenimiento y soporte.
Estimación: Que la estimación es un aspecto complicado del desarrollo del software es por todos conocido y un tema que he tratado recurrentemente en este blog. En Scrum la estimación es aspecto central. Estimamos el Product Backlog y estimamos las tareas de cada Sprint. La estimación es el primer paso para todo el proceso de planificación tanto a medio como a corto plazo. Aquí el principal problema con el que me suelo encontrar es que los equipos no tienen experiencia en estimar, y por lo tanto se les hace difícil. Esta dificultad hace que muchos equipos recorten las actividades relacionadas con la estimación que Scrum propone. Es imposible hacer una planificación realista sin realizar las actividades de estimación. Además el realizar los procesos de estimación explicita que Scrum propugna conseguimos no solo una estimación realista sino que además aprovechamos el propio proceso de estimación para lograr información sobre qué debemos construir. Una obra indispensable para comprender la estimación y la planificación en las metodologías ágiles es Agile Estimating and Planning de Mike Cohn.
Si bien Scrum tiene sus dificultades a menudo es fácil diagnosticar si estamos funcionando en el marco de Scrum o no. Basta con comprobar, una a una, si estamos siguiendo las reglas de Scrum:
Las reglas de Scrum (I)- El Sprint Planning Meeting
Las reglas de Scrum (II)- Durante el Sprint
Las reglas de Scrum (III)- El Sprint Review Meeting
Las reglas de Scrum (y IV)- El Sprint Retrospective Meeting
Además de esto, las retrospectivas son un excelente momento en el que podemos averiguar si Scrum está funcionando o no: basta con escuchar al equipo para saber si Scrum les ayuda o no. Cuando Scrum no ayuda al equipo es que no está funcionando. Toda metodología que no ayude al equipo de desarrollo a trabajar mejor y con más facilidad, sufrira el rechazo de los desarrolladores. Con el rechazo de los desarrolladores, el grupo más numeroso en cualquier proyecto, ninguna metodología llega para quedarse, por mucho que alguien la empuje.