¿En una organización muy madura podemos prescindir del Propietario del Producto?

¿Propietario del Producto o Feature Owner?
Photo by bonneval sebastien on Unsplash

A medida que una compañía madura en su forma de trabajar, un Scrum Master en su forma de coach de equipos, llega a ser prescindible cuando los equipos de desarrollo están rodados y la cultura empresarial está fuertemente asentada para que estos puedan evolucionar sin acompañamiento a través de la mejora continua.

La cuestión es si en una empresa madura, en la que exista un verdadero sentimiento de compromiso en todos los empleados, es posible prescindir del Propietario del Producto. Este, en un ambiente muy maduro y como parte del equipo de Scrum que enlaza con los interesados y la gente de negocio, puede convertirse en un cuello de botella que dificulte la aceleración del flujo de entrega de valor.

El compromiso de los Business Owners, o interesados/usuarios/cliente clave, es la mayor garantía de que la empresa esté invirtiendo adecuadamente en el producto, ya que estos aseguran que los equipos están trabajando en lo que dé máximo valor de negocio. Entendido esto, ¿no seria más deseable que los equipos trataran directamente con los Business Owners?

Podríamos pensar en Business Owners desalineados y con intereses propios, pero en una empresa madura que fomente visibilidad y transparencia y que tenga una visión y misión bien definida y comunicada, existirá un objetivo y propósito que imperará por encima de los intereses individuales y fomentará la colaboración de todos los Business Owners hacia un objetivo común.

Hace poco tomando una cerveza con Alexandre este me contó de una empresa que había acompañado y en la que decidieron prescindir del rol del Propietario del Producto. Crearon el rol de feature owner, un interlocutor principal por funcionalidad, que es quién añade funcionalidades a la pila de producto y es el que la sigue hasta su validación en un entorno productivo. Esta idea está totalmente alineada con LeSS en su concepto de pila única cuyos propietarios son los equipos.

Para priorizar la pila de producto una buena opción es la técnica "buy a feature" en la que participan todos los features owners:

• Cada uno presenta sus funcionalidades que previamente han sido estimadas en esfuerzo por el/los equipo/s de desarrollo.
• Cada feature owner obtiene un presupuesto de dinero ficticio para gastar, este debe estar entre un tercio y la mitad del esfuerzo total.
• Los feature owners usan su presupuesto para comprar las funcionalidades que sean más importantes para cada uno de ellos.
• A medida que los jugadores compran se recolecta el dinero y estos explican por qué están comprando esa funcionalidad.
• El juego termina cuando se acaba el dinero o cuando los jugadores han comprado todas las funcionalidades en las que están interesados. Finalmente el total de dinero ficticio obtenido por cada funcionalidad, de más a menos, determinará la prioridad de la pila de producto.

¿Por qué utilizamos post-its en Scrum?

Tableros con post-its que gestionan los
flujos de valor y trabajo de la compañía

La Agilidad se ve rodeada de post-its, solemos asociar una pared con post-its con equipos de Scrum o Kanban, transformaciones ágiles y Agile. ¡Hasta he oído que la Agilidad consiste en pegar post-its en un tablero y las paredes!

A parte del colorido que aportan los post-its ¿cuáles son los beneficios de utilizarlos?

El post-it es algo muy flexible, podemos escribir en él lo que tenga valor, podemos llevarlo a otra área de la sala o del edificio y tener conversaciones con otros alrededor del concepto escrito, y llegar a acuerdos y decisiones que podemos refleja en otro post-it, quizá de otro color. Los colores de los post-its nos permiten mostrar items de diferentes naturalezas; quizá amarillo para unidades de trabajo, rojo para bloqueos, verde para incrementos funcionales, etc... las personas somos visuales y los post-its son un elemento de trabajo muy alineado con la naturaleza humana que nos hace asimilar y recordar mejor sobre lo que tratan.

En Agilidad los equipos de Scrum o de Kanban hacen que sus post-its recorran tableros en los que se representan diferentes estados en columnas, por tanto los post-its recorren flujos de valor o flujos de trabajo. Eso convierte a los tableros y sus post-its en una gestión visual del flujo y verdaderos puntos de referencia para los equipos, áreas y la compañía en sentido más amplio. Estos dan absoluta visibilidad y transparencia al progreso, podemos ver la situación general o agregada cuando observamos el tablero desde la distancia, y podemos ver el detalle acercándonos a los post-its individuales. Irradian de forma continua la situación actual, son puro elemento de gestión del flujo y de conexión y comunicación entre personas.

Pero, ¿no valdrían de igual manera herramienta con tableros y post-its virtuales como JIRA o Redmine?

