Hace casi un año que la gente de Basecamp hizo pública la manera en que desarrollan su exitoso software de gestión de proyectos, valiente ejercicio comunal con el que de vez en cuando alguna empresa puntera en el sector se desmarca, enriqueciendo y aportando su enfoque sobre la materia. En este caso, Basecamp va más allá en su divulgación al explicar también cómo integrar paso a paso esta metodología haciendo uso de su propia herramienta, animándonos a enviar sugerencias para su más fácil adopción.
Antes de nada, hay que agradecer este tipo de iniciativas, pues además de mostrar tus armas a posibles competidores -aunque en el caso que nos ocupa pueda revertir en el uso de la plataforma- implica exponerse a críticas pormenorizadas como la que aquí, con respeto y humildad, se va a llevar a cabo. Porque lo cierto es que la lectura de esta publicación me ha generado bastantes dudas, alguna de ellas idiosincrásica, lo cual no quiere decir que no resulte inspiracional en ciertos aspectos o que no pueda haber implantaciones satisfactorias, tal y como expuso David Roch, responsable de producto en Marketgoo, en el World Product Day de este mismo año, sobre cuya charla haré ciertas consideraciones.
Y es que, a diferencia de otras publicaciones semejantes, se percibe un cierto afán por trascender en su tono iconoclasta: ya desde el principio se reniega firmemente de adscribirse a una corriente o framework determinados, si bien se alude una y otra vez a los pilares y propósitos del Agilismo, aunque con terminología análoga. Tampoco hace falta ser muy perspicaz para sospechar que si han podido dar forma a este marco de trabajo “iterando mediante prueba y error durante los últimos 15 años” ha tenido que ser, por necesidad, prácticas Agile mediante, y que si cualquier parecido de un framework específico con la realidad actual es como el de un huevo a una castaña, no es más que por la lógica evolución a una fase de maestría (la llamada fase Ri) en que la inercia te lleva a explorar nuevos caminos manteniendo la esencia intacta. De lo contrario, estaríamos hablando de que es un modelo de trabajo excesivamente complejo de implantar en una organización que no haya trabajado previamente con Scrum o Kanban, ya no digamos que aún no haya efectuado su transición cultural hacia mentalidades ágiles.
Analizando el método, si algo queda patente desde el mismo título de la (vastísima) publicación es la importancia que tiene la llamada etapa de diseño (Shape), que involucra a expertos de negocio, analistas y arquitectos y que discurre en paralelo con la de desarrollo (Build). Es en esta fase cuando se perfilan las funcionalidades venideras como si de proyectos independientes se tratara, poniendo el foco tanto en acotar las necesidades reales a cubrir como en la identificación de riesgos (dependencias, limitaciones, lagunas técnicas, etc.). A destacar que esta fase se realiza de manera asíncrona, lo cual supone una gran optimización en tiempos y coordinación para las ocupadas gentes de negocio, exigiendo entre ellas, eso sí, un compromiso y una comunicación fluida y certera -en este caso a través de Basecamp- que, desafortunadamente, no siempre se da a estos niveles.
Una vez dado forma al proyecto, con la incertidumbre reducida a su máxima expresión (“el esfuerzo inútil conduce a la melancolía”, que diría Ortega y Gasset), aquí viene el principal enfoque divergente respecto al agilismo: no es el equipo encargado del desarrollo quien estimará o quien irá entregando mínimos productos viables de manera iterativa, sino que es negocio, en una audaz pirueta, quien va a predefinir qué cantidad de tiempo (Appetite) está dispuesto a invertir (Bet) en la necesidad concreta (6 ó 2 semanas, por lo general), dejándose bien clara su improrrogabilidad, aunque no siempre.
Otro punto interesante es que no hay un backlog como tal, se habla de lo frustrante que puede llegar a ser manejar el típico backlog infinito y de lo poco eficaz que es tener que refinarlo y repriorizarlo una y otra vez, con tareas al final del mismo que nunca se van a abordar. De esta manera, se corta por lo sano haciendo que cada proyecto tenga, por así decirlo, un sponsor, que es quien velará por que sea escogido para llevarse a cabo (Pitch) llegado el momento, que no es otro que la mesa redonda (Betting Table) que se produce al final de cada ciclo a nivel de C, en la que se escogen y asignan, según disponibilidad y capacidades, equipos a todos estos mini-proyectos para las próximas 6 semanas, período estipulado de Shape-Build (recordemos que discurren en paralelo). Aquellos proyectos no escogidos… se desestiman sin más, confiando en la tenacidad y poder de persuasión del sponsor para rescatarlos cuando considere necesario en la Betting Table pertinente (habría que ver qué sucede ante la ausencia de trazabilidad, pero me suena a que pueda repensarse la misma idea varias veces, por no hablar del tiempo invertido en moldear y presentar algo que, quizá, no encontró su mejor momento).
Hasta aquí, lo que más enjundia tiene en el modelo, y percibiendo claramente lo que viene a solventar, yo no veo más que una reorganización del trabajo de negocio, con sus épicas a nivel de Q, definición de historias de usuario con criterios de aceptación bien claros y un trabajo exhaustivo del roadmap de un producto, con certidumbre clara del valor entregado y menor autonomía del PO. Bien. Pero es a nivel de equipo de desarrollo donde percibo una remodelación de competencias que no veo nada claras. Y, lo peor de todo, se esgrimen como soluciones a problemas que no se dan o que al menos no deberían darse en un modelo Agile. Veamos.
Los equipos suelen estar conformados por un front, uno o dos backs y un QA asignados a un proyecto concreto de 6 semanas o varios de 2 (incógnita, ¿se rellenarán huecos?) y es en la propia Betting Table que, del pool de desarrolladores existentes, se escogen y conforman los equipos encargados de llevar a buen puerto el mini proyecto en cuestión, aduciendo que, en su política de aversión a las reuniones, se ahorra un paso. No olvidemos que igual también para ahorrar un paso los proyectos vienen ya estimados, algo que, por otro lado, no resulta tan infrecuente en la oferta comercial del proyecto pequeño de turno. Pero lo que me molesta especialmente es que para suprimir cualquier suspicacia jerárquica se diga que los proyectos tienen nivel de abstracción tal que otorgan una flexibilidad y responsabilidad total al equipo para su ejecución. Claro, total salvo para analizarlos, estimarlos y organizarse.
El colmo sería que en esta supuesta libertad total para inferir las historias de usuario y su ejecución cada equipo se organizase en Sprints, haciendo lo que acabamos haciendo casi todos: agilefall de manual, aunque la verdad que siendo 2-3 personas no creo que haga falta, pues entiendo que lo que se hará es desmenuzar las tareas (se explica muy concienzudamente cómo agruparlas en Scopes) y rezar remar para poder acometerlas en las semanas estimadas, porque de lo contrario y según se dice, salvo contadas y justificadísimas excepciones, el trabajo se tirará a la basura, esperando a ser llamado de nuevo, con una aproximación diferente, en alguna otra Betting Table. W-T-F. A estas alturas más que un framework de trabajo, y entendiendo la necesidad de una fecha que genere cierta presión en la entrega, parece más una suerte de Juego de la Oca en la que cualquier paso en falso te lleva a la casilla de salida.
Para finalizar, tras el ciclo Shape-Build llegaría el de Cool-Down o enfriamiento de 2 semanas, en las que en un inicio se comenta que los desarrolladores pueden aprovechar para dar rienda suelta a sus propias iniciativas, reunirse (ahora sí) para intercambiar opiniones y decidir siguientes pasos. Pero pronto se vislumbra que, seguramente con más asiduidad de lo deseable, son aprovechadas para rematar flecos pendientes y solucionar bugs.
En honor a la verdad he de decir que me ha resultado muy interesante el enfoque sobre la visibilización del progreso hacia negocio basado en Scopes (conjunto de tareas correspondientes a una funcionalidad independiente) mediante una Hill Chart apoyada en la certidumbre, lo conocido.
Pero, como digo, me rechina la justificación de ciertas decisiones como solución a problemas dudosos. Y aparte de lo ya mencionado, quizá lo más flagrante, hay alguna más. Lo de que diseño e implementación vayan en paralelo me suena a déjà vu (habría que echarle un vistazo a Dual-Track). Tampoco entiendo que se perciba que en modelos Agile el equipo de desarrollo se limite a ser un recogetickets cuando precisamente se le hace partícipe desde el principio del análisis y diseño de la solución. Se insiste demasiado en las bondades en la clarificación del porqué y el para qué de las cosas, cuando en cualquier metodología ágil que se precie dicho contexto sería compartido. Y el que haya pujas en lugar de planificación de Sprints al uso no garantiza per se que el compromiso o el foco sea aún mayor.
Sin embargo, tan minucioso como es el modelo, no parece ofrecer soluciones eficaces para problemas -estos sí- recurrentes, como pueden ser la gestión de incidencias o la deuda técnica y el aseguramiento de la calidad. Problemas que, justamente, David Roch de manera humilde admite en su charla que aún no han sabido cómo integrar.
Sobre el soporte, coincido en que si se desarrolla bien rara es la ocasión en que haya un bug tan crítico como para tener que pararlo todo. Pero hay que preverlo. Es más, esta presunción de que las cosas se estén haciendo bien queda en evidencia con aseveraciones del tipo «si tuviéramos que eliminar cada bug no terminaríamos nunca» o el hecho de que en períodos de carga de trabajo más bajos se aproveche para hacer un pedazo de bugatón, vamos, pegarse la panzada de matar bugs uno tras otro durante un ciclo entero. Sobre la figura del QA y los estándares de calidad, la laxitud es tal (tareas deseables, PR opcionales…) que uno sencillamente no cree que esas dos semanas de chill out no sean aprovechadas más que para solucionar ñapas.
En definitiva, Basecamp hace público el marco de trabajo al que han llegado, les funciona (son guapos y exitosos) y lo tienen hiper mega analizado, lo cual es por sí mismo elogiable e inspirador. Pero la vocación de ser exportable queda precisamente en entredicho por su pormenorizado nivel de abstracción (aquí les ha fallado un poco la fase Shape). Es más, el nivel de detalle es tal que me resulta incluso difícil de inculcar internamente… ¿Quién vela por que se cumplan todas estas reglas y premisas? Siquiera se habla del rol. Que se entienda: si Spotify publicaba su modelo de manera aséptica y transversal, Basecamp hace lo propio comparándose subjetivamente y de manera tan específica como maniática.
Inspiraciones:
Esto no es Scrum. 