Agile puede verse solo como una técnica para acelerar el proceso de entrega de software, pero sirve para mucho más si pensamos en métricas de producto, resultado e impacto. ¡En este artículo lo explicamos!
Cursos relacionados
| Fecha | Ciudad | Curso |
|---|---|---|
| 04/03 | Curso virtual | Professional Scrum Master – Advanced (PSM-A) |
| 13/01 | Curso virtual | Professional Scrum Master (PSM) |
Primera visión de Agile: mejorar el proceso
Habitualmente se toma la creación del Agile Manifesto [3] en 2001 como el hito que da inicio al movimiento Agile. Si revisamos sus celebérrimos valores y principios, hablan de como desarrollar software de una manera más efectiva. Los aspectos en los que se hace énfasis están orientados a mejorar el proceso de desarrollo, en resumen:
- Más flexibilidad en la planificación y procesos para adaptarse mejor a las necesides del cliente.
- Comunicación más flexible y espontánea para entender antes y mejor dichas necesidades.
- Buscar y realizar cuanto antes los cambios que mejoren el producto, para hacer mejor producto y más barato.
Si pensamos como se desarrolla el software en España en 2020, con todo el error que conlleva una generalización, mayoritariamente el software se desarrolla en forma de proyectos con un alcance y presupuesto definidos inicialmente. Agile se considera principalmente una manera diferente de construir y entregar el producto, ciertamente más flexible. Pero el producto y la motivación de la inversión asociada suelen estar definidos y decididos antes de comenzar el desarrollo.
Ciclo de vida en cascada (Waterfall) vs. Ciclo de vida Iterativo e incremental (Agile). Fuente: PMI MK.
La principal crítica al Agile orientado a proceso es que los equipos Scrum corren el riesgo de convertirse en fábricas de producto (feature factories), donde no prima el uso del producto y como se atienden las necesidades del usuario, sino que se prioriza la productividad (velocity, funcionalidades entregadas, cumplir un roadmap, etc.)
Segunda visión de Agile: orientación a producto (el qué)
Agile aumentó la tasa de éxito de los proyectos. Se detectaban antes y se gestionaban mejor los riesgos, y además los productos eran más satisfactorios para los usuarios. Aún así, hay dos escenarios donde Agile ha evolucionado de manera diferente:
- Productos corporativos (B2B): en estos productos las interacciones con los “usuarios clave” pueden ser “relativamente” suficientes para entender y validar lo que necesitan los usuarios. Aún así, en grupos grandes de usuarios es difícil que estos usuarios clave representen bien a todos los demás, y que el feedback del resto de usuarios llegue a ser oido por el Equipo Scrum. En estas últimas situaciones es vital contar con métricas que ayuden al Product Owner a optimizar el uso de la aplicación y la inversión en nuevas funcionalidades.
- Productos de Internet (B2C): para este tipo de proyectos, prácticamente nadie utiliza proyectos cerrados. Entender las necesidades de los usuarios, con perfiles potencialmente numerosos y distintos, es tan difícil que la validación rápida del uso de los productos mediante experimentos y métricas, así como escuchando la opinión del usuario es imperativa.
La orientación a producto define a éste como un activo sobre el que se hacen inversiones y se espera un retorno de dicha inversión (ROI). Para maximizar este ROI es necesario que el producto:
- Ofrezca funcionalides útiles para las necesidades del usuario (efectividad).
- Sea usable y ofrezca un rendimiento adecuados (eficiencia).
- Ofrezca otros aspectos de calidad (rendimiento, seguridad, soporte a diferentes dispositivos, etc.)
Además es vital que las métricas estén alineadas con los objetivos de negocio. En el caso de los productos de Internet (B2C) es habitual basarse en el ciclo de vida del cliente para definir objetivos para el producto y las métricas asociadas. En 2007 David McClure [5] definió las Pirate Metrics (o métricas AARRR) para ayudar a optimizar los productos de las startup que acogía en su incubadora:
- Acquisition (adquisición): ¿cómo se captan los potenciales clientes al producto (web o móvil)?
- Activation (activación): ¿cuántos de los usuarios adquiridos pasan a registrarse en el producto?
- Retention (retención): ¿cuántos de los usuarios activados usan frecuentemente el producto?
- Referral (recomendación): ¿cuántos de los usuarios activos recomiendan el producto a terceros?
- Revenue (ingresos): ¿cuántos de los usuarios que recomiendan el producto, además pagan por éste?
En definitiva, en el Agile orientado a producto, se usan las métricas de producto tras los despliegues (ya sean por Sprint o por funcionalidades concretas) para optimizar el uso del producto por encima de la productividad de los equipos. En este contexto, las hojas de ruta (roadmap) pierden protagonismo, e incluso son criticados por algunos como una versión Agile de los cronogramas de proyecto (Gantt).
Ejemplo de métricas de producto asociadas al ciclo de vida del cliente (fuente: Marketo)
La principal limitación del Agile orientado a producto es que podemos tomar decisiones erróneas basadas en un uso abusivo de las métricas del producto (“Culto a los números”, como dice Kent Beck), ya que los indicadores nos dicen el “qué” hace el usuario, pero no el “por qué”. Las métricas de producto solo nos dicen indirectamente si el producto soluciona las necesidades del usuario.
Tercera visión de Agile: orientación al resultado
El movimiento del diseño de experiencias de usuario (UX Design, o frecuentemente UX) ha hecho aportaciones importantes a Agile. El UX supone aplicar la perspectiva del usuario a través de una serie de técnicas específicas a todas las actividades del diseño. Los diseñadores de UX [7] suelen trabajar en este orden:
- Primero: preguntando el POR QUÉ: qué necesidades tiene el usuario.
- Segundo: pensando en el COMO: como las funcionalidades pueden dar respuesta a las necesidades identificadas.
- Tercero: pensando en el QUE: cual debe ser la interacción, usabilidad y estética de las funcionalidades.
Los diseñadores de UX no han sido inmunes a los problemas de los proyectos predictivos (waterfall). Mucho se su trabajo se basaba en hipótesis que no se validaban con un producto y usuario reales hasta bastante tiempo después, y por ello la cantidad de retrabajo necesario era frecuentemente enorme al descubir que algunas de estas suposiciones eran incorrectas, o bien por falta de comunicación con los desarrolladores de software.
La aparición del modelo Lean Startup [8] tuvo un impacto enorme tanto en el mundo del software como del diseño. Su característica principal es iterar en pequeños ciclos para validar hipótesis respecto al producto, siempre mediante datos del producto generados por los usuarios. Jeff Gothelf y Josh Seiden crearon Lean UX [9], inspirado en Lean Startup para aplicarlo al diseño centrado en usuario (UX). A diferencia de Lean Startup, Lean UX busca un cambio en la conducta del usuario y no en métricas de producto, para los ciclos de aprendizaje. Esto orienta este modelo a la priorización de los resultados para el usuario (resultados u outcome) por encima de entregar más funcionalidades (output) que potencialmente no aporten soluciones, incluso si son muy usadas.
Las historias de usuario bien usadas proporcionan orientación al resultado.
Cuarta visión de Agile: impacto (y sostenibilidad)
Finalmente, la actividad de proporcionar productos y servicios a los clientes es sostenible cuando el intercambio de valor es recíproco.
- Si el productor no ofrece suficiente valor, el consumidor dejará de relacionarse con él.
- Si el consumidor no genera suficientes ingresos al productor, éste último dejará de realizar su actividad.
La definición de comercio como intercambio de valor. (fuente: Beck)
La definición de estas condiciones de sostenibilidad parece trivial, pero en la práctica no siempre se tiene en cuenta.
- Muchas organizaciones no saben proporcionar lo que quiere el usuario, quizás porque no miden ni dan transparencia al verdadero elementos de valor: solucionar problemas del cliente.
- Otras organizaciones creen que triunfan porque tienen ingresos, pero puede ser por una “ventaja injusta” que no se sostenga mucho tiempo, p.e. tener a los clientes cautivos o que no conozcan competidores.
- Y otras organizaciones no son internamente sostenibles, p.e. pierden su talento interno por tratar mal a sus empleados.
En definitiva, medir el beneficio interno (si queremos que sea sostenible, no se limita a medir los ingresos. Hemos de buscar otros indicadores.
Conclusión: ponemos la atención en lo que medimos
El conocido mantra de la gestión empresarial “aquello que se mide, se puede gestionar”, nos debería hacer pensar que si queremos tener una agilidad orientada a la generación de verdadero valor sostenible, deberíamos tomar un conjunto equilibrado de métricas de proceso, producto, resultados e impacto.
Y para acabar un principio aún más importante: las métricas sin contexto ni una buena interpretación, no son información que ayude a tomar decisiones: son solo datos que pueden intentar justificar sesgos u opiniones previas.
Referencias
- Kent Beck: Outcome Over Output: Also Impact and Effort
- Alex Ballarin: producto, resultado, impacto, métricas y contexto
- Agile Manifesto
- Project Mindset or Product Mindset?
- Dave McClure: Startup (Pirate) Metrics
- Jeff Patton: Output vs. Outcome & Impact (Vimeo)
- Interaction Design Foundation: What is User Experience Design
- Eric Ries: The Lean Startup
- Gothelf y Seiden: Lean UX: Designing Great Products with Agile Teams
- What is Unfair Advantage
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
