Leo en el blog Diario de Programación que su autor, ha decidido abandonar Scrum, antes de ni siquiera completar un par de Sprints… hasta aquí poca noticia, porque no es el primero caso ni el último que se da. En este caso no se puede pensar en que se desconoce Scrum, pues el autor de blog, ha publicado una serie de post sobre este tema bastante interesante y se, de primera mano, que había realizado una importante tarea investigadora. ¿Pero que ha fallado entoces? Bueno partiendo del post en el que cuenta que problemas ha encontrado, y como simple ejercicio que me parece interesante, voy a tratar de diagnosticar la situación. Creo que esto puede ayudar a gente que se encuentre con problemas parecidos cuando se decida a intentar gestionar con Scrum sus proyectos. Para ello voy a comentar su post (en cursiva) entre líneas. La verdad que he estado siguiendo lo que escribía ultimamente pues siempre estoy muy interesado en ver cuales son las experiencias de otra gente que utiliza Scrum.
Bueno, al final lo de Scrum se ha ido un poco al garete.
La semana pasada no hicimos ninguna reunión, en parte porque yo tuve que faltar un par de días, lo de las reuniones diarias se me hace un poco cuesta arriba, etc, etc
Uno de los pilares centrales de Scrum son los Daily Scrum. Es la manera de abordar la comunicación en esta metodolgía. La comunicación es uno de los mayores problemas a los que nos enfrentamos en el desarrollo de software. Todas las metodologías abordan este problema y plantean alguna solución. Es un problema además vital en los equipos ágiles, donde no hay documentación que prentenda sustituir a la comunicación cara a cara. Si prescindimos del Daily Scrum o no le damos la continuidad pautada en Scrum estamos dañando la metodología de tal manera y en un area tan importante que es muy dificil que lleguemos a buen puerto. Sin Daily Scrum, no hay Scrum. En general, sin abordar el problema de como se comunica el equipo y darle una solución, no hay metodología.
Entiendo que para convocar la reunión diaria y llevarla, el Scrum Master no puede ser una persona que hace/le gusta hacer código. Aunque hay excepciones, me hace la impresión de que en general es cierto que la persona cuya mente entiende los punteros, no es una persona que grandes dotes sociales. No quiero decir que sea un inadaptado, pero posiblemente no es el tipo de persona que gusta dirigir una reunión de ocho o nueve personas … todos los días.
Otro ‘error’ que se vislumbra es el pensar que alguien dirige el Daily Scrum. Esto es un error habitual, al Daily Scrum se va a compartir información, no a rendir cuentas. Es muy importante que esto quede claro de palabra y de acción, sino perderemos la posibilidad de que el equipo nos traslade la información que necesitamos para guiar el desarrollo.
Es importante que el Scrum Master se capaz de comunicar, de escuchar y de actuar para eliminar impedimientos. Pero no veo que esto este reñido con que te guste programar o entiendas los punteros. A mi me encanta programar y entiendo los punteros. Se que hay equipos que incluso rotan la figura del Scrum Master entre uno de los miembros del equipo. No creo que sea recomendable al principio, pero sin duda si no hay nadie que disfrute con ese rol puede ser una solución para repartir esta ‘pesada carga’.
Otro problema que nos tira abajo es el horario flexible de la gente. Desde que llega el primero hasta que llega el último puede pasar hora y media o dos horas. Cuando llega el último, los primeros no solo están ya enfrascados en su trabajo, sino que incluso pueden que no estén en su sitio liados con otras cosas.
Sobre el tema del horario flexible, no creo que sea un impedimiento de peso. ¿No hay horas en las que todos los miembros del equipo coincidan? Seguro que un café todos juntos ya se toman al día, seguro que hay otras reuniones a las que acuden, seguro que comentan el futbol quince minutos al día, no me creo que no haya un momento en el día en que poder ubicar el Daily Scrum y que todos acudan. Esto no es un problema si cumplimos una regla básica: ¡el Daily Scrum solo dura quince minutos!
También es difícil coordinar los finales de Sprint. Cuando se hace la versión ejecutable, siempre hay pequeños fallos de última hora, por lo que planificar la última reunión de demo y demás es complicado. Para que esa versión entregable salga bien y a tiempo, da la impresión de que es necesario reservar uno o dos días al final del Sprint para depurar los útlimos errores. También sabemos todos que depurar errores no es algo que se pueda planificar, un error se puede encontrar y corregir en dos minutos o en dos días, según le de.
Sin duda es dificil. Pero no es una dificultad que surja de la necesidad de hacer una demostración. La demostración es la solución, la dificultad es integrar software tan complejo como el que se construye actualmente. Solo haciendo la integración un hábito, lograremos que deje de ser un problema. Integrar es como correr cinco kilometros, muy dificil si no lo haces a menudo, muy facil si lo haces habitualmente. Es normal que aparezcan errores durante una demo, nadie va a abuchear al equipo. Pero si que es cierto, que el tener que demostrar el funcionamiento del software hace que el equipo no deje la calidad para el final. Dejar la calidad para el final es algo que la daña de manera irremisible y la calidad no es opcional. Además el enfoque debe estar en no tener que depurar bug, en no introducirlos, en ser cuidadoso y escribir buenos test. Con buenos tests, no es necesario reservar días para preparar la demo. De hecho, dedicar dos o tres días a preparar la demo esta desancosejado y debe evitarse, pues es sintoma de que no se está desarrollando con la calidad sufiente.
Y otro problema más es la coordinación de la gente en esas etapas finales. En los últimos días del Sprint hay quien ha terminado sus tareas, mientras que otros todavía no o está depurando detalles. ¿Qué hacemos con los que han acabado?. Normalmente no pueden ayudar en las etapas finales de las tareas de otros, ya que les son ajenas y posiblemente entorpezcan más que ayuden.
Sobre esto preguntaba un lector de este blog hace un tiempo y respondí en este post. Esto demuestra que es un problema que aparece habitualmente. Me limito aquí a reproducir la respuesta que entonces dí: No olvidemos que el equipo en Scrum es un rol central. No olvidemos que el equipo en Scrum debe ser multidisciplinar y que por lo tanto, debería contar en su interior con todo el conocimiento necesario para llevar a cabo el proyecto de manera colegiada. Ninguna actividad en el ciclo de vida de un proyecto se realiza en completo aislamiento de otras, luego todos los integrantes del equipo tienen algo que aportar en todo momento. Cuando un miembro del equipo acaba sus tareas y no puede colaborar con otras (raro me parece) tiene muchas cosas que hacer: tomarse tiempo para conocer otras partes del proyecto que no domina, formarse en tecnologías que tendrá que usar más adalante, mejorar la cobertura de código de los test, mejorar el proceso de build, programar algún script que automatice alguna tarea engorrosa o propensa a fallos, sentarse con otro programador que esta escribiendo algo que es importante, hacer una ppt para presentar la próxima demo, investigar que componentes pueden ser utiles para implementar proximos Product Backlog Items, leer este blog ;)… ¡Siempre hay algo importante que hacer!. Basta con decir que estas ‘mirando’ en el Daily Scrum para que alguien sugiera algo que puedes hacer.
En fin, no ha salido rápido y a mí, como buen inadaptado social, no me apetece seguir con ello -tampoco veo demasiado apoyo de los demás-. Así que seguiremos con algo similar -pequeñas entregas cada cierto tiempo-, pero de una forma un poco más tradicional -preguntando de vez en cuando a cada uno cómo va-.
Desarrollar software es complejo. Nada, nunca sale facilmente y rápido. Sobre todo las cosas en las que no tenemos experiencia. Sobre todo lo relacionado con procesos y metodologías, un area en la que cada proyecto y cada equipo debe realizar ajustes imprescindibles. Sobre el apoyo de los demás, sin duda se ha cometido el error habitual de no tener un sponsor y no tener una táctica para lidiar con esta carencia. Ya escribí sobre este tema, que es clave para lograr que una metodología triunfe. Todo el mundo es reticente al cambio, al menos de entrada. Además creo que es vital explicar al equipo y al Product Owner, que van a obtener si Scrum funciona y creo que esto no se ha hecho.
De todas formas, este proyecto me pillaba un poco ajeno, simplemente estoy como ayudante/asesor o cosa rara similar. Es posible que si en algún momento me toca a mí llevar un proyecto de estos de forma más directa, vuelva a intentarlo.
Si quien es el Scrum Master, no lo tiene claro desde el principio… Es vital que la figurar del Scrum Master sea una figura fuerte, que tenga claro en que consiste Scrum, que ventajas aporta, que resultados se persiguen y lo más importante, que sea capaz de transmitirlo con entusiamo y claridad. Creo que si Scrum falla, en un 90% de los casos se debe a que no hay un Scrum Master con capacidad suficiente detrás de la iniciativa. Scrum, en esencia, no es dificil, pero comenzar con Scrum si que lo es. Creo que es un error lanzarse a Scrum contando solo con lo que se ha leído en libros, webs y blog. En mi opinión es casi imprecindible recibir una formación profunda y un periodo de mentoring con alguien que haya logrado implantar Scrum con anterioridad. Creo que esto es algo que se aplica a cualquier metodología.
¡No tireís la toalla con las metodologías! Cuesta, pero merece la pena.
Por ultimo agracer al amigo Chuidiang que haya compartido su experiencia públicamente en su blog.