Muchos meses después he estado en mi segundo o quizás tercer madrid.rb. Lo cierto es que no me acuerdo muy bien porque ya son tantos sitios a los que he ido que al final uno pierde un poco la cuenta. Tampoco es que sea muy importante pero Luis, un habitual lector de este blog al que agradezco que compartiera conmigo ayer un ratillo de charla y sus preocupaciones profesionales, me sugirió titular este post como “Mi segundo madrid.rb” en honor al que hice para “mi primera vez”.
El caso es que David Calavera por fin ha conseguido su “green card” y se puede mudar establemente a San Francisco (California, USA) y tuvo el detallazo de compartir con nosotros cómo trabajan en su actual empresa: Engine Yard. Para poneros en contexto antes de empezar, Engine Yard es uno de los mayores proveedores de PaaS del mundo y tienen una facturación anual de varios millones de dólares. El trabajo de David, tal y como él lo describió consiste en desarrollar aplicaciones y servicios para sus clientes (considerando a ellos mismos como los primeros clientes).
Pues bien, David nos explicó cómo trabajan en Engine Yard y nos dijo que ellos no hacen Agile. De hecho, y creo reproducir literalmente sus palabras:
Si alguien dice Agile yo dejo de escuchar.
La manera de trabajar en Engine Yard es simplemente razonable y adaptada a sus necesidades y cultura. Son un equipo muy unido, maduro y cualificado. No necesariamente en ese orden.
Agile slaves
David nos estuvo hablando del proceso de desarrollo. Cómo planifican un mes de trabajo pillando funcionalidades nuevas entre todos, sin un dueño de producto ni nada por el estilo. Es una reunión donde todos tienen voz y voto pero donde se demuestra que todos (dirección y programadores) están muy alineados alrededor de la visión y la misión de la compañía y de los productos que tienen que construir. Claro, eso no encaja mucho con otros modelos de negocio ni, sobre todo, con otras culturas empresariales. Ésa era justamente la clave de la charla de David. Nos estaba tratando de decir que ellos no siguen un proceso según ningún libro porque ha sido un proceso de maduración al que han ido llegando entre todos y a lo largo de mucho tiempo.
Me llamó mucho la atención el nivel de madurez de la compañía porque el departamento de marketing espera a anunciar los productos cuando estos están listos y no antes, lo cuál, entre otras cosas, evita la necesidad de gestionar las expectativas.
Bomberos, mecánicos y programadores
Todas las semanas hacen cambio de pareja (SIEMPRE, SIEMPRE, SIEMPRE trabajan en pareja) y cambian también en el foco de su actividad porque una pareja se dedica a “apagar los posibles fuegos” que puedan surgir durante esa semana, otra se dedica a “reparar defectos” y el resto está enfocada en trabajar. Se reunen lo menos posible pero no por ello no saben lo que se cuece ni dejan de ayudar a otros cuando es necesario.
Con el tiempo (y mucha constancia) han llegado al famoso “despliegue continuo” entre otras cosas porque se han dado cuenta de que es mucho mejor poner las cosas en producción en cuanto están hechas para evitar luego el dolor de los “merges”. Claro, todas las funcionalidades están parametrizadas para evitar que las vean los usuarios que no deben verlas.
¡Ah! Y que no se me olvide. No tienen herramientas para medir la cobertura de tests porque todo lo que está en producción tiene sus tests (automatizados, claro). Y están seguros porque SIEMPRE, SIEMPRE, SIEMPRE trabajan en pareja, con lo que además del “code review” continuo, sumas la “autoexigencia redundante” 🙂
En resumen
Suscribo 100% las palabras de David:
El fin no es ser ágil porque eso no hará que funcionen nuestros productos. El fin último es tener un producto genial y las metodologías son simplemente el medio.
Y agradezco mucho que haya compartido esto que, siendo una realidad, para muchos nos resulta una utopía y para otros un imposible. Pero creo que es mucho más sencillo: es simple pragmatismo. Otro día hablaré de pragmatismo, optimismo, el mundo real y de cómo las utopías se hacen realidad. 🙂