Tu forma de trabajo hoy no será la misma mañana: Evolución de la forma de trabajo ágil
En esta ocasión, saldré de la línea editorial que normalmente sigo, y hablaré de una idea que surgió después de leer un hilo en Twitter.
Sigo y leo en Twitter a Allen Holub (@allenholub), quien comparte sus ideas sobre Desarrollo de Software y Agilidad, y con quien suelo diferir constantemente. Les recomiendo su Time Line.
En días recientes, publicó el siguiente hilo:
(Un ejemplo perfecto de cómo debería funcionar la agilidad: uso odrive. Ayer, envié un comentario a soporte, pidiendo un cambio trivial que mejoraría mi vida en gran manera [El ícono de la barra de menú en Mac es gris oscuro, invisible si tienes un tema oscuro]. Hoy, Tony de odrive publicó una versión nueva con el problema resuelto. Cambio trivial. Hace una gran diferencia al cliente. Sin estimaciones, backlogs, espera del inicio de un sprint ni burocracia, solamente lo hicieron)
En este texto, Holub describe la situación donde un equipo ha definido una forma de trabajo que cumple el primer principio Ágil: Software funcionando en el menor tiempo posible. A mí, me hizo pensar: esta forma de trabajo en odrive no surgió de repente; seguramente tuvo un proceso de evolución lleno de aprendizaje, aciertos y errores. De eso te quiero hablar hoy.
El mito del proceso perfecto
En muchos equipos y organizaciones, existe la firme creencia que diseñar un proceso de trabajo toma tiempo, que lo debe hacer gente especializada y que debe ser perfecto. El proceso debe funcionar todo el tiempo y cambiar poco (de preferencia, no hacerlo). Así, pasan meses definiendo su forma de trabajo y después crean un grupo de personas que obliga a todos a usarlo. Los buenos resultados escasean, las propuestas de cambio demoran o no se atienden y, al final, el proceso se mantiene en la biblioteca, pero nadie lo usa.
Diseñar una forma de trabajo requiere tiempo, sin embargo, el esfuerzo no debe concentrarse en definirla la primera vez, sino en revisarla, mejorarla y permitir que evolucione con el tiempo y con la participación de todo el equipo
Tu forma de trabajo hoy no será la misma mañana
Esta es la razón por la cual el proceso perfecto es un mito. Cada producto, proyecto y equipo son diferentes. Incluso, equipos que trabajan en el mismo producto a lo largo de mucho tiempo (como odrive y otros), cambian su forma de trabajo porque las circunstancias son diferentes.
Estoy seguro que odrive comenzó el desarrollo de su producto usando una forma de trabajo distinta a la actual. Es probable que, en un inicio, usaran Sprints; que al principio había estimaciones y diseño que tomaba algunos días. Cuando tuvieron sus primeras versiones, muy probablemente cambiaron algunas cosas. Hoy, que operan una infraestructura y conjunto de funciones, la forma de trabajo es adecuada para esas circunstancias.
Hay un par de principios del framework Disciplined Agile que aprendí y concuerdan con la evolución de la forma de trabajo:
El contexto importa: entiende las circunstancias actuales
Conciencia de la organización: comprende lo que hay en tu equipo/organización en ese momento
Tu forma de trabajo hoy será adecuada y producirá buenos resultados. En el momento en que los resultados no son buenos o cuestan más, es el momento de evolucionar y adecuarla.
Todas las prácticas se mantienen, aunque se hacen de maneras diferentes
Holub es un defensor implacable de las ideas contrarias a burocracia y gestión (no hacer estimaciones, no hacer análisis detallado, diseño de arquitecturas extenso, etc.). Para él, las personas deben reunirse y trabajar en el software todos los días, punto. Sin embargo, todas las decisiones del equipo siguen apoyándose en las prácticas y principios de Ingeniería de Software (estimación, diseño, gestión de requerimientos, gestión del cambio, etc.); lo que ocurre, en el tiempo, es que los equipos logran implementarlas rutinariamente, de la manera más pequeña posible.
Es seguro que, en el caso de odrive, un ingeniero hizo una estimación (es fácil, puedo hacerlo hoy por la tarde), puso el requerimiento en su plan del día y lo priorizó, diseño una solución adecuada que respetara la arquitectura, lo implementó, probó y marcó como listo, y documentó lo necesario. Todo un proceso de Ingeniería en pocas horas, pero sin omitir las actividades.
Este es un proceso de evolución, que permite mantener los buenos resultados haciendo las prácticas de manera diferente, pero manteniendo los principios que dan solidez a nuestra disciplina.
¡Nos vemos en la siguiente entrega!