Recientemente participé en un hangout de la gente de AgileSpain muy interesante sobre Agile Inception, gracias a Jaume Jornet.De allí me inspiré a continuar con los post sobre puntos de encuentros entre Agile y la gestión tradicional de proyecto. Sigo insistiendo que en realidad no son exclueyente, sino que más bien tienen muchos puntos en común y pueden convivir sin problema (por eso a veces me da risa los radicales de ambos lados..)
Para muchos el kickoff meeting o reunión de inicio, se utiliza para marcar el comienzo del proyecto, otros lo utilizan para discutir aspectos claves entre los principales actores.
En el caso de Agile Inception (Inception Deck o simplemente Inception), tiene como principal finalidad alinear a los involucrados en el objetivo del proyecto (servicio, producto o resultado).
Definitivamente son dinámicas muy diferentes, sin embargo, tienen algunos puntos en común que a continuación describo:
- Se trata de alinear a los involucrados sobre un objetivo, visión del producto o servicio.
- Ambas corresponden a la fase inicial del proyecto (en general).
- Se debe procurar que participen todas aquellas personas que de alguna manera se vea impactado por el proyecto, sobre todo, aquellos que más adelante se puedan convertir en bloqueadores!
- En ambas se puede utilizar la técnica de elevator pitch para mostrar la visión .
- En general, son reuniones costosas por el número de participantes.
- Se aprovecha la presencia de los involucrados para generar ideas.
- Más que reuniones, son procesos.
Diferencias:
- El kickoff marca el inicio del proyecto, inception no necesariamente.
- Inception son más creativas que los kickoff.
- En general, los kickoff ya vienen predefinido y se utilizan para divulgar información o acordar sobre cómo se ejecutará el proyecto.
Comentarios
Como dices, no hay balas de plata, y no todos los equipos están dispuestos o ti€n€n lo$ r€cur$o$ para tener a un equipo de 5 a 9 personas y al menos un product owner durante al menos dos días encerrados en una sala detallando elevator pitch, tarjetas kanban, historias de usuario o como decidan representarlo. Un kickoff ya lo da pre-mascado, el equipo asume que lo que está es lo que es (como los 10 mandamientos) y a partir de ahí viene el desarrollo de los objetivos.
También está el tema de si se cobra o no se cobra. Un kickoff "cuela" mejor en la factura. A veces el inception no tanto ya que "¿para qué te voy a pagar para que te enteres? si te pago por el trabajo hecho".
Échale un ojo sobre este tema en el hang anterior que lideró Jose Manuel Beas sobre cómo cobrar un servicio, está muy ligado a esto último.
Ya para cerrar: ¿han imaginado el caso de un inception con un equipo distribuido geográficamente? ¿alguien desea comentar sus experiencias en este tema? En local ya es un palizón, en remoto es como para ir a terapia.
Sobre cosas sorprendentes que se hacen en una inception y la documentación que surge de ello (sí, documentación, y ágil, y mucha) solo basta con pinchar en las secciones del diagrama principal de esta página. http://www.agilemodeling.com/
Saludos!
Con respecto a Inception Distribuido, no me he animado porque le he dado vuelta y todavia no me convence. En el hang hay un comentario sobre un chico que hizo un inception a distancia y no lo vuelve hacer. Lo de cobrar o no cobrar, es cierto. Me leeré el artículo de jmbeas.
Seguimos en contacto.
Una de los inconvenientes que siempre encontraré en las fases iniciales de los proyectos ágiles, además de como bien menciona Helder la interrogante de cobrar por el servicio, es lo poco colaboradores que he notado en mi experiencia a los clientes finales de participar en el proceso de definición y toma de decisiones en el proyecto. Es como si sintieran que no es su trabajo, y peor aún, que están haciendo el trabajo por el equipo.Esto es grave, porque en muchos casos deriva en la preferencia por hacer un documento con una descripción de la herramienta o aplicación "que el equipo considera que necesita el cliente", firmarlo con sangre y apegarse al guión, lo cual como sabemos es muy poco probable que de resultados de valor. Con esto culmino planteando: ¿hasta que punto un cliente es responsable de conducir un proyecto sin sentir que para eso nos paga? ¿Cuál es el punto de equilibrio?¿por qué como alegan muchos clientes diciendo: debo definir que debes hacer, escribiendo las historias de usuario y además priorizarlas, para que tu luego solo las programes?
Saludos