Recorrido por las 10 dinámicas de Agile Inception

Blog Single

Agile Inception, o también conocido como Inception Deck, es un conjunto de técnicas orientadas a alinear a todas las personas involucradas en un proyecto.

El objetivo de estas técnicas es el de reducir muchas de las incertidumbres que puedan surgir, ayudando a identificar los riesgos más evidentes y poniendo en común las expectativas de todos los stakeholders. Esto permite reducir considerablemente la falta de consenso, problemas de comunicación y la ambigüedad en ciertas partes del proyecto.

Estas técnicas se publicaron por primera vez en el libro “The Agile Samurai: How Agile Masters Deliver Great Software”. Se puede aplicar al iniciar cualquier tipo de proyecto, no sólo de desarrollo software, aunque está pensado especialmente en las fases conceptualización de startups porque facilita la definición de Productos Mínimos Viables (MVP).

El output de Agile Inception nos ayuda considerablemente en la identificación de funcionalidades, roadmapping  y definición de una arquitectura de alto nivel. Estas técnicas se centran en comunicar los objetivos, la visión y el contexto del proyecto al equipo para que se puedan tomar decisiones inteligentes mientras se ejecuta este y proporciona a los stakeholders la información que necesitan para ayudarlos. Ya que estas técnicas son muy colaborativas se requieren de materiales como post-its, pizarras y rotuladores para poder participar y colaborar en un escenario común.

Como he tenido que realizar en el master de “Gestión y Dirección de Proyectos Software” una práctica recorriendo cada una de las técnicas de Agile Inception, vamos a ver una pequeña descripción de cada una de las técnicas y un ejemplo con la aplicación de mensajería instantánea Whatsapp.

Mucho de los ejemplos se han construido con una herramienta online Realtime Board (https://realtimeboard.com) que nos permite construir los distintos tipos escenarios simulando el uso de post-its.

1. Why are we here?

La primera de las preguntas que debemos hacernos en Agile Inception es encontrar los motivos por los que este proyecto tiene sentido para el cliente preguntándonos ¿por qué estamos aquí? Descubriendo los motivos principal de nuestro proyecto,  nos va a dar el conocimiento suficiente para ayudarnos en la toma de decisiones y entender el contexto de uso. Para que la comunicación fluya en esta fase de discovering, se utilizan técnicas como World Coffee, donde los interlocutores interactúan potenciando la comunicación en distintos espacios de conversación. Otra técnica útil es el Impact Mapping el cual hablamos en posts anteriores.

Ejemplo

El producto que se desea construir es una aplicación de mensajería instantánea para smartphones. Cada día nos encontramos más conectados, y el objetivo es lanzar un producto que permita a millones de personas poder comunicarse. El target principal de consumo de esta aplicación es cualquier persona física con un smartphone, pero también señalar la importancia de las herramientas de comunicación dentro de las empresas.

El impulsor principal del proyecto no es otro que mejorar la comunicación de las personas de una manera sencilla, accesible y segura para todos.

Tras una sesión de world coffee se han obtenido los siguientes key points:

  • Las funcionalidades principales son la mensajería vía chat,  la privacidad de la comunicación, la compartición de contenido multimedia y la facilidad de uso
  • Los objetivos de negocio son los de tener la mayor cuota del mercado respecto otras aplicaciones de mensajería instantánea y llegar a cualquier tipo de dispositivo
  • Entre los requisitos no funcionales principales destacan la disponibilidad, la seguridad y la usabilidad
  • Entre los riesgos principales han destacado la gran competencia del sector,

2. Elevator Pitch

En este apartado el objetivo es construir un briefing de 45 segundos que resuma el proyecto y se  centre en el valor real del producto. Es importante que en este discurso nos centremos en los elementos principales que queremos transmitir. Por ello debemos de centrarnos en las necesidades, la solución propuesta, como se encuentra el mercado, cuales son los competidores y cual es nuestra propuesta de valor.

Ejemplo

Para los usuarios habituados al uso del smartphone

Quienes desean poder comunicarse con su círculo social estén donde estén

Whatsapp es una aplicación móvil

Que pretende posicionarse como aplicación de mensajería instántanea principal

En lugar de alternativas como Telegram, Line o Skype

Con el valor diferenciador de ofrecer una experiencia sencilla para todo tipo de consumidor y con una privacidad absoluta de las comunicaciones.

3. Product Box

En este apartado el objetivo es construir una caja de producto como si la ofreciéramos en un centro comercial, junto a sus slogans principales. Diseñar una caja de producto es un concepto relacionado con marketing que nos invita a imaginar la caja de un producto con los mensajes e imágenes necesarias como si nuestro producto estuviera empaquetado y fuera a estar expuesto de forma que resulte lo más atractivo posible para el cliente.

Ejemplo

Para ello se ha construido la siguiente caja, jugando con simplicidad y con un slogan con sus tres claves “comunicación instantánea y segura”.

4. NOT List

Una lista de Noes lo que hace es establecer las fronteras del producto a la hora de empezar a hablar, estableciendo un punto de referencia a las expectativas sobre lo que no se va a considerar como parte del proyecto. Esto es importante por qué es lo que nos va a determinar el alcance del proyecto.

Ejemplo

Para ello se ha construido el siguiente tablero con tres zonas principales: En Alcance, Fuera de Alcance y Por decidir:

agile inception

Como vemos, hemos diferenciado entre aquellas funcionalidades que no entran dentro del desarrollo de producto, las que están claras que son necesarias y aquellas que deben de resolver si entran o no entran en el alcance. Esto proporciona una primera aproximación de las funcionalidades principales del producto que se abordarán en el desarrollo del MVP.

5. Meet your neighbors

Es importante que todos los stakeholders del proyecto tengan en su radar al resto. Los entornos empresariales suelen ser grandes, y habitualmente no somos capaces de identificar cuantas personas están involucradas para lograr que el proyecto sea un éxito.

Es mejor establecer pronto las relaciones entre los miembros y generar un nexo confianza entre los mismos, esto implica que a la hora de enfrentar ciertos problemas la comunicación y el compañerismo  será mejor

Ejemplo

En nuestro caso vamos a identificar a todos los actores involucrados en el proyecto.

  • Equipo de Desarrollo
  • Equipo de Diseño
  • Equipo de UX
  • Product Owner
  • Equipo de Analítica
  • Departamento de Marketing
  • Finanzas

Como vemos, existe un equipo core formado por los equipos de desarrollo, UX y diseño, liderados por el product owner y luego stakeholders interesados en medida en la evolución del proyecto como pueden ser el equipo de marketing, de analítica y de finanzas. Hemos identificado cuanto de importante son los equipos para lograr el éxito del proyecto.

6. Show the solution

En este apartado se debe de trabajar en conjunto para mostrar una primera aproximación de la solución, planteando arquitectura, tecnología y herramientas que serían necesarias para la construcción del producto.

Esto conlleva generar expectativas, visualizar suposiciones, que todo los involucrados tengan claro el producto y sus principales escenarios.

Ejemplo

Para lograr esto, se ha trabajado junto con unas plantillas móviles para diseñar entre todos un prototipado de baja fidelidad que represente cómo sería la interacción del usuario final con nuestro producto

 

7.  Keep us at night

En este apartado debemos detectar aquellas cosas que nos pueden mantener despiertos por la noche. Es el lugar adecuado para que salgan a la luz aquellos riesgos que puedan influir en el desarrollo del producto, desde todas las perspectivas posibles. De tal manera que detectando estos riesgos podremos manejarlos y tenerlos en mente durante la evolución del proyecto, siendo consciente de las posibles desviaciones que puedan conllevar.

Ejemplo

Para ello se ha construido  una matriz de riesgo a partir de una dinámica de post its donde todos los involucrados han expuesto los posibles riesgos y etiquetados entre todos entre Bajo, Medio y Alto riesgo.

 

Riesgo Descripción Nivel
Real Time Technologies Experience El equipo de desarrollo tiene poca experiencia con tecnologías de real time Bajo
Devops Strategy Es el primer proyecto de la compañía donde se aplica una estrategia DEVOPS Bajo
Rivals Pueden aparecer distintos rivales que compiten con nosotros Bajo
Login with Phone Number Preocupa la integración con los proveedores de SMS para asociar el número de teléfono al usuario Medio
Co-located Teams Hay miembros de los equipos que trabajan en remoto, y la comunicación puede debilitarse Medio
Percentage of Dedication No todos los miembros del equipo están al 100% en este proyecto, ya que se encuentran en transición en otros desarrollos. Medio
Staff Turnover Preocupa la alta rotación en empresas tecnológicas y que algunos miembros clave abandonen la empresa antes del final del proyecto Alto
Product Owner Availability La disponibilidad del Product Owner preocupa ya que también está involucrado en el desarrollo de otros productos de la empresa Alto

8. Size it up

En esta dinámica se trata de lograr una estimación de alto nivel de cuándo esfuerzo en recursos y tiempo puede conllevar el proyecto. No se trata de dar una estimación exacta, pero si de algo aproximado teniendo en cuenta todas las implicaciones que conlleva. Esto proporciona a los stakeholders una idea de cuánto de grande es lo que se desea construir. El objetivo no es la precisión pero si aproximar el posible tamaño.

Ejemplo

Para llevar a cabo esta técnica se ha construido un Gantt en el que han colaborado todos los equipos marcando ciertos hitos del proyecto con entregas funcionales.

El producto podría estar listo para lanzarse en el Q4 de 2019 aproximadamente en Septiembre. Y las funcionalidades más prioritarias tras el MVP, podrían lanzarse en dos paquetes de funcionalidades cada 3 meses.

A continuación se muestra en diagrama de Gantt de alto nivel en el que se detallan los distintos posibles hitos del proyecto. Se considera con la estimación que el desarrollo del producto abarca aproximadamente entre 9 y 15 meses.

9. Be clear on What’s going to give

En esta dinámica se trata de establecer ciertas prioridades en los factores claves de ejecución del proyecto, y si entran en conflicto cuales son más prioritarios.  Se deben establecer estas palancas, siempre teniendo en cuenta las 4 más importantes: Presupuesto, Alcance, Tiempo y Calidad. Además en este proyecto en cuestión entran en juegos dos factores adicionales claves para el éxito del proyecto que son la experiencia de usuario y la seguridad.

Ejemplo

Para ello todos los involucrados han priorizado del 1 al 6 los factores que entran en juego sin poder repetir la prioridad, de tal orden que queda un orden de factores.

  1. Seguridad (El factor más importante es la seguridad, ya que el valor principal debe ser el servicio de mensajería instantánea más seguro, debido a los problemas de privacidad y la legislaciones surgidas en los últimos años
  2. Calidad (Para tener un valor diferenciar el producto debe ser robusto y de calidad
  3. Tiempo (Es importante no desviarse de la estimación realizada en el Size it Up por posibles competidores
  4. Experiencia de Usuario (La experiencia de usuario debe de ser buena, pero tampoco se requiere reinventar la rueda
  5. Alcance (El alcance no preocupa siempre que existan ciertas actualizaciones planificadas tras el lanzamiento, se podría prescindir de alguna funcionalidad que no sea core
  6. Presupuesto (Ha entrado un fuerte inversor, y el presupuesto a día de hoy no hay problema para añadir más recursos al proyecto.

10. Show what it’s going to take

En esta dinámica se trata de calcular aproximadamente el número de personas involucradas para cumplir con las necesidades en el tiempo establecido y estimar el coste que pueda conllevar.

Ejemplo

Tras el recorrido de las distintas dinámicas se ha establecido que el equipo podría establecerse de esta manera:

  • 3 analistas programadores (2 senior y 1 junior)
  • 1 diseñador senior
  • 1 UX senior
  • 1 Product Owner
  • 1 Tester/QA
  • Aportaciones puntuales del equipo de analítica y marketing

Con el equipo disponible y la estimación de tiempo de 1 año de media aproximado (9 a 15 meses), podemos dar la siguiente estimación:

7 personas -> 12 meses  -> 250K

Conclusión de Agile Inception

Como hemos podido ver, todas las técnicas de Agile Inception tienen un nexo, ya que están focalizadas en visibilizar a todos los involucrados el alcance y necesidades del proyecto. Las 5 primeras técnicas se centran en el QUÉ mientras que las otras 5 se centran en el COMO. Este tipo de sesiones son caras de llevar a cabo ya que requiere de un día entero de todos los involucrados pero las ventajas que se logran cara al producto son notables.

Si has participado en algún tipo de workshop en el que has aplicado Agile Inception me gustaría que colaboraras en los comentarios de este post y nos contaras tu experiencia.

# Bonus Track

La siguiente formación de Elena Naranjo en el canal de youtube de CICE me ha parecido realmente útil e interesante. Os recomiendo que le echéis un vistazo para profundizar en las dinámicas y en la técnica de Agile Inception y User Story Mapping

Referencias

The Agile Inception Deck

https://www.autentia.com/wp-content/uploads/2018/07/Mazo_Inception_Deck.pdf

Comparte el artículo si te ha resultado interesante: