La combinación de organizadores, patrocinadores y asistentes confesos asegura llevarnos “one step beyond” a los tres miembros de nuestro comando: Pedro (un caso de “usuario final con criterio” ¡existen! – primera alegría del #AOS2014), @jturegano (inamovible pilar ágil en @PanelSistemas – ¿a que suena a contradicción? ;), y servidor: @mnicolao11 (como un niño con zapatillas de Casillas).
El formato Open Space se rige por unas reglas sencillas, exigentes y que funcionan. Pasadita por el fotocall y a la primera actividad: la construcción de la agenda con la que se va a desarrollar la propia jornada. Brevísima presentación, propuesta al muro y paso atrás. Más de 50 (c-i-n-c-u-e-n-t-a) propuestas, magnífico. Los asistentes marcamos nuestras preferencias utilizando las tres pegatinas que tenemos cada uno y con esta información la organización monta la agenda a la velocidad de la luz.
Agenda resultado:
AOS2014 Agenda final
Hay varias propuestas orientadas a jerarquías, aspectos de coordinación de alto nivel y contratos, ¡vaya! ¡ese será mi hilo master!. Aunque tengo algunas colisiones de agenda, eso son solo futuribles, así que empecemos con lo que tenemos a mano.
Empezamos la mañana con la propuesta de Vanesa Tejada sobre “Crear un panel de RoadMap visual”. Vanesa es apuesta segura, ¡vamos!
Partiendo de una escena con varios dueños de producto (“Product Owners”) con interdependencias potenciales, en esta charla nos comparte cómo están trabajando para mantener una visión temporal y un compromiso comunes entre ellos. Para ello han definido un tablero que muestra los hitos (historias de negocio en el mes en que se quieren entregar) de todos productos en los próximos meses, situando así las fechas de puesta en producción requeridas. En suma: un Roadmap Visual multiproducto.
Básicamente han montado el tablero con columnas por meses y calles por producto. Es un tablero de intenciones (serias), es decir, muestra qué se quiere (a alto nivel) y cuándo (se pretende o se necesita). Cada Product Owner tiene luego sus tableros para trabajar con más detalle con sus equipos.
Como el cronómetro es tan peculiar y cabezón, visualizar las dependencias temporales en ese alto nivel les resulta muy necesario para mantener una visión holística. Por ello, han incorporado un elemento visual [a] un hilo de lana [z] que abre la historia de negocio en el tiempo, desde el mes en que hay que dedicar recursos a ella hasta el mes en que se (re)quiere entregar. Y lo mismo para las dependencias entre historias de distintos productos (dependencias entre calles del tablero).
¿Qué han conseguido? Aunar visión, viabilidad y compromiso entre los diversos negocios/productos/equipos. Es la herramienta de comunicación y debate (mucho debate, pero informado) entre responsables de negocio y product owners. Es lo más parecido al “Árbol de las Almas” de Avatar que he visto por el momento. Interesante e intenso debate.
Visión común – el árbol de las almas
Os lo enlazo con la propuesta de Daniel García: “Product Owner (PO) Multicliente, Multiequipo“. De primeras suena a ser mitológico, ¡veamos!.
Daniel nos condujo por un peculiar “city tour”, visitando los recovecos de un complejo entramado con numerosos clientes a nivel de país, de áreas de Marketing junto con varias líneas de producto y varios equipos de trabajo (uno de Front y tres de Back -justificadamente-). Multicliente y multiequipo.
Duro trabajo para los Product Owners que atienden, cada uno de ellos, varios clientes simultáneamente y también realizan labores de Technical Product Manager (un rol más técnico que “sabe escribir historias de usuario”). Dejan pequeños al doctor Jekyll y al señor Hyde, me parece ;).
Nos explica que trabajan la visión hablando de planes e impacto en el negocio: “para quién hago esto”; “por qué lo hago”; “qué voy a ganar con ello”; “cómo lo mido”. Al final, resume, “estamos hablando de prioridades, como todo en product-ownership”.
¿Cómo hacen para tener una vision muy clara, crucial para poder gestionar a múltiples clientes?
- En dos fases:
- Como Product owner
- Como Technical product manager
- Para cada funcionalidad, se mide el impacto en cada cliente como información de apoyo a la priorizacion.
- Hay un jefe de Product owners que arbrita entre ellos y también tiene capacidad de atemperar a los clientes (Marketing).
En cuanto a los equipos, nos comenta que tienen una capa de aplicaciones (con versiones por pais) y tres capas de backend, una de ellas muy pegada a cada cliente. Como les cuesta mucho conseguir que la parte de backend tenga una vision más amplia, incluyen una vision Extremo a Extremo para cada historia de usuario, de forma que se valore el impacto. Asi se enriquece la misma.
Desde la primera fase de Backlog grooming se apoyan en un cluster de proyectos, implementado en JIRA. En breve: proyecto padre y proyectos hijos (con algún criterio, como componente por ejemplo). Además, utilizan un plugin denominado Structure para representar las dependencias de las épicas, toda vez que la limitación de JIRA a dos niveles jerárquicos les añade un discutido punto de complejidad.
Los equipos son muy estables y están deslocalizados, lo que conlleva dificultades a nivel de cultura, idioma, zonas horarias o festivos. No están contentos, por lo que han incorporado personas con visión de conjunto y perfil de coordinador, no solo desarrollo software. No es ideal, pero es lo mejor que tienen por ahora. Los equipos que lo necesitan, también tienen su facilitador o Scrum Master.
Durante el debate postrero, se matizaron algunos aspectos para, finalmente, disfrutar del resumen visual de Pepe Vazquez … Daniel sigue a la búsqueda de nuevas ideas que les ayuden a mejorar.
Resumen visual PO: Mulcliente, multiequipo
A estas alturas, una cosa estaba quedando clara:
El trabajo ágil, en ambientes complejos, con clientes de negocio “egoístas” (reales) requiere de mucho poso, asertividad y criterio por parte de los product owners para mantener un nivel de satisfacción razonable en todos los interesados.
Cosa seria.
El #AOS2014 nos dió para bastante más, como debatir sobre contratos ágiles, experimentar con potenciar equipos a través del dibujo, aprender de la experiencia de un equipo de rescate software y atender a las novedades en BDD. Os las iremos desgranando.
Personalmente disfruté cada segundo. La frescura y espíritu de colaboración permanentes me llenan y me motivan para, por lo menos, otros 12 meses más. La principal diferencia que he notado entre la #AOS2012 de Zaragoza y esta #AOS2014 de Valladolid es el porcentaje de propuestas relacionadas con aspectos de jerarquías, coordinaciones complejas y contratos. Esto se pone serio.
¿Os parece un síntoma de madurez?
AOS2014_MN11
