¿Cómo podemos modelar un sistema?

Equipo de miembros de un sistema modelándolo

System Thinking nos enseña que debemos de tomar una perspectiva holística de los sistemas y optimizar el todo. LeSS, el entorno de escalado Scrum, y SAFe®, el marco de escalado Lean-Agile, dan capital importancia a esta disciplina a través sus principios. Para ello System Thinking nos dota de herramientas como System Modelling que nos permiten desvelar el sistema y tomar decisiones adecuadas para su mejora continua.

Sin una herramienta adecuada los directivos y los responsables de la toma de decisiones pueden acabar aplicando su instinto con "soluciones de sentido común" y soluciones rápidas "incorrectas" que no crean una mejora del sistema que sea duradera. ¿Qué pretendemos? ¿Optimizar un equipo? o ¿que la compañía como un todo sea capaz de adaptarse a un mercado cambiante?

La mayoría de los sistemas de construcción de producto tienen un comportamiento no lineal a través de complejos circuitos de retroalimentación positiva y negativa. System Modelling nos desvela conocimiento sobre la dinámica del sistema, sus circuitos de retroalimentación o refuerzo, y nos permitirá encontrar y entender más fácilmente las causas de raíz de los problemas.

Como la mayoría de las herramientas de la Agilidad, el modelado se hace ante un tablero, y su parte esencial es la de tener conversaciones y debates para generar aprendizaje y una comprensión compartida. Su visualización se materializa en un diagrama fácil de ver que permite que las ideas sean concretas e inequívocas

Para empezar con el modelado comenzamos escribiendo en post-its las variables de nuestro sistema.

Elementos, las variables, que se escriben en post-its, y la notación de las flechas que representan sus relaciones

Para un sistema de construcción de software con Scrum un ejemplo de variables puede ser (y puede haber muchas más):

• velocidad
• #bugs
• calidad código
• #miembros del equipo
• presión para aumentar la velocidad
• #sprints
• retención de grandes profesionales
• habilidad para mejorar el mentoring
• #desarrolladores mediocres
• %código limpio
• %tiempo en codificación limpia
• %tiempo de resolución de bugs
• motivación del equipo

Empezamos pegando los post-it en un tablero y esbozamos las flechas con las relaciones entre las variables. Habrá, o debería de haber, mucha reescritura, borrado y redibujado durante la sesión de modelado. El resultado más significativo de esta fase es la comprensión del sistema.

Una vez llegado a las variables más representativas, para entonces se habrá minimizado la conversación y se habrá llegado a un alineamiento general, pasamos a buscar las sutilezas del sistema, los ciclos de refuerzo o retroalimentación negativa y positiva. Los ciclos de refuerzo son como bolas de nieve que podemos utilizar para impulsar o degradar el sistema.

Podemos encontrar ciclos de refuerzo positivo buscando ciclos con un número par de relaciones de efectos opuestos.

Ejemplo de un ciclo de refuerzo

En el ejemplo de la derecha hemos encontrado un ciclo de refuerzo del que podemos comprender que:

• Si aumentamos la presión para ser más rápidos, lo que realmente ocurrirá es que la velocidad disminuirá y la calidad del producto se degradará.
• Si aumentamos la calidad del producto, estableciendo una definición de hecho DoD por ejemplo, la velocidad aumentará y la presión se verá limitada.

Lo más potente de esta fase es que son los propios responsables de la toma de decisiones que habrán llegado por ellos mismos a las conclusiones, y por tanto no hay lugar para excusas y justificaciones, solo para decisiones nuevas que vayan a favor del sistema.

Una vez hayamos identificado los ciclos de refuerzo buscamos aquella variable con más valor para la compañía, la que queramos optimizar, esta es la que se denomina optimization goal.

En una esquina de su post-it apuntamos un "100", y seguimos su relaciones, si es de mas a mas apuntamos en el otro extremo el mismo número, "100" en el ejemplo, y si es de mas a menos, apuntamos un "0". De esta manera populamos nuestro diagrama con "0" y "100" representando como se interrelacionan las variables entre si. Cuando si al llegar a una variable haya conflicto porque de sus relaciones con otras variables una dice que debería de ser "0" y la otra "100", es que hemos descubierto un malentendido o una o varias asunciones ocultas. Este conflicto hay que dilucidarlo y resolverlo, es justo aquí donde las debilidades del sistema salen a la luz.

