martes, marzo 28, 2017

Las habilidades blandas -Soft Skills- de un Scrum Master


Hola a todos:

Quisiera compartir en este post un poco más del entendimiento que he logrado del rol de Scrum Master, este rol tan extraño que hace poco hemos comenzado a emplear en proyectos de desarrollo de software.

Según la Guía Oficial de Scrum (1), el Scrum Master (SM). lo define como:
  • es el responsable de asegurar que Scrum se entienda y se adopte
  • es un líder que está al servicio del Equipo Scrum (Ojo: Recordemos que el Equipo Scrum esta compuesto por el Equipo Desarrollador (2), Scrum Master y Product Owner)
  • ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
  • Facilitar los eventos de Scrum según se requiera o necesite.
  • Sirviendo al Product Owner en:
    • Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
    • Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
    • Entender la planificación del producto en un entorno empírico;
    • Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
    • Entender y practicar la agilidad; 
  • Sirviendo al Equipo Desarrollador (2) en:
    • Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
    • Ayudar al Equipo de Desarrollo a crear productos de alto valor;
    • Eliminar impedimentos para el progreso del Equipo de Desarrollo;
    • Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.
  • Sirviendo a la Organización en:
    • Liderar y guiar a la organización en la adopción de Scrum;
    • Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
    • Motivar cambios que incrementen la productividad del Equipo Scrum; y,
    • Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.
Podríamos parafrasear o abstraer todo esto en
  • El Experto y Maestro de Scrum
  • Quien enseña al Equipo Scrum a hacer Scrum
  • Facilitador de los eventos de Scrum
  • Líder Servicial (al servicio del equipo Scrum)
  • Agente de cambio
  • Coach del Equipo Desarrollador y del Product Owner
  • Remueve impedimentos 
  • Protege y guía al Equipo Scrum y a la Organización la forma como estos interactuan más efectivamente.
Podríamos decir entonces:
"Wow que rol tan importante dentro del equipo, alguien que lidera y sirve al equipo a la vez", 

Pero el lío viene cuando tenemos que salir a elegir dentro de nuestra organización o contratar Scrum Masters en el mercado, Definitivamente no es fácil, pues a la luz de las definiciones mostradas anteriormente la mayoría son blandas y se podrían resumir en:

  • Liderazgo de equipos*
  • Liderazgo Servicial (propone y cuestiona, pero no impone) (4)
  • Trabajo en equipo
  • Don de Maestro
  • Proactividad
  • Comunicación Asertiva
  • Constante autoformación
  • Orientación al logro* (o sea, hace que las cosas pasen)
*La orientación al logro y el liderazgo son cruciales para que un Scrum Master sea exitoso, pues no tiene presentación que este sea una víctima:
  • del Product Owner, 
  • del Equipo Desarrollador 
  • o de la organización. 
Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto, valiéndose de las herramientas que le proporciona Scrum y la agilidad, e insisto no es una víctima del entorno, es un protagonista que energiza al equipo y presenta radiadores de información que ayuda a todos a tomar acciones oportunamente.

"Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto."

Según el marco solo requiere una competencia cognitiva:
  • Maestría en el Framework de Scrum (es importante aclarar que dos días de entrenamiento en scrum no convierten a nadie en MAESTRO), lo que se podría resumir en;
    • Saber como facilitar un planning (clic aquí)
    • Saber como facilitar un daily (clic aquí)
    • Saber como guiar al equipo durante el sprint de manera que se logre la autoorganización
    • Saber como facilitar un review (clic aquí)
    • Saber como facilitar una retrospectiva (clic aquí)  
    • Saber como facilitar un refinamiento (clic aquí)
    • Saber como hacer el rol de Product Owner (pues el SM es su coach)
    • Saber como se hace planeación de un producto
    • Saber como se hace la estimación de un product backlog, un sprint backlog y el seguimiento del mismo
    • Saber sobre agilidad
    • Saber sobre prácticas técnicas ágiles (para el mundo del software), o las herramientas que hacen a su equipo más eficiente (pensando en la aplicación de scrum en un escenario agnóstico - o fuera del software - ) (recomiendo este post : Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo - Clic aquí- )

Y por último, es requerido que el Scrum Master tenga conocimientos básicos (no es necesario que sean avanzados - pues para eso está el equipo -) del escenario técnico en el cual se desenvuelve el proyecto o la construcción del producto, pues sino el primer impedimento sería el Scrum Master al no tener herramientas suficientes para saber cómo o quién puede ayudar a su equipo.


Bueno, hasta acá este compartir.

Próximo post relacionado con este ¿cómo encontrar, contratar o formar un scrum master?

Bienvenido el feedback

Saludos ágiles

Jorge Abad.





Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla, encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
  3. Dos buenos links que me sirvieron de gran utilidad para escribir este post  https://www.scrumalliance.org/community/articles/2013/july/soft-skills-for-scrummasters  -- http://www.yodiz.com/blog/10-essential-skills-every-scrum-master-must-have-infographics/
  4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - Clic aquí -

miércoles, marzo 22, 2017

[Scrum] El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog

Hola a todos

