Hoy en día el desarrollo ágil de software está de moda. Cuando algo se pone de moda siempre salta el debate entre los que llevan mucho tiempo y los que se suben a la ola. Una analogía podría ser la fórmula 1 con Fernando Alonso.
Había quien llevaba años vibrando con las carreras y otros como yo que nos pusimos a verlo porque había un español que ganaba. Personalmente, no creo que los que lleven más tiempo tengan un derecho moral sobre los nuevos. Ni dividiría entre antiguos y “aprovechados de la ola”, sin embargo, sí que dividiría entre quienes hacen bien las cosas y los que no.
El otro efecto colateral de las modas es que se introduce mucho dinero y eso hace que se perviertan los valores y la esencia. La formula1 es un mundo de mucho dinero, que se ponga de moda no pervierte su esencia. Sin embargo, el desarrollo ágil habla de valores y de principios y cuando entra el dinero empezamos a chocar. Pongamos algunos ejemplos:
Sprint 0 o Iteration 0
El Sprint 0 lo podemos encontrar en multitud de referencias y de libros. La guía de Scrum no lo reconoce. El motivo es que la esencia de Scrum se basa en la inspección y la adaptación y el Sprint 0 se asocia a una “fase de análisis”, al que podemos seguir con Sprints de “desarrollo”. Sin embargo, he visto Sprints 0 en los que se trataba de aterrizar la idea que tiene el cliente de cara a saber qué queremos hacer. Generalmente estos Sprint 0 tenían prácticas que nacieron del desarrollo ágil como el Inception o el User Story Mapping por lo que no siendo Scrum, puede ayudar mucho al inicio.
El problema con el nombre “Sprint 0” es que el concepto de “sprint” sí está definido en Scrum. Un Sprint debe ser una entrega de valor y entregar un backlog o un prototipo no se considera valor. Si hacemos software, un periodo de tiempo donde lo que entregamos documentación no podemos considerarlo valor. Todo esto genera mucha controversia, hay quién trata de justificar que un backlog si es valor para un cliente porque de alguna manera le aportas. Para mí, hay que discernir entre útil y que sea valor. Un sprint 0 puede ser útil porque nos dé información pero ningún usuario paga por el resultado del Sprint 0, pagan por el software que se hace a continuación. ¿Alguien se preocupó alguna vez por el análisis funcional del Microsoft Word?
El debate
Debatir este tipo de cuestiones a mi siempre me ha gustado, sacamos a la persona que tenemos dentro. El problema es cuando los debates acaban con una de estas dos frases: “Es que lo entiende el cliente” o “Es que se vende”.
Si un cliente no lo entiende, entonces envía a la venta a un Agile Coach. Las empresas que transforman con mejores referencias utilizan a los Agile Coach como comerciales. Un buen Agile Coach va a detectar en una conversación de venta si de verdad hay ánimo por cambiar, es todo postureo por una moda que ha llegado o intentar conseguir una bala de plata que soluciones fácilmente los problemas.
En cuanto al argumento “esto se vende”. Si hacemos cosas en función de lo que se puede vender, difícilmente crearemos un impacto en el cliente donde entienda el cambio de verdad. Nuestra imagen como organización será cuestionada si solo nos centramos en los que se puede vender porque el mercado aún está anquilosado en el modelo tradicional. Es normal que un Sprint 0 se pueda vender si el cliente lo interpreta como la fase de toma de requisitos de siempre pero con post-it de colores y dinámicas.
Antes de seguir, me gustaría hacer una aclaración. Si nos centramos solo en vender desarrollo ágil, entonces posiblemente vendamos poco o menos de lo que necesitamos para los objetivos empresariales. En estos casos, propongo ser honestos y tener equipos Scrum que construyan productos digitales y equipos de proyecto tradicionales que tengan alguna práctica ágil o partes de Scrum que les ayude. De esta manera, le ofreces a un cliente las dos opciones y que él decida. No todos los clientes van a querer trabajar en el modo producto de entrega de valor, pero al menos eres honesto con tu cliente y con tus empleados.
Todo es Scrum a partir de ahora
El problema es cuando todo tiene que ser Scrum porque es la moda y tapamos las carencias con mensajes de marketing. Scrum no tiene escala de grises: o lo haces o no lo haces. Y esto es un gran problema porque muchos creen que haciendo Daily Scrum y retrospectivas con post-it ya es suficiente. Sinceramente, hasta hace no mucho yo también lo creía, es cuestión de ir aprendiendo y madurando.
Otro ejemplo de moda ocurre con las Transformaciones Digitales. Para mí, una transformación une negocio, tecnología, agilidad y cultura. Las empresas tradicionales que solo sabían hacer proyectos tuvieron que adaptarse al cambio. Podían haber interiorizado lo que es ser ágil, construir productos basados en valor mediante la inspección y la adaptación. Sin embargo, muchas optaron por decirle a sus clientes que la transformación digital se abordaba con un cambio tecnológico a base de proyectos cerrados. De esta manera, se aseguran que venden lo que saben hacer, pero con tecnologías más actuales. Ahora, el cliente podía anunciar que se estaban transformando digitalmente y la consultora propagar que lo estaba transformando, es un win-win claro para todos, salvo para la honestidad.
¿Dónde quedan entonces los productos digitales construidos mediante el feedback continuo del mercado?
Hay otras organizaciones que han decidido entrar en la venta del cambio cultural, pero en forma de proyectos una vez más. ¡Por qué es lo que saben hacer! Creamos Sprint 0 de transformación, ponemos fechas, hitos, entregables y nos olvidamos de la inspección y la adaptación. Si queremos afrontar la transformación cultural en base a lo que hemos hecho siempre, difícilmente superaremos los retos que se presentan. Tu equipo de transformación tiene que ser un ejemplo de cómo serán los equipos de producto que quieres tener en tu cliente.
Camuflando el modelo tradicional con la palabra “agile”
Otro ejemplo de moda es utilizar herramientas de otros mundos como las propuestas del Project Management Institute (PMI) y ponerle la palabra Agile delante para colarlas en la moda. Por ejemplo, la técnica de Valor Ganado es la manera en que el PMI propone para medir el estado de los proyectos. He visto a empresas añadirle la palabra Agile e incluirlo en una formación como algo novedoso. La técnica en sí no tiene nada malo, pero no hay que añadir el adjetivo Agile a todo por moda.
Por último, algo parecido está ocurriendo con las herramientas. Precisamente el desarrollo ágil habla de personas por encima de herramientas y procesos y en muchos sitios encuentras un Jira como si eso lo convirtieran en desarrollo ágil. Jira, según cómo se use, puede dar soporte y ayudar a la autoorganización, o puede ser una manera de controlar a los equipos. Por ejemplo, si un equipo no puede decidir cómo usar su tablero, difícilmente la autoorganización aparecerá. Es esencial dar la libertad para que los equipos maduren y busquen caminos para ser mejores.
Esta está siendo mi experiencia de los clientes en los que he podido trabajar y aprender. Creo que tenemos que aprender a ser más ágiles todos y a poner menos el foco en cómo venderlo. Cada vez que voy a un evento sobre agilidad, me siento pequeño rodeado de tanto talento y mola porque siempre pienso “cuánto camino me queda por recorrer”. No paréis de aprender y dedicar menos a aparentar, esa es la clave.
