Waterfalacias: Mitos y creencias sobre Scrum

 

En toda transición hacia Scrum o cualquier otra metodología ágil es común enfrentarse a un elevado porcentaje de rechazo entre la gente que es parte de ese cambio (de hecho cualquier cambio impuesto suele generar rechazo en primera instancia). Los motivos que esta gente tienen para no aceptar este cambio no  pueden ser de lo mas variado: hay quien tiene miedo a perder poder, otros intuyen que va a tener que «trabajar más» e incluso hay gente que simplemente están contentos con la situación actual, pero curiosamente muchos de ellos suelen coincidir en su argumentario a la hora de explicar el porqué de sus objeciones.
Algunos de estos argumentos comunes los recoge Mike Cohn en su estupendo libro «SuccedingWith Agile« (de hecho el título del post lo he «robado» del libro) y ciertamente son argumentos que yo mismo me he encontrado o que he escuchado mas de una vez cuando intentas explicar o formar a alguien en metodologías ágiles, y que ya se han convertido en mitos o creencias «populares».
En este artículo voy a intentar desmitificar algunos de estos argumentos, explicando mi visión sobre cada uno de ellos y intentado aclarar el porqué son incorrectos o inexactos. 
Empecemos:
  • En Scrum no se planifica, por lo tanto no somos capaces de dar estimaciones a nuestros clientes
Aunque parezca lo contrario en Scrum se planifica bastante más que en las metodologías tradicionales, lo que pasa que esta planificación se lleva a cabo de una manera mucho más «responsable». En lugar de hacer todo el esfuerzo de planificación al inicio, donde la incertidumbre es mayor y estamos sujetos a cualquier tipo de cambio o imprevistos, en Scrumse va planificando durante toda la vida del proyecto, y además a diferentes niveles:
– Planificación inicial: Donde se crea, prioriza y estima el product backlog inicial del proyecto (normalmente se realiza en una iteración 0 o fase de Inception y los requisitos son definidos a alto nivel)
Planificación durante cada iteración: Donde se refina el product backlog (ProductBacklog Grooming) y se decide que se va a llevar a cabo durante la siguiente iteración (SprintPlanning Meeting)
Planificación diaria: Donde el equipo ajusta la operativa del día a día (Daily Meeting)
Así vemos que en Scrum se está planificando continuamente y que la diferencia principal con metodologías más clásicas es que la planificación inicial no es ningún dogma, sino que a partir de lo que se va aprendiendo durante el proyecto esta se va ajustando para cumplir mejor las expectativas del cliente.
  • Scrum necesita que todo el mundo sepa hacer de todo
Otro de los principales mitos de Scrum es que todo el mundo tiene que saber hacer de todo, y esto hace que los especialistas dejen de tener sentido. Aunque bien es cierto que demasiada especialización de los miembros del equipo puede ir en contra de los intereses del proyecto, realmente lo deseable es que «El Equipo» sea multidisciplinar, es decir que entre todos los miembros del mismo reunan los «skills» necesarios para llevar a cabo el proyecto evitando cosas como equipos de analistas, equipos de testing, etc… que favorecen los nichos de conocimiento y el «lavado de manos» dentro de un proyecto. Si a esto le sumas que las personas que forman estos equipos son capaces de, más allá de su especialidad, ayudar con otras tareas en momentos concretos de los proyectos tenemos equipos donde el conocimiento está muy compartido y donde es difícil ver bloqueos ante la falta de alguno de los miembros.
  • Tenemos equipos distribuidos y en Scrum es necesaria la comunicación cara a cara
Al igual que as anteriores ideas, esta proviene de gente que simplemente se ha quedado en la superficie de Scrum y no ha profundizado en la misma. Uno de los principales valores de las metodologías ágiles es la comunicación entre los miembros del equipo , entonces «¿que hacemos si nuestro equipo es distribuido?» La respuesta más fácil es «no podemos hacerScrum«, aunque realmente la respuesta correcta sería: «lo mismo que si el equipo está co-localizado», aunque eso si, con matices. Obviamente la comunicación cara a cara no se sustituye con nada, pero con la tecnología actual deberíamos ser capaces de llevar a cabo un proyecto de manera muy normalizada con nuestros compañeros que trabajan en remoto (videoconferencia,chats, etc…)
  • Los equipos Scrum no documentan y nuestros clientes nos exigen documentación
