Empezar proyectos agiles “Agile Inception”

Agile Mammut
Aug 8, 2017 · 7 min read

Empezar un proyecto de software, especialmente cuando acabas de caer (te lo acaban de asignar); especialmente cuando estas en el rol de Project manager o Product Owner puede sentirse como un salto al vacío y sin RED; en particular estos proyectos se inician cuando ventas le ha dicho SI a un montón de intenciones o ideas felices entre ventas y top Management del cliente. Ese SI, esa venta se necesita aterrizar a tierra, sino se hace a tiempo será dolores de cabeza.

Y estos dolores de cabeza se pueden atajar a tiempo. Jonathan Rasmusson ha agrupado una serie de técnicas conocidas de toma de requisitos y de customer engagement en su libro Agile Samurai, esta técnica la llama Inception Deck.

Voy hablar en detalle mi experiencia utilizando este conjunto de herramientas; los pros y contras desde mi punto de vista; este conjunto de técnicas es un decálogo de ejercicios que sería una locura no llevarlas a cabo antes de empezar el proyecto; además nos obliga a poner a todos los stakeholder del proyecto en situación; aclarando todo, y haciendo las preguntas más difíciles al inicio del proyecto, que es donde se puede tomar decisiones, en el que el coste del mismo es mucho menor, que hacerlas en el transcurso del mismo. Decisiones tan importantes como el ejecutar el proyecto o no hacerlo; sin más preámbulo numero estas técnicas.

· ¿Por qué estamos aquí?

Es una especie de intro, para recordarnos quienes somos, quien es el cliente, sector del mismo, sus necesidades. Por qué decidimos empezar ese proyecto. Realmente esto todo lo hacemos al iniciar un workshop de toma de requisitos con el cliente; ciertamente lo que funciona muy bien con esta técnica, es el de pasar la batuta al cliente, que se explaye todo lo que quiera hablándonos de que es lo que quiere de este proyecto, que problemas le va a solventar; dándole la batuta nos va a empezar a resolver dos temas; el primero es que iniciamos a involucrarlo en el proyecto, que empiece a sentir el proyecto como suyo y como segundo tema, aclara a todos los participantes el objetivo del proyecto y se empieza a definir la visión del proyecto.

· Crear un Elevator Pitch

Con el ¿Por qué estamos aquí? , dejamos a nuestro cliente explayarse y ahora con elevator pitch, sintetizamos lo máximo la idea del proyecto, ayuda a traer claridad al proyecto, a definir los límites del proyecto; ya empezamos a vislumbrar el alcance del proyecto con esta técnica. Jonathan nos recomienda el siguiente template

En el workshop con el cliente, debemos llevar los deberes un hechos y realizar previamente por lo menos hasta 5, modelos del elevator pitch, no podemos esperar que la parte cliente llegue a definir un buen pitch al principio, si se lo dejamos en su terreno, se puede enquistar la actividad y perder mucho tiempo. Cuando las he realizado, juego mucho con los post it, para poder escribir al vuelo el conceso de la sala y cambiarlo tantas veces sea necesario. Una vez que estamos todos de acuerdo pasamos a

· Diseñar la caja de producto

La idea de esta herramienta es definir el producto desde la perspectiva del ciente; Jonathan la define en tres pasos.

o Brainstorm de los beneficios del producto: Simplemente preguntar 3 razones del por qué van a comprar este producto/proyecto.

o Crear el slogan

o Diseñar la caja

En mi experiencia los dos últimos pasos los saltos cuando estamos con los representantes del cliente, en algunas organizaciones este no se considera “serio. Pero los dos últimos pasos me da paso para otro punto importante en el proyecto es también conseguir el engagement del equipo de desarrollo, por lo que esta actividad la he realizado justo al inicio antes del Sprint 0/1 lo que consigue poner en el mismo barco a todo el equipo y todos sabemos a qué dirección navegar.

· Crear una “NOT LIST”