Como lo había compartido en el post anterior (clic aquí) el Product Owner:

  • Es alguien con empoderamiento y capacidad de decisión sobre el producto
  • Es el responsable del  ROI -return on investment-
  • Es voz del cliente ante el equipo
  • Define, refina y prioriza el Product Backlog
  • Esta disponible para el equipo
  • Hace seguimiento del avance y la construcción del producto
  • Decide cuando cancelar el sprint 
  • Decide cuando salir a producción.

Pero lo que quiero resaltar en este post es lo que dice la guía(1) dice expresamente acerca del Product Backlog y la Lista de Elementos (o ítems) del Producto y como debería trabajar con ella el Product Owner


"El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye: 

  • Expresar claramente los elementos de la Lista del Producto;
  • Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
  • Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
  • Asegurar que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y,
  • Asegurar que el Equipo de Desarrollo(2) entiende los elementos de la Lista del Producto al nivel necesario. 
El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo*. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo."

Cabe aclarar que he estado en proyectos donde las historias de usuario o ítems de backlog son escritas por otra persona diferente al Product Owner que no hace parte del Equipo Scrum(2), pero esto no exime que el Produt Owner siga al frente de este trabajo y de sus responsabilidades frente al Equipo y al Producto.



Por lo tanto, el Product Owner (de un producto de software), respecto a
  • los requerimientos en prosa,
  • historias de usuario,
  • casos de uso, 
  • o cualquier forma de expresar la Elementos del Producto o ítems de backlog
 podría de acuerdo a su contexto:
  • Elaborar la Lista de Elementos del Producto (Product Backlog) - esta es la práctica más común  -,
  • Delegarla o apoyarse en el equipo de desarrollo para su construcción, o
  • Delegarla en otros por fuera del equipo de desarrollo - esta es fruto de mi experiencia y de varios coaches en la industria, y nos ha sido bastante útil en contextos donde el Product Owner no tiene tiempo para explicitar reglas de negocio compleas -.
Cada Equipo Scrum debe experimentar y entender cual es la configuración que más le conviene.

Basados en la sorpresa anterior quisiera hacerte una pregunta:
¿Cuándo fue la última vez que leíste la guía de Scrum? 

Es bueno leerla cada cierto tiempo, pues en la medida que ganas conocimiento y destreza con Scrum la lees y la comprendes mejor.

Hasta acá esta pequeña nota curiosa.

Les recomiendo este otro post  Un vistazo a la guía de Scrum - Clic Aquí relacionado con la guía y sus apartes "ocultos a nuestro rapido mirar" de mi estimado amigo Lucho Salazar - @LuchoSalazarC traductor de la versión actual al español.

Saludos Ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. Recordemos que el Equipo Scrum esta constituido por: El Product Owner, El Equipo de Desarrollo y el Scrum Master.

domingo, marzo 12, 2017

