Cuando se trata de abordar el trabajo de un producto a escala, muchas organizaciones tienden a mirar a frameworks de escalado como SAFe, Nexus o LeSS.
En un artículo anterior vimos como gestionar dependencias en Scrum y hoy vamos a centrarnos en como escalar la gestión del producto.
Antes de comenzar a trabajar con un framework tenemos que entender cual es el propósito y preguntarnos por qué necesitamos escalar. Al fin y al cabo hay muchos ejemplos de productos que sirven decenas de millones de usuario que se mantienen con equipos muy reducidos.
Y esto tiene mucho sentido.
Trabajar con equipos reducidos elimina complejidad y permite ser más ágiles. De hecho mi primera recomendación en el curso de escalado con Nexus es: No escales.
Escalar agilidad
Cuando escalamos nuestro trabajo podemos hablar de dos tipos de escalado: Vertical y horizontal. Dependiendo de si lo aplicamos a uno o varios productos podemos encontrarnos con cuatro casos:
- Un producto, uno o dos equipos: En este caso lo mejor es utilizar el sentido común, un framework como Scrum o el método Kanban.
- Un producto, múltiples equipos: Aquí tienen sentido los frameworks de escalado a partir de cierto volumen de personas trabajando sobre el mismo producto.
- Varios productos, múltiples equipos: Además de cualquiera de los anteriores, ya sea Scrum o Kanban para productos con uno o varios equipos; herramientas de escalado para múltiples equipos trabajando en un solo producto, en este caso hemos de añadir Portfolio Management.
- Múltiples productos, un equipo: Este caso es muy complejo y lo único que puede ayudar a sobrellevarlo es usar sistemas Kanban. A medio plazo hay que, o eliminar productos o integrarlos en un solo producto.
En este artículo me centro en el segundo caso. Un producto y múltiples equipos que trabajan sincronizados para generar incrementos en este producto.
Antes de pensar en escalar hay que evaluar muy seriamente si ya hemos hecho todo lo posible y estamos obteniendo la máxima capacidad posible con los equipos que tenemos.
En OpenAI desarrollaron durante mucho tiempo DALL-E y ChatGPT con menos de 40 personas. En Stripe alcanzaron millones de usuarios con apenas 20 ingenieros. Cuando Milanuncios se vendió por 100 millones de euros contaba con menos de 10 personas en staff.
Algunas de las empresas más exitosas con las que he trabajado facturaban decenas de millones de dolares con 20 o 30 personas.
Una sola regla para dominarlos a todos
Si a pesar de esto decidimos escalar hay una regla que sigo siempre: Tener un solo Product Owner. Cualquier otra cosa nada más que genera caos y confusión a largo plazo, creando espacios para que nuestra capacidad de aportar valor se diluya en las divergencias.
Si lo pensamos detenidamente tiene todo el sentido del mundo. En cualquier iniciativa importante, en cualquier campo de ingeniería, producto o esfuerzo humano, tener un único punto de accountability es importante.
A pesar de todo, puede que cuando empezamos a trabajar un producto a escala nos encontremos con la duda de si un Product Owner puede realmente hacerlo todo.
Un Product Owner puede hacerlo todo, con estrategia y cabeza
Una vez que hemos comenzado el esfuerzo de escalar, esto es, añadir más equipos a un solo producto, comienzan los dolores de cabeza.
El Product Owner se puede ver arrastrado a pensar que tiene que invertir muchas más horas detallando historias de usuario, tomando decisiones y supervisando cada detalle para asegurarse de que todo está perfecto. Y al cabo de poco tiempo pensar que lo mejor es contratar a un Product Owner Junior.
Esto es un error.
El trabajo del Product Owner a escala sigue siendo el mismo. Lo que ocurre es que la manera de alcanzar sus objetivos escalan junto con el producto. Lo que antes se hacía manualmente ahora se hace a través de la integración de herramientas.
Acceptance Testing
Automatizar los tests de aceptación para cada elemento que completamos en nuestro producto nos permite centrarnos en, una vez que los tests estan en verde, elementos concretos. Nos evita tener que revisar todo el trabajo en cada Sprint. Herramientas como Selenium o Cucumber facilitan la colaboración y permiten centrarse en lo importante
Design Systems
Un sistema de diseño es una colección de componentes reusables que se pueden utilizar en múltiples aplicaciones. Habitualmente contienen componentes y patrones que permiten que los equipos Scrum desarrollen sin tener la dependencia de un diseñador o necesiten la aprobación del Product Owner. Puedes ver el ejemplo de Flame, el sistema de diseño del banco Santander o DESY, el del gobierno de Aragón.
Métricas en tiempo real
A través del uso de cuadros de mando o dashboards podemos obtener feedback en tiempo real del uso que nuestros clientes hacen de nuestro producto. Una solución muy popular es Grafana, que permite la integración de otras herramientas como Graphite para monitorizar series temporales y transformarlas en gráficas de uso del producto.
Feature Usage Index
Una métrica clave para entender el valor que está generando nuestro producto es cuantas de las opciones de nuestro producto utilizan nuestros usuarios. Esto nos permite tomar decisiones sobre en que features invertir, cuales mantener e incluso cuales eliminar. Userpilot es un software que te permite medir el engagement de los usuarios dentro de una aplicación digital.
Feature flagging
Además de lo anterior, feature flagging es una técnica que nos permite elaborar una estrategia de despliegue funcional. Cada función es una unidad independiente que puede ser encendida o apagada a voluntad. De esta manera el Scrum Team puede ir desplegando nuevas funcionalidades sin terminar en el producto final y la decisión de activar la feature queda a criterio del Product Owner. TeamCity es una solución de JetBrains para integrar feature flags en nuestro producto.
Delegación de responsabilidad
Por último, todo esto debe de ir acompañado de una delegación mayor de responsabilidad sobre el backlog en los Developers. Cuando un producto escala, es habitual que el Product Owner delegue la mayor parte de las decisiones sobre la organización y el detalle del backlog en los Developers -no en un Product Owner Minion- para cerrar el gap entre negocio y tecnología.
¿Y si el producto evoluciona a cientos o miles de desarrolladores?
En este caso lo que ocurre es que el producto se reparte en una suite de varios productos que se configuran a medida como un stream de productos personalizados para cada cliente.
Para generar una página de producto Amazon, por ejemplo, llama a unos 300 productos que le proporcionan toda la información que necesita.
Este caso lo trataré en un artículo más adelante.