J de Jira

Lo sabemos, suena mal hablar de un producto específico en un libro como este. Jira es la herramienta de seguimiento de proyectos más popular del sector, hasta el punto de haberse convertido en uno de esos estándares de facto. Por supuesto hay otras, pero no son tan usadas.

Diversas herramientas de software, librerías, frameworks etc., presumen de ser opinionated. Tienen una agenda: se jactan de tener una opinión fuerte sobre como se deben hacer las cosas y están construidas de manera que nos fuerzan a plegarnos a lo que sus creadoras consideran.

Jira presume de lo contrario. Este tipo de herramientas suele hacerlo. Su objetivo es agradar a cuantos más usuarios sea posible, desde gestores de proyecto a desarrolladores. Pero por esa misma razón, es una herramienta que ha contribuido como ninguna otra a desvirtuar la filosofía de trabajo ágil.

En realidad, no existe ningún software que sea neutral. Incluso el presumir de no tener opiniones fuertes es, en sí misma, una opinión fuerte. Y es que una opinión expresada en forma de herramienta, es siempre una opinión fuerte por aquello que te permite y por lo que no te permite hacer.

Existe un nivel de gestión que desconfía del desarrollo ágil de software. Precisamente, este movimiento nació para esquivar el control y el micro-management, es decir, el tener a alguien detrás de la espalda diciéndote lo que tendrías que estar haciendo. Las herramientas de gestión de proyectos como Jira favorecen devolver ese control a la cadena de mando.

Por supuesto, todo negocio necesita que existan unos circuitos de información que permitan conocer el estado de los proyectos. No hay negocio viable si fuese de otra forma. Y allí donde Agile propone confianza mutua y entrega de valor sostenible, muchos equipos directivos parecen esperar informes de progreso cada día. De nuevo, estas herramientas prometen proporcionar eso.

Sin embargo, a veces parece que la herramienta se haya convertido en un fin en sí misma. ¿Has tenido alguna vez la sensación de pasar más tiempo gestionando tarjetas que desarrollando? ¿Tenéis discusiones en el equipo sobre lo que debería ser una tarea, una subtarea o una historia de usuario?

La flexibilidad de la herramienta en su afán de contentar a todo el mundo, hace que se introduzcan elementos que no están ni siquiera en los frameworks ágiles más regulatorios como Scrum. De hecho, buena parte de la gestión del proyecto ocurre fuera del equipo de desarrollo, en un nivel que está más interesado en las capacidades de reporting y de seguimiento, y que se siente más seguro si existe un proceso.

De hecho, la herramienta tiende a proporcionar demasiados elementos ajenos a una auténtica forma de trabajar ágil. La posibilidad de tener épicas, tareas, subtareas o spikes, tareas subordinadas o enlazadas, puede complicar la priorización, restar visibilidad a ciertas problemáticas, o incluso favorecer malas prácticas como distribuir carga de trabajo de forma descontextualizada.

¿Recordamos el Manifiesto? Individuos sobre procesos.