En este punto no voy a comentar demasiado. Simplemente señalar que en Scrum y en las metodologías ágiles en general los documentos son un medio, nunca un fin, y por lo tanto se intenta evitar toda aquella documentación que no sea útil para que el proyecto se lleve a cabosatisfactoriamente y quedarse con aquella que si es importante. Es decisión de cada equipo pensar que es y que no es útil para este fin y actuar en consecuencia. Pero… ¿de verdad todavía nos creemos que toda la documentación que nos exigen algunas metodologías tradicionales tiene sentido?
  • Scrum no tiene en cuenta la arquitectura y el diseño
Nada más lejos de la realidad. Simplemente que el hecho de definir esta arquitectura y este diseño se lleva a cabo de manera totalmente opuesta a cómo lo intentan hacer las metodologías tradicionales: En Scrum no hay un equipo de «arquitectos» que deciden al principio del proyecto sobre un Power Point cómo va a ser la arquitectura, sino que a partir de unas líneas generales iniciales a alto nivel la arquitectura va emergiendo iteración a iteración a medida que se va desarrollando el proyecto, y además durante todo este tiempo los «arquitectos» trabajan codo a codo con los desarrolladores adaptando la arquitectura a los nuevos requisitos. De hecho en las metodologías ágiles se considera que buena parte del diseño (si no todo) está en el propio código y en consecuencia se le da el estatus y la importancia que eso implica, poniendo mucho énfasis en prácticas de ingeniería que aseguren una alta calidad y mantenibilidad del código (TDDBDDPair ProgrammingCode ReviewsContinuous Integration, S.O.L.I.DPrinciples…)
  • Nuestros proyectos son demasiado complejos para realizarlos con Scrum

Esta es una de las ideas que menos entiendo ya que en toda la literatura sobre Scrum que he leído nunca he visto nada que pueda dar a entender esto. Precisamente Scrum funciona especialmente bien en proyectos complejos, siendo flexible a posibles cambios durante todo el proyecto, gestionando los riesgos de manera implícita iteración a iteración y potenciando además la creatividad y la innovación de los miembros del equipo lo que garantiza un porcentaje de éxito mucho mayor en cualquier proyecto.

Cómo veis, todos estos argumentos son fácilmente rebatibles desde el raciocinio y el sentido común y no deberían ser un problema real en una implantación de metodologías ágiles. Sin embargo, como ya hemos dicho antes, estas argumentaciones suelen ocultar otro tipo de miedos, y estos son el verdadero desafío a la hora de hacer que la gente esté receptiva o no ante un cambio metodológico.
Un saludo!!

 

