Equipos de Producto y creación de productos con Scrum

Aquí comparto una experiencia de varios años de un mismo equipo y el impacto de negocio con la incorporación de Scrum y prácticas orientadas a gestión de producto.

Este año se cumplen 20 años de la firma del Manifiesto Ágil. Un hito que se transformó en un punto de inflexión de toda una industria. Hoy, veinte años después quisiera comentar algunas cosas al respecto, pero no de la agilidad y el Manifiesto (creo que de eso ya se ha hablado mucho) sino de un camino tangencial que aporta el Product Management.

Para eso me voy a remontar a mi primer desafío importante en cuestión de Product Management. El mismo comenzó a mediados de 2003 y duró hasta finales de 2006. Sí, hace muchísimo tiempo (no vale sacar cuentas!!).

Un ejemplo con metaSAP (ViaWise)

El producto en cuestión se llamaba metaSAP y posteriormente ViaWise. Era una solución web que se integraba a SAP y creaba copias de las pantallas y reglas de negocio para ejecutar los procesos desde un navegador (en ese momento Internet Explorer y Netscape) o una handheld con Windows ME. (Dije que no vale hacer cuentas eh :)).

Gracias a ese producto tuve la oportunidad de experimentar por primera vez en mi vida profesional la diferencia entre un equipo de delivery, un equipo de features y un equipo de producto. Esa experiencia me marcó tanto que fue uno de los factores claves por los cuales varios años más tarde me convertiría en un fiel promotor de la agilidad y el foco en resultados de productos digitales.

Éramos un equipo de seis personas. Separaría el desarrollo de metaSAP, y su sucesor ViaWise, en tres grandes momentos donde la atención la hemos puesto en diferentes aspectos:

  1. Atención al delivery
  2. Atención a las funcionalidades
  3. Atención a los resultados de producto

A continuación te cuento las particularidades de cada momento y cómo yo los viví.

Gestión de proyectos y cumplimiento de tareas (foco en el delivery)

En 2003 iniciamos el desarrollo de metaSAP. Con la gestión de proyectos tan presente en nuestras cabezas, el desarrollo se basó en las propuestas del Project Management Institute (PMI) y Rational Unified Process (RUP).

El trabajo se organizaba alrededor de un Work Breakdown Structure (WBS), planes y Gantt charts, donde la principal preocupación era concluir las entregas en tiempo y forma. El equipo recibía una lista de entregables y sus deadlines. Algunos ejemplos de entregables eran del estilo Artefactos de RUP, como Stakeholders Requests, Business Case, Software Requirement Specification, Deployment Plan, etc. Podríamos llamar "documentación exhaustiva" a todo este grupo de entregables.

Como te imaginarás, entre estos documentos y el software construido había un divorcio significativo. Nada se correspondía con nada, ya que las soluciones propuestas cambiaban luego de haberse diseñado y los diseños nunca se actualizaban. Adicionalmente, la integración y el testing de estos desarrollos se hacían en fases. En ningún momento durante la construcción de metaSAP nos detuvimos a evaluar los resultados ni beneficios que obtenían los potenciales clientes.

Bajo este esquema existe un divorcio entre el software construido y la documentación.

Digo potenciales porque fue un desarrollo de meses que se hizo puertas adentro siguiendo las "mejores prácticas" del momento. El producto tenía una calidad técnica y un nivel de innovación enorme para el estándar de esos años.

El error que cometimos fue no involucrar a ningún cliente directo en el día a día. En su lugar hicimos una serie de entrevistas a potenciales clientes que habíamos identificado y luego diseñamos la solución y la desarrollamos mirándonos el ombligo. Obviamente, ya entrado el 2004, no se lo habíamos vendido a nadie. El producto se puso en el freezer y a otra cosa.

Involucramiento de los stakeholders (atención a los features y outputs)

A mediados de 2005 decidimos darle otra oportunidad a metaSAP. La idea fue renovar su tecnología pasando de ASP.NET a Java, hacer un renaming de metaSAP a ViaWise y redefinir por completo su identidad de marca.

Nota de color: una de las personas con quien trabajamos en ese proyecto fue Martín Gorricho, a quien le tengo una admiración enorme y quien años más tarde diseñó toda la identidad de una de mis empresas. Hoy, en 2021, Martín no para de tener reconocimientos internacionales por su trabajo, y me enorgullece mucho haber tenido la oportunidad de trabajar y aprender de él hace tantos años.

Sigo…. Como ya habíamos tenido buenas experiencias con Scrum durante 2004 y principios de 2005 decidimos utilizar ese marco de trabajo para esta iniciativa.

Yo me sumé como desarrollador y también asumí el rol de Product Owner. Mi objetivo principal era no volver a cometer el error que cometimos cuando nos enfocamos en el delivery. Entonces, como Product Owner me reunía periódicamente con los directores de la empresa (stakeholders) quienes me hacían llegar sus requerimientos priorizados y luego yo discutía junto al resto del equipo de desarrollo para que les demos detalle al feature, lo estimemos y finalmente sean desarrollados.

