Agile inception

Esta semana he hecho dos incepciones ágiles para dos proyectos muy diferentes. Para el que no sepa qué es una incepción, probablemente lo pueda resumir como “una receta para una reunión de trabajo donde las personas implicadas en la elaboración de un producto definen juntos las expectativas del mismo”.

Me gustaría hacer hincapié en el hecho de que el objetivo final de la incepción es llegar a un punto de acuerdo sobre las expectativas del producto que hay que construir. El producto puede ser desde software hasta una silla de madera, eso es lo de menos, lo realmente importante es que todos los que están en la reunión son los que van a construir esa silla de madera, además de los que se van a sentar en ella, los que la van a vender, los que la van a comprar y cualquier otro intermediario. (En un escenario ideal, claro).

Esta semana he hecho una para arrancar un proyecto para el que ya se había hecho una consultoría previa y en la cuál no estaba el cliente ni el usuario final. Eso nos obligó a imaginar mucho sobre los personajes relacionados con el producto. Pero también me obligó a trabajar mucho, como facilitador de la incepción, en tratar de evitar que esa consultoría nos influyera demasiado en la averiguación conjunta de cuál debe ser el plan iterativo e incremental que el equipo debe seguir.

En la otra incepción, el escenario era diferente, aunque quizás no tanto. Se trataba de un producto cuya construcción se ha atascado y no son capaces de poner en producción. Como detectamos que había una discrepancia fuerte entre lo que se entendía que era el producto, planteé esta incepción. Pero durante la sesión fueron saliendo que las discrepancias son muy de fondo. Trabajamos mucho, mucho, mucho en qué no hace el producto y nos centramos sólo en un personaje para tratar de construir el plan para el MVP (Minimum Viable Product) y permitir que construyan sobre él. Wow! Eso costó. Creo, sin embargo, que mereció la pena, aunque sólo el tiempo lo dirá.

Como resumen:

La incepción es una poderosa herramienta si se usa con sabiduría.

Perdón por la pedantería, pero en la práctica he comprobado que no es una receta “for dummies” porque requiere de mucha mano derecha para avanzar y mucha mano izquierda para ayudar a que salgan las discrepancias que permiten avanzar con seguridad. Es una herramienta que puede crear la falsa sensación de tener un buen plan pero, si no se ha sido honesto, puede haber dejado riesgos latentes; o si no se ha contado con todas las personas necesarias (porque es una reunión muy cara) haber construido una imagen falsa del producto.

Esto me recuerda eso de:

Individuos e interacciones sobre procesos y herramientas

P.S.
Si hubiera querido ser psicólogo habría estudiado psicología. 😉

  • Jajaja, lo de la psicología no irá por la mejor charla de la CAS2011, verdad?? 🙂
    Un psicologo creo que no podría ponerse a planificar un producto 🙂 pero para crear la Visión Compartida, muchas veces necesitamos sabiduría que no es de lo que comunmente se llama ingeniería informática.
    Y también pienso como tu último párrafo. Crear la visión compartida es como tener una idea,… sin una buena implementación, no sirve de nada 🙂