Incepción Ágil: la pregunta del millón

¡Llegamos a la última actividad de la Incepción!

¿Parece largo? En realidad muchas de las actividades pueden regularse para que avancen rápido ó podemos llegar a saltear algunas si tenemos menos tiempo. Eso es parte de la decisión del facilitador. Mi recomendación es tratar de recorrer las 10 actividades, aunque sea dedicándole 20 a 30 minutos en promedio a cada una, para que entre en una mañana o una tarde.

En la última actividad vamos a tratar de tener una estimación de MUY alto nivel sobre el costo del proyecto. Casi nunca llegamos a un número, sino a un nivel de inversión, como para responder dudas como (dependiendo del tipo de proyecto y organización):

• ¿Podemos encarar esto con el presupuesto que ya teníamos?
• ¿Necesitamos conseguir un inversor?
• ¿Qué chances hay de que el proyecto se auto-financie a partir de X entrega?
• ¿Hace falta conseguir aprobación presupuestaria del Gerente del Área? ¿Del Directorio?

Para poder llegar a alguna conclusión de ese tipo, lo que hacemos en grupos es una "lista de compras", en la que incluimos todos los costos importantes que pueden incidir, como:

• Costo del equipo (si son internos y tenemos que costearlos, o si debemos contratar)
• Equipamiento, espacio físico, licencias de software, suscripciones
• Homologaciones, certificación o auditorías necesarias
• Espacio físico o instalaciones necesarias durante el proyecto

Nuevamente, cada grupo presenta su lista, y se discute en conjunto hasta lograr una versión unificada. No es importante ponerle valores, más allá de una estimación muy gruesa para llegar a entender el nivel de presupuesto, pero esa lista será el punto de partida para empezar a elaborar el presupuesto definitivo cuando el proyecto arranque realmente.

Y con eso finalizamos el proceso de la Incepción. Dejo una foto de otro taller. 

Incepción Ágil: hablemos de prioridades

Como mencionamos antes, sabemos que nuestra Incepción va a darnos una idea general, pero que el proyecto va a ir mutando y adaptándose en el tiempo para lograr el mejor resultado posible.

Si embargo, podemos tratar de seleccionar algunas restricciones tempranas que nos ayuden a pensar si los cambios o novedades que aparezcan nos están alejando o no de la idea inicial. Y podremos en ese momento decidir que no es un problema, o incluso re-evaluar estas prioridades, pero lo bueno es tener más elementos para evaluar esas decisiones.

Para esta actividad los equipos se dividen en grupos nuevamente y piensan en una lista de requisitos no-funcionales o preocupaciones transversales al proyecto, como por ejemplo:

• Costo de operación del producto final
• Mantenibilidad
• Time-to-market (cuanto antes tengamos algo, mejor)
• Interoperabilidad
• Equipo propio (o local)
• Seguridad o Confidencialidad
• Tiempo de respuesta
• Cumplimiento de regulaciones
• Cobertura desde múltiples dispositivos

...o muchos otros, desde características de calidad, temas de mercado, cuestiones internas o lo que nos preocupe.

Lo importante es que cada grupo quede con los 5 a 10 temas que les parecen más importantes tener en cuenta.

El siguiente paso es priorizarlos. Para eso prefiero una variante que aprendí de Alan y Ariel, que es seleccionar entre todos los que queremos priorizar, y a continuación elegir un participante por cada uno de los atributos a priorizar, que se pone de pie con una hoja de papel en la mano con el nombre de ese atributo. Esas personas se ponen en fila, y el resto, mirándolos de lado, de manera de verlos a todos, va intercalando con ellos, haciendo que se muevan hacia adelante o atrás en la fila, hasta que llegamos a un acuerdo.

Idealmente, al llegar al orden final, tomamos una foto de todos sosteniendo su cartel bien visible.

Esta actividad es más divertida con ese componente físico, y tiene también el valor testimonial de la foto con mucha gente involucrada, que perdura y queda para el equipo de proyecto. Muchas veces al ver las personas que participaron en esa priorización el mensaje es reforzado.

Insisto: esas prioridades no son inamovibles, pero tenerlas como filtro nos permite tener las discusiones necesarias a tiempo, y nos da contexto.

Incepción Ágil: estimación global

Ahora que ya tenemos una idea general del alcance, el tipo de solución a construir, y los riesgos principales que anticipamos, podemos empezar a pensar qué tan grande será el proyecto.

Nuevamente dividimos equipos (recordemos que lo ideal es combinar gente diferente a lo largo de la Incepción) y cada grupo hace una estimación de alto nivel, teniendo en cuenta:

