Es muy común pensar en agilidad y asociar su inicio con la creación del Manifiesto Ágil para el desarrollo ágil de software a principios del 2000. Esto no es correcto, ya que la agilidad existía mucho antes de la aparición del manifiesto.
A continuación, y sin entrar demasiado en detalle, te voy a contar rápidamente de dónde viene esto de la agilidad y cómo ha ido evolucionando a lo largo de los años… ¡Sigue leyendo!
Un poco de historia
Muchos consideran el TPS (Toyota Production System) como el padre de la agilidad ya que esta deriva en gran medida del movimiento Lean que empezó usando Toyota en sus fábricas tras la Segunda Guerra Mundial.
Si nos centramos únicamente en el desarrollo de software, la historia tardaría aún unas décadas en traer la agilidad a nuestras vidas. Allá por 1970 el desarrollo de software se basaba en el modelo de cascada.
Todo estaba calculado y planificado como un proceso industrial en el que apenas existía incertidumbre, se controlaban los costes minuciosamente y se obedecía a lo planificado. Era al final de esa planificación cuando el usuario recibía su producto.
Este modelo de desarrollo de software implicaba grandes bloques de código (monolitos) con una escalabilidad y evolución ligada a elevados costes.
Vamos, que se hacían para que no tuvieran cambios muy profundos durante muchos años.
No fue hasta la década de los 90 y la llegada de internet cuando ese modelo empezó a ser cuestionado de una forma global por la comunidad de desarrolladores. Ya no tenía sentido un modelo donde los plazos de entrega fueran tan largos, cambiar las condiciones de entrega era un gran problema o lo peor de todo: cuando se entregaba el producto al usuario, ya no lo quería o necesitaba.
Surgieron métodos como RAD (Rapid Application Development) en 1991, UP (Unified Process) y DSDM (Dynamic Systems Development Method) en 1994, SCRUM en 1995, Crystal Clear y XP(Extreme Programming) en 1996 y FDD (Feature-Driven Development) en 1997.
Han pasado casi 22 años desde que Kent Beck y 16 compañeros más que desarrollaban software, se reunieron para tratar de encontrar un consenso que se alejara del modelo waterfall y que se materializara en un manifiesto firmado por todos los asistentes: Manifiesto para el desarrollo ágil de software (2001)
Desde el nacimiento de la agilidad nos ha dado tiempo a todo… Han surgido infinidad de frameworks bajo su paraguas, han surgido haters y detractores por doquier y como no podía ser de otra forma hay mucha gente que tiene formado un buen batiburrillo en la cabeza.
Durante todos estos años ha sido exponencial el crecimiento del número de empresas que se han lanzado a desarrollar software. Esto ha hecho que muchas de ellas adopten la agilidad como si fuera un manual mágico que seguir para poder desarrollar software rápidamente, sin encontrar problemas y encima se pueden poner la etiqueta de “We love Agile”.
Si esto te suena es porque ya has sufrido en tus propias carnes lo que significa aplicar en tu empresa cualquiera de estos frameworks al pie de la letra y volverte loco porque no se entrega valor a los usuarios. Si no te suena estamos a tiempo de aclararte que los frameworks ágiles son un medio y no un fin.
Entremos en materia
Antes de nada es necesario aclarar que la agilidad no siempre es la mejor opción para la fabricación de cualquier producto tecnológico. Dependiendo del contexto puede ser mucho más recomendable optar por otro tipo de desarrollo. Algunos ejemplos pueden ser:
- Procesos de fabricación altamente regulados: Si el proceso de fabricación está altamente regulado y requiere un seguimiento estricto de los procedimientos y las normativas, la Agilidad puede no ser la mejor opción.
- Proyectos con requisitos muy específicos y poco cambiantes: Si los requisitos del proyecto son claros y no cambian con frecuencia, la Agilidad puede ser menos útil que un enfoque más tradicional y planificado.
Para poder desarrollar un producto en un entorno ágil es necesario crear primero el contexto adecuado. No es suficiente con aplicar el manual del framework al pie de la letra y esperar que todo empiece a funcionar por arte de magia.
Conlleva una transformación mucho más profunda en la que se debe involucrar a toda la compañía tanto culturalmente como organizacionalmente. Los principales factores que una empresa debería tener en cuenta para poder abrazar la agilidad serían:
1. Equipo colaborativo: Un equipo que trabaje juntos hacia un objetivo común. Todo el equipo debe estar comprometido para intentar lograr los objetivos establecidos.
2. Comunicación efectiva: La comunicación continua y transparente es esencial en un enfoque ágil. De nada sirve si cada equipo trabaja en “lo suyo” y no le interesa lo más mínimo el trabajo del resto de equipos.
3. Enfoque en valor: La entrega continua de valor al cliente es fundamental en metodologías ágiles. Es imprescindible no perder el foco en la entrega de valor. Recuerda que queremos entregar outcomes y no outputs.
4. Flexibilidad y adaptabilidad: La capacidad de adaptarse a los cambios y ajustar el plan en consecuencia es crucial. Los cambios son bien recibidos.
5. Uso de herramientas y tecnologías adecuadas: Las herramientas y tecnologías adecuadas facilitan la colaboración y la comunicación en el equipo. La empresa debe crear un contexto cultural y tecnológico que favorezca la comunicación de toda la compañía a todos los niveles.
6. Liderazgo y compromiso: Un liderazgo fuerte y un compromiso por parte de todos los miembros del equipo son esenciales para el éxito. Es muy común encontrar compañías donde la agilidad deja de ser el vehículo que lleva a objetivos.
No es raro que una empresa, para empezar a desarrollar todos sus productos bajo un framework ágil, comience a aplicar al pie de la letra el manual esperando que así todo cambie de un día para otro.
Esto puede llevarnos a un escenario en el que “somos super ágiles” porque hacemos sprints, todas las ceremonias habidas y por haber, utilizamos todas las herramientas típicas del framework peeeero NO TENEMOS UN OBJETIVO. Vamos como pollo sin cabeza aplicando a pies juntillas todo lo que dice nuestro manual de agilidad pero no funciona. No entregamos algo que nuestros usuarios quieran o estén dispuestos a pagar por ello. Tendremos el mismo resultado en grandes empresas, pero añadiendo la complejidad que supone escalar la agilidad a muchos más squads y un producto mucho más grande.
De hecho es muy probable que bajo la máscara de la agilidad se encuentre nuestro viejo amigo waterfall…
La agilidad no vale de nada si realmente no sabemos hacia dónde vamos. Necesitamos tener muy claro cuál es nuestro objetivo. Por supuesto, sobra decir que no vale que nuestro objetivo sea entregar muy rápido en cada sprint si carecemos de un objetivo que entregue valor.
Sin darnos cuenta, habremos iniciado un camino lleno de reproches y frustración porque nadie comprende por qué, si somos tan ágiles, nuestro producto no es el esperado por los usuarios. En ese momento podéis ir diciendo a vuestro CEO que se va a empezar a quemar mucho dinero sin esperar ningún retorno. En ese momento la agilidad se habrá convertido en el fin y no en el medio. Es por este motivo por lo que la agilidad debe ser siempre el medio y nunca el fin.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
¿Cómo solucionarlo?
Los cambios han de venir desde la base, la médula espinal, la razón de ser de tu producto. Necesitas tener muy claros los objetivos de tus productos. Recuerda, deben ser objetivos que respondan a la visión que tienes de tu producto. Ese pain o necesidad que solucionas a los usuarios.
Haciendo un breve repaso por dos de los frameworks más utilizados, como son Scrum y Kanban, podemos observar cómo en ambos, uno de sus principales principios es la entrega de valor al usuario. Los objetivos deben siempre estar enfocados en esa dirección.
Para grandes compañías con un amplio porfolio de productos siempre me inclino por utilizar OKRs para conseguir un alineamiento de todas las verticales y productos. Como ya sabréis, Google comenzó a utilizar este método en 1999 (por cierto, inventado por Intel) que a día de hoy se ha extendido a grandes y medianas empresas.
Sin entrar mucho en detalles podemos decir que consiste en dos pilares básicos:
1 - los objetivos (O) deben ser ambiciosos e inspiracionales
(ojo → no deben ser cuantificables ni estar acotados en el tiempo)
2 - los resultados clave (KR) que ahora sí deben ser cuantificables y acotados en el tiempo (normalmente trimestres). Ellos nos dirán si hemos alcanzado el éxito o no.
Cabe destacar que estos objetivos deben ser inicialmente establecidos por la directiva de la empresa para poder marcar la estrategia que seguirán durante el próximo año (OKRs estratégicos).
Estos objetivos de negocio darán a Producto las bases para marcar sus propios OKRs trimestrales que deberán mover para conseguir los objetivos marcados por la directiva.
Conclusión
No hace mucho, leí una publicación de Pawel Huryn en el que comentaba que el Manifiesto Agile está muerto. Argumentaba que esta tremenda afirmación se debía a que en el fondo tenía un tinte de proyecto y animaba a realizar una verdadera agilidad adoptando una cultura de producto donde se mida el impacto, donde se busque el compromiso de todo el equipo, donde se priorice el valor al usuario sobre el valor para negocio…
Esto, sin duda, nos acerca mucho al manifiesto que de verdad apunta a producto y que sienta las bases del camino que debe llevar el desarrollo de productos: el Manifiesto Ágil de Producto.
Ojo, con estas líneas no quiero decirte que repudies el Manifiesto Agile. Solo quiero dejarte claro que hoy en día puedes abrazar diferentes frameworks para hacer producto con muy buenos resultados siempre y cuando tengas muy claro a dónde quieres ir.
Y sino tienes muy claro a dónde quieres o dónde va tu equipo de producto en tu empresa, ¡charlemos y vemos cómo os podemos ayudar!
Para aprender más, descarga nuestro libro Las Claves del Product Management
Foto de Brendan Church en Unsplash