Una vez obtenido el diagrama completo podemos buscar diferentes maneras de influenciar en la variable que queramos optimizar a través de otras. A veces no podemos cambiar una variable concreta, pero podemos hacer que se refuerce o se degrade a través de otras utilizando los ciclos de refuerzo.

Tablero con el modelado de un sistema constructor de software

La herramienta es escalable, podemos modelar los diferentes sistemas contenidos en nuestra compañía para luego establecer relaciones entre variables de cada uno de ellos y así obtener un diagrama del sistema al completo. Por ejemplo un diagrama de desarrollo de producto, otro de finanzas y otro de marketing tienen variables en común... recordemos, los flujos de valor cruzan las áreas de negocio como requieren y todo está conectado en una compañía.

---

Y para aquellos que queráis modelar un sistema de forma remota quiero invitaros a echar un vistazo la aplicación de Nicky Case llamada LOOPY.

Esta aplicación proporciona herramientas mentales para comprender y modelar sistemas complejos del mundo que nos rodea, permite simulaciones con preguntas "y si" para obtener percepciones de cómo funcionan estos sistemas.

Gracias a Leonardo Tapia que nos mostró LOOPY en su sesión
"Systems Thinking en Scrum a gran escala LeSS" de AgilityTRes60

¿SAFe® y LeSS sirven para escalar el mismo tipo de compañías?

¿SAFe? ¿LeSS? ¿cuál es mi mejor opción? - Cortesía de Pixabay

Por fin llegó el momento en el que he podido asistir a un curso de Certified LeSS Practitioner y sumergirme en LeSS. Asistí al curso de Jurgen De Smet, y gracias a él comprendí la naturaleza y esencia de LeSS, también conocí anécdotas como que LeSS tiene una "e" minúscula como guiño a la "e" minúscula de SAFe® :-D

Lo primero que me fascinó fue que LeSS no es un marco, es un entorno de aprendizaje continuo. LeSS es Scrum multiequipo y trata de descubrir cómo aplicar los principios, el propósito, los elementos y la elegancia de Scrum en un contexto a gran escala, y de la forma lo más simple posible.

LeSS => Principios

LeSS nos enseña que no existen mejores prácticas en el desarrollo de productos, solo hay prácticas que son adecuadas dentro de un contexto determinado, y esas hay que descubrirlas. Como en toda adopción de Agilidad hay que cambiar la estructura de la compañía, y LeSS nos enseña que hay que hacerlo desde los principios.

La fase principal es la de convencimiento de la aplicación de principios, una fase que suele superar los 6 meses, y una vez llegado al punto de inflexión la adopción del entorno LeSS consiste en un aprendizaje continuo mediante inspección y adaptación, y haciendo transparente todo aquello que sea necesario para aprender.

LeSS también nos provee de guías y experimentos con dinámicas para aprender sobre la compañía, pero hay que evitar o eliminar aquellas que limitan la mejora continua o simplemente no encajan.

SAFe en cambio si es un marco que incluye todos los valores y principios Lean y Agile, que se define como una base de conocimiento pública revelada on-line de patrones comprobados e integrados para implementar el desarrollo Lean-Agile. Proporciona una guía completa a nivel de portafolios, de gran solución, de programa y de equipo.

Podemos deducir que LeSS pone el foco en los principios, y SAFe, aunque incluya principios de escalado, lo pone en las prácticas. La Agilidad interna, de tribu o equipo de equipos hacia dentro es fácil, los que estamos a ese nivel experimentamos que las prácticas son una excelente solución, pero la Agilidad externa, la organizacional y que afecta a toda la compañía, es difícil, y solo es alcanzable a través de los principios.

Tanto LeSS como SAFe son una solución correcta, no hay mejor o peor, son soluciones para niveles de madurez diferentes. Para acelerar la transformación ágil en gran parte de las compañías tradicionales la mejor opción inicial es SAFe, un marco complejo que provee de proceso y de prácticas prescriptivas que guiarán a la compañía en la transformación. Las transformaciones ágiles de grandes compañías oscilan entre los 10 y 15 años, por tanto SAFe tiene un largo recorrido en estas.

Para empresas abiertas a cambiar su cultura, o aquellas con una cultura cercana a la Agilidad, la mejor opción es LeSS, ya que le dará herramientas desde la simplicidad para su mejora continua en ambas dimensiones, las técnica y la organizacional. LeSS realmente tratará de desescalar la compañía para que a través de la simplicidad, que es amiga de aquello que mejor funciona, encuentre su forma ágil y eficiente de operar, y que aporte valor a sus clientes y la sociedad.