• ¿Cuánta gente necesitamos en el equipo? ¿Cómo debería estar compuesto?
• Si vamos a ejecutar con Scrum, podemos pensar quienes serían el Scrum Master y el Product Owner
• Dado ese equipo que imaginamos ¿Cuánto tiempo duraría el proyecto?

Aquí cabe una aclaración: el equipo final deberá revisar la estimación, pero como estamos pensando un proyecto ágil, lo importante es que sabemos que en el tiempo que pensemos no esperamos resolver necesariamente todo el alcance, si no lo más valioso del alcance, por lo que aceptamos que no sabemos el detalle total. Es importante que todos los participantes comprendan que no están tomando una decisión, sino realizando un ejercicio para analizar lo que el proyecto implica. 

• Podemos pensar alternativas de equipos y fases, e incluso alternativas de solución, para diferentes extensiones de proyecto.

Al finalizar, y una vez que cada grupo expuso su estimación, se discuten y seleccionan las mejores alternativas, para usarlas como referencia, y probablemente tomemos un márgen de unas a otras.

El objetivo que buscamos es tener un rango general:

• ¿será un solo equipo de 5~6 personas?
• ¿serán 4 equipos de 8~9?
• ¿podemos tener resultados en 6 semanas, 6 meses, 2 años?
• ¿tenemos una idea al menos general de qué es lo más valioso resolver en cada etapa?

Aunque suene insistente, esto nos sirve para discutir si el proyecto es viable o no según estos parámetros, y eventualmente revisar algunos de los ejercicios anteriores. Como esto es una Incepción Ágil, sabemos que todo va a tener variaciones cuando el proyecto comience, y sobre todo cuando se entreguen los primeros resultados y el proceso de aprendizaje se potencie.

Incepción Ágil: manejo de riesgos

Llegamos a la actividad de la Incepción donde nos dividimos en grupos y nos ponemos todos el sombrero negro, pensando en todo lo que puede salir mal.

Trataremos de discutir todo lo que potencialmente podría quitarnos el sueño durante el proyecto, desde todos los puntos de vista. La gente de tecnología aportará riesgos de conocimiento del equipo, de complejidad tecnológica, de requisitos difíciles por distintos temas; la gente de seguridad pensará en las vulnerabilidades, potenciales brechas, criticidad de datos; la gente de negocio analizará costos, oportunidades, dependencias con otras áreas, necesidad de flexibilidad; y así diferentes actores expondrán miedos respecto al inicio, desarrollo, puesta en marcha, ejecución, mantenimiento y evolución del proyecto.

Al finalizar, cada grupo comparte los resultados y volvemos a tener una discusión abierta en la que tratamos de consensuar cuáles son los principales problema potenciales, y anotamos algunas de las medidas con las que podríamos mitigarlos.

 

Incepción Ágil: ¿y entonces qué hacemos?

Esta actividad de la Incepción se puede realizar en grupos si tenemos gente con buena visión técnica como para ayudar en conceptualizar la solución a desarrollar.

Cuando digo "técnica" me refiero al punto de vista de lo que vamos a construir (si es un sistema, un arquitecto o líder técnico; si es de marketing o publicidad, un diseñador o experto en campañas; si es un proceso, alguien experto en ese área).

Si en la audiencia contamos con una sola persona con esas características, podemos realizar esta actividad todos juntos. La idea es que en grupo, y con la ayuda del experto, analizamos el tipo de solución a construir, a muy alto nivel.

Como la mayoría de los lectores de este blog están vinculados al software, tomemos un ejemplo de ese mundo, y supongamos que el equipo elabora un clásico diagrama de componentes, indicando que va a haber un servidor web, que hablará con una aplicación existente, que conecta con tales bases de datos e integra los servicios X, Y y Z...

Tal vez aparezcan detalles de seguridad, o se sugiera mover algo a una nube, o utilizar algún tipo de tecnología, y lo importante de exponerlo ante todos es que surjan dudas como:

• ¿Y eso funciona en un Iphone?
• No se si conviene conectar con Siebel... eso quiere decir que si el proyecto del CRM se demora, nosotros también
• Antes de poner esos datos en la nube, deberíamos consultar con legales ¿Podemos dejar eso en una base local y mover lo demás?
• Creo que en el proyecto ZYX ya resolvieron esa interconexión ¿podemos pedirles ayuda?

Como antes, no buscamos que este diagrama o visión sea definitiva. Queremos explicar algunos detalles de cómo sería el proyecto para que la gente de otras áreas, técnicas, de negocio o administrativas, vean de qué se trata y comenten cualquier problema o relación que no hayamos tenido en cuenta.