4 comentarios sobre “Waterfalacias: Mitos y creencias sobre Scrum”

  1. Me ha gustado el post, pero algunas cosas me han «sonado mal». Te dejo mis apuntes

    «En Scrum no se planifica, por lo tanto no somos capaces de dar estimaciones a nuestros clientes. Aunque parezca lo contrario en Scrum se planifica bastante más que en las metodologías tradicionales,» … mmm la gran diferencia está en que en SCRUM nunca vas a poder firmar un proyecto a 2 años, porque no sabes que puede suceder de aqui a 2 años. En otras metodologías si se firman planificaciones a 2 años, no se cumplen luego, pero si se firman.

    «Tenemos equipos distribuidos y en Scrum es necesaria la comunicación cara a cara» aquí es donde más peleas tengo yo con os Agiles Gurues, y no coznoco a ninguno con una solución mágica para equipos grandes distribuidos y con diferentes zonas horarias. yo te digo que Scrum con equipos de Seattle, Madrid y Bangladesh no se puede hacer. La solución pasa por la organización y la separación de responsabilidades, fases, equipos más pequeños, etc. Pero no he visto un equipo de, digamos 5 personas, 3 en Madrid y 2 en Canberra que hagan Scrum. Si alguno tiene una experiencia de ese tipo pues yo quiero ser el primero en conocer como ha funcionado eso.

    ¿De verdad todavía nos creemos que toda la documentación que nos exigen algunas metodologías tradicionales tiene sentido? … a lo que yo te pregunto: ¿has trabajado con militares? ¿o con equipos de investigación oficiales? pues en esos casos la documentacion tiene sentido porque es la que da vida al proceso. Es una pena y muchas veces realmente no aporta nada al resultado «tangible» de un proyecto, pero si a la firma burocrática del mismo.

    Espero que no suene a crítica de mala manera, solo es mi pequeño grano de arena 😀

    salu2

  2. Muchas gracias por los comentarios! Para nada suenan a crítica!!

    Entiendo tus argumentos, aunque no los acabo de compartir del todo.

    Por ejemplo, dices que la documentación es necesaria en algunos entornos cómo militares y equipos de investigación, pero después dice que no aporta nada «tangible» al proyecto. Esto precisamente es lo que yo intento expresar, que hay «mucha» documentación que no sirve. Otra cosa es que esos entornos sean capaces de librarse de ese lastre algún día…

    En cuanto a lo de los contratos a 2 años… pues no veo el motivo que lo impida.Obviamente esta planificación habrá que ir refinándola a medida que avance el proyecto y se vayan descubriendo cosas del mismo, vayan emergiendo nuevos requisitos, etc. Pero de hecho… en los proyectos tradicionales tampoco se sabe que va a pasar en 2años!! Otra cosa es que la gente crea que lo sabe, jejej.

    Un saludo!

  3. Juan Antonio,

    el tema de la documentación está más bien atado al proceso en el caso que traté de explicar. Cuando digo que no es un resultado tangible, me refiero a lo siguiente: supon que estas trabajando con una agencia espacial en la programación del módulo de una tarjeta integrada que controla el escape de gases de un ABC. Por lo general, las líneas de código para este producto suelen ser muy pocas (pero muy pocas), pero detrás de estas líneas de código hay una serie de artefactos que dan soporte al proyecto que pueden llegar a marear: diseños, análisis del diseño, diagramas de implementación, casos de pruebas, resultados de los casos de prueba por iteración, etc. Vamos que en realidad para 200 líneas de código (no más) hay una cantidad de «documentación» que puede asustar. Pero en estos entornos (militares, investigación, $$$$) pues suele ser el pan de cada día. No digo que esté bien, y seguro que se puede mejorar para seguir teniendo un producto de gran calidad, y mucho más rápidamente, pero cuando pasa lo que paso por ejemplo hace 3 años en el CERN, pues desde aquí se tira del hilo.

    En conclusión: 200 líneas de código > 1TB de documentación asociada. ¿asusta no?

    Salu2

    PD: que conste que en estos casos la propuesta no pasa por elegir SCRUM o no SCRUM, sino por cambiar el proceso para obtener resultados antes pero respetando el proceso. Se puede «hacer SCRUM» y seguir respetando el proceso.

  4. Bruno, totalmente de acuerdo contigo. En el fondo creo que pensamos lo mismo aunque lo enfoquemos diferente.

    Lo que yo quería expresar (y seguramente no he conseguido) es que Scrum te da libertad a la hora de definir la documentación que necesitas para llevar a cabo tu proyecto: Si por contrato es necesario todo este volumen documentación, pues adelante, pero siempre es interesante pensar si hay algo que podamos eliminar, que no nos sirva, que no aporte al resultado final (en fin, eliminar el desperdicio). Más o menos lo que tu comentas sobre cambiar el proceso para obtener resultados antes.

    Un saludo y gracias!

Responder a elbruno Cancelar respuesta

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