Hasta he imaginado que SAFe podría ser el mejor y más completo experimento de LeSS... sigo siendo apóstol incondicional de SAFe, cuando evolucione espero llegar a serlo también de LeSS.

Big Picture completo versión 4.5 => Prácticas

Mis agradecimientos a Jurgen por llevarme más allá de lo que soy, a una de esas personas con las que colisionas y te hace cuestionar muchas cosas y te hace crecer de un solo golpe

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿Qué nos dicen las manos de un Scrum Master?

Así son las manos de un buen Scrum Master :-P

Peter mencionó el término "Scrum Master Hands", algo que me llamó mucho la atención; los buenos Scrum Masters siempre tenemos las manos manchadas de rotulador. Bueno, es normal, estos forman parte de nuestras herramientas del día a dia.

Recordemos que un Scrum Master facilita reuniones, entrenamientos y otros eventos, y también se ocupa de expandir Scrum en la cultura de la compañía. A lo que Jurgen explicó que siempre lleva un rollo de Magic Whiteboard encima, un rollo con hojas de plástico que se pegan por electrostática a cualquier superficie y sirven de tablero que se puede montar en cualquier lugar.

Por ejemplo al facilitar una retrospectiva, o al dar una formación, es posible tener de forma muy sencilla y rápida un tablero pegado a cualquier superficie. Al finalizar se puede enrollar fácilmente junto a todos sus post-its, textos y/o dibujos, ya que el plástico sirve de protector y no se arruga tanto como el papel.

Como buen Scrum Master tenemos la misión de evangelizar y entrenar a todos aquellos que se encuentran dentro del sistema. Si se presenta una oportunidad al hablar con un directivo escéptico, se puede desplegar una hoja en la pared más cercana, y con la excusa de que "eres muy visual y necesitas representar lo que estamos hablando" se puede trabajar a plena potencia visual, recordemos que todos somos visuales, y así desvelar asunciones equivocadas u ocultas o hacer emerger claridad o grandes ideas.

Y así es como nos manchamos las manos... y aquí un remedio casero, una buena manera de quitarnos las manchas es frotándolas con un jugo de limón, muy efectivo.

¿Cuál es la diferencia entre Kanban y Canvas?

Lienzo Business Model Canvas de Strategyzer

Es una duda que es usual entre mis alumnos, ocurre especialmente en los cursos de Kanban. Veamos qué hay detrás de cada uno de los términos:

Canvas significa lienzo en inglés, su definición habla de una tela que sirve como soporte a las artes pictóricas hecha normalmente de lino, algodón o cáñamo. Llevado a otras disciplinas como Lean y Agilidad, cuando hablamos de lienzo nos referimos a templates, documentos físicos o virtuales que nos ayudan y guían en el diseño creativo.

Ejemplo de ello es el Business Model Canvas, un documento creado por Alex Osterwalder y Yves Pigneur que sirve como herramienta para explorar y generar modelos de negocios. Este canvas nos guía en pasos claros y simples para generar un modelo de negocio rentable que genere valor para nuestros clientes.

Otro ejemplo es Agile Coaching Canvas, un documento que sirve como herramienta para ayudar a crear una visión sólida y pegadiza de una transformación ágil, aplica desde los equipos y agentes del cambio a los líderes de la compañía.

Agile Coaching Canvas de Alexey Krivitsky

Kanban, es un término con orígenes chino y japonés que va relacionado con tableros y tarjetas. En su artículo "Introducción a Kanban" Jerónimo Palacios nos explica que Kanban escrito en chino (看板) significa señal o tablero visual, literalmente significa "Mirando al tablero", y escrito en japonés (かんばん) significa tarjeta o señal.

Usualmente cuando nos referimos a Kanban en un entorno Lean/Agile nos referimos al sistema creado por David J.Anderson de mejora de procesos basado en un sistema de arrastre con restricciones al trabajo en proceso y visualización del flujo, que se suele materializar en lo que llamamos tableros Kanban.

Ejemplo de un tablero Kanban que visualiza el flujo de epics y/o historias de usuario de Propietarios del Producto

Podemos concluir que ambas son herramientas visuales, canvas es una herramienta que no fomenta la creatividad de los participantes, y Kanban es una herramienta que nos ayuda en la gestión del flujo de trabajo.

¿En qué consiste System Thinking?

Dependiendo del nivel de su complejidad un sistema
puede operar bajo un proyecto en cascada o Scrum

Hace poco Alexandre Magno dio una clase magistral sobre System Thinking. En este post quiero exponer mis aprendizajes más algunas ideas de mi cosecha.

La wikipedia define un sistema como una entidad con límites y con partes interrelacionadas e interdependientes cuya suma es mayor a la suma de sus partes.

Un sistema tiene como objetivo entregar valor al entorno que le rodea, lo hace partiendo de un input para crear un outcome que entrega en forma de outputs. En el caso de proyectos de TI es el cliente/usuario quien recibe el valor, y por tanto este forma parte del entorno.

Imaginemos un interruptor y una bombilla, estos forman un sistema cuyo input es la acción sobre el interruptor, el output es la bombilla que se enciende o se apaga, y el outcome, el beneficio, es que las personas en la habitación puedan ver.

De igual manera un sistema en TI es aquél que, dadas las necesidades de un cliente/usuario, tiene todo lo necesario para construir el software, el output, que da solución a las necesidades de este, el outcome.

Un sistema incluye a las personas y a los recursos necesarios para construir, como los son herramientas, procesos y restricciones. System Thinking es la disciplina que se focaliza en el sistema de forma holística para que funcione de manera optimizada. El system thinker es aquel que lo comprende a alto nivel, tanto en comportamiento como en arquitectura, y lo lidera, apoya e impulsa. Los Scrum Masters son system thinkers de equipos, los coaches ágiles de tribus y equipos de equipos, y los líderes ágiles lo son a nivel de la compañía y sus áreas.

Un system thinker comprende que:

• El flujo de valor de un sistema pasa a través de sus interconexiones, por tanto analizar el flujo para optimizar el sistema es clave
• Un sistema no puede evolucionar más rápido que su punto de integración más lento, fijándonos en retrasos y cuellos de botella sabemos donde debemos de actuar
• Optimizar un componente, un equipo sin tener en cuenta las dependencias con otros equipos o áreas por ejemplo, no optimiza el sistema
• Sólo el entorno, en nuestro caso el cliente/usuario, quien tiene la necesidad y es consumidor del software, puede validar los outcomes del sistema

También hay que comprender que hay sistemas dentro de otros sistemas, y que debe de haber lideres system thinkers a cada uno de los niveles existentes. Podemos tener un sistema en forma de equipo muy optimizado, pero si la compañía dentro de la cual opera no está optimizada por un system thinker, la optimización del equipo no trascenderá e incluso puede crear frustración en sus miembros por sentirse encorsetados y limitados.

Como ejemplo pensemos en un telefonista de una pizzería que entrega pizzas a domicilio. Este puede ser un vendedor excelente que haga que sintamos que estamos comprando la mejor pizza del mundo, pero si la cocina no está optimizada y el producto que recibimos es mediocre, la empresa como sistema es un sistema mediocre.

Matriz de Stacey que nos muestra los
diferentes niveles de complejidad

Cuando tratamos con sistemas de construcción de software, ¿Scrum es siempre la mejor forma de operar? Para ello nos puede ayudar la matriz de Stacey:

Sistemas simples: en estos sistemas la incertidumbre respecto a "qué" construir y "cómo" construirlo es muy baja. En estos sistemas es muy fácil identificar las causas y sus efectos, las decisiones que tomemos podemos tomarlas de forma correcta y clara en el primer momento. Para este tipo de sistemas la gestión clásica en cascada es ideal para optimizar la construcción de la solución de forma completa.

Sistemas complicados: en estos sistemas la incertidumbre de "qué" y/o "cómo" construir tiene peso pero es manejable, las decisiones que tomemos tienen consecuencias predecibles por lo que hay múltiples soluciones correctas. Con el involucramiento de expertos y buenas prácticas se puede llegar a identificar la mejor solución al principio. Scrum podría emplearse pero no sería la forma más eficiente de construir, una gestión de proyectos clásica en casada sería una excelente forma de trabajo ya que la solución puede identificarse completa al principio.

Sistema complejos: es cuando la incertidumbre del "qué" y/o del "cómo" construir es alta, cuando somos capaces de entender las consecuencias de nuestras decisiones pero no las interacciones entre estas consecuencias. Los resultados se vuelven impredecibles y no podemos identificar una solución al principio, solo podemos examinar los resultados y adaptarnos. Esto requiere contextos donde haya lugar para la experimentación y donde esté permitido fallar, con un bajo impacto de los fallos y se donde se pueda aprender rápidamente. En este tipo de sistemas, en los que se requieren niveles altos de creatividad, innovación, interacción y comunicación, Scrum, con sus ciclos de inspección y adaptación, es un marco de construcción ideal.

