¡Nuevo episodio de Scrum Manager Podcast! Disponible en Spotify e iVoox.
Hace unas semanas hicimos una encuesta en redes sobre prácticas ágiles sobre las que hablar. En este episodio hablamos de la práctica ganadora: Agile Inception.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
¡Hola y bienvenidos! Hace poco lanzamos una encuesta sobre varias prácticas ágiles, para elegir una sobre la que profundizar. Venimos a cumplir con lo prometido. Hoy hablaremos sobre Agile Inception.
Agile Inception: definición y características
Agile Inception, Inception o Kick-off son términos que se usan para englobar muchas prácticas distintas que se utilizan en la fase de planificación y descubrimiento de un proyecto ágil. En español se pueden llamar lanzamiento o inicio ágil, o reunión de lanzamiento. Son actividades para planificar o diseñar en equipo un nuevo producto, función o versión. Tratan de aprovechar el conocimiento de personas expertas en diferentes áreas de la compañía y lograr una visión compartida.
Su duración puede variar mucho: algunas no son más que una reunión, en cuyo caso se usa más el término kick-off; pero también pueden durar una o más jornadas de trabajo.
Ayudan a no malgastar recursos, a delimitar el alcance y los riesgos de lo que se quiere conseguir y descubrir en poco tiempo si es viable.
Existen muchas prácticas que se utilizan como Inceptions. Puede ser complicado elegir la que mejor se alinee con las necesidades del proyecto y la cultura del equipo. Entre otras cosas, porque dependen de varios factores. Por ejemplo, si queremos incluir una nueva funcionalidad con un nivel de incertidumbre bajo, puede ser suficiente con una reunión kick-off y alguna práctica de gamificación. Con nivel de incertidumbre bajo queremos decir que ya existe una idea de lo que va a ser esa funcionalidad, más o menos.
Pero si el producto es novedoso o incierto para la mayoría de los implicados puede convenir más una práctica tipo taller, de uno o varios días.
Así que no todos los Agile Inception siguen los mismos métodos. Algunos están específicamente pensados sólo para el principio del proyecto; mientras que otros forman parte de un proceso completo que incluye una fase inicial que podría considerarse como inception.
Pero podemos extraer algunos pasos y actividades comunes, tales como:
- Identificar las necesidades de los usuarios.
- Definir metas y objetivos.
- Identificar competidores o soluciones alternativas que ya existan para las mismas necesidades.
- Recopilar y revisar los requisitos del proyecto.
- A veces los inception trazan también un plan inicial, con requisitos a alto nivel.
Vamos a mencionar algunos Agile Inception conocidos antes de pasar a la práctica.
Agile Inception: prácticas y metodologías
Sprint 0 o inception sprint
Dentro de scrum está el sprint 0 o Inception sprint. Cabe mencionarlo, pero por aclarar que no es un inception. El sprint 0 nació siendo un primer sprint que no se usa para construir un incremento, porque se dedica a tareas como preparar servidores, configurar herramientas de comunicación y cosas así. Luego ha generado polémicas, ya que suele usarse para tareas de preparación.
Se puede emplear también para «descubrir» el proyecto, para probar una hipótesis o crear un proyecto piloto para el cliente. Pero no es como se planteó en origen.
Agile Inception Deck
Un inception bastante popular es el Agile Inception Deck. Es un modelo de reunión de trabajo o taller creado por Jonathan Rasmusson. Lo desarrolla en su libro The Agile Samurai y lo define como «una colección de diez preguntas y ejercicios difíciles que sería una locura no hacer antes de comenzar cualquier proyecto».
Son, en efecto, 10 actividades con objetivos muy concretos y útiles. Desde dar con un “elevator pitch” o frase que describa en pocas palabras el proyecto hasta identificar rasgos o que los miembros del equipo empiecen a conocerse. Podéis encontrar las 10 actividades buscando Agile Inception Deck en el Body of Knowledge de Scrum Manager.
Agile Unified Process (AUP)
Un proceso que incluye una fase de inception es el Agile Unified Process (AUP). Es una versión simplificada de Rational Unified Process desarrollada por Scott Amber. Contiene una fase de inicio que es la que corresponde a un inception: se identifica el alcance y la dimensión del proyecto, el problema a solucionar, y se hace una propuesta de la arquitectura según el presupuesto del cliente.
Design Thinking
Probablemente os suene Design Thinking. Es un inception basado en el usuario. Se centra en las interacciones, las relaciones humanas y la creatividad. Se da mucha importancia a lo emocional y promueve la escucha activa hacia el usuario y la empatía. No se trata de vender el producto al usuario sino de comprenderlo para mejorar.
Se divide en cinco fases: se investiga el problema partiendo del usuario, se identifica, se resuelve mediante técnicas creativas e innovadoras, se crea un prototipo y se valida con los usuarios.
Lean inception
También está Lean Inception, actividad desarrollada por Paulo Caroli en un libro del mismo título. La utilizó como consultor en ThoughtWorks, y la considera muy valiosa para proyectos grandes que necesitan comenzar rápidamente y orientarse para trabajar en un estilo lean. Pero también es útil para organizaciones más pequeñas o startups.
Es un taller de varias jornadas de duración en el que las partes interesadas realizan actividades en equipo para definir y comprender un MVP (Mínimo Producto Viable).
Son tantas las prácticas ágiles que pueden utilizarse como inception, que difícilmente podemos explicarlas todas. Para no saturar y ayudar a elegir, hemos preparado dos ejemplos con los que vamos a ver otras 2 prácticas populares: Design Sprint e Impact Mapping.
Al elegir deberíamos considerar la incertidumbre y la urgencia del proyecto. Es decir:
- ¿Tenemos ya una idea de lo que hay que construir, o sólo hemos identificado una necesidad, pero no sabemos cómo abordarla?
- ¿Con cuánta urgencia necesitamos lanzar una primera versión o prototipo?
Normalmente no es necesario un taller de varios días que interrumpa el trabajo de varias personas. Hay soluciones que son obvias. La fase de inicio nos puede servir en esos casos para ordenar y compartir ideas y planificar el trabajo, y puede ser sólo una reunión. Pero si queremos diferenciarnos de la competencia, encontrar una solución innovadora, o el proyecto está atascado y no sabemos por qué, quizás vale la pena invertir tiempo y esfuerzo en un taller inception.
Design Sprint
Nuestra empresa de videojuegos lanzó al mercado un juego de Shooter hace poco, pero no está teniendo éxito. No sabemos por qué y queremos aprender cuanto antes. El riesgo es alto y disponemos de poco tiempo. Es decir, nuestro grado de urgencia y el nivel de incertidumbre son altos. Mala combinación.
Ante esta situación, hemos decidido realizar un Design Sprint. No confundir con el sprint típico de scrum ni sprint 0. Es un taller grupal de cinco días que nos permitirá generar muchas soluciones, filtrarlas, y preparar un prototipo realista de la que más nos guste para probarla con usuarios. En 5 días.
Fases de un Design Sprint
Primero se forma un equipo transversal de no más de 7 personas, y asignamos algunos roles. Necesitamos una persona que tome decisiones, un facilitador o moderador, y un reclutador.
Supongamos que empezamos un lunes. Ese día se traza el mapa de lo que se persigue con el taller, para explicárselo y pedir consejo a expertos. El equipo toma notas durante estas entrevistas, y luego las ordena y prioriza en el mapa.
El martes toca esbozar posibles soluciones. Lo haremos con «demos relámpago», que pueden ser soluciones inspiradas en otros juegos para verlas en acción, y con «bocetos individuales». Dibujos con los que compartir sugerencias para partes concretas del mapa.
El miércoles revisamos todas las sugerencias y elegimos la mejor solución entre todos, aunque la persona con el rol de toma de decisiones tiene la última palabra. Guionizaremos la prueba del prototipo para esa solución en 15 escenas: una escena por cada minuto que durará el test.
El jueves tendremos que construir un prototipo. Tiene que ser realista, pero no real. Es como un escaparate. Por ejemplo, mostrando información en la pantalla del juego que no es dinámica ni depende de una base de datos, sino que está escrita a mano para el ejemplo. Hay poco tiempo, así que elegimos las herramientas y dividimos tareas. Gráficos, texto, código… Una persona debe encargarse de ensamblar el trabajo de los demás. Cuando el prototipo esté construido, se prepara una prueba para presentarla a todo el equipo.
El último día probamos nuestro prototipo con cinco usuarios. Un entrevistador está con cada uno durante una hora mientras el equipo observa desde otra sala, en tiempo real, y toma notas. Así obtenemos feedback directo que nos servirá para aprender y saber si el prototipo puede ser la solución, o hay algo de valor en él.
Impact Mapping
Vamos a suponer que el Design sprint fue un éxito y nuestra empresa ha logrado subir las ventas de nuestro juego Shooter.
Solucionado el problema, centramos nuestra atención en la plataforma. Y nos damos cuenta de que, a diferencia de la competencia, nuestros jugadores no reciben logros en nuestros juegos. Nos planteamos si esto es algo a añadir.
Tenemos un objetivo y necesitamos planificar y priorizar las tareas. Es un ejemplo de urgencia e incertidumbre menores. Podemos querer diferenciarnos de la competencia, eso sí. Y entender qué valor aportan los trofeos a nuestros usuarios y a nuestro negocio. Así que vamos a hacer un inception, pero esta vez utilizando Impact Mapping.
Fases de un Impact Mapping
Se estructura en torno a cinco preguntas o temas: Meta, Actores, Impacto y Entregables. Dicho de otra forma: ¿por qué? ¿quién? ¿cómo? y ¿qué?
Primero debemos descubrir las metas, el por qué. Nuestro equipo, de no más de siete personas, hace una lista con posibles objetivos. En nuestro caso, la pregunta ¿por qué queremos incluir logros y trofeos en nuestra plataforma? genera respuestas como: «fomentar la competitividad», «animar a jugar más para mejorar puntuaciones», «generar conversaciones», «ganar visibilidad», «fidelizar» … Podemos extraer de aquí que el objetivo real no es crear trofeos, sino que queremos fidelizar a los usuarios y crear comunidad.
En cuanto a los actores: ¿a quién afecta nuestro producto y quién puede beneficiarse? Se busca ser específico. Usaremos grupos o roles de usuarios como por ejemplo «jugadores activos registrados hace un año o más», «jugadores inactivos» y «jugadores nuevos».
El cómo, es decir, el impacto, lo tenemos más o menos claro. Los actores estarán alineados con nuestras metas si pasan más tiempo en la plataforma, si la recomiendan… (fidelización) y si se comunican con otros jugadores (comunidad).
Los entregables, el qué, pueden ser los trofeos, o puede que se nos ocurra otra cosa. Pero si optamos por los trofeos debemos pensarlos para que estén alineados con lo que queremos. Deben ser valiosos para los usuarios: premiar a jugadores con más habilidad o curiosidad, comunicar gustos e intereses, ser divertidos de obtener y compartir.
Afinando el mapa
Con esto dibujaremos el esqueleto del mapa. Pero no vamos a quedarnos ahí. Vamos a discutir otras opciones, centrándonos en los actores y el impacto. Se nos pueden ocurrir otras ideas como «recomendar juegos» o «invitar a amigos», que también ayudarían a fidelizar y crear comunidad.
Como no se puede hacer todo, por último, filtraremos. ¿Cuál sería la forma más eficiente de lograr el impacto que queremos? En nuestro caso podría ser, por ahora, «recomendar juegos a amigos». Y el entregable tendrá forma de invitaciones integradas en X redes sociales, con una sugerencia de mensaje ya escrita. Nuestro mapa final tiene como meta «fidelizar usuarios y crear comunidad». Tiene varios actores, varios impactos y entregables. Nuestro inception podría terminar aquí. De hecho, es un objetivo bastante sencillo. Pero si no lo fuese podríamos preparar un MVP (Mínimo Producto Viable), o pruebas con varias opciones de mensaje para compartir en redes antes de quedarnos con una definitiva.
Sabemos que hemos dejado temas en el tintero, pero esperamos que estos ejemplos os sirvan como introducción al tema de los agile inceptions, y que considerar la urgencia e incertidumbre del proyecto os ayude a elegir.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!