Por qué no usamos Product Backlogs
Cada vez que me preguntaban qué metodología de desarrollo usábamos en Unagi mi primera reacción era una combinación de taquicardia, sudor y voz temblorosa. No porque no usáramos ninguna metodología, sino porque sabía que la respuesta no iba a satisfacer a quien me lo preguntaba. Por lo general se espera una respuesta como "Trabajamos con la metodología ágil Scrum, donde tenemos un Backlog de tareas y sprint a sprint vamos 'quemando' esas tareas".
La cuestión es que en Unagi no usamos ni Scrum, XP, Kanban o ninguna de las clásicas, sino que creamos nuestra propia metodología. ¿¿Crearon una?? Bueno, en realidad no creamos una, sino que fuimos tomando algunas cosas de las arriba mencionadas y las fuimos "unagizando".
El objetivo de este artículo no es explicar cómo trabajamos en Unagi, sino contar por qué no usamos Product Backlogs, o al menos por qué no los usamos como dice su definición:
Product Backlog: lista priorizada y ordenada de requisitos del cliente sobre un proyecto. Es gestionado por el Product Owner (PO), incluyendo su contenido, disponibilidad y peticiones. La lista está ordenada según las prioridades del cliente.
La verdad que nadie puede negar que la definición menciona conceptos claves para todo desarrollo de software: "tareas", "orden", "prioridades", "cliente", etc. El tema es que una cosa es lo que dice la definición y otra cómo llevarlo a la práctica.
Cuando usábamos Backlogs
Permitanme primero contar un poco cómo ha sido nuestra experiencia usando backlogs. Porque claro que en un momento trabajamos con backlogs. Es más, no solo los usábamos, sino que estábamos convencidos de que era la mejor manera de trabajar.
Teníamos un listado de tareas de grano muy fino escritas desde la perspectiva del usuario. Cuando llegaba una nueva tarea que no era prioritaria o imposible de llevar a cabo en el momento, la incluíamos al final del backlog. Luego, cada X días organizábamos la pila según las necesidades y prioridades del cliente, para dejar todo prolijito.
Cada 2 o 3 semanas, al comienzo de un nuevo Sprint, tomábamos las tareas del backlog y la metíamos en el sprint backlog.
Por qué dejamos de usar Backlogs
1. Requiere mantener el backlog ordenado
Creo que la razón más importante que nos hizo replantearnos sobre el uso de backlogs fue el cambio de prioridades de forma constante. Hoy vivimos en un mundo en el que los negocios viran sin parar, en el que las prioridades cambian más rápido que Abreu de equipo de futbol y en el que las urgencias de hoy probablemente no sean las de 3 meses atrás y sean distintas a las de 3 meses hacia adelante.
Entonces llegó un punto en el que nos empezamos a preguntar:
¿tiene sentido invertir tiempo y esfuerzo en mantener organizada y priorizada una lista de tareas que ya perdieron relevancia?
Encima, lo que termina ocurriendo es que aquellas tareas que quedaron obsoletas nos terminan dando pena y no las terminamos quitando por si en algún momento las necesitamos. El resultado, una backlog gigante de tareas sin relación alguna, de las cuales solo unas pocas nos interesan actualmente. Es decir, como diríamos en Argentina, una gran bolsa de gatos.
2. Desglose de tareas
Para organizar el trabajo dividíamos cada módulo en múltiples tareas de grano fino, a tal punto que quizás un módulo de usuarios incluía 10 tareas.
Este desglose de tareas, consumía gran parte de nuestro esfuerzo semanal. No solo por el análisis asociado a dividir un módulo en tareas, sino que además organizar el backlog requería de mucho tiempo y dedicación. Primero, por la gran cantidad de tareas que acumulábamos. Luego, porque muchas tareas no tenían sentido de forma independiente y se tenían que mover en bloque.
3. Tareas obsoletas
Llegó un punto en el que toda tarea, idea o bug que aparecía iba a parar al backlog. Era nuestra forma de dejar registro de potenciales features o bugs que no merecían solucionarse de inmediato.
El problema es que muchas tareas o ideas quedaban obsoletas o eran imposibles de llevar a cabo y quedaban ahí, abandonadas. Era tal la cantidad de tareas que se nos acumulaban que hasta nos ocurría que desconocíamos la razón y origen de algunas de ellas.
4. El desglose lo hacía quien no correspondía
La creación de las tareas la hacía la persona a cargo de la gestión del proyecto en lugar de hacerlo la persona que iba a implementarlas, es decir, quien realmente sabe cómo dividir su trabajo.
Abandonando el backlog
Un día eran tantas las preguntas sobre si valía la pena manejar backlogs que empezamos a cuestionarnos si no debíamos abandonarlos. Y así fue. Desde hace ya casi un año que dejamos de manejarnos con backlogs y empezamos a trabajar de otra forma.
Ahora adoptamos una filosofía distinta para encarar nuestros proyectos. Más allá de que cada proyecto tiene sus objetivos y misión, nuestro horizonte en términos de implementación no está más alla de 1 o 2 meses. Es decir, antes de cada sprint (ahora llamado ciclo) nuestro abanico de features a implementar es muy reducido, no tenemos un registro infinito de tareas imposibles de organizar. Creemos que si es algo prioritario e importante, va estar latente en las reuniones con el cliente y seguramente se tire sobre la mesa al momento de decidir qué se va a hacer en el siguiente ciclo.
¿Entonces no tienen registro de nada? No, no dije eso. Tenemos documentos muuuy extensos con un análisis sumamente exhaustivo, pero sólo de cosas de acá a 1 o 2 meses. Si hay algo que está fuera de esa ventana de tiempo, se descarta/ignora.
Ese análisis exhaustivo es escrito desde la perspectiva del usuario y buscamos encontrar la mejor solución en términos de UX. Se escribe en lenguaje coloquial y el desglose de tareas (el cómo) lo realizan los desarrolladores que participarán del ciclo, a quienes internamente llamamos Ciclistas.
Como podrás ver no creamos nada original ni reinventamos la rueda, simplemente simplificamos algunos procesos. Nos encanta hacernos preguntas, cuestionar nuestras metodologías, ya que creemos es la única forma de progresar.
Cuando esas preguntas se repiten una y otra vez, nos damos cuenta de que es momento de actuar, y así lo hicimos. Hoy dejamos de utilizar backlogs y encontramos en ese cambio mejoras claras, tanto para dentro del equipo como para con los clientes.
Con esto no quiero decir que las metodologías clásicas no sirven, sino que uno debe adaptarlas para que le queden cómodas. Es como cuando comprás un par de zapatos que te aprietan. Uno puede usarlos así como vienen de fábrica, sufriendo esa incomodidad, o llevarlo a un zapatero para que le agrande la horma. Nosotros optamos por la segunda y ajustamos los zapatos a nuestros pies.
Me gustaría escuchar qué opinan ustedes y saber cómo trabajan. Creo que las empresas de diseño y desarrollo de software debemos estar más abiertos a compartir nuestros procesos y metodologías.
Ahora, cada vez que me preguntan “qué metodología usamos en la empresa” contesto “¿tenés tiempo? te cuento”.