Sistemas caóticos: cuando la incertidumbre del "qué" y/o del "cómo" construir son muy altas el sistema se considera caótico, su evolución es tan sensible a las más pequeñas variaciones que en la práctica, más allá de un corto intervalo de tiempo, su evolución resulta impredecible. Para poder lidiar con un sistema caótico necesitamos que los profesionales tengan poder de decisión al nivel de la información con la que tratan para poder adaptarse rápidamente y continuamente. Este sería otro escenario para utilizar Scrum, probablemente con ciclos lo más cortos posibles, como sprints de 1 semana por ejemplo. Otra opción sería aplicar Kanban dando respuesta en forma de flujo continuo y con limites WIP que permitirá mantenernos siempre en lo más prioritario.

Mis agradecimientos a Alexandre por su clase magistral y sus dibujos del post :-)

¿Cómo establecer o reestablecer la visión estratégica de la tribu?

Visualización de la tribu en forma de criatura

Una empresa ágil, viva y activa debería de refrescar la visión estratégica de sus tribus de tanto en tanto. Todos los líderes de la misma, Tribe Lead, Propietarios del Producto, Chapter Leads y coaches ágiles deberían de reconectar emocionalmente desde el nivel de esencia sensible para idear nuevos proyectos e iniciativas y crear planes estratégicos desde la pasión e inspiración.

El modelo de coaching de organizaciones y sistemas relacionales ​ORSC™ propone sacar la visión a la luz desde el nivel de esencia sensible, que define como:

"El lugar de la visión y la inspiración. El lugar
donde sentimos un lugar común, donde nosotros somos uno. También incluye tendencias energéticas básicas inexpresables como la química entre las personas. Incluye principios universales comunes y experiencias como la supervivencia, la muerte y la inmortalidad. Es el lugar donde la polarización entre individuos no existe".

La dinámica, que hemos adaptado, empieza por una fase de visualización en la se que hace uso creativo de la metáfora para ayudar a contactar con los retos, fortalezas y necesidades de la tribu. Con un folio y rotuladores en mano se les pide a los asistentes que utilicen su imaginación para que dibujen a su tribu, su experiencia con esta, como si fuese una criatura con una vida propia:

• Si fuese una criatura real o imaginaria ¿qué aspecto tendría?
• ¿Cómo se movería, qué sentiría?

Dibujada la criatura se desarrolla un poco más y se les pide que tomen notas (en la parte trasera del folio por ejemplo):

• Primero, ¿en qué sentido es fuerte y se desarrolla con salud?
• Finalmente, ¿cuáles son sus necesidades y sus retos?

Los diferentes dibujos se colocan en una pared, el suelo o en algún sitio que sea fácilmente visitable por todos. En individual todos visitan los dibujos y notas de los demás. Puede haber preguntas y aclaración de dudas, pero no es el momento de debate.

La segunda fase trata de traer la visión a la luz.

• Las fortalezas se llevan y agrupan en un rotafolios.
• De la misma manera se llevan y agrupan los problemas y retos en un segundo rotafolios.
• A modo de retrospectiva se votan los problemas y retos principales y se buscan ideas y soluciones en una sesión de brainstorming.
• Las ideas y soluciones se unifican en un tercer rotafolio como una visión renovada de la tribu. Es importante que la visión se escriba como un objetivo SMART, específica, medible, alcanzable, relevantes y limitada en el tiempo.

Ejemplo de dinámica de una visión traída a la luz

La segunda fase la presento muy resumida, el foco en este post está en la fase de visualización, cuyo valor está en desvelar lo que hay en su esencia a la tribu y permitir ser más creativos y trabajar desde "fuera de la caja".

¿Un buen proyecto implica un buen producto?

Podemos llegar a un producto a través de un proyecto o a
través de la gestión de entregas de producto que hace Scrum

En una conversación con Alexandre Magno, un apasionado por la gestión de productos, dió como ejemplo al Titanic para entender la diferencia entre proyecto y producto.

Pensemos en el Titanic como barco: fue un excelente proyecto, se construyó en tiempo y costes y cumplió perfectamente con todas las normativas de la época, pero fue un producto mediocre, se hundió en el primer viaje en una ruta que iba a ser habitual y solo tenía un tercio de botes salvavidas para poder cubrir el pasaje, con lo que murieron más de 1.300 pasajeros.

Ahora pensemos en la película Titanic: fue un proyecto nefasto, sus costes de producción se multiplicaron por 17 y James Cameron tuvo que hipotecar su patrimonio, ahora como producto fue superior y produjo beneficios mucho más allá de lo que cabía esperar, en su momento fue la película mas taquillera de todos los tiempos, se recaudaron más de 1.800 millones de dólares.

Quiero invitaros a leer el post de Alejandro Pérez ¿Proyecto o Producto? ¿Sabes diferenciar correctamente sus ciclos de vida? en el que trata la diferencia de ambos. Las definiciones oficiales y los ciclos de vida de ambos según el estándar internacional de gestión de proyectos, el PMBOK, son:

• Proyecto: Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.
• El ciclo de vida del proyecto son todas las fases necesarias para llevar a cabo este objetivo, que el PMBOK describe en 5: Inicio, Planificación, Ejecución, Monitorización/Control y Cierre.
• Producto: Es un artículo producido, cuantificable y que puede ser un elemento terminado o un componente.
• A diferencia del proyecto, el ciclo de vida del producto, está centrado en el entregable, el producto en si mismo, siendo sus fases diferentes: Introducción, Crecimiento, Madurez y Retiro.

Podemos construir un producto a base de uno o varios proyectos, cada uno de ellos tiene un inicio y finaliza a una fecha de entrega. Los ciclos de vida son totalmente independientes, el producto subsistirá mientras no quede desfasado u obsoleto. De hecho un producto exitoso es aquel que está en constante evolución, adaptándose una y otra vez a los cambios y oportunidades del mercado. Pensemos en Amazon por ejemplo, tanto software como los productos que ofrecen están en continua evolución, el día que la tienda no evolucione probablemente se estará acercando al final de su existencia. Un producto basado en software suele estar obsoleto en el momento en el que deja de evolucionar.

Project manager versus Product Owner

Profundicemos en la gestión de proyectos; esta se basa en montar lineas de tiempo (planes) atadas a un alcance inicial y en dotar a la linea de tiempo de los recursos necesarios para cumplir con esa linea, y lo hace en el primer momento sin tener en cuenta capacidades ni dependencias.

Se basa en traer a la gente al trabajo, en equipos asociados al proyecto que por diseño no tienen continuidad. Con cada proyecto se crea un equipo nuevo del que no se sabe su capacidad hasta que esté rodado, y sabemos que los equipos suelen tardar de 3 a 6 meses en estar integrados, haber adquirido el conocimiento sobre el producto y entorno tecnológico y a establecer conexiones con otros equipos y otros interesados clave. Por tanto la dotación de recursos al plan no deja de ser una intención o deseo.

Durante el proyecto el jefe de proyecto o project manager, que está comprometido con el alcance y una construcción óptima del mismo, tiene su foco en cumplir con el triángulo de hierro protegiendo al proyecto de todo cambio, y por tanto está indefenso para lidiar con la turbulencia del cambio del mundo actual y la divergencia diaria de las metas de proyecto y producto.

Scrum proporciona una forma distinta para construir y hacer evolucionar un producto, una forma centrada en el producto y no en proyectos. Se basa en medir la capacidad de flujo del sistema y sus equipos, equipos maduros y estables y con continuidad, ajustar el trabajo inyectado a la capacidad y poner el foco en mejorar el flujo de forma continua, alineando, sincronizando y planificar teniendo en cuenta las dependencias. Trae el trabajo a la gente y en forma de incrementos de valor para el producto. Un Propietario del Producto o Product Owner está comprometido con los problemas del cliente y su foco principal es conseguir el mejor producto del mundo.

Ambas son formas para construir y mantener un producto. En mi experiencia, en especial en el desarrollo de software y aquellas áreas que tratan directamente con clientes y usuarios, cuando lo hacemos a través de proyectos pasaremos por varias crisis de ajuste a la realidad, ya que el foco está en las actividades del proyecto y no en los incrementos de valor del producto. Cuanto más corto sea el proyecto menos incertidumbre le rodea y más posibilidades tiene de incorporar las divergencias y por tanto tener éxito. Si construimos con Scrum, focalizados en incrementos de valor, garantizamos el mejor producto posible para el presupuesto y tiempo dado, solo hemos de liberarnos del anclaje a un alcance inicial y entender que al principio de un proyecto es imposible saber como va a ser el detalle de ese mejor producto posible.

Quiero dedicar este post a Dani, el autor del dibujo del Titanic, con el que he disfrutado impulsando a algunos jefes de proyecto en su trayectoria ágil