Visto el punto anterior una de las grandes desventajas de las herramientas con tableros virtuales es que no suelen estar preparadas para dar una visión agregada del tablero, este no suele caber al completo en un solo pantallazo, con lo que se minimizan los beneficios de la visión holística, y eso provoca que las personas pongan el foco en los elementos individuales, probablemente los propios, y se pierda la visión periférica y la colaboración se sienta resentida.

La desventaja más importante es que las herramientas tienen sus procesos embebidos, con lo que las personas ponen el foco en aprender a utilizar la herramienta y sus procesos, no a desarrollar su propio proceso a través de la mejora continua, tal como fomenta la Agilidad. A diferencia de estas los tableros con post-its fomentan la colaboración y el desarrollo del propio proceso a través de la mejora continua.

---

Para los ecologistas y los que piensan que los post-its hacen que empresas como 3M se forren, quiero invitarles a leer el artículo de Alexander Helleboogh "About post-its and trees" en el que se concluye que un árbol medio provee de 100 post-its al sprint a 10 equipos de Scrum durante 5,5 años, mientras que un árbol no es suficiente para proveer de papel de WC a una única persona en el mismo periodo.

¿Qué significa que un Scrum Master es un system thinker?

Equipo de desarrollo, el sistema del Scrum Master - cortesía de Pixabay

Imaginemos una situación en la que en un evento de Scrum, por ejemplo una planificación de sprint, un miembro del equipo participa escasamente y está sumido en su móvil.

Un facilitador no system thinker lo que haría sería dirigirse a la persona en concreto, quizá en un break, y hacerle ver que su comportamiento no es el adecuado y que perjudica seriamente al resto y al evento.

Para fomentar un comportamiento adecuado como equipo integrado es necesario una comprensión superior del sistema y hacerles entender a todos los miembros que la creación del valor solo es posible mediante la colaboración de todos los miembros. Por tanto un Scrum Master system thinker percibe y entiende el problema a nivel de equipo e intentará resolver el problema desde el equipo, utilizando el sistema para resolver el problema y así hacer evolucionar y crecer al equipo.

En la situación descrita al inicio del post un Scrum Master reconoce el problema que hay en el sistema y pensará en qué actividad o práctica puede intentar aplicar para hacer emerger el problema y que ayude a que el propio equipo lo resuelva. Por ejemplo una práctica colaborativa, como un planning poker, una retrospectiva, una dinámica de team-building... una dinámica en la que todos tengan que participar y donde la peer pressure hará que la persona disonante se alinee.

Liberating Structures tiene un repositorio de 33 métodos

Podemos utilizar actividades de Liberating Structures que nos provee de un repositorio de casi medio centenar de métodos accesibles a un Scrum Master para hacer que todas las voces de un sistema o equipo participen, son métodos 100/100, 100% de los miembros al 100% en el 100% de las actividades. Mencionar que un 20/80 no es inusual, un 20% de los miembros acaparan el 80% de la actividad. Con estas actividades el Scrum Master hará que todos se sientan incluidos y comprometidos.

En otras ocasiones el Scrum Master utilizará alguna dinámica dirigida a resolver el conflicto. En una ocasión distribuí tres caramelos a todos los miembros del equipo y les invité a regalar sus caramelos al resto acompañando cada caramelo de unas palabras de agradecimiento por alguna razón concreta. El miembro disonante se quedó sin caramelos; me quedé cerca de él y cuando se acercó conversamos; él sabía perfectamente porqué había ocurrido.

Por ello es tan importante que los Scrum Masters tengan habilidades blandas como las habilidades sociales y conocimiento de coaching sistémico como el impartido por ORSC™.

El coaching sistémico entiende a empresas y equipos como un sistema formado por elementos interconectados cuyas acciones y decisiones individuales repercuten en los demás y en todo el sistema. Este tipo de coaching ayuda a cada individuo a contribuir al sistema completo y a lograr un equilibrio global, aporta soluciones sencillas y rápidas a situaciones complejas a través de la interrelación entre los individuos. Por otro lado sirve para detectar el origen de diferentes problemas o conflictos organizacionales para analizarlos y ayudar a solventarlos.

¿Scrum es una metodología o es un marco?

Marco de Scrum, cortesía de Miguel Ángel Sobrino :-)

En múltiples ocasiones hemos oído el término metodologías ágiles, concepto que chirría a los agilistas y que estos suelen corregir por métodos ágiles y/o marcos ágiles. Entonces, ¿cuál es la diferencia entre metodología y marco?

Alexandre Magno en una clase magistral resumió la diferencia en una comparación muy clarificante:

• Una metodología es una forma de trabajar lista para usar, una forma de trabajar para followers.
• Un marco es un conjunto de valores y prácticas que está listo para empezar a construir la propia forma de trabajar a través de la mejora continua, para aquellos que lideran su forma de trabajar en su propia singularidad e identidad de empresa.

