Camino para ser un Equipo de Producto

Nota: este es un estudio de caso real, pero los nombres de la organización y de los actores clave han sido modificados o anonimizados a su solicitud.

A finales de la década de 2000, un gran operador belga de entrega de paquetes tradicional comenzó a experimentar con formas de trabajo ágiles en algunos de sus equipos de TI. Esta no fue una decisión estratégica tomada desde la alta dirección de la organización, sino más bien una iniciativa de un par de gerentes intermedios en TI que se sentían cada vez más frustrados con los problemas de entrega que experimentaban con sus equipos.

Una de las áreas con más problemas dentro de TI era "Correo Rastreado". En esa sección, había alrededor de 23 personas trabajando en distintas aplicaciones para apoyar todos los servicios relacionados con el seguimiento de las entregas. Dentro de la organización, principalmente atendían a dos unidades de negocio:

• Operaciones de Correo (las personas que gestionan los centros de clasificación, donde los paquetes se clasifican y se preparan para la entrega)
• Cuentas Clave (los gerentes de cuentas que manejan a los clientes empresariales interesados en los servicios de correo rastreado)

Tom era el gerente de TI responsable de las entregas de Correo Rastreado, y sabía que las cosas necesitaban cambiar. Se sentó con ambas unidades de negocio para que pudieran alinearse sobre cómo seguir adelante. Primero, se pusieron de acuerdo en los problemas principales que estaban enfrentando:

• Entregas tardías y falta de claridad sobre el progreso (demasiadas sorpresas negativas)
• Arquitectura demasiado compleja (demasiadas tecnologías)
• Aplicaciones con fallos que convertían los lanzamientos de producción en un periodo estresante (>1 mes)
• Baja moral en el equipo

Luego, Tom procedió a explicar su plan para cambiar la situación: quería experimentar con Scrum como forma de trabajo. Tom no sabía mucho sobre Scrum, pero había oído hablar de él en una conferencia y, posteriormente, contrató a un coach ágil que comenzó a ayudarle a entender cómo podría empezar a hacer cambios. Este coach le ayudó a explicar Scrum a las unidades de negocio y por qué podría ser útil para ellos.

Las unidades de negocio eran escépticas, pero reconocían el problema y no tenían nada mejor que proponer. Además, era una iniciativa de Tom, por lo que no podían ser culpables si algo salía mal… así que acordaron comenzar un pequeño experimento. No habría cambios en el lado del negocio, pero los equipos de TI comenzarían a trabajar con Scrum. Había un Product Owner de TI que se alinearía en cuanto a prioridades y avances con las unidades de negocio.

Un comienzo empedrado

La configuración inicial para su inicio con Scrum fue bastante sencilla. Como los equipos de Correo Rastreado estaban entregando valor a dos unidades de negocio, decidieron dividirlos de esta manera. Crearon dos equipos (aproximadamente 11 personas por equipo), uno enfocado en las solicitudes de Operaciones de Correo y el otro en las solicitudes de Cuentas Clave. Había un Product Owner (de TI) que alineaba las prioridades de ambos backlogs con los líderes de cada unidad de negocio. El coach ágil que Tom había contratado estaba trabajando como Scrum Master para ambos equipos. Esta división también tenía sentido desde el punto de vista técnico, ya que algunas aplicaciones eran exclusivas de una unidad de negocio en particular.

Para sorpresa de Tom y los stakeholders del negocio, los primeros 2 Sprints (Sprints de 2 semanas) de los equipos no fueron muy bien desde el punto de vista de la entrega, ya que los equipos no lograron terminar muchos ítems. Parecía que ahora había más problemas que antes.

Sin embargo, Tom notó que algo había comenzado a cambiar. Antes de que comenzaran su primer Sprint, el Scrum Master había logrado convencer a las personas clave de ambos negocios para asistir a las primeras Retrospectivas de Sprint. Al principio, Tom no pensó que fuera una buena idea, pero ahora comenzaba a entender por qué. 

Aunque todavía no estaban entregando, las unidades de negocio comenzaban a comprender el tamaño del desafío. No es que no lo hubieran escuchado antes, pero siempre había sido un punto más en alguna diapositiva de PowerPoint tratando de explicar por qué iban a llegar tarde y con sobrepresupuesto. Otra vez. Esta vez lo escuchaban cara a cara, directamente de la boca de los desarrolladores. Y se enfrentaban a la dura realidad de que no había soluciones simples. Cualquier ilusión que el negocio tuviera de que TI era "poco profesional" y solo necesitaba un poco más de presión para acelerar el ritmo había desaparecido.

Se enfrentaban a desarrolladores altamente competentes que no dudaron en aprovechar la oportunidad para contarles los hechos:

• Alta deuda técnica: el equipo de Correo Rastreado había estado bajo presión durante más de 3 años para entregar soluciones rápidas porque el negocio nunca quiso gastar lo suficiente para hacer las cosas correctamente. Por otro lado, las promesas de "ustedes tendrán tiempo para hacer algo de refactorización más adelante..." nunca se materializaron. Así que ahora la arquitectura está desordenada y tienen mucho código heredado, lo que hace que los cambios futuros sean aún más difíciles de realizar.
• Malas prácticas de ingeniería: como nunca tuvieron suficiente tiempo ni presupuesto para instalar las herramientas adecuadas y mejorar las prácticas de ingeniería, no pudieron adoptar prácticas como la integración continua. En su lugar, trabajaban en ramas paralelas y básicamente fusionaban todo el código durante el periodo de Pruebas de Aceptación de Usuario (UAT), lo que, por supuesto, resultaba en todo tipo de errores.
• Comunicación inflexible con el negocio: más del 30% del Lead Time de una entrega se gastaba en la fase inicial de recolección de requisitos del negocio. Había otro departamento interno llamado "Solutions", que se había creado para asegurar la alineación entre las demandas de las diferentes unidades de negocio hacia TI. Solutions pasaba 2-3 meses en talleres con el negocio para definir requisitos claros y qué debía hacerse (sin TI). Luego, TI tenía que estimar esos requisitos. Y el resultado de este proceso era que durante la corrección de errores en UAT, cuando discutían una funcionalidad con el negocio, con frecuencia se daban cuenta de que habían malinterpretado el verdadero problema.
• Responsabilidad pero sin poder: el equipo sentía que se les responsabilizaba por las entregas tardías y los problemas de calidad, mientras que al mismo tiempo se sentían impotentes para resolver las causas raíz.

Hubo algunas conversaciones difíciles en esas retrospectivas, pero ambos lados aprendieron mucho el uno del otro. Tom también comenzó a darse cuenta de que había subestimado a algunos de los desarrolladores senior en su equipo. Ellos eran bastante capaces de explicar claramente directamente al negocio los problemas que tenían, y lo suficientemente valientes como para proponer alternativas. Y comenzó a surgir un camino a seguir:

• Tendrían 1 Sprint para trabajar en algunas herramientas nuevas que necesitaban para mejorar sus prácticas de ingeniería.
• Tendrían un 10% del tiempo de cada Sprint para invertir en mejorar las prácticas de ingeniería (lo cual el equipo utilizaba para dedicar a una persona a tiempo completo para gestionar todas las herramientas y configuraciones).
• Cada unidad de negocio nombraría a una persona para actuar como su representante durante el Sprint, para responder preguntas de los desarrolladores o probar alguna nueva funcionalidad (llamaban a esta persona el "Business Lead").
• Una persona dedicada a la arquitectura empresarial trabajaría con el equipo en simplificar el panorama de Correo Rastreado.

Esto significaba que, para el Sprint 3, el modelo operativo comenzó a cambiar.

Con la mayor implicación de los dos Business Leads, la persona de TI con el título de "Product Owner" se dio cuenta de que su rol comenzaba a cambiar. En lugar de ser el único que daba retroalimentación al equipo sobre las funcionalidades que se estaban desarrollando, ahora estaba ayudando a facilitar las conversaciones entre los Business Leads y los desarrolladores durante el Sprint. Aún realizaba el trabajo operativo de product owner, manteniendo actualizado el backlog del producto, liderando las sesiones de estimación con el equipo y actualizando a los stakeholders sobre el progreso y los riesgos.

Crecimiento de un equipo Ágil

¿Cuál fue el resultado de estos cambios? Al final del Sprint 5, comenzaron a entregar a un ritmo bastante constante. Tanto el equipo como las unidades de negocio sintieron que habían superado un obstáculo. Para el Sprint 10, hubo una mejora considerable en comparación con su punto de partida. Específicamente:

• Mejorando las prácticas de ingeniería: el equipo había avanzado en algunas prácticas clave de ingeniería como la integración continua, la definición de estándares de código limpio, la revisión por pares del código y las pruebas de aceptación automatizadas. Aún quedaba mucho por hacer, pero los desarrolladores comenzaron a sentirse más confiados acerca de los cambios que estaban realizando. Y los Business Leads comenzaron a tener más visibilidad sobre el progreso.
• Colaboración con el negocio: la colaboración más estrecha que comenzó a crecer entre los desarrolladores y el negocio fue un gran cambio, y Tom lo notaba. Pasaba mucho menos tiempo en reuniones de actualización de estado y más tiempo resolviendo obstáculos reales, como dependencias con otros equipos. Nadie estaba completamente feliz aún, pero por primera vez en mucho tiempo Tom sintió que ahora había una dirección.
• Hoja de ruta para la simplificación: el hecho de que la arquitectura empresarial hubiera dedicado a una persona de su equipo a Correo Rastreado también fue muy significativo. Las decisiones arquitectónicas que se habían tomado 3-6 meses antes durante la fase de recolección de requisitos ahora podían revisarse junto con el equipo durante la refinación. Y si se necesitaban cambios porque alguien encontraba una mejor solución o porque algunas de las suposiciones que habían hecho antes ya no eran válidas, simplemente acordaban un nuevo diseño juntos e inmediatamente lo implementaban. Y juntos estaban creando su hoja de ruta para simplificar la arquitectura y hacer que la aplicación de Correo Rastreado fuera más resistente.
• Mejor compromiso del equipo: los desarrolladores empezaban a generar confianza entre sí, y el conocimiento se estaba compartiendo. Hubo algunas discusiones difíciles en ocasiones, y un par de personas fueron rotadas a otros equipos porque no estaban contentas con la dirección, pero en general, los 23 miembros del equipo estaban comprometidos con su trabajo, colaborando y confiando en el proceso. Habían entendido el cambio y lo habían asumido. Fue refrescante verlo.

A pesar de estos signos positivos, algunos desafíos seguían presentes:

• Crisis financiera: la crisis financiera de 2007-2008 significó recortes presupuestarios por todos lados, y las unidades de negocio tuvieron que reorganizar sus hojas de ruta. Esto hizo que la demanda de ambas unidades empezara a variar. Un mes había mucha demanda de "Operaciones de Correo". Luego, su siguiente proyecto quedaba atrapado en la fase de aprobación presupuestaria durante algunas semanas y no había mucho trabajo para el equipo el mes siguiente. Lo mismo ocurría con "Cuentas Clave".
• Cambio en el panorama competitivo: como empresa, este operador postal se había beneficiado de algunas protecciones gubernamentales, limitando el número de competidores en algunos de sus mercados. Estas protecciones terminarían en 18 meses, lo que significaba que habría una mayor competencia en su espacio de mercado. Así que el negocio quería innovar y volverse más ágil ante las necesidades del mercado, para mantener su liderazgo en el sector.
• Integración con otros productos: para desbloquear nuevas capacidades y servicios, necesitaban empezar a integrarse más estrechamente con otras áreas clave, como "Gestión de Rutas de Entrega" y "Puntos de Venta".

Tom se sentó con el Scrum Master para discutir las opciones que tenían. Dada la crisis financiera, había presión sobre Tom para que comenzara a mostrar resultados impresionantes o empezara a reducir costos (es decir, personas). Y acordaron una idea: invitarían a los Business Leads a un taller, junto con dos de los desarrolladores senior. Querían hacerles a todos una pregunta simple.

¿Cuál es nuestro producto?

Los desarrolladores habían planteado el tema en una de las Sprint Retrospectives, ya que sentían una desconexión entre lo que les habían dicho sobre Agile y lo que realmente estaban experimentando. Les dijeron que todo se trataba de centrarse en el cliente y en la entrega de valor, pero lo que veían eran proyectos desconectados y unidades de negocio discutiendo entre ellas sobre quién era más importante. Con el permiso de los desarrolladores, el Scrum Master decidió comenzar el taller compartiendo esto con los Business Leads. Y les preguntó si estaban de acuerdo con esa evaluación.

Hubo algo de defensiva, y el Scrum Master tuvo dificultades para facilitar ese taller. Se compartieron algunas "verdades difíciles" por parte de todos, pero al final lograron llegar a un entendimiento. Acordaron que el enfoque actual era más prometedor que cualquier otro que hubieran probado. Y, de hecho, tratar de definir su visión y objetivos desde la perspectiva de los clientes parecía coherente, dado el cambio en el panorama competitivo (la crisis financiera y la entrada de nuevos competidores en el mercado).

El resultado del taller incluyó el acuerdo sobre los siguientes cambios clave:

• Un gran "Equipo de Producto" - dejarían de tener backlogs separados para gestionar las solicitudes de "Operaciones de Correo" y "Cuentas Clave". Su producto era "Correo Rastreado", y tendrían solo un Product Backlog donde todas las características, mejoras y correcciones tendrían que ser priorizadas.
• Dos objetivos guías (por ahora) - acordaron colaborar en la priorización con dos objetivos comunes en mente. Primero, querían maximizar el valor que estaban generando para el Correo Rastreado, independientemente de dónde viniera esa solicitud. Y segundo, necesitaban mejorar su excelencia técnica, incluyendo la mejora de la calidad del código, las prácticas de integración continua y la simplificación de su arquitectura.
• Cuatro pequeños equipos de producto multifuncionales - en lugar de tener 2 equipos grandes (11 personas por equipo), se dividirían en 4 equipos más pequeños (5-6 personas) con algunas personas compartidas entre los equipos (probadores, el arquitecto empresarial y el antiguo "product owner" que ahora trabajaba con los equipos como analista senior). La intención era acelerar el intercambio de conocimientos, de modo que todos empezaran a conocer todas las aplicaciones diferentes y a compartir los estándares de calidad
• Un Sprint - dado que todos estaban trabajando en el mismo producto, básicamente todos estarían en el mismo Sprint. Las Sprint Plannings serían compartidas, para que los equipos pudieran decidir qué elementos querían trabajar. Además, las Sprint Reviews serían compartidas, para que todos pudieran ver lo que los otros equipos habían construido, asegurándose de que no se crearan nuevos silos de conocimiento.

Así que el nuevo modelo operativo para Correo Rastreado se veía así:

Y esto funcionó bien durante un tiempo. Habían logrado conseguir suficiente presupuesto de diferentes fuentes para mantener al equipo unido durante la recesión, y el enfoque continuo en la entrega de valor y las prácticas de ingeniería estaba dando sus frutos. Específicamente:

• Ciclos de retroalimentación rápidos - la combinación de una colaboración cada vez más cercana con los líderes de negocio, que ahora se llamaban "Co-Product Owners", así como las mejoras en integración continua, cobertura de pruebas automatizadas y estándares de calidad claros (y suficientemente altos), permitió al equipo obtener retroalimentación mucho más rápida sobre las características que construían. Estaban entregando de manera constante características probadas de extremo a extremo al final de sus Sprints.
• Burbuja de cultura ágil - la organización en sí no había cambiado. Seguían existiendo las unidades de negocio de "Operaciones de Correo" y "Cuentas Clave", y oficialmente, el negocio todavía tenía que entregar los requisitos a TI, y TI era, en última instancia, responsable de cumplir con sus compromisos. Nada de esto había cambiado oficialmente en la organización. Pero cualquiera que observara a este equipo trabajando no lo habría creído. Habían creado una burbuja cultural dentro de la gran organización, y era evidente para cualquiera que simplemente pasara cerca del espacio del equipo... Las líneas que separaban los diferentes departamentos presentes en el equipo de producto de Correo Rastreado en el organigrama habían comenzado a desaparecer.
• Ganar confianza dentro de la organización - El área de Correo Rastreado había sido considerada durante mucho tiempo como una zona problemática dentro de TI. De hecho, esta fue una de las razones por las cuales Tom obtuvo el permiso de su jefe para probar "algo diferente" (Ágil). Ahora, menos de un año después de embarcarse en este viaje, su reputación había dado un giro completo. El negocio estaba contento con el equipo, estaban entregando, y entregando con alta calidad. Esto comenzó a abrir oportunidades de colaboración con otros productos y equipos dentro de la organización, que ahora veían a Correo Rastreado como un socio confiable y no como una carga.

Los equipos de Correo Rastreado esencialmente estaban trabajando ahora como un gran equipo Scrum:

• 1 Sprint - todos los equipos comenzaban y terminaban sus Sprints en el mismo día
• 1 Product Backlog - todos los equipos tomaban trabajo del mismo backlog
• 1 Sprint Planning - todos juntos alineando los próximos entregables
• 1 Sprint Review - todos juntos recibiendo retroalimentación sobre esos entregables
• 1 Sprint Retrospective - el Scrum Master se sorprendió de que esto funcionara tan bien, pero los equipos compartían desafíos y problemas comunes, y encontraron que era mejor tener una sola retrospectiva
• 1 Definition of Done - todos los equipos debían adherirse a los mismos estándares de calidad

Y unos meses después, justo cuando Tom comenzaba a sentirse satisfecho con su valentía por haber iniciado este viaje y orgulloso de lo que habían logrado, comenzaron a surgir dos problemas graves:

• Desalineación entre los negocios: una vez que la situación económica comenzó a mejorar, el presupuesto de las unidades de negocio comenzó a aumentar nuevamente. Y había mucha presión para innovar y entregar debido a los nuevos competidores que ingresaban al mercado. Esto creó un desafío para la estructura de Correo Rastreado, ya que había más ambición por parte del negocio que capacidad de entrega por parte de TI. Y de repente, la estructura de co-product owner dejó de funcionar: no podían alinearse en las prioridades.
• Presión para acelerar y volver a tomar atajos - la falta de alineación entre las áreas de negocio volvió a generar presión sobre Tracked Mail para que acelerara. Tom volvió a escuchar sugerencias de los stakeholders sobre la posibilidad de tomar atajos (reduciendo la calidad) en el corto plazo, dado que nuevos competidores estaban entrando en el mercado. “Podemos dedicar algo de tiempo más adelante para hacer una limpieza y saldar esa deuda técnica”, decían. Tom ya había oído esto antes y sabía que sería un error. Ese tiempo de limpieza nunca llegaría y volverían a estar ahogados en el desperdicio generado por la baja calidad. Además, los desarrolladores quedarían extremadamente desmotivados después de todo el esfuerzo que habían hecho para limpiar y simplificar.

Sin embargo, esta vez Tom tenía un as bajo la manga: las mejoras en Tracked Mail durante los últimos 18 meses y su alto rendimiento en el último año les habían dado una voz más fuerte dentro de la organización. Así que Tom se mantuvo firme. Con la ayuda del Scrum Master de Tracked Mail, prepararon su argumento sobre el curso de acción que debían seguir.

En una serie de talleres con las áreas de negocio, gestión de programas y liderazgo, Tom sostuvo que sería extremadamente contraproducente repetir los mismos errores del pasado. Por el contrario, todo el trabajo que habían realizado para mejorar su situación los había preparado precisamente para este momento. El problema era claro: había más ambición desde el negocio que capacidad de entrega desde IT, lo cual es normal. La solución no era volver a los errores anteriores, sino continuar en el camino que habían elegido. El objetivo siempre había sido convertirse en un equipo de producto de alto rendimiento, centrado en el cliente y ágil en su respuesta. El problema al que se enfrentaban ahora tenía que ver con una mejor priorización, y la solución no debía ser simplemente aumentar el personal rápidamente ni comprometer la calidad.

En cambio, debían dar el siguiente paso y alinear mejor la estructura de la organización con la estructura del equipo. Tom había creado el equipo de producto de Tracked Mail. Lo que esto requería de la organización era un único Product Owner para Tracked Mail: una persona responsable de tomar estas difíciles decisiones de priorización para asegurarse de que el tiempo del equipo de Tracked Mail se invirtiera en las iniciativas correctas. Una persona que, en última instancia, fuera responsable del retorno de inversión del producto Tracked Mail.

Esto llevó a otra ronda de discusiones difíciles, ya que ahora se estaban desafiando las verdaderas líneas organizacionales. ¿Quién tenía el poder de decidir las prioridades entre las distintas áreas de negocio? Este rol no existía en la organización anterior. Sin embargo, el éxito del equipo de Tracked Mail en los últimos 18 meses, junto con la firme defensa de Tom para continuar con el proceso de cambio, fueron suficientes. Nadie en la organización quería asumir el riesgo de ser responsable de desarmar algo que estaba funcionando. En su lugar, uno de los líderes de la organización fue designado como responsable del flujo de valor de Tracked Mail.

Este líder no tenía tiempo para colaborar realmente con el equipo durante el Sprint, pero Tom no necesitaba eso. La colaboración entre los líderes del negocio y los desarrolladores no era un problema. Al contrario, habían construido una relación de confianza durante los últimos 18 meses. El Scrum Master explicó que podían dividir las responsabilidades del Product Owner entre los líderes del negocio y el nuevo Product Owner de Tracked Mail según los siguientes criterios:

• Priorización: ¿Cuáles son los elementos más importantes en los que enfocarse a continuación?
• Clarificación: ¿Qué se necesita entregar exactamente para esos elementos?

La primera (priorización) debía ser responsabilidad de una única persona encargada de la visión y el retorno de inversión. La segunda (clarificación) podía ser asumida por los dos líderes del negocio. No era un problema que varias personas se encargaran de esta parte, siempre y cuando las prioridades estuvieran claras.

Para este punto, el equipo de producto de Tracked Mail había logrado involucrar a todos los niveles de la organización, desde la dirección (el Product Owner de Tracked Mail) hasta los miembros del equipo. Tom sintió que esto representaba un hito importante y comenzó a replantearse cuál debía ser su rol en el futuro. El equipo claramente no lo necesitaba para operar y entregar valor, pero él aún tenía que asegurarse de que estuvieran protegidos ante el próximo desafío que la organización pudiera presentarles. Su rol estaba cambiando, y eso lo hacía feliz.

Un ejemplo para la organización

El enfoque constante en la excelencia técnica, combinado con la incorporación de un único Product Owner para Tracked Mail, logró resultados y hitos impresionantes:

• Mayor autonomía – Durante todo este tiempo, los procesos y políticas oficiales de gobernanza de entrega no cambiaron en la organización. IT aún debía seguir un proceso muy estructurado (y lento) que no estaba alineado con las formas de trabajo ágiles. Sin embargo, gracias al éxito de Tracked Mail (períodos de UAT rápidos, bajo número de incidencias en producción y alta satisfacción del negocio), no seguían esos procesos de manera estricta y nadie se quejaba. Tenían más autonomía para tomar decisiones (todas las partes relevantes ya formaban parte del equipo de alguna manera) y podían evitar burocracia innecesaria.
• Un ejemplo de cambio – Otros líderes de equipo en la organización comenzaron a acercarse a Tom para preguntarle cómo había logrado transformar el equipo de Tracked Mail. Esta curiosidad generó un interés natural por parte de otros equipos, que querían aprender si podían replicar el mismo enfoque en su propio entorno.
• Satisfacción del cliente (internos y externos) – Tracked Mail tenía tres perfiles principales en los que se enfocaban: la persona que enviaba los artículos a rastrear, la persona que los recibía y la persona que realizaba la entrega. Uno de estos era un cliente interno. A medida que el equipo se volvió más centrado en el cliente, la comprensión de las necesidades de estos tres perfiles creció, lo que resultó en una mayor satisfacción para todos ellos.
• Entrega de valor y capacidad de respuesta – Al comprender mejor las necesidades de su mercado objetivo y de las personas involucradas, Tracked Mail comenzó a entregar funcionalidades de manera más consistente, generando un impacto positivo tanto para los clientes como para la organización. Además, las mejoras en las prácticas técnicas les permitieron reaccionar con mayor rapidez y realizar cambios de alta prioridad sin generar estrés innecesario.

1. Scrum define el rol del Product Owner como "responsable de maximizar el valor del producto resultante del trabajo del equipo Scrum". Mirando hacia atrás en el caso de estudio de Tracked Mail, reflexiona sobre el nivel de empoderamiento necesario para actuar como un Product Owner efectivo. ¿Qué desafíos surgirían si quisieras dar a los Product Owners en tu organización este nivel de empoderamiento? ¿Qué tendría que cambiar? ¿Podrías articular un caso a favor de este cambio?
2. Scrum también establece que el Product Owner "es una persona, no un comité". ¿Estás de acuerdo con esto o crees que podría haber una propiedad del producto compartida por un comité? ¿Por qué? ¿Qué problemas surgirían si hubiera más de un Product Owner? ¿Cuáles son los desafíos de tener un único Product Owner?
3. Visita el sitio web de Large Scale Scrum (LeSS) y lee las páginas del marco de trabajo LeSS (es una lectura rápida). ¿Ves cómo el caso de estudio de Tracked Mail es un ejemplo de un equipo ágil que pasó de hacer Scrum de un solo equipo a LeSS? ¿Cuáles crees que son las principales dificultades o desafíos que las organizaciones enfrentan al tratar de implementar LeSS? ¿Podrías aplicarlo en tu contexto? ¿Por qué?
4. Una de las lecciones clave del caso de estudio de Tracked Mail es la importancia de la colaboración estrecha dentro del flujo de valor. El hecho de que el negocio interactuara con los desarrolladores, reconociera su trabajo y empatizara con sus desafíos facilitó la implementación de algunos cambios. ¿Cuáles crees que son las condiciones necesarias para crear un entorno donde la colaboración entre distintas divisiones organizacionales realmente ocurra? ¿Cuáles son los mayores impedimentos para que esto suceda?
5. Tom parece estar quedándose sin trabajo. Si fueras Tom, ¿qué harías a continuación? ¿Qué has aprendido del ejemplo de Tom sobre cómo transformar un equipo?

1. LeSS Framework (Bas Vodde, Craig Larman) - https://less.works/less/framework/introduction
2. "Large-Scale Scrum: More with LeSS", B. Vodde & C. Larman, 2016
3. "Introduction to LeSS", YouTube, 2017