[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:
  • El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
  • Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
  • Expresa claramente los elementos de la Lista del Producto;
  • Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
  • Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
  • Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
  • Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
  • Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
  • Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
  • Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
  • Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
  • El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
  • Decide si libera o no el incremento
Lo anterior podríamos parafrasearlo un poco como
  • Es alguien con empoderamiento y capacidad de decisión sobre el producto
  • Es el responsable del  ROI -return on investment-
  • Es voz del cliente ante el equipo
  • Define, refina y prioriza el Product Backlog
  • Esta disponible para el equipo
  • Hace seguimiento del avance y la construcción del producto
  • Decide cuando cancelar el sprint 
  • Decide cuando salir a producción.
Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir
  • qué se hace 
  • y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
  • y qué definitivamente NO SE HACE



Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:
    • eso NO se puede hacer aún, 
    • es que necesitamos generar valor con lo mínimo posible
    • eso va para otra versión o release
    • eso aun NO tiene prioridad
    • eso NO agrega valor
    • eso definitivamente NO se hará
Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.


Cerrando

Un buen PO sabe:
  • Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
  • Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
  • Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.
NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:
  1. Que conoce que problema de negocio está resolviendo
  2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
  3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
  4. Que comprende que el NO es de las mejores formas de controlar el ROI
Bienvenido el Feeback

Saludos ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
  3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
  4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?


viernes, febrero 17, 2017

Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo



Hola a todos:

Hace poco en una sesión de acompañamiento a Scrum Master, alguien me preguntó

¿Hacia dónde seguir mejorando el equipo, pues creo que no podemos mejorar más?

Ante esta pregunta, comencé a explicar el Modelo Operativo de Generación de Valor (1) el cual se basa en:

  • Personas
  • Procesos y
  • Herramientas


Por lo tanto, si el Scrum Master se centra solo en personas y procesos "rápidamente" (tal vez en 10 sprints, tal vez muchos más, tal vez menos ) el equipo logrará sinergia y alcanzará la maestría en el manejo de Scrum, sus ceremonias, priorización del backlog, etc.,  y caerán en una "zona cómoda" en la cual la pregunta realizada tiene todo el sentido.

Bajo este contexto la frase de Ken Schwaber - cocreador de Scrum -  toma todo el sentido:

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”( no dudo que la hubiera querido terminar con otra palabra)


Es necesario entonces, que como Scrum Masters y Coaches adicionemos a los procesos de mejora del equipo las herramientas (2) -o prácticas técnicas- y lograr que los equipos adquieran la maestría en ellas, aun más que sean sanamente insatisfechos y estén siempre buscando una mejor manera de hacer las cosas. De esta forma se genera valor hacia el interior y exterior del equipo estando en constante crecimiento.

Cerrando

A continuación quiero compartirles una pequeño listado de prácticas técnicas con las que pueden y deben retar a sus equipos como Coaches Agiles que son de ellos, la lista en esta en continuo crecimiento, este es el pequeño listado que encontré a la fecha:



Herramientas (Prácticas ágiles) 

Zona 1: Personas y Herramientas
  • Inspección o revision por pares
Zona 2: Procesos y Herramientas
  • Pruebas unitarias
  • Test Driven Development (TDD)
  • Aceptance Driven Development (ATDD)
  • Refactoring
Zona 3: Personas, Procesos y Herramientas
  • Pair Programming
  • Mob Programming
Zona 4: Solo Herramientas
  • Integración Continua
  • Despliegue Continuo
  • Revisión de código estática
  • Pruebas funcionales Automatizadas
  • Principios SOLID de POO (Programación orientada a objetos)
  • Clean Code
  • Automatizar lo automatizable
  • etc, etc, etc.




Para terminar les comparto esta frase que constantemente me inquieta "los pacientes se enferman de lo que el médico sabe (3)", por lo tanto si como Scrum master o Coach no estas en constante aprendizaje de estas tres áreas no podrás ayudar apropiadamente a tu equipo


Bienvenido el feedback


Saludos ágiles
Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias


  1. Operating model - https://en.wikipedia.org/wiki/Operating_model
  2. El tablero Kanban, la Gestión Visual, etc también son herramientas, el objetivo del post es hacer visible el punto de las prácticas técnicas ágiles.
  3. "los pacientes se enferman de lo que el médico sabe" - clic aquí para ver post relacionado




domingo, febrero 05, 2017

[Scrum] Ritmo Sostenible sobre Ritmo Insostenible


Metrónomo: utilizado para indicar tiempo o compás de las composiciones musicales. Produce regularmente una señal, visual y/o acústica, que permite a un músico mantener un pulso constante al ejecutar una obra musical.(1).

Hola a todos:

He escuchado algunas veces decir esta expresión a los Scrum Masters o Product Owners:

"Equipo TENEMOS QUE DARLE A MORIR para que entreguemos todo lo comprometido en este sprint"
[BadSmell-1: Se impone al equipo el sobre-esfuerzo](2)

Desde el punto de vista de Scrum y Agile se ven varios problemas en esta frase.
  1. En Scrum los equipos trabajan en hacer la MAYOR y MEJOR cantidad de alcance (o ítems de backlog) que solicite el PO durante la jornada laboral, ni más ni menos.
  2. Es posible que durante el sprint se complete o no todo lo propuesto durante el planning, en caso de que se termine antes se solicitará más ítemes, en caso de que no se complete lo planeado se emplea el timebox para identificar en la retrospectiva por qué no se logro lo planteado y las acciones a realizar en el siguiente ciclo.
  3. (se que el comentario que sigue le dolerá a los amigos del control) En Scrum los equipos son los que deciden si sobre-esfuerzan o no - ojo, es importante no caer en el otro extremo y creer Scrum significa ser anárquicos, y no cumplir jornada laboral etc, recomiendo estos dos post acerca del tema (7)(8)-,es normal que planteemos el sobre-esfuerzo pero debe ser una decisión de equipo no una imposición, y como principio clave se debe compartir el propósito de este sobre-esfuerzo para comprender la causa y la necesidad del mismo.

Pero no todo termina allí

El problema radica en que la frase del "DARLE A MORIR" no es solo de un sprint, sino que es frecuentemente usada todos los sprints, y allí con seguridad emerge [BadSmell-2] que ni la organización, ni el Product Owner, ni el Scrum Master entienden mucho de Scrum, ni de Ágil, y estan llevando las prácticas de la gestión tradicional al contexto ágil, y pronto veremos al equipo decir:
  • "no ganamos nada con Scrum"
  • "pensábamos que íbamos a mejorar nuestra forma de trabajo y nuestra vida, y no es cierto"
  • "esto no fue lo que nos dijeron en el entrenamiento"
  • "antes -en cascada- solo nos esforzábamos al final, ahora cada dos semanas tenemos una semana de martirio"
Lo anterior denota que se olvida el principio ágil de:
"Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida." (3)

Y no estoy afirmando que esporádicamente o muy ocasionalmente no existirá algún sobre-esfuerzo(4) -realmente a veces se requiere- pero es importante comprender que los equipos necesitan cierta cadencia o ritmo para navegar con cierta comodidad - o cuasipredictibilidad - en el mar de la incertidumbre(5).

Por lo tanto este sobre-esforzar al equipo constantemente es indicador de:
  1. [BadSmell-3] El Scrum Master no esta empleando la retrospectiva como instrumento para entender por qué el desgaste constante del equipo y como salir de este círculo vicioso.
  2. [BadSmell-4] El Product Owner cree que puede pedir y exigir todo lo que quiere sin considerar la capacidad del equipo.
  3. [BadSmell-5] El equipo no es protegido por el Scrum Master de las malas prácticas
  4. [BadSmell-6] El equipo aun no es consciente de su autoorganización y de su capacidad de decir "NO" ante esta mala práctica continuada

Adicionalmente este sobre-esfuerzo frecuente llevará al desgaste del equipo y con seguridad a la desintegración del mismo o renuncia de alguno o varios de sus miembros (6).

Espero con esto haber aclarado un poco sobre este BadSmell en las organizaciones que comienzan con Scrum o aun no saben como trabajar con el.

Hasta la próxima.

Saludos ágiles
Jorge Abad.


Referencias, Aclaraciones, Comentarios y Notas

  1. Ver definición de Metrónomo en Wikipedia - clic aquí.
  2. Usaré la etiqueta BadSmell para resaltar lo que son malas prácticas
  3. Ver los principios -aquí-.
  4. Un post sobre el sobre-esfuerzo que escribí hace un muy buen tiempo - clic aquí -.
  5. Principios de Incertidumbre de Requisitos, Procesos y Productos de Software - clic aquí-.
  6. Dice Sun Tzu en el arte de la guerra: "Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."
  7. ¿Que significa autoorganización en Scrum? (Clic aquí)
  8. Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado (Clic aquí)

lunes, enero 30, 2017

La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?






Hola a todos

Dentro de las muchas ocasiones en las que comparto con clientes, equipos, product owners, scrum masters o personas que van a comenzar a trabajar en Agile una pregunta recurrente es:

¿Cómo hago para que el proyecto no se salga de control?


Vamos por partes entonces:

¿Qué se quiere decir con la pregunta?

La Rae define control como (Ver definición - clic aquí):


y cuando un cliente o gerente, lider funcional, product owner, o gerente de proyecto pregunta esto se refiere típicamente a esto:

¿Cómo hago para que el proyecto no cueste más, no se demore más, se construya realmente lo que se requiere o no se quede eternamente consumiendo recursos(1)?

Poniendo este tema en blanco y negro, comencemos.

No es que exista mucho control con los proyectos en cascada 

En el informe del caos los proyectos en cascada no salen muy bien librados versus los ágiles, los cuales muestran un resultado más satisfactorio en cuanto tiempo y costo.(https://www.infoq.com/articles/standish-chaos-2015 )



Dado esto:
  • La probabilidad de cumplir estas expectativas es más alta en Ágil que en Cascada, ahora respecto a que el proyecto se vaya a desbordar el problema existe en cualquiera de los dos enfoques, el problema radica en el mecanismo para estar informados si vamos a lograr o no la meta propuesta y reaccionar a tiempo.
  • Los proyectos en cascada cuando se salen de control - de tiempo o costo- (el alcance lo tienen garantizado, tal vez se construya lo que NO se necesita - como ocurre en muchos casos - pero esta garantizado el "qué") o costarán más o nos demoraremos más (ambas son dinero para alguien), el punto clave es que tan diestro es el proveedor para gestionar los cambios:
    • si el proveedor es experimentado o tiene un buen gerente de proyectos el sobrecosto lo asume el cliente, sino 
    • el sobrecosto lo asume el proveedor, caso más común.
  • En cascada (y muchos lo hemos vivido) el proyecto y el cronograma va bien hasta la parte de análisis (como diría un conocido mío: "el papel aguanta todo", todo se complica cuando comienzan las fases de desarrollo, la fase de pruebas con informes de avance que del 90% luego a las tres semanas 90.3% , a las 4 semanas 90.38% y el proyecto se demora un 90% del tiempo cerrando el 10% faltante del alcance (fruto de la procrastinación o postergación del proceso en cascada) y si logramos entregar el proyecto terminamos entregando el producto tardíamente a nuestros clientes o al mercado, tal vez cuando ya no lo necesitan o cuando las condiciones iniciales que dieron origen al proyecto cambiaron.
La verdad, a lo anterior yo no llamaría control


Cómo se "controlaría" un proyecto en ágil

Ahora respecto a la comprobación, inspección, fiscalización, intervención. del cual habla la RAE, se tienen varias soluciones:

1. La Transparencia

En ágile nos enfocamos en valernos de radiadores de información que nos permitan tomar decisiones informadas y todos conocer como está el proyecto y producto en cualquier momento:

  • Burndown chart del Sprint
  • Burndown o burn up release (clic aquí)
  • Flujo Acumulativo
  • Velocidad
  • entre otros

2. La brújula de la agilidad es la simplicidad

Comencemos recordando el décimo principio del manifiesto ágil:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo

Nuestra mayor prioridad es NO generar ni software ni trabajo de desperdicio (o hacer algo que terminará siendo inutil)


3. En Scrum existen tres roles que te pueden ayudar a tener "control" de tu proyecto / producto, en cuanto tiempo, costo y alcance.

Product Owner (PO)
En primer lugar el PO es quien esta encargado dentro de sus funciones de dos aspectos claves:

  • ROI (Return On Investment): Preocupado por salir a producción con la menor cantidad de software posible que solucione el problema de negocio
  • DECIR NO (5): El PO al negociar con los stakeholders (interesados) les debe decir para ciertas funcionalidades:
    • eso no se puede hacer aún, 
    • necesitamos generar valor con lo mínimo posible
    • eso va para otra versión o release
    • eso aun no tiene prioridad
    • entre otras.
Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de software.

Scrum Master (SM)
El otro rol es el Scrum Master, este es el coach del PO y estará atento a que quien esta ejecutando este rol lo haga bien y este preocupado sanamente por mantener un product backlog refinado y priorizado.

El Equipo Desarrollador (Development team, o equipo solucionador)
Y por si fuera poco, es una buena practica que cada Relase tenga un objetivo (3)(4), por lo tanto cuando el PO este "corrompiendo el alcance" - como dicen el el mundo PMBoK - por añadir lo que no es clave para el proyecto, tanto SM como Equipo Desarrollador se lo harán ver.

Adicionalmente existe el Review
Cada sprint (ciclo de trabajo entre 2 y 4 semanas) el equipo Scrum - PO, SM y Equipo Desarrollador -  más los Stakeholders del proyecto se reúnen a ver el demo del sprint -a ver software funcionando cumpliendo la definición de terminado- , ha realizar inspección y adaptación sobre el producto y a decidir como seguir avanzando sobre el mismo, de manera que no hay sorpresas y el progreso o no progreso es evidente para todos.

Y si es que lo anterior no funciona
Ahora si ves que el proyecto no lo va a lograr..
  1. Desde las primeras dos semanas tuviste software funcionando 
  2. Suspende el proyecto y fin de la historia.

Cerrando

Los proyectos y productos que son construidos con el enfoque ágil pueden darnos suficiente información sobre su estado y nos permitirán tomar decisiones informadas sobre el éxito y fracaso de los mismos,  depende de nosotros emplearlos o no. En cascada si decides interrumpir el proyecto es probable que no tengas al final ni siquiera software funcionando pues depende mucho de la fase en que se interrumpa o finalice abruptamente el proyecto

Hasta acá esta pequeña reflexión, espero sea útil.

Bienvenido el feedback y sus comentarios

Saludos ágiles

Jorge Abad

Referencias, Comentarios, Notas y Aclaraciones

  1. Entendiendo recursos como dinero y tiempo invertido por las personas o empresas
  2. http://agilemanifesto.org/iso/es/principles.html
  3. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?-  http://www.lecciones-aprendidas.info/2016/04/la-zona-del-valor-de-negocio-una.html 
  4. Go Product Map -  http://www.romanpichler.com/tools/product-roadmap/
  5. Este post está altamente relacionado con este: El valioso "NO" del Product Owner



lunes, enero 23, 2017

Algunas Frases para Product Owners

















































jueves, enero 05, 2017

Mi punto de vista: ¿Bimodal un punto medio entre la agilidad y la predictibilidad?


En la actualidad la Banca, los Seguros (y hace algún tiempo el Transporte, La Hotelería) entre otras industrias están sufriendo grandes cambios debido a la fuerte disrupción digital (1), la velocidad a la que está avanzando la tecnología, la economía, las comunicaciones es tal, que "estos negocios cambian o se convertirán en otro caso de estudio" (ver tweet).

Como medio de apalancamiento las organizaciones han decido abrazar la agilidad como herramienta para enfrentar el cambio, pues en sus fundamentos y pilares están los factores de éxito de los negocios que están cambiando las reglas de juego. Por lo tanto, no se adopta la agilidad como una evolución natural hacia la generación de valor en periodos cortos con equipos multifuncionales y felices (cosa impensable y que no estaba en el core de sus intereses), sino que se llega a ella como salida hacia la supervivencia, razón por la cual muchas organizaciones quieren comprar la agilidad por kilos, sin comprender que se requieren esfuerzos para transformar la cultura para lograr ser exitoso en este enfoque.

Debido a esto - es mi observación -  es común ver como organizaciones al hablarles de Agile, preguntan más sobre bimodal,
"Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability. Both play an essential role in the digital transformation."  http://www.gartner.com/it-glossary/bimodal/

pues no quieren soltar el esquema tradicional y quieren poner un "if o condicional" para determinar cuando adoptar el uno o el otro, pues no entienden los beneficios entre Ser Ágil y Hacer Ágil. (obvio para eso estamos los de este mundo para ayudar a comprender esta diferencia)



¿Por qué entonces trabajar en Agile?

Existen varias razones

  1. La ley de la incertidumbre de los requisitos: “Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después de que los usuarios hayan usado el sistema" Watts S. Humphrey” (3)
  2. La incertidumbre inherente en productos y procesos de software "“La incertidumbre es inherente e inevitable en los procesos y productos del desarrollo de software”(3)
  3. La cantidad de software de desperdicio que se construye en cascada (4)
  4. La inestabilidad de los requisitos y su volatilidad convirtiéndolos casi en material radioactivo que se degrada con el tiempo. Actualmente el tiempo promedio de vida de un requisito está en 6 meses- o tal vez o menos -.(5)
  5. La velocidad de cambio en el mundo de los negocios (1)
  6. La posibilidad de ver el producto funcionando en dos semanas o menos y poder redireccionar y repriorizar hacia el problema que quiere resolver el producto de software que vamos a construir.



Para complementar comparto algunos links a post comparativos:

  • Por qué los Equipos Scrum son más “rápidos” que los tradicionales. Un enfoque desde Lean Software Development (clic aquí)
  • Waterfall vs Agile (clic aquí)
  • Gráficas Ágil vs Tradicional (clic aquí)
  • El Lego y la plasticidad del software (clic aquí)


En que proyectos se recomienda cascada

Gráfica de Henrik Kniberg
Sugiero se cumplan ciertas premisas
  • El cliente sabe exactamente que es lo que quiere
  • Los desarrolladores son conocedores del negocio y de la tecnología
  • No haya incertidumbre, se sabe exactamente lo que se quiere
  • El tiempo transcurrido desde que el proyecto comienza el tramite para su aprobación y la finalización de su desarrollo es inferior a seis meses, de forma que se evite la corrupción de requisitos por el tiempo de levantamiento o identificación de la necesidad superior a seis meses(5)
  • Yo sugiero proyectos de máximo tres meses cuyos requisitos no tengan más de 3 meses de haber sido levantados.

Además recordemos que:



Concluyendo


Dado lo anterior, la inestabilidad de requisitos, el entorno cambiante, la incertidumbre reinante, y la sugerencia de realizar proyectos en cascada para periodos menores a tres meses, observo que:
  • El enfoque bimodal es más una herramienta de transición entre modelo tradicional o cascada al modelo ágil, que un "if-condicional" para clasificar diferentes tipos de proyectos, pues por un tiempo, ambos modelos convivirán- ágil y cascada- (6), y llegará el momento en que la organización concluya por sus propios medios si es conveniente que sigan ambos o desaparezca uno de los dos.
  • El modelo bimodal no es sostenible en el tiempo, pues la evolución los sistemas existentes requerirá de repriorizaciónes de backlog en los cuales ágil es mucho más eficiente.
  • Para que el modelo bimodal sea exitoso requeire de  procesos ágiles de priorización y aprobación de proyectos, sino cuando se construyan ya sea los proyectos tradicionales o ágiles será tarde para el negocio o el mercado.
  • Es importante hacerse acompañar por quienes tengan experiencia en ágil para no fallar y realizar malas transformaciones y adopciones, y que por ende se lleguen a conclusiones y resultados erróneos que no reportarán todo el beneficio de Agile.
  • Cada organización debe encontrar su ritmo, su cadencia, su mejor forma de transformarse a Agile, que le permita aprender de si misma, de su cambio cultural para realizar procesos de cambio exitosos
Bienvenidos los comentarios y apreciaciones


Saludos Ágiles
Jorge Abad


Notas, Comentarios, Aclaraciones y Referencias

  1. Empresas tradicionales: llegó la hora de desprenderse del pasado o desaparecer. Revista Dinero (clic aquí).
  2. Manifiesto Ágil (clic aquí)
  3. Post: Principios de Incertidumbre de Requisitos, Procesos y Productos de Software (clic aquí)
  4. http://versionone.com/assets/img/files/ChaosManifesto2013.pdf: "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. " 
  5. Post: Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software (clic aquí)
  6. Es mejor realizar una transformación guiada por pilotos y casos de éxito en los cuales la organización encuentre su mejor forma de SER ÁGIL, que una transformación big-bang que trae consigo una gran entropía al sistema y requiere de una gran cantidad de energía (Coaches, Scrum Masters, Agentes de Cambio) para estabilzarlo




domingo, diciembre 25, 2016

Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning



Hola a todos

Uno de los primeros retos que enfrenta un Scrum Master con su Equipo es realizar el primer planning, pues para este no hay velocidad anterior (1), quiero compartirles tres propuestas de como se hace este cálculo, las cuales son muy sencillas, pues la verdad en la agilidad preferimos invertir más tiempo en el desarrollo de software que en la estimación que a la larga siempre fracasamos en ellas y terminan siendo un desperdicio.

Demos inicio.


Datos de entrada
  • Un equipo multifuncional de 6 personas
  • Un Product Owner (obviamente, no esperaría menos)
  • Un Scrum Master (obviamente, no esperaría menos)
  • Un sprint de 10 días)
  • Días de reuniones del sprint: 1.5 días aproximadamente  (ver tabla de tiempos reuniones de Scrum - clic aquí -)
    • Planning medio dia
    • Review y retrospectiva medio día
    • Refinamiento máximo el 10% del tiempo del sprint
  • Días efectivos del sprint: 8.5 días (8.5 días = 10 días del sprint - 1.5 días de reuniones)
  • Días-persona disponibles para el producto: 51 días-persona/sprint 
    • (8.5 días x 6 personas = 51)

Método 1: Un día-persona es igual a un punto (punto de historia)

Los pasos son los siguientes:
  1. Determino cuantos días-persona tengo (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que los hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 2 días de esfuerzo entonces son 2 puntos (o puntos de historia)
  5. Y la velocidad máxima que tendrá ese equipo en este sprint y en los demás sprints será de 51 puntos
  6. Luego se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas

  • Para toda la organización y todos los equipos la medida es única (1 día-persona = 1 punto)
Desventajas
  • Los equipos tienen velocidad estática, aunque mejoren sus procesos, interacciones, forma de trabajo, se automaticen tareas repetitivas su velocidad será siempre la misma
  • Serán fiscalizados en función los puntos que son capaces de lograr debido a la cantidad de integrantes y presionados a lograr el 100% de lo comprometido


Método 2: Un punto (punto de historia) es igual a una funcionalidad pivote

  1. Determino los días persona (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que las hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 3 días de esfuerzo 
  5. Se considera esa funcionalidad será el pivote y es igual a 1 punto y que estimemos relativamente el resto de las historias de usuario o pantallas según el caso.
  6. La velocidad esperada ese primer sprint será = 17 puntos (51 días-personas/3 días =17 puntos) 
  7. Para la siguiente historia saco el lapicero de Will Smith de Men in Black y pido que miren fijamente, diciéndoles que olviden el cálculo 1 punto es aproximadamente 3 días y que sigamos pensando solo en la pantalla y estimemos relativamente respecto este pivote.
    Equipo por favor miren a acá un momento y olviden que esta historia de usuario toma 3 días.
  8. Se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Los equipos encuentran mejores formas de interactuar y de resolver los problemas con el tiempo, por lo tanto con seguridad habrá aumento de velocidad y esta pantalla que en inicio tomaba 3 días es probable que al sexto sprint tome menos viendo la organización de forma tangible la mejora del equipo.
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar

Método 3: "Ojo de buen Cubero" o "nos comprometemos hasta aquí"

  1. El equipo escucha las historias en orden, resuelven el qué y el cómo de cada una de ellas.
  2. hasta un momento donde el equipo dice: "Somos capaces con estas historias, paremos el planning"
Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Es necesaria la confianza en el equipo
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar

Concluyendo

De estos tres métodos sugiero más al método 2 (aunque por años usé el método 1) y con equipos maduros al método 3. Espero que este post les sea de ayuda en su primer planning,

Saludos ágiles

Jorge Abad



Notas, referencias, comentarios y observaciones

  1. Para la estimación de la velocidad o capacidad del segundo sprint se usa un concepto que se llama “el clima del dia anterior”, y se basa en la premisa si ayer hizo un clima es muy probable que hoy haga el mismo clima, si el sprint pasado hicimos 30 puntos es muy probable que estemos cercanos a ese puntaje, entre 25 y 35, ya es potestad del Equipo y del ScrumMaster si van más allá o nó. Lectura Recomendada Comprometiéndonos un poco más allá en el planning - clic aquí- )
  2. Obvio es probable que entre una actividad y otra toque esperar un tiempo, pero nos estamos refiriendo solo a tiempo de trabajo y no se incluyen tiempos de espera)
  3. Se sugiere en días, pues  de esa manera se amortiguan las malas estimaciones.
  4. Lectura recomendada:Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad (clic aquí)
  5. Libro recomendado: Scrum y XP desde las trincheras (clic aquí)

domingo, diciembre 18, 2016

Tan cerca, Tan lejos. Una Comparación entre el Agile Inception y el Acta de Constitución del Proyecto (Project Charter) del PMBok



Hola a todos
Desde hace un tiempo me debía a mí mismo y a ustedes la escritura de este post, pues en numerosas ocasiones durante los entrenamientos de Scrum o Gerencia de Ágil de Proyectos he hecho esta comparación, y es bueno dejarla plasmada para ayudar mejor a la ilustración de lo que quiero decir.

Los Dos Mundos, el Predictivo y el Ágil

Dentro de los 47 procesos de la gerencia de proyectos del PMBoK (versión 5) existe el primer proceso llamado “4.1 Desarrollar el Acta de Constitución del Proyecto” (este proceso pertenece a los procesos de inicio) que cuenta básicamente con los siguientes aspectos
·         Objetivo
o   “Es el proceso de desarrollar un documento que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto”(1)
·         Entradas
o   Enunciado del trabajo del proyecto
o   Caso de Negocio
o   Acuerdos
o   Factores ambientales de la empresa
o   Activos de los procesos de la organización
·         Herramientas y Técnicas
o   Juicio de Expertos
o   Técnicas de Facilitación(2)
·         Salidas
o   Acta de constitución del proyecto
Y sugiere documentar los siguientes aspectos (1):
·         El propósito o la justificación del proyecto,
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Los riesgos de alto nivel,
·         El resumen del cronograma de hitos,
·         El resumen del presupuesto,
·         La lista de interesados,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto),
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.
Para mayor ilustración sugiero leer este articulo del PMI Colombia (Acta de Constitución del Proyecto) y este excelente ejemplo (Ejemplo Acta de inicio del Proyecto)
Ahora, si realizamos los talleres de Agile Inception (Inicio Ágil – en español) como los sugieren:
·         The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) de Jonathan Rasmussone (clic aquí)
·         Inceptions. Starting a Software Project de Enrique Comba Riepenhausen (clic aquí)
Encontramos que sugieren en un taller de 2 a 3 días obtener lo siguiente
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         Diseñar la caja de producto
·         Crear el Product Backlog Board(3)(4)
·         Crear la lista de No
·         Encontrar tu comunidad
·         Que te mantiene despierto en la noche
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         Story Mapping (Plan de Releases)
·         Qué vamos a obtener (Restricciones, Prioridades, Beneficios)
·         Cuánto va a costar y cuánto nos va a tomar

Y si comparamos ambos
Realizando la comparación de ambos, se tienen muchas coincidencias:
Agile Inception
Acta de Constitución del Proyecto (PMBoK)
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Aplica parcialmente, no siempre es un taller.
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         El propósito o la justificación del proyecto,
·         Diseñar la caja de producto
·         Product Backlog Board
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto -  esta última parte no corresponde a un inception - ),
·         Crear la lista de No
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Encontrar tu comunidad
·         La lista de interesados,
·         Que te mantiene despierto en la noche
·         Los riesgos de alto nivel
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         La descripción de alto nivel del proyecto y sus límites,
·         Story Mapping (Plan de Releases)
·         El resumen del cronograma de hitos,
·         Que vamos a obtener (Restricciones, Prioridades)
·         Los supuestos y las restricciones,

·         Cuánto va a costar y cuánto nos va a tomar (estos valores son aproximados, nunca cerrados)
·         El resumen del presupuesto,
·         No aplica
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         No aplica
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.


¿Entonces en dónde radica la diferencia?

En esencia, se observa que es lo mismo para ambos tipos de iniciativas (predictiva o ágil), aún más el PMBoK sugiere que sean talleres facilitados y no dudo que algunos gerentes de proyecto lo hagan así, pero lo que si es cierto es que en Agile es necesario (por no decir obligatorio) que sea un taller y que se maximice la comunicación cara a cara como lo sugiere el manifiesto ágil y sus principios (5) para garantizar el éxito de lo que se va a realizar.
Adicional en proyectos tradicionales (en los cuales la planeación predictiva es ideal):
-          Construcción de edificios
-          Construcción de puentes
-          Construcción de carreteras
-          Ampliaciones de fábricas
-          Construcción de barcos
Se hace hasta lo imposible por cerrar el alcance y no dejar lugar a la incertidumbre, pues el costo de los cambios es altísimo (¿o no creen que un dos nuevos carriles en la carretera o 2 pisos más en el edificio, fuera de afectarán gravemente los planes, cambiará el diseño de temas importantes?), cosa muy distinta en desarrollo ágil donde el software es más maleable y  donde somos tenemos una arquitectura base sobre la que podemos evolucionar.
Para cerrar esta pequeña comparación, les comparto esta tabla en donde presento las principales diferencias de ambos enfoques:

Agile Inception
Acta de Constitución del Proyecto (PMBoK)
Propósito principal

No es el objetivo del Inception, esto debe ser resuelto antes.
Autoriza formalmente la existencia de un proyecto
No tiene como objetivo entregar Autoridad.


confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto
Es un taller que permite a los interesados y al posible Product Owner(PO):
·         Entender la idea que se tiene a un nivel más profundo
·         Identificar las posibles dificultades del proyecto
·         Decidir si se continuará o no con el mismo
·         Proporciona al PO y a sus Interesados información suficiente para guiar al equipo de desarrollo en la construcción del producto
No corresponde a su objetivo primordial
Respecto al alcance
Se busca tener una primera versión u hoja de ruta sobre las cuales realizaremos la construcción del producto mínimo viable (MVP - http://www.lecciones-aprendidas.info/search/label/mvp ) y seguiremos creciendo incrementalmente hasta que construyamos el producto que requiere el negocio.
Se centra en esbozar el alcance va a detallar y gestionar en las siguientes grupos procesos de la gerencia de proyectos:
·         Planeación
·         Ejecución
·         seguimiento y control
·         y cierre
Transparencia
Esta información queda disponible al lado del equipo del proyecto para que sirva como radiador de información y le sirva para tomar decisiones
Muchas veces no es un taller, se comparte con el equipo y los interesados del proyecto, pero no se garantiza que todos la conozcan aunque se sugiere que todos la dominen.

Hasta acá esta corta comparación, los invito a profundizar en estos links
-          Sprint Cero o Agile Inception
-          Colección de entregables generados en un Inception

Bienvenidos sus comentarios y feedback.

Saludos Ágiles, 

Jorge Abad        


Notas, aclaraciones, referencias

1.       Guía de los Fundamentos para la Dirección de Proyectos. Guía del PMBoK Quinta Edición.
2.       Se enumeran entre varias posibles actividades: la tormenta de ideas, resolución de conflictos, gestión de reuniones para realizar la obtención de este entregable.
3.       Aunque no Corresponde a una propuesta de Agile Samurai o Inceptions, es ampliamente usado y recomendable para este proceso
4.       Ejemplos del Product Backlog Board - http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board
5.       http://agilemanifesto.org/iso/es/principles.html - “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.”,  “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.”