Release Roadmap en JIRA

Cuando tuve la oportunidad de acompañar a una de las organizaciones en su viaje hacia la transformación ágil, una experiencia que tuve con los C-Level fue el hecho de solicitar visualizar la ruta critica de los proyectos.

Nosotros como área de Agentes de cambio, mostrábamos en reuniones semanales de comité, los riesgos, el avance en general, y el roadmap que te daba la vista de donde estabas en cuanto al avance general del proyecto. Cabe mencionar que todo el desarrollo de los proyectos se realizaban con los marcos de trabajo agiles, haciendo uso de la herramienta mas popular hoy en día, Jira.

Por lo que comenzamos a investigar una forma de generar el reporte del release roadmap que te muestre la ruta critica. Encontramos un plugin de gantt para Jira donde precisamente te mostraba la ruta critica del proyecto.

Link: Jira Gantt

Las únicas consideraciones era que teníamos que incurrir en un costo adicional, por lo que habilitamos para la versión trial, para su evaluación, la encontramos útil en su momento.

Hace poco me entere que Jira en su plan Cloud premium, incluyo la vista de Release advanced roadmap, la cual básicamente te da la opción de manejar interdependencias entre diferentes equipos que trabajen bajo el mismo proyecto, así como la capacidad por equipo, pudiendo identificar cuando tu equipo se encuentra sobre cargado y excede su capacidad en un sprint en especifico, también te da la vista de tener la administración de tus equipos de trabajo, así como tener una vista del estado de tus releases, pudiendo identificar si alguno se encuentra muy retrasado en su salida.

Link: Jira Premium

Algo que me agrado mucho es los múltiples filtros, agrupadores, campos y el timeline donde se puede visualizar las fechas comprometidas a nivel de Epicas, Historias de Usuario y subtareas.

En lo personal me parece muy útil esta herramienta para los equipos que desean tener actualizado continuamente su release roadmap y poder ajustarlo de manera mas eficiente y sincronizada con las tareas de cada equipo dentro de los proyectos.

Discord como herramienta colaborativa

 Discord para equipos de desarrollo y cualquier equipo de diferentes industrias

Hace un tiempo atrás participe de un meetup donde el equipo organizador utilizo una plataforma diseñada para gamers, en el cual se comunican de forma síncrona, pudiendo compartir pantalla y en el cual se tienen salas, servidores, según grupos de intereses. Me llamo la atención cuando lo vi por primera vez, sin embargo lo vi mas como otra herramienta simple de IMs, ahora me doy cuenta lo equivocado que estaba en su momento.

Hace un par de años atrás cuando comenzamos una etapa bastante intensa saliendo a producción con una versión del producto, en el cual estábamos como 3 semanas realizando el desarrollo y soporte para incluir nuevos features y corregir los errores que van saliendo cada día.

El punto es que los mismos desarrolladores sugirieron utilizar esta herramienta para poder trabajar todos los días, emulando un trabajo semi presencial, pudiendo realizar pair programming, saltando de sala en sala, pudiendo comunicarse de forma instantánea, uniéndose a cualquier presentación de pantalla. Un tema importante es la de seguridad donde el administrador puede restringir el acceso a los servidores.

Ahora cuando uno necesita el feedback o simplemente conocer en que esta trabajando el equipo, simplemente a cualquier hora del día solo basta conectarse a la plataforma y unirte al servidor y sala de interés donde el equipo esta trabajando de forma colaborativa.

Desde mi rol de facilitador encontré invaluable esta plataforma, que a un comienzo no entendía su potencial, lo recomiendo altamente para equipos de desarrollo y cualquier otra industria, siendo muy útil en esta época de pandemia, donde el 90% de las empresas habilitaron la modalidad de home office, debido a las medidas de seguridad.

Acá les dejo la dirección para que puedan evaluarla en sus equipos.

https://discord.com/

Espero les sea de utilidad como lo es en estos momentos para mi.

Dual Track Agile: Ventajas y Desventajas

En muchas organizaciones actualmente estan adoptando esta forma de trabajo, ya había trabajado de esta manera en una anterior organización hace un par de años atrás, solo que ahora le pusieron el nombre de Dual Track mencionado por primera vez por la diseñadora Desiree Sy.

En esta modalidad los diseñadores trabajan de forma paralela al desarrollo de la solución, realizando un descubrimiento del producto a desarrollarse en futuros Sprints, lo cual lo encuentro bastante útil, con una sola salvedad, en la experiencia que tuve anteriormente, el mismo equipo de desarrollo realizaba el diseño de los prototipos para luego implementarlos. El hecho de separar a los diseñadores del equipo, en mi percepción dificulta el sentimiento de trabajo en conjunto como trabajo único del equipo como tal, dando la sensación de tener otro equipo separado solo de diseño del equipo de desarrollo, donde ellos se ocupan de prototipar y nada mas como única responsabilidad.

Otra desventaja que pude apreciar es en esta separación se crean PBIs diferentes a los que se toman luego para su desarrollo, estos se trabajan netamente como incidencias de diseño, para luego convertirlos en Historias de Usuario, tomando así mucho tiempo (Age) sin poder entregarlos al final de cada Sprint (DoD) en caso de trabajar con Kanban.

Además que en la ceremonia de Sprint Review el Product Owner muchas veces requiere ver solo como un incremento los avances de las tareas de Diseño a los stakeholders, debido a la extensión prolongada de la sesión. Esto también desmotiva al equipo de diseñadores, los cuales no pueden presentar el trabajo realizado durante el Sprint. 

Conclusión

Personalmente, no elegiría esta forma de trabajo (por lo menos en su totalidad) ya que pude evidenciar varias desventajas que a la larga impactan en la madurez de los equipos. Prefiero trabajar directamente sobre las Historias de Usuario únicas tanto en su diseño como en su desarrollo, en sesiones de discovery sin necesidad de diferenciar y separarlas por diseño y desarrollo. Me interesa bastante que las personas que realicen el prototipado se sientan parte del equipo y aporten y sientan que son parte de la co creación del producto para entregar incrementos potencialmente entregables al final de cada Sprint.