Entonces, podríamos decir que el flujo de las ideas era el siguiente:

  1. Idea de feature: stakeholders
  2. Priorización de historia de usuario: Product Owner
  3. Refinamiento de historia de usuario: Product Owner y Developers
  4. Desarrollo de historia de usuario: Developers
Ahora el objetivo era cumplir con los criterios de aceptación de las historias de usuario y entregarlas a tiempo para el Sprint Review.

ViaWise comenzó a tener un poco de tracción, pero seguía sin terminar de convencer al mercado. Había más interés, había más reuniones, pero no necesariamente se transformaban en una gran cantidad de ventas. Podríamos decir que era un producto moderadamente valorado.

Involucramiento del cliente (atención a los resultados del producto o outcomes)

Hacia 2006 teníamos una oportunidad más de hacer despegar ViaWise de una vez por todas.

La diferencia con las veces anteriores es que en esta ocasión nos acompañaría Expofrut, un cliente cercano a la empresa y dispuesto a colaborar en el desarrollo de ViaWise. Aquí sentí la gran diferencia entre lo que éramos antes (un equipo de delivery o features enfocados en el output) y lo que logramos ser en ese momento, que yo considero fue un equipo de producto orientado a outcomes.

A diferencia de las veces anteriores, yo ya no recibía una lista priorizada de pedidos de features (o historias de usuarios) de parte de los stakeholders sino un conjunto de problemas que el producto debía resolver.

La priorización de estos problemas estaba determinada por la estrategia de producto donde sí tenían influencia los directores de la empresa.

Una vez recibido cada problema, los encargados de validarlo éramos nosotros, el equipo de producto, y lo hacíamos interactuando directamente con las personas que utilizaban ViaWise en Expofrut.

Nos reunimos, los entrevistamos, hicimos prototipos en papel (confieso haber hecho alguno que otro en photoshop), y nosotros junto a los clientes definimos los features. Los resultados que los usuarios obtenían a partir de los nuevos features los medíamos en términos de uso del producto y optimización operativa. Por ejemplo: tiempo total de escaneo de pallets de un camión con doble acoplado, demora entre el cambio de turno y el primer pallet despachado, disminución de errores por escaneos defectuosos, etc.

Todo este trabajo lo hacíamos sin intervención de los directores de la empresa (stakeholders), a quienes sí manteníamos informados sobre la evolución del producto y con quienes sí medíamos el impacto en términos financieros: cantidad de ventas, rentabilidad, etc.

Esto es lo que yo creo fue crucial en las oportunidades que se abrieron para ViaWise luego de este trabajo junto a Expofrut.

Productos digitales y equipos ágiles

15 años después de esta experiencia, y habiendo pasado por muchos equipos en calidad de Agile Coach y/o consultor en desarrollo de productos, sigo recordando y promoviendo la importancia de mirar los resultados que los usuarios/consumidores obtienen de esos productos digitales construidos por los equipos Ágiles.

Hoy podría decir que veo noticias muy buenas y noticias prometedoras.

Las muy buenas son que ya hemos superado en muchas empresas el mindset de delivery. Ese mindset que está orientado a proyectos, entregables intermedios y trabajo en silos. Si bien sigue habiendo muchas organizaciones que aún están buscando salirse de ese esquema, es un escenario que, por suerte o por el gran trabajo hecho por la comunidad ágil global, muchos ya podemos identificar a un solo golpe de vista. Esto permite que al verlo podamos hacer algo al respecto.

Las prometedoras son que hay muchos equipos de features que están comenzando a ver el valor del mover su atención de la entrega de historias de usuario hacia los outcomes del producto. Para poder identificar estos movimientos de equipos de features a equipos de producto podemos listar los cambios más significativos en ciertos atributos:

  • Las features les llegaban como pedidos de stakeholders, en su lugar ahora los stakeholders les presentan problemas priorizados.
  • El product owner se encontraba limitado a la gestión del backlog y en muchas ocasiones ni siquiera tenía autonomía para determinar las prioridades. Ahora el product owner está empoderado y realiza muchas otras acciones de product management como la definición de la estrategia y la coordinación del discovery.
  • Los developers sólo tenían influencia sobre la forma de construir el producto pero no con respecto a qué construir. Ahora los developers suman la capacidad de diseño de producto y se involucran de lleno en el discovery, decidiendo no sólo cómo construir sino también cuáles son los features con los cuales experimentar soluciones.
  • Las sprint reviews eran reuniones en donde se evaluaba si el incremento construido cumple con las especificaciones de las historias de usuario, pero no indagaban acerca de resultados de producto (outcomes). Ahora son reuniones donde se tiene en cuenta múltiples factores de éxito del producto, incluyendo los outcomes y, en algunas ocasiones, los impactos también.

De todas formas, creo que aún queda mucho camino por delante para transformar las culturas ágiles orientadas a outputs hacia culturas ágiles de productos. Definitivamente es un paso más allá de mucho de lo que se ha hecho hasta ahora y lo celebro con mucho entusiasmo y ansias.