Nadie dijo que no exigiese un esfuerzo…

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.

27 comentarios sobre “Nadie dijo que no exigiese un esfuerzo…”

  1. Rodrigo … en 1er lugar, excelente post –> los comentarios sobre SCRUM !!!

    Y como tu bien siempre escribes: uno de los pilares fundamentales para llegar con exito al final de un proyecto es implantar de manera correcta una metodologia de trabajo (independientemente de cual, pero para gustos colores)
    Yo por suerte he tenido la suerte de trabajar con Scrum en varios proyectos y en cada uno de ellos siempre he aprendido un poco mas al respecto. Y creo que el daily scrum pueden parecer medio tedioso, pero termina siendo imprescindible al momento de evaluar el estado del proyecto. Aunque también es fundamental la capacidad del ScrumMaster para interpretar los mensajes que se obtienen en el daily scrum y con los mismos gestionar el proyecto.

    Yo le daría una oportunidad más a Scrum … total a la 3ra es la vencida 😉

    Saludos

  2. Pues yo, estoy a punto de comenzar mi tercer sprint, y la verdad estoy encantado, y las ventajas me parecen infinitas, es mas, mi idea es trasladarlo a varios departamentos de la empresa donde creo que se podria adaptar a la perfección, tan ilusionado estamos que, aunque mi equipo es muy pequeño (4 personas), si en alguna ocasión me olvido de hacer la reunion de scrum, los demas miembros del equipo me lo hechan en cara, ya que han comenzado a valorar la importancia de esta tarea, que en nuestro caso, normalmente no excede de 10 minutos, pero es fundamental para planificar, priorizar tareas y resolver algun problema, y ademas muchas veces la utilizamos para bromear y entre unos y otros nos hechamos en cara porque no hemos terminado esto y aquello, «Aunque ya se que esto no no es lo que dicta la metodologia», nos solemos reir bastante de nosostros mismos… es un momento en el que los miembros del equipo se liberan tambien en cierto modo del desarrollo, y eso mejora el ambiente de trabajo.

    Curiosamente cuando observo problemas en otros los dptos, en su mayoria debidos a una mala comunicación y planificación entre sus miembros, empiezo a pensar, scrum esto, scrum aquello, estare enfermo ???, en cualquier caso estoy deacuerdo con una frase que escuche a Rodrigo que decia algo asi como, «lo peor es no utilizar ninguna metodologia…»

    Os agradezco mucho el trabajo que realizais. A mi me esta ayudando enormemente, y creo que la gente que tenga la oportunidad de ponerlo en marcha, estara deacuerdo conmigo, no solamenente en cuanto a proyectos informaticos, creo que muchos de los proyectos que desarrollan las empresas tienen en scrum la posibilidad de mejorar enormemente su gestión, la idea de hacer builds, y reducir en pequeñas tareas el proyecto, acompañando de reuniones diarias son cosas tan sencillas y faciles de implantar que se puede trasladar a cualquier proyecto, como dice el refran (divide y venceras…) y no solamente a la hora de construir sino a la hora de vender un proyecto, creo que la mayoria de las consultoras y fracasos informaticos bienen por no utilizar una metodologia adecuada. No se quizas lo consulte con mi psiquiatra… scrum, scrum, scrum,

    Por cierto me estoy planteando utilizar esta metodologia con mi mujer, reuniones diarias de 10 minutos, no se… si alguno teneis esperiencia o conoceis una metologia mas adecuada por favor, no dudeis en informarme.

    Salu2.

  3. Mic, me parece que tu si que has pillado la esencia del Daily Scrum, en mi equipo es muy similar. A nosotros no se nos olvida, porque llegar tarde al Daily Scrum es un euro para el bote de equipo…

    Con el Bruno comparto que nunca se deja de aprender sobre Scrum, es claro que es un marco bastante abierto, que en cada proyecto y cada equipo necesita su adaptación. Es como jugar al baloncesto, muchos equipos juegan al baloncesto y comparten la reglas, pero cada uno hace su baloncesto.

    Saludos y gracias por los comentarios, es lo que más enriquece el blog.

  4. Interesantísimo. Yo la estoy pensando empezar a usar… pero lo que más me echa atrás (aparte de que vamos a certificarnos en CMMI nivel 2, jeje esa es otra película) es que los proyectos se empiezan con los requerimientos «cerrados»! Vamos, que obviamente el cliente quiere un presupuesto, y entonces se definen casos de uso y una planificación… Total, metodologías ágiles al carajo (no sus «buenas prácticas»). ¿tiene sentido usar Scrum en ese entorno? A mi me gusta como metodología de desarrollo, pero no sé, si al final se va a intentar minimizar los cambios de los clientes por que ya estás en presupuesto cerrado, de ágil na de na…

  5. Scrum no esta reñido con CMMI Nivel 2, todo lo contrario, hay empresas que se han certificado en el nivel 2 utilizando Scrum. También existen varias aproximaciones a como casar las metodologías ágiles con los contratos cerrados, es un tema que quiero abordar proximamente. Pero de todas formas, no hay contratos cerrados, no hay requisitos cerrados, solo hay negociación con el cliente. La diferencia está en que esta sea explicita y a lo largo de todo el proyecto, buscando hacer el mejor software que cubra las necesidades del cliente, o implicita y solo al final del mismo para acordar si los requisitos se han cubierto o no.

  6. Rodrigo, lo primero de todo la enhorabuena por tan excelente post. Efectivamente, adquirir el hábito por bueno que sea, siempre cuesta inicialmente.
    Y hablando de formación, ¿ dónde se puede recibir formación sobre Scrum em España ?

  7. Hola aderojas!!!

    En Plain Concepts, además de hacer nuestros proyecto usando Scrum, damos formación y mentoring sobre como utilizar Scrum, con y sin Visual Studio Team System.

    Un saludo.

  8. Hola:

    Aunque los motivos del «fallo» son más o menos los que puse en el blog, la realidad es que me pilló un momento bajo, sin muchas ganas de pelear o seguir esforzándome en ello. ¡¡ Me dolía una muela !!. De hecho, los dos días que comento que falté fueron para ir al dentista.

    También me echó mucho atrás el ver que en mi ausencia nadie se tomó la molestia de hacer el Scrum diario y lo que es peor, al dejar de hacerlos, sin decir nada, nadie preguntó si ibamos a seguir o no. Ante la indiferencia total del equipo -a pesar de que lo habíamos hablado antes y parecían dispuestos a intentarlo-, decidí que mejor dejarlo correr.

    Sin embargo, aunque ahora sé que va a costar más esfuerzo del que parece, sigo teniendo en mente volver a intentarlo en algún otro proyecto.

    Se bueno.

  9. Hola a todos:

    Desde mi punto de vista, es una pena empezar algo así y tener que abandonarlo al inicio, teniendo en cuenta que yo en concreto he puesto todo mi entusiasmo en iniciarlo. En mi caso, casi lo abandonamos antes del sprint 0 (no es coña), y no por el equipo, sino por la directiva, tema que nadie ha comentado, me imagino que porque no habéis tenido problemas de este tipo. Para mi es la parte más complicada, hacer ver al los cherifs las bondades de SCRUM. En cuanto a las ganas…., pues como dice Rodrigo, si el Scrum Master no cree en ello….
    En relación a sacar partido a SCRUM en otras áreas, yo lo voy a aprovechar (espero que este blog no lo lea el cherif) para intentar meter todo lo relacionado con nuestros productos, desde planificación, obtención de datos de clientes, marketing, gestión de producto, distribución y todo lo que se me ocurra, ya que en la actualidad no existe estructura en nuestra empresa (todos capitán general) y me parece una buena oportunidad de exprimir al máximo SCRUM (mientras nadie se lo huela….).
    El lunes empezamos nuestro particular Sprint 0, espero que lleguemos al 1.
    Un saludo.

  10. Vas… es lo que ya he comentado en anteriores ocasiones de buscar un Sponsor, comprarlo o actuar como caballo de troya: http://geeks.ms/blogs/rcorral/archive/2006/10/09/Implantar-mejoras-en-la-gesti_F300_n-de-tus-desarrollos.aspx

    Vuestro enfoque ha sido intermedio entre buscar un sponsor y un mentor (papel que un servidor ha tenido el placer de realizar) y actuar con el enfoque de caballo de troya (papel que tu has jugado de manera acertada e inteligente a pesar de los reveses). Creo que el equipo ha quedado convencido de las bondades de Scrum y eso es más importante en un primer momento que que sea el ‘sherif’ quien se convenza. Al ‘sherif’ en cuanto empiece a ver software funcionando en el Sprint Review os lo ganáis… ahora ya digo… esto, al principio, exige un esfuerzo, la idea es que merezca la pena.

    De todas formas conozco vuestro intento de primera mano ;), y quitando las reticencias que podaís encontrar en un principio, no tengo duda de que tendréis exito. Tenéis las ganas y el equipo necesario.

    Suerte con vuestro Sprint 0!!!

    Un saludo!!!

  11. Hola!
    Me parecen muy valiosas las reflexiones que haces Rodrigo.
    Como dice Ken Schwaber es una metodología simple, pero dura; y como apuntas en tu comentario es un modelo abierto del que nunca se termina de aprender.
    Son frecuentes los fracasos o los resultados solo a medias al implantar una metodología, como en este caso apunta Chuidiang, pero la metodología en sí no tiene por qué ser el problema.
    Es muy importante que tanto el scrummaster como el propietario del producto y todo el equipo la conozcan bien; y que el «sistema» en su conjunto: la organización, su cultura, el tipo de proyecto y como lo ha vendido y cerrado o no requisitos o compromisos con el cliente etc. estén alineados. De lo contrario se fragmenta el sistema y no se obtiene el funcionamiento que se debería.

    Un saludo!

Deja un comentario

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