Típica sección del “out of the scope” del Project charter según PMI; el objetivo es durante el workshop definir lo que NO es parte del proyecto y acordarlo. Esta parte es complicada y delicada por una parte el equipo de ventas no quiere dejar perder el cliente y agradarlo lo máximo posible, esto esta muy bien, que el cliente se sienta el centro de todo; pero la larga esto es una de las principales fuentes de dolores de cabeza; realmente los clientes con los que he realizado workshop ven a la larga un beneficio en tener esta discusión, definir claro los límites y lo que se incluirá y lo que no se incluirá; además que salen los “unresolved” que se tendrán que discutir con el tiempo. Esta herramienta o paso es fundamental, nunca pero nunca saltársela, para no crear falsas expectativas.

· Conoce a tus vecinos

También típica identificación de stakeholder que nos dice el PMI, cobra fuerza en este ejercicio si lo realizamos durante el workshop y con todos en la misma sala; créeme que sale una lista de roles que nunca pensarías en primer lugar, y por supuesto esta lista está viva y se tiene que revisar con periodicidad.

· Muestra la solución

Presenta y discute en workshop tu propuesta inicial, muestra todo lo que puedas desde un diagrama de arquitectura de la solución hasta donde crees que van a quedar los botones. Pero sin abusar, todo lo que muestra es para un objeto, como por ejemplo muestra la arquitectura de la infraestructura de la solución, es para empezar a descubrir por ejemplo, si están de acuerdo en que el entorno que se ejecute sea Jboss o un Weblogic, que la BBDD sea Oracle o MongoDB, o les da igual.

No te enfoques en los detalles, presenta todo a muy grandes rasgos; muestra todos los themes y algunos Epics que van a componer tu Backlog de producto.

· Pregunta que nos quita el sueño

Aquí lo que se debe hablar es de los riesgos que vemos en el proyecto; es un muy buen ejercicio el darle a cada miembro que participa en el workshop un taco de postit, y que vayan escribiendo riesgos que ven en el proyecto; hacer unas rondas d brainstorming; solo hablar de los riesgos, no de como mitigarlos.

· Dar la dimensión

Decir a muy alto nivel lo que puede llevar hacer el proyecto; no se trata de dar una estimación, se trata de dar una dimensión, hablar de 2 meses 5 meses, 1 año. Esto ayuda a gestionar las expectativas de lo que puede ser el proyecto, y tener a toda la audiencia del workshop con la idea clara del esfuerzo y tiempo. Aclarar que no es una estimación, pero por lo menos salir del workshop con la sensación de entender el coste y dimensión del proyecto.

· Sé claro con lo que vas a dar. Trade-off Sliders

De esto va Agile, si Agile es flexible en el proceso de change Request incluyendo continuo feedback de los stakeholder a través de las demos y priorizado con por el product Owner; en este punto se tiene que aclarar en donde el proyecto tiene flexibilidad, como por ejemplo si aumentamos el Scope, podemos aumentar el presupuesto? O el Go-Live?.

Por lo que tienes que acordar con el cliente en por donde puedes jugar. La idea es que expliques al cliente el concepto de trade-off sliders (ver imagen), y con esta imagen darles a entender en donde puedes jugar para llevar el proyecto a buen puerto.

· Muestra lo que os va a llevar

Ya habéis dado una dimensión del proyecto, en este punto se debe resumir y mostrar a alto nivel, coste, tiempo y el equipo necesario para cumplir con el proyecto, pese a que el equipo de ventas haya llegado a ciertos compromisos, hay que dar y aclarar la flexibilidad (trade-off sliders) del proyecto. Toda esta información, genera una empatía con los que tienen que construir y entregar el proyecto; además como tener un sentimiento de pertenecía ya que han sido consultados y han estado en la definición del proyecto.

No he comentado anteriormente que Jonathan nos aconseja que este workshop estemos todos los stakeholder a lo largo de un periodo de tiempo, desde un par de días a semanas, alrededor de la misma sala, en muchos casos por el coste, el tiempo y la disponibilidad de los clientes, o la inmersión ágil que tiene el cliente, esta técnicas de inception deck pueden o no ser factible; lo de firmar un documento de requisitos de 1000 páginas y que nadie lee, poco a poco hay que romper esta resistencia y adoptar técnicas que nos dé un acercamiento, compromiso y sobretodo pertenencia al proyecto.

Agile Mammut

Written by

Agilismo, scrum y Product ownership

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade