¿Cómo hacer funcionar Scrum? ¿Cómo saber si Scrum está funcionando?

Broken bridge 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.

12 comentarios sobre “¿Cómo hacer funcionar Scrum? ¿Cómo saber si Scrum está funcionando?”

  1. Muy buen post Rodrigo, es una «checklist» completita para los que estamos comenzando con Scrum.

    Una sugerencia…dedicar algún post al mantenimiento del Product Backlog. Creo que muchas veces no queda claro el nivel de refinamiento que debe tener cada entrada partiendo por ejemplo de un requisito de usuario.

  2. Olé, olé, olé.

    Señor Corral, he tenido que frotarme los ojos tras dos lecturas. No me lo podía creer. Ningún maltrato al castellano.

    Enhorabuena, Señor Corral, porque parece moco de pavo escribir para el público sin faltas. Ambos lo sabemos que cuesta 😉

    Fdo. J, talibán a mucha honrilla.

  3. Edu:
    Lo del libro… mucha gente me lo dice, pero la verdad es que ya hay muchos. Cada vez me inclino más por la interactividad, la inmediatez y la cercanía del blog…

    Querido Talibán:
    Has logrado lo que no han logrado años de educación pública.

    Augusto:
    Si vieses la de equipos que esperan milagros de Scrum o de MSF o de Team System y son incapaces de ver que los cambios de contexto son el principal problema que tienen… Bien es cierto que Scrum puede ayudar mucho a minimizar los cambios de contexto.

  4. Excelente post, Rodrigo. 🙂

    Me llama la atención el énfasis de los talibanes ortográficos, como ellos se autodenominan. Me resulta especialmente gracioso cuando ellos mismos cometen errores. En este caso, afirmando que el post está libre de errores cuando no es así. A raíz del comentario de J me puse a revisar el texto y encontré 3 fallos en las primeras 14 líneas… Cuando llegué a la expresión «La falta de atención a los detalles», decidí dejar de prestar demasiada atención a detalles que a mi modo de entender no son de vital importancia.

    Con esto no quiero criticar ni causar polémica, ni contigo (llevo las de perder a juzgar por tus dimensiones :-P), ni con los talibanes ortográficos, ni con nadie… Desde luego, quien esté libre de pecado que tire la primera piedra. Y mis posts y comentarios tienen infinidad de errores, tantos o más que los de cualquier otro.

    Lo que sí me gustaría es resaltar la importancia de saber relativizar en lo que a errores se refiere, algo aplicable tanto a la corrección ortográfica de nuestros posts como a la calidad de nuestros desarrollos software.

    Creo que ambos estamos muy de acuerdo en ambas cosas, y desde luego espero que una excesiva atención al detalle no tire por tierra el planteamiento global de una idea acertada. Un sintagma nominal («idea acertada») bastante adecuado a la hora de describir la gran mayoría de tus posts, dicho sea de paso.

    Un abrazo y enhorabuena de nuevo.

  5. Sin ánimo de crear polémica.

    El título de talibán ortográfico me lo dio el Señor Corral y yo recogí el guante como una manera de aceptar también las críticas a mi criticismo.

    Por supuesto que estoy sujeto a fallos. Trabajo fallando más que acertando. Por eso me gusta que me lo digan y me ahorren el tiempo de buscarlo yo. Si tengo fallos ortográficos, fetén, di cuáles, no lo dejes en plan abstracto.

    De los 3 fallos del Señor Corral en las 14 primeras líneas, he encontrado uno «como saber si Scrum «. Ese «cómo» va con tilde. No lo vi, porque yo también me equivoco.

    Entiendo que escribir para el público con faltas es como ir al amor sin duchar. Habla mal de uno. Lo que dice el Señor Corral es muy interesante, pero tenía algo entre los dientes que deslucía el texto. Me preocupé de decirle que tenía algo para que se lo quitara.

    Además no creo que el Señor Corral necesite monaguillos para estas lides.

    Un saludo a todos, J, talibán mal que pese.

  6. Ya basta de coqueteos muchachos!

    Muy buen post Rodrigo, muchas gracias.

    Por cierto, siempre es bienvenido el esfuerzo de mostrar de mejor manera las cosas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *