Ir al contenido principal

Kickoff Meeting vs. Agile Inception

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.
Si tienes algo que agregar..o alguna queja.. bienvenido y deja tu comentario..!

Comentarios

Genial! solo comentar que en todos los kickoff en los que he estado no necesariamente la información que está siendo emitida llega a los receptores, mientras que en los inception cada miembro del equipo ha estado sudando la gota gorda por cubrirse las espaldas indagando más y más en lo que está detrás del proyecto, como es lógico, ya que luego es el propio equipo el que meterá las manos en el fuego por los tiempos y las entregas.

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!
Gustavo Bonalde dijo…
Helder, gracias por el comentario. Voy a ir agregando esas diferencias o semenajanzas que vienen de buena experiencia como en tu caso.
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.
Gerardo Barcia dijo…
Excelente artículo. Personalmente me inclino por la opinión de que las diferencias entre estos dos grandes mundos(tradicional y ágil) no estriba en la forma sino en el fondo. Con esto me refiero a los valores y la forma del equipo en abordar los problemas. En un entorno ágil ideal: menos burocracia, más colaboración con el cliente y roles más diversos y menos jerárquicos. Considero que el manifiesto ágil siempre ha sido muy claro en cuanto a de cuales elementos se desligaba del desarrollo tradicional, y esto resultó en un marco de valores e intenciones más que de procesos,técnicas y herramientas. Todo proyecto tiene los mismos principios y debe inevitablemente pasar por todas las fases de su ciclo de vida, las técnicas y estrategias aplicadas a esos principios pueden resultar válidas en función de un contexto: Se puede aplicar TDD,BDD y AM a cualquier proyecto tradicional tanto como se puede aplicar un kickoff a un desarrollo ágil. En ese sentido, creo que kickoff e Inception pueden resultar ser sinónimos por momentos, pues cumplen con la misma función en un marco general de proyecto.

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
Gustavo Bonalde dijo…
Gerardo, estoy bastante de acuerdo con tu comentario.. me quedo con la frase "en función de un contexto", mi objetivo al escribi estos articulos comparando ambas técnicas es indicar la certeza de que pueden convivir, no son exclusivos.

Entradas más populares de este blog

¿Cuál programa tomo? ScrumAlliance vs. Scrum.org

Luego de participar en varias discusiones de foros acerca de las distintas certificaciones que existen de Scrum, me decidí a escribir este post para tratar de aclarar este enredo (CSM, CSPO, CSD, CSP, CSC,CST, PSD, PSF, PSM, PSPO, PMI-ACP) que a veces surge con todo esto.

Resulta que los 2 principales organismos ScrumAlliance y Scrum.org (hay otros varios como ScrumManager.net) que ofrecen los cursos de certificación en Scrum, vienen del mismo origen: Ken Schwaber. En una carta del año 2010, Ken explica por qué deja el ScrumAlliance y decide crear un nuevo instituto: "Este viajeha sido moldeado pordos fuerzas opuestas: el deseo dehacer lo correcto,y el deseo deganar dinero.ForméScrum.orgpara reenfocarmis esfuerzos enhacer lo correcto.".. Lo cierto es que no se puede negar el factor "revenue" para estas empresas, por su cursos, certificaciones y assessment que ofrecen, al igual que su objetivo de divulgar Scrum y mantenerlo por un buen tiempo.

A continuación les dejo…

Borrador de la 6ta edición de PMBOK

Les dejo un extracto de los cambios más relevantes del borrador del PMBOK 6, cuya versión definitiva se prevé para el tercer trimestre del 2017.

La secciones de la 1-3 han sido modificadas, dejando la información importante y agregando nueva información que refleja la evolución del Gerente de Proyecto hacia agente de cambio y proveedor de valor de negocio. En la sección 1, se incorporan términos relacionados con enfoques ágiles y entornos iterativos y adaptativos.Los grupos de procesos se mantienen igual que en la versión 5.Cambian de nombre 2 área de conocimiento:
Versión 5 Versión 6 Project Time Management Project Schedule Management* Project Human Resource Management Project Resource Management.

*Me gusta, porque definitivamente el tiempo no se gestiona, podemos gestionar son las actividades.

Hacer las cosas correctas vs Hacerlas correctamente

"Hacer las cosas correctas" es un aspecto de satisfacción en el producto, servicio o resultado que se quiere hacer, mientras que "Hacerlas correctamente" se refiere más al método utilizado en su desarrollo o implementación.

Existen cuatro combinaciones posibles:

Hacer lo correcto y hacerlo correctamenteHacer lo correcto y hacerlo incorrectamenteHacer lo incorrecto y hacerlo correctamenteHacer lo incorrecto y hacerlo incorrectamenteSi lo llevamos a los conceptos de Management: "Estrategia y Táctica", la combinación quedaría de la siguiente manera:
Se tiene una estrategía y se cuenta con una táctica adecuada (el estado del arte)Se tiene una estrategía y no se cuenta con una táctica (según Sun Tzu “Strategy without tactics is the slowest route to victory" )No se tiene estrategía, pero se cuenta con una táctica adecuada (según Sun Tzu "Tactics without strategy is the noise before the defeat”)No se tiene estrategía, ni tampoco con táctica (al menos …