La Agile Inception

por | Abr 12, 2021 | Agile | 0 Comentarios

Los modelos tradicionales por fases estaban presentes en etapas mucho más tempranas que la construcción de software. La ideación de un producto estaba ocupada por largas fases de análisis y diseño cuya solución quedaba plasmada en grandes cantidades de papel. Pero esta documentación podía no ser consultada o creada por todas las partes interesadas, lo que a la larga traería problemas para el producto. Por suerte, los valores y principios Agile también llegaron a la conceptualización de producto.

En un artículo anterior te contábamos qué es la conceptualización y para qué sirve (Piensa en el usuario antes de crear producto). Recuerda que es el proceso para convertir una idea en un producto, donde se alternan fases de divergencia y convergencia para conseguir una buena solución. Pero, ¿qué tiene lugar en una conceptualización?

En 2010, Jonathan Rasmusson escribió su libro “Agile Samurai” donde recoge una serie de actividades que ocurren en una Agile Inception. Para lograr una buena conceptualización necesitarás identificar a las personas relevantes que tienen que participar de todas las partes del proceso.

Las primeras actividades hacen referencia al dominio del problema y su propósito es alinear a los participantes en cuál es el reto a resolver. El resto de actividades responden al dominio de la solución donde a partir de la información obtenida se empieza a construir un prototipo a muy alto nivel.

Dominio del problema

Para qué estamos aquí: con el objetivo de lograr una visión compartida del producto, se dedica la primera actividad a alinear a todos los participantes respecto a la idea del producto.

Elevator Pitch: ¿Cómo elaborarías un discurso de venta sobre el producto que estás conceptualizando? Para esta actividad, Jonathan Rassmusson propone utilizar la siguiente plantilla:

elevator pitch

Caja de producto: Imagina que tu producto tiene que mostrarse en un lineal de un supermercado donde está rodeado de productos de la competencia. ¿Cuál es su propuesta de valor? ¿Qué información debería mostrar? Con la metáfora de la caja de producto, se escogerá el eslogan y las frases claves para su propuesta de valor.

product box

Qué no es: para acotar las expectativas del producto, podéis comenzar por escribir lo que no es el producto. Después seguro que es más fácil describir lo que es. Incluso puede ocurrir que existan dudas. Todo ello lo podemos reflejar en una tabla así:

que es

Conoce a tus vecinos: en la última actividad del dominio del problema identificarás a las personas involucradas en el producto y el nivel de participación, desde los que participarán en el día a día hasta los que únicamente necesitan estar informados. Puedes representarlo en círculos concéntricos.

Dominio de la solución

Solución de alto nivel: para comenzar en el dominio de la solución, qué mejor forma que crear un primer boceto de cómo sería el producto. Es probable que necesites involucrar a parte del equipo que construirá la solución.

¿Qué nos mantiene despiertos por la noche?: Para asegurar que el producto sea un éxito, se debe hacer una gestión de riesgos identificando sobre cuáles se puede actuar y cuáles se escapan del ámbito de actuación. El resultado será una serie de métricas que te permitirán identificar cuándo aparecen esos riesgos durante la construcción del producto.

Mídelo: Con la información que has recibido hasta ahora puedes dar una estimación aproximada del tamaño de la solución en términos temporales e identificar posibles hitos que se necesiten cumplir.

Trade-offs: Dentro de un proyecto hay un montón de dimensiones que pueden actuar: alcance, coste, tiempo, presupuesto, … En esta actividad se establecerá sobre cuáles hay poder de negociación y cuáles son innamovibles.

trade off

Cuánto nos va a costar: Ahora que ya estás llegando al final del proceso, hay información suficiente para hacer una estimación de qué se necesitará para sacar adelante el producto: personas, materiales, infraestructura, licencias, … Y esto se puede empezar a traducir en coste para construir el producto.

Podemos encontrarnos con Agile Inception que se alargan desde varios días hasta varias semanas, en función del tamaño del producto, el conocimiento, la experiencia en este tipo de sesiones de co-creación, … Incluso, en algunas ocasiones, según se va obteniendo información sobre el producto puede llegar a darse el caso en que no tenga sentido continuar con su ideación y posterior desarrollo. Sin embargo, lejos de pensar que es un fracaso, estas actividades te han evitado construir un producto que no cubría las necesidades.

También puedes pensar en eliminar alguna de las actividades para acortar los tiempos del proceso. En ese caso piensa en qué conversaciones están dejando de ocurrir por esa decisión y qué impacto pueden tener en el producto final. Por supuesto, también puedes añadir más actividades, pero en ese caso identifica que su propósito no está cubierto ya por otro ejercicio y cuál es el resultado que esperas obtener.

También te puede interesar.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo?? Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies