Pages Menu
Categories Menu

Posted by on May 29, 2017 in General | 2 comments

Interiorizando el significado del Dual-Track y que un Sprint Review no es para el Product Owner

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.

El trabajo del “Discovery Track” alimenta el Product Backlog. El “Discovery Track” tiene como misión tener listas las historias de usuario antes de que arranque el Sprint de construcción en el que se implementarán, lo que incluye la información necesaria complementaria, y, según lo que hemos hablado, el UX, UI y similares.

Lo anterior es, aparentemente, fácil de entender, pero cuando veo a algún equipo intentando aplicar lo anterior… esto es lo que muchos equipos NO suelen entender:

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 vaidación del trabajo de creación. No, no, no hay dos equipos, Product Owner vs Equipo Técnico (quizá te quede más lcaro 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.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.
Javier Garzás

2 Comments

  1. 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?

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This