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!!

 

Mis tres días en la XP2011!

Después de que mi compañero Vicenç haya explicado sus experiencias en la XP 2011 me toca a mi el turno de hablar de los 3 días que pasé allí. La conferencia tuvo lugar en Madrid la semana pasada, y es la más grande de Europa y la segunda en tamaño del mundo después de la Agile Conferenceque se celebra en Estado Unidos, y yo tuve la inmensa suerte de asistir durante 3 días (la conferencia duraba 4, pero el primero de ellos no pude estar). Estaba realmente emocionado con la oportunidad ya que se iban a dar cita algunos de los grandes referentes en el mundo del desarrollo ágil de los últimos años cómo Mary y Tom Poppendieck creadores del término «Lean Software Development»,David Anderson creador de Kanban y muchos otros cómo J.B. Rainsberger, Jurgen Appelo, Michael Feathers…

Así que con las expectativas muy altas llegaba el Miércoles por la mañana con la Keynote de Esther Derby titulada «Still No Silver Bullets» ya empezada. Después de terminar esta y de saludar brevemente a algunos compañeros de diferentes grupos ágiles de España pasamos directamente a las sesiones. El formato de la conferencia durante los dos días intermedios (el primero y el último eran talleres y tutoriales) mezclaba sesiones de una hora entera con lightning talks de 20 o 30 minutos cada una, lo que tiene su lado positivo (dinamiza mucho la conferencia) pero también su lado negativo (muchas veces el tema se toca de manera demasiado superficial).

Aun así salí contento de unas cuantas sesiones sobretodo de las de Jurgen Appelo: «The Purpose of Leadership and Governance» y la de Angel Medinilla presentando «Scrumban» (divertido e ilustrador como la mayoría de las veces que le he visto).
El primer día lo acabamos con la creación de la agenda del Open Space que se iba a realizar al día siguiente y más tarde con una cena de gala cortesía de la organización en la casa de campo de Madrid, donde se repartieron los premios a los mejores papers de la conferencia y donde después de la cena unas cuantas personas de la comunidad demostraron que no se les queda pequeño el adjetivo «ágil», con bailes imposibles, saltos fuera de lo común y movimientos de cintura realmente espectaculares… 😛

El segundo día siguió un guión parecido: Keynote de Brian Marick(que consiguió que todos los presentes en la sala se pusieran a bailar tango…) y más sesiones y lightning talks. Esta vez creo que acerté un poco más con las sesiones cortas donde hubo cosas realmente curiosas cómo por ejemplo charlas sobre Zombies y Scrum por Marc Löffler, sobre rehabilitación de adictos al Command and Control por Angel Medinilla , sobre cómo Scrum podría convertirse en un nuevo paradigma del socialismo por Rafael Viveros (pero socialismo del de verdad, no del que nos venden ciertos políticos del tres al cuarto…) o alguna sesión más convencional sobre cómo empezar a hacer TDD de manera práctica por Thomas Nielssen.
Después de una interesante cena y post-cena por Madrid en compañía de unos chicos Holandeses (de los que no me acuerdo del nombre) nos fuimos a dormir cansados pero con ganas de afrontar el último día de conferencia que a priori se presentaba muy bien ya que se trataba de 2 talleres y tutoriales de 4 horas de duración cada uno.
Con 10 minutos de retraso debidos a problemas logísticos entramos al taller sobre Refactoring de Michael Feather’s, que supuso una pequeña decepción…ya que la sesión no era de Refactoring!! En disculpa del señor Feathers hay que decir que en la puerta de la sesión había una hoja donde se explicaba cómo iba a ser el taller, pero al llegar tarde no nos dimos cuenta pero… ¿porqué poner ese título? Aún así la sesión nos sirvió para aprender un poco de Ruby, ya que era el el lenguaje en el que se hacía el taller
Tras pelearnos con Ruby fuimos a comer, y después una larguísima sobremesa (para mi uno de los únicos fallos de la organización, que por otro lado estuvo genial y además eran gente muy maja y a la que felicito desde aquí) nos dirigimos al último taller. Para el fin de fiesta escogí el taller de Jurgen Appelo, basado en su curso sobre Agile Management y que a priori tenía muy buena pinta. Y la verdad es que no defraudó. Aunque muchos acusan a Appelo de ser un mero recopilador de ideas de otra gente, yo creo que está creando cosas y conceptos interesantes, o por lo menos les está dando una visión que me parece muy adecuada. Además el taller fué entretenido y mezcló la teoría con juegos cómo el Delegation Poker el Meddlers of Catán o uno sobre una matriz de métricas, todos ellos muy amenos y que además te hacen pensar.
Meddlers of Catán de Jurgen Appelo

Al acabar el taller sólo tuve tiempo de despedirme de la gente y salir corriendo para no perder el AVE de vuelta a Barcelona donde cansado (pero contento por todo lo aprendido, por la experiencia vivida y por poder debatir sobre metodologías ágiles con algunas de las personas más destacadas de este país y de todo el mundo) no tardé en quedarme dormido…

 

Mis dos dias en la XP2011

Este jueves y viernes he tenido el placer de asistir a la XP Conference 2011 que se ha organizado en Madrid. Esta conferencia es la más importante de Europa sobre metodologías ágiles y la segunda del mundo después de la Agile Conference que este año se realizará en Salt Lake City.

El jueves, después del madrugón llegué puntual a las 9 de la mañana para estar en el stand de Microsoft y acabar de rematar los últimos flecos de la presentación que iba a hacer con Jose Luís Soria a las 12:35. Bueno, principalmente la presentación la hizo Jose Luís y yo le ayudé en una de las demos. Nuestra presentación versaba sobre integración continua y despliegue automatizado con Team Foundation Server y Visual Studio 2010. Justo antes, Jose Luís tubo otra charla, esta vez sobre el Definition Of Done, que fue muy divertida y un rotundo éxito y que os animo a ver.

La presentación nuestra estuvo también bien, pero no nos dio tiempo a hacer la demo de todo lo que queríamos. Teníamos planeada una build de integración continua, una gated check-in, una de despliegue de una base de datos y otra de un despliegue de una web personalizando la plantilla de proceso. Al final sólo nos dio tiempo a hacer la primera y la última.

Después de la comida vinieron las sesiones de la tarde. Yo fui a una mesa redonda sobre BDD que me gustó bastante, sobretodo porque hacía énfasis en algo que me parece esencial que es la comunicación con el cliente. El hecho de hacer BDD nos obliga a una fuerte comunicación con el cliente para definir las historias, una comunicación que tiene que ser de todo el equipo ( se comentó que estaría bien tener presen a alguien de negocio, a un tester y a un desarrollador como mínimo ).

Después fui a una session del Open Space sobre como migrar de un mal sistema de control de versiones a otro mejor. El chico que la propuso tenia dos servidores de CVS y tres de Subversion y se había decidido a cambiar a Git, entre otras cosas porque contaba con un equipo en China con muy mala conectividad para intentar mantener un sistema centralizado. Charlamos de los pros y contras de hacer una migración manteniendo el historial completo y de las ventajas e inconvenientes de los servidores distribuidos en función de los centralizados. Fue una charla muy interesante.

Para acabar el dia fui a una charla titulada “Forty years of software engineering, ten years of Agile, now what?.”. Esta no me gusto tanto. Básicamente se habló que no hay que quedarse con el estado actual del mundo ágil, sinó que se tendrían que potenciar más las comunidades locales y cambiar planes de estudio de las universidades, para que Scrum y otras no se queden solo como algo que está de moda y la gente aplica simplemente las liturgias, sinó que la gente entiende los principios y se guía en función de ellos. Después ya vino la cena y la fiesta, con Raquel Laina de guía por Madrid, pero de esto ya no os haré la crónica 😀

El viernes fui a dos sesiones. La primera era de “Refactoring in the 4th dimension” con Michael Feathers. Como ejercicio no estuvo mal ( practicamos ruby y pensamos un poco ) pero la charla no tubo nada de refactoring. En parte fue culpa nuestra por no mirar bien la descripción del workshop, pero por otra parte, si pones la palabra refactoring en un workshop, haz un poco de refactoring, que tampoco cuesta tanto.

Con un poco de mala leche por la elección de charlas hechas hasta ahora, decidí apostar a caballo ganador e ir a la charla de Jurgen Appelo sobre Agile Management. Era un tiro bastante seguro, pero cumplió mis expectativas. La charla estuvo muy bien y, a parte, hicimos tres ejercicios muy interesantes. El primero consistió en aplicar técnicas de delegación. Jurgen nos explicó que para él había siete niveles de autoridad, ordenados de más aseverativos a más colaborativos: Tell, Sell, Consult, Agree, Advise, Inquire y Delegate. Nos dio unas cartas con estos niveles y discutimos en grupo ( como si hiciéramos un planning poker ) sobre historias que nos habían sucedido o que nos inventábamos. Esto nos llevó a charlas muy interesantes y a profundidad en el nivel de confianza en la autoorganización que tenemos cada uno. Brian Marick tiene mucha confianza en la organización, porque votó a todo con un Delegate 😀

El segundo fue el ejercicio de los Meddlers. Nos dio unas casillas hexagonales que representaban cada uno de los actores en una organización: customer, cross functional team y functional team. A parte nos dio otras casillas con los roles de la gente: product manager, software developer, tester, line manager, etc. Y nos puso cuatro problemas, cuatro situaciones en las que teníamos que decidir como organizar el equipo. También fueron muy interesantes las discusiones a las que desencadenó.

 

Y finalmente llegamos a las métricas. Nos puso una parrilla con un eje que eran los múltiples stakeholders ( individual, team, organization, customer, supplier, shareholder y community ) y en el otro eje las dimensiones de las métricas ( time, tools, people, value, functionality, quality y process). Por equipos, tuvimos que pensar en métricas para cada una de las diferentes intersecciones de la parrilla, sin repetir ni fila ni columna, es decir, 7 métricas por equipo. Muy interesante también.

Y finalmente regaló un libro y también lo repartió de manera colaborativa. Cada equipo decidió que persona de su equipo se merecía más el libro, y después entre los seleccionados decidieron quien se lo quedaba.

Y esto es la XP2011 que viví yo. Como siempre, tan o más interesante que las charlas fue compartir charlas y momentos con gente tanto de la comunidad ágil española como de otros países.