Agile: ¿Cambios en producción cada 2 semanas?

Hace pocos días leí un magnífico artículo de David Jeske con un provocador título: Why do some developers at strong companies like Google consider Agile development to be nonsense?

Cambios en 2 semanas

El titular impactante no resume exactamente el contenido del artículo. Pero sí que resume su objetivo: los valores y los principios ágiles sirven de guía, de mindset, de enfoque en nuestros proyectos y en nuestra forma de trabajar. En este artículo, David Jeske, Director de Ingeniería en Google del 2003 al 2008, expone que, en algunos casos y algunos productos, es necesario un diseño detallado inicial, trabajar sobre algo con mínimas interfaces externas, y esto puede llevar meses o años hasta que realmente se percibe un avance para el usuario final.

Es curioso ver como en los cursos de Agile y en los acompañamientos para la implantación de metodologías ágiles, surgen de manera recurrente algunas preguntas acerca del enfoque de los proyectos. Normalmente empezamos por explicar la problemática que intentan resolver las metodologías ágiles, ser conscientes de qué queremos intentar evitar. Entregas tardías, productos que no resuelven la necesidad real de los usuarios, avance basado en hitos del proceso (análisis cerrado, diseño cerrado…), … para ello, nos centramos en el Agile Manifesto, sus valores y sus principios del manifiesto Agile.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible. Este principio ágil, combinado con la explicación de Scrum y el concepto de Incremento de producto cada 1-4 semanas en condiciones de ser utilizado siempre genera un debate.

“¿Cada dos semanas? ¡No podemos hacer un desarrollo, pruebas, validaciones, y puestas en producción cada dos semanas!” Y los motivos habituales para argumentarlo son del estilo “nuestra tecnología actual no nos permite hacerlo”, “una funcionalidad así de pequeña no sirve de gran cosa”, “no podemos molestar a nuestros usuarios con cambios cada dos semanas”, “entonces tendríamos que hacer también la formación a usuarios, documentar los cambios en producción, … demasiado trabajo extra cada dos semanas”.

Siempre son buenos motivos, argumentados, basados en la experiencia de quien conoce su negocio… pero que requieren darle una vuelta, un cambio de enfoque, y trabajar en ese sentido. Es poco probable que la tecnología per se no permita hacerlo, normalmente se trata de los procesos internos y la división del trabajo asociada al proceso. Una funcionalidad pequeña, más otra, más otra, más otra… permiten grandes cambios. Si añadir funcionalidades a tu producto significa molestar a tus usuarios, tienes un problema mayor que tu capacidad y velocidad de entrega en el desarrollo de software. Y si puedes hacer productos usables, intuitivos, que requieran de una formación mínima, vas a ahorrar un montón de tiempo en actividades con poco valor añadido.

El hecho de que cada dos semanas generemos un incremento en condiciones de ser utilizado no significa necesariamente que lo pongamos a disposición de ser utilizado. Está claro que cuando antes lo pongamos en producción, antes nos estará proporcionando el valor por el cual decidimos implementarlo. Precisamente por ese motivo en Kanban se utiliza el lead time, para medir este tiempo y tratar de reducirlo al mínimo posible. Pero en ocasiones, hasta que no tengamos varios incrementos no lo pondremos en producción.

Me gusta mucho la manera que tiene SAFe de describir este concepto: Develop on Cadence, Release Any Time. El desarrollo de nuevas funcionalidades se demuestra y se integra cada dos semanas, con una cadencia fija. Y la release a nuestros usuarios, cuando sea necesario.

Debemos invertir en automatizar al máximo las pruebas, integraciones, y subidas a producción para minimizar el esfuerzo en este proceso. Invertir en DevOps. Citando el libro The Phoenix Project: In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand.

Tal como dice el artículo de David Jeske, en ocasiones será necesario dedicar un gran esfuerzo en un diseño previo, y trabajar en componentes durante varias iteraciones, sin demostrar visibilidad a los clientes.

Pero debería ser una excepción a la regla. Algo puntual dentro de todos nuestros desarrollos.

Revisa el tamaño de los incrementos que pones en producción. Plantéate si realmente los puedes hacer más pequeños. Piensa en el cómo. Haz este trabajo conjuntamente con negocio, con tus usuarios y con el equipo técnico. Recibe feedback constantemente del avance realizado en base a entregas. Reduce los tiempos de espera de las aprobaciones entre etapas de tu flujo de trabajo.

Así es como conseguiremos adaptarnos y ser más ágiles.