En su libro "Inspired, how to create tech products consumers love", Marty Cagan comenta que las compañías que realmente destacan en cuanto a productos tecnológicos saben que deben asegurar una innovación consistente de sus productos. Básicamente esto significa estar creando constantemente nuevo valor, tanto para sus clientes como para su negocio.
Sin embargo, poder lograr llegar a un ciclo donde la innovación sea aquello alrededor de lo cual gire, respire y camine una organización, no es cosa fácil. Incluso para los equipos de desarrollo de tecnología que puedan pertenecer a las organizaciones. Es muy fácil entrar en un ciclo tanto de puro mantenimiento con mejoras y retoques a lo ya establecido, o peor aún, en la falacia de decirse ágiles sin serlo, construyendo soluciones que no entregan valor por mucho trabajo que impliquen.
De hecho, como lo ilustra el autor en su libro, el gran problema viene de que, por muchos procesos ágiles que implemente un equipo de ingeniería y desarrollo de tecnología, la realidad es que el proceso en general que la organización sigue para llegar a un producto, es la temida y extremadamente lenta cascada...
Desde que se genera una idea, hasta que se aprueba, se planea, se desglosa, se diseña y ahora si se comienza a construir ("ágilmente", decimos), y luego se prueba, lanza y por fin llega a un usuario final, pueden pasar tantas cosas, que lo más seguro es que el producto fracase. No lo digo yo, lo dicen años de experiencia de tantos creadores de tecnología: la cascada es la peor metodología para llegar a un producto terminado y exitoso si lo que se pretende es ser también innovador (y hoy en día por lo tanto también, ganador).
Y el tema aquí no es problema de que el equipo intentando ser ágil no lo esté haciendo bien. Es que la organización en que se enmarca, sólo ve agilidad en la "entrega" del producto final que desea, en lugar de que en sí misma se vuelva ágil para la creación y entrega de innovación.
Sin embargo, los mismos equipos también caen en vicios o falacias, ante los cuales es bueno siempre estar en guardia.
- Sobrevalor a los roadmaps
En primer lugar, sobrevalorar los planes estableidos. Sea un roadmap o un simple desglose de tareas y pendientes organizado por fechas de entrega, muchas veces nos "enamoramos" de la solución que proponemos ante el problema, y nos enfocamos en poner manos a la obra para terminarlo. Por muchos sprints bajo los que ejecutemos esto, si nos atenemos al roadmap, al plan, y no abrimos los ojos de vez en vez hacia nuestros usuarios, posiblemente al "terminar" el plan, nos topemos con un escenario nada agradable, en completo desacuerdo con lo que al principio creíamos que sería al llegar.
- El enfoque incorrecto
Para organizar trabajo y llevarlo a cabo, solemos meternos en un ciclo clave para cumplir un hito: un Proyecto. Nos decimos que llevamos a cabo el proyecto para construir un producto. El problema no es plantear un proyecto para cumplir los hitos. El problema es enfocarnos en la salida que esperamos obtener al final: el proyecto cumplido, en lugar de hacerlo en el resultado que buscamos: el producto. Y de nuevo, nos enamoramos por 1, 3 o 6 meses con el proyecto, la solución que nos planteamos, en lugar de mantenernos enamorados con el producto que queremos construir.
Esta "ceguera de taller" nos puede provocar que, por ejemplo, nos atengamos al proyecto, en lugar de estar dispuestos hasta a arrugar el papel del proyecto y tirarlo al bote de basura, para volver a empezar, con tal de mantener el enfoque que en verdad importa: no el output (el proyecto terminado) sino el resultado (el producto que construimos).
Si al final lanzáramos algo (la salida del proyecto) pero esto no cumple los objetivos, ¿para qué esforzarnos en construirlo?
- Validación con usuarios... demasiado tarde
Si alguna vez has manejado en tráfico, usando alguna app de tráfico, un Waze por ejemplo. Quizá planeas tu ruta desde un principio, pero ¿qué pasaría si a medio trayecto la aplicación no te notifica que ocurrió algún accidente a medio camino y deberías cambiar tu ruta? Sucederá que te verás en medio de un congestionamiento, y posiblemente prefieras no volver a usar la aplicación, no sirve para nada.
Mientras creamos un producto, de eso se trata la validación con usuarios. Podríamos ir con ellos al principio para aclarar qué vamos a construir, construirlo con base en nuestro fabuloso plan, y al final volver a reunirnos para entregarle. Igual podríamos pensar que esto es un buen camino a seguir, pero en realidad es todo lo contrario.
En un verdadero ciclo ÁGIL de desarrollo, vamos a tocar base con el usuario CADA VEZ QUE PODAMOS. Porque si, como con el tráfico, sucede un "accidente" que nos va a meter en un congestionamiento, preferiríamos poder evitarlo cuanto antes, ¿cierto?
ÁGILES
Ser ágiles no es labor únicamente de un equipo exclusivo del proceso, sino de toda la organización
De esa forma, los riesgos que haya que afrontar, se atacan desde el principio (no al final una vez que el producto ha sido construido).
Toda la ideación, concepción y diseño, surgen colaborativamente, pues todos están inmiscuidos en lograr una mejor visión del producto a construir, sin esperar a que sea "su turno" de intervenir en el proceso.
Con estas ideas, podemos cambiar la visión y el objetivo, no se trata de implementar características a un producto en construcción, sino de resolver problemas REALES de los usuarios para los que el producto será la solución.