Este post es un intento más, desde lo poco que puede hacer un humilde post por cambiar el mundo, de romper una práctica del «Lado Oscuro» que nos es muy difícil de ver, de romper, identificar, y a la que, por alguna razón, siempre intentamos volver… el trabajo en equipos especializados (en vez de Habilidades en forma de T), tipo «silos», pero sin llegar a tanto, lo que lo hace más difícil de detectar, y la división en «fases» secuenciales en vez de «tareas» más cercanas, casi concurrentes.
En este caso concreto voy a centrar los anteriores en el trabajo del equipo que descubre que debería hacer el producto y el que crea el producto.
Para empezar, recuerda aquello, que en ¿Cuándo se hace el diseño de interfaces (UI) y el UX en Scrum? o Agilidad, ¿En qué momento hay que descubrir nuevos requisitos? Constantemente #ContinuousDiscovery ya habíamos comentado, quizá sin la suficiente profundidad en lo que refiere al trabajo colaborativo.
El “Dual Track” era el concepto que nos advertía de que las necesidad (no lo llames requisitos) no se saben de una todos antes de empezar al crear el producto, sino que eran trabajos prácticamente en paralelo. Dos líneas de trabajo, en una nos centrados en descubrir y en otra en construir.
Dos tipos de trabajo, no dos equipos
Mientras que el trabajo de desarrollo del producto (típicamente, no exclusivamente, software). El de creación de producto, busca el control de la deuda técnica, calidad, la velocidad, etc. Y el de descubrimiento en aprender lo más rápido posible, lo que implica tirar ideas.
El descubrimiento es «parte» de la creación del producto, no algo separado. Descubrimiento y creación forman parte del mismo proceso. Y el descubrimiento es ágil, sigue un proceso ágil y le aplican los mismos principios e ideas que al desarrollo de producto, por ejemplo, software.
El trabajo del equipo de descubrimiento es cercano al de creación del producto. Un diseñador, UX, debería estar en contacto frecuentemente con aquellos que están creando el producto.
Error de no entender esto… pensar que un Sprint Review es para Product Owners, cuando es para Stakeholders
Te advierto, que a ojo, 8 de cada 10 de dicen «hacer Scrum» no conocen esto del «Dual Track», menos aún han interiorizado su significado real. Pero en cualquier caso, más avanzado o no, una evidencia de trabajar en equipos separados, es establecer el «sprint Review» como el momento de la validación del trabajo de creación.
No, no, no hay dos equipos, Product Owner vs Equipo Técnico (quizá te quede más claro si en este ejemplo cambias Product Owner por Tester), y hay interacción frecuente… al Sprint Review se llega con todas las validaciones hechas por parte de del Product Owner.
El Sprint Review es para enseñar a los Stakeholders no al Product Owner. Como diría ese mítico y desconocido documento llamado guía de Scrum… «During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
Descubrir implica tirar ideas
Y esas ideas se tiran antes de convertirse en parte del producto… o después, lo que vuelve a resaltar la unión de la creación de producto y del descubrimiento. De hecho, hay quien comenta que realmente todo es descubrimiento, hasta el desarrollo de producto.
Esto nos llevaría a ideas como el Hypothesis-Based Development, desarrollo basado en Hipótesis y a que si el trabajo de creación se guía ppr la «velocidad» el de descubrimiento se guíe por métricas como el número de aprendizajes.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Estimado Javier
Un comentario sobre a quien esta dirigido el Sprint Review si es para el PO o Stakeholder. Me parece que la confusión viene al tener diversos conceptos o guías de Scrum que imparte SCRUM.ORG, ScrumManager , ScrumStudy , Scrum Alliance.
Y no solo en este punto si no en varios, seguramente se coincide en la mayoría de las definiciones pero cada autor tiene su propia interpretación. ¿Que opinas?
Pero ya sabes, guía de Scrum… sólo hay una 🙂