La definición formal del concepto de metodología hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el objetivo que rige una serie de tareas que requieran habilidades, conocimientos o cuidados específicos. A su vez un marco de trabajo se define como un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar, por tanto es algo incompleto que desarrollamos a nuestra medida.

Scrum por tanto es un marco a la vez que un contenedor para otras prácticas o métodos ágiles como TDD y BDD por ejemplo, marco que fomenta equipos autoorganizados que deciden qué, cuando y como usar estas prácticas. En una metodología los equipos no piensan en su forma de trabajar, se basan en un proceso con pasos predefinidos; en cambio con Scrum los equipos piensan y reflexionan sobre su forma de trabajar y la mejoran continuamente a través de las retrospectivas, lo que fomenta el descubrimiento y empirismo hacía una mejor forma de trabajar en continua evolución.

¿Qué es y como funciona un Centro de Excelencia Lean-Agile (LACE)?

Velando por la excelencia - Cortesía de Pixabay

SAFe® define el Centro de Excelencia Lean-Agile (LACE) como un equipo de personas dedicadas a la implementación de la forma de trabajo Lean-Agile.

Equipos de 4 a 6 personas dedicadas el 100% pueden apoyar a unos pocos cientos de practicantes, mientras que equipos de 8 a 12 personas pueden apoyar proporcionalmente a grupos más grandes.

Punto focal

Evaluación y mejora de cada una de las cinco competencias básicas que identifica SAFe de una empresa Lean:

• Liderazgo Lean-Agile.
• Equipo y Agilidad técnica.
• DevOps y Release on Demand.
• Soluciones de Negocios e Ingeniería de Sistemas Lean
• Lean Portfolio Management

Responsabilidades

• Comunicar la necesidad de negocio, la urgencia y la visión para el cambio.
• Desarrollar el plan de implementación y gestionar la pila de transformación.
• Establecer las métricas.
• Capacitación de ejecutivos, gerentes y líderes, equipos de desarrollo y roles especializados, como Propietario del Producto, gerente de producto, Scrum Master, etc.
• Identificar flujos de valor y ayudar a definir y lanzar equipos Lean-Agile.
• Proporcionar capacitación y entrenamiento a los interesados y a los equipos Lean-Agile.
• Participación en eventos iniciales críticos asociados a las formas de trabajo Lean-Agile.
• Fomento de las Comunidades de Práctica (CoPs).
• Comunicar el progreso.
• Implementar días de enfoque Lean-Agile, con ponentes invitados y presentando casos de estudio internos.
• Benchmarking y conexión con la comunidad externa.
• Promover la educación continua Lean-Agile.
• Extender las prácticas Lean-Agile a otras áreas de la empresa, incluidos Presupuestos Lean, Lean Portfolio Management, contratos y recursos humanos.
• Ayudar a establecer la mejora continua.

Forma de trabajar

El funcionamiento es el de un equipo ágil. Como resultado, se necesitan roles similares:

• El Propietario del Producto trabaja con las partes interesadas para priorizar la pila de transformación de los equipos.
• Un Scrum Master facilita el proceso y ayuda a eliminar obstáculos e impedimentos.
• El equipo es multifuncional. Personas creíbles de varias áreas funcionales son los miembros integrales del equipo. Eso les permite abordar los elementos de la pila donde sea que surjan, ya sea que estén relacionados con la organización, la cultura, el proceso de desarrollo o la tecnología.
• Un líder de nivel C generalmente actúa como el gerente de producto del equipo.

En base a la información anterior proponemos un ejemplo de la misión de una LACE para una empresa proveedora de servicios de TI ficticia:

Para ADVANCED IT Inc.

Quienes proveen de servicios de TI a terceros (desarrollo, mantenimiento, servicios)

El Centro de Excelencia Lean-Agile

Es un equipo multifuncional Lean-Agile a tiempo completo de gestión del cambio

Que conduce la transformación de ADVANCED IT Inc. a una forma de trabajar Lean-Agile

A diferencia de nuestros esfuerzos tradicionales de transformación

Nosotros proveemos agentes de cambio Lean-Agile dedicados al 100% y el liderazgo comprometido para implementar el entrenamiento, procesos, tecnología, cultura, herramientas y cambios a nivel de gobernanza necesarios para alcanzar los beneficios de una forma de trabajar Lean-Agile

Dentro del Alcance

• Comunicación
• Liderazgo, entrenamiento y coaching de equipos
• Creación de equipos ágiles
• Metodologías de trabajo
• Herramientas de trabajo

Fuera del Alcance

• Cambios en la estructura organizativa

Criterios de éxito

• % de personas entrenadas en sus nuevos roles
• % de líderes entrenados en sus nuevos roles
• % de equipos trabajando de manera Lean-Agile

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