Menos Agile y más agilidad

Nota previa: Es importante entender un mínimo qué es SCRUM para seguir con fluidez este artículo, no es el objetivo de servidor entrar en el cómo de SCRUM, sino en el para qué y el cuándo. Si el libro del otro enlace se hace demasiado, la página de wikipedia debería bastar para seguir el contenido.

Me despierto y por primera vez en meses me puedo dar una ducha fría (me encanta y me mantiene a prueba de resfriados, pero cuando las tuberías están expuestas al invierno holandés, el agua fría puede detener una reacción nuclear). Espabilado como si me hubieran dado una descarga, desayuno y me encamino a la oficina.

Me pongo a ojear la red y me encuentro un artículo sobre metodologías ágiles, con el foco puesto sobre SCRUM. El artículo en sí es bastante interesante, pero está planteado como una iniciación y servidor lleva unos añitos metido en la práctica, así que voy directamente a la sección de comentarios a ver cómo ha sentado en la comunidad.Parece que había consenso:

«SCRUM = Esclavitud».

«Agile = Tambores en las galeras».

«No es más que otra forma de hacernos echar horas extra como animales».

No soy partidario de ir por el mundo creyendo que tiene uno la verdad suprema. Incluso cuando la experiencia de uno es positiva, no se puede tomar por cierta para la generalidad algo que podría ni ser cierto para nosotros y simplemente una coincidencia.

Pregunté a colegas y, para mi sorpresa, la persona que me introdujo al SCRUM me comentó algo parecido, que son tambores en las galeras, pero con el agravante de que son los propios compañeros los que tocan el tambor.

Me costó aceptarlo, pues yo siento muchísima menos presión cuando trabajo con una metodología ágil, así que presioné para ver dónde acabábamos.

Expongo el método que seguí con tanto detalle porque creo que ilustra una forma de pensar que es tan necesaria en nuestra industria como el conocimiento de algoritmos. He dicho en muchas ocasiones y recientemente, en una charla que tuve oportunidad de dar a futuros desarrolladores, pude repetirlo un par de veces hasta que se convirtió en un mantra: No tengo ni puta idea. Yo estoy convencido de que SCRUM funciona, pero enfrentado a una opinión tan radicalmente distinta, discuto no para tener la razón, sino para saber cuál es la verdad. Es muy fácil echar balones fuera y decir que el problema es de otro, que no tiene que ver con nosotros.

Después de mucho apretar, vi por dónde iba el problema: SCRUMterfall. Vendemos SCRUM y otras metodologías ágiles como una panacea, la solución definitiva a todos los problemas que viene a triunfar donde fracasó waterfall. Y es cierto que SCRUM triunfa en situaciones donde fracasa waterfall, esto es debido a que cada metodología tiene su propósito y su contexto de aplicación.

Servidor trabaja en un equipo senior, todos los integrantes son personas con una carrera detrás compuesta de años de experiencia bien aprovechados y con un criterio profesional basado en la observación y el estudio (desarrollar el criterio con base en la observación es peligroso, es tema para otro artículo).

SCRUM es una metodología pensada pasa sacar el máximo partido de ese criterio y esa experiencia manteniendo un ritmo de trabajo predecible por la gente de negocio.

Mi experiencia es que vivo con muchísimo menos estrés, pues después de un par de iteraciones, puedes saber con cuánto trabajo tuyo cuenta el equipo y sabes por experiencia que puedes aportarlo. Desde que trabajo de esta forma, las horas extra y los requisitos sorpresa son cosa anecdótica y los requisitos imposibles simplemente no existen.

También tengo otra ventaja: Mi jefe es el puto amo.

Mi jefe es holandés y no lee mi blog, no es peloteo, el tío se sobra más que un bote familiar de nutella. Es el director ejecutivo técnico de la empresa (CTO), tiene un pasado realmente técnico, viene de administración de sistemas y es un bestia en redes y telefonía IP. Añade a eso que el tipo es accionista de la empresa. El resultado es que la persona que toma las decisiones técnicas sabe a la perfección qué se puede y no se puede hacer y el resto de la junta directiva respeta sus decisiones sabiendo que tiene en mente el mejor interés de la empresa, al fin y al cabo posee un pellizco.

El resultado de esto es que toda decisión que se toma parte de razones lógicas y objetivos posibles.

Si intentas aplicar SCRUM en una empresa en la que el director técnico no tiene la última palabra, sino un jefe de producto con trasfondo de márketing (no tengo nada en contra de la gente de márketing, estoy en mi trabajo actual gracias a mi experto en márketing favorito, simplemente son personas no técnicas que no deberían tener la última palabra en decisiones técnicas). Si además el jefe de producto entiende que los puntos de historia son una sugerencia y siempre intenta meter veintidós puntos en un sprint de veinte al que luego intentará colar dos puntos más. Si añades que el desarrollador líder es el único que toma las decisiones de arquitectura y que los otros cinco miembros del equipo suman cuatro años de experiencia en total, tienes una fórmula para el desastre.

Porque SCRUM no es una herramienta para echar carreras con un FIAT 500, SCRUM es una herramienta para sincronizar el avance en convoy de varios camiones pesados. No es la solución universal a todos los problemas de desarrollo de tu empresa, como tampoco lo es TDD o, más ampliamente, XP.

No basta con entender qué, hay que saber por qué hacemos lo que hacemos o estaremos en el equivalente profesional de correr con tijeras.

A ser felices. O no, no soy la madre de nadie (aunque sí el padre de dos ricuras que madremíaquemeloscomo).

Post data.- La charla con los futuros desarrolladores fue fabulosa, me preocupaba no poder captar su atención y al final pasé más tiempo respondiendo preguntas que con la charla en sí, ha sido una experiencia fabulosa y reveladora. De hecho, creo que saldrá media docena de artículos de las preguntas que me hicieron, sobre todo el tema del machismo condescendiente en nuestra profesión (he trabajado con compañeras que tenían que validar cada postura que defendían hasta un punto incómodo), algo sobre lo que investigaré un poco más antes de meterme a ello.

Post-post data.- Perdón por el retraso (no el mental, con ese os chincháis, sino con el de las publicaciones), he estado organizando un viaje sorpresa a las Canarias para sorprender a mi suegra, de hecho, os escribo este artículo a treinta grados de temperatura. Con un poco de suerte, empezaré a tener un buffer de publicaciones pendientes de publicar y no volverá a pasar, un abrazo.