¿Por qué Los Agilistas como los Gatos Siempre Caemos Parados?

Hola a todos

Dentro de mi trabajo de acompañamiento a equipos y proyectos ágiles tengo dos frases acuñadas que repito con cierta frecuencia, que van por lo general una después de la otra:

<<es que los agilistas somos como los gatos "siempre caemos parados">>

 ----

<<y la verdad no se que hacer en este caso, nos toca tomar una decisión, hacer un experimento y realizar  "inspección y adaptación"(1)(2) para determinar si fue lo mejor o no.>>

Y la verdad no es que no tenga respuesta y use "inspección y adaptación" como muletilla de mi lenguaje o como escape ante una pregunta difícil, lo cierto es que estamos en la mayoría de las veces en los proyectos de software en entornos de incertidumbre donde no tenemos la seguridad de como será el resultado ante una práctica o solución propuesta, y tal como lo expone Cynefin (3), debemos revisar el resultado en retrospectiva y la respuesta será una práctica emergente que solo es útil en el contexto de ese proyecto en específico.

Obvio es necesario saber de métodos, frameworks, prácticas ágiles, el por que están allí, para que sirven, que tipo de problema quieren resolver para recomendar que hacer, que no hacer o simple y humildemente decir:

"La verdad no sé que hacer en este caso, nos toca elegir un camino y hacer luego inspección y adaptación" 

pues quienes hemos recorrido un poco de este camino hemos aprendido otra máxima universal:

"Lo que aplica para un equipo - o contexto - no necesariamente aplica para otro"

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Tengo un amigo coach que me dice, "Jorge no conozco a nadie que use tanto esa frase como vos"
2. La gestión empírica de proyectos esta basada en los pilares de inspección y adaptación.
3. Te recomiendo este post a cerca de Cynefin: Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos- clic aquí)

Demostrando el Valor Económico de Ejecutar Proyectos de Manera Ágil (Datos Hipotéticos)

Hola a todos


Hace poco alguien me preguntaba como demuestro el valor económico de ejecutar un proyecto en ágil versus uno tradicional. Dado este reto me dí a la tarea de crear este ejemplo hipotético basado en la experiencia de muchos proyectos ejecutados en ágil y en tradicional.

Datos de entrada

• Proyecto Tradicional (fila 1 a la 10 de la tabla)
• Tiempo formulado: 10 meses 
• Costo inicial: $500
• Tiempo adicional: 10 meses (por lo general los proyectos grandes fallan en grande y toman el doble del tiempo y del costo)
• Costo adicional : $500 (en color rojo)
• Valor total proyecto $1.000.
• Salida a producción: Mes 21
• Luego de estar el proyecto en producción alguien determinó que el beneficio era por 80 mensual
• Proyecto Ágil (fila 13 a la 24 de la tabla)
• Tiempo formulado: 10 meses
• Costo inicial: $500
• Tiempo adicional: 4 meses 
• Costo adicional : $200(en color rojo) (se decide ir un poco más allá del presupuesto para hallar todo el valor de negocio esperado)
• Valor total proyecto $700
• Salida a producción Release 1: mes 5. Beneficio producido 30
• Salida a producción Release 2: mes 8. Beneficio producido y acumulado 50 
• Salida a producción Release 3: mes 15. Beneficio producido y acumulado 80

Descargar Excel - Clic Aquí

Resultados obtenidos

• Los indicadores de TIR, Punto de Equilibrio, Ingresos netos en tres años, son mucho más favorables en Ágil que en Tradicional.
• En ágil se puede generar el mismo impacto con menos valor en producción debido a que el alcance construido en ágil se enfoca en solucionar un problema de forma incremental y no en resolver el problema con un alcance definido al inicio que no se sabe si cumplirá con las expectativas del cliente.

Aclaraciones

Es importante aclarar que he estado en proyectos donde:

• El valor de negocio se ha encontrado antes del presupuesto y fecha esperada, y para esto es clave un excelente Product Owner orientado por el valor de negocio, el ROI y no por satisfacer un alcance.
• Y tambien he fallado haciendo ágil en escenarios donde:
•  el cliente no entendía la metodología 
• y donde bajo un proyecto con alcance, tiempo y costo fijo y un contrato desventajoso, montamos ágil para mitigar riesgos pero aun así no logramos cerrarlos

En conclusión

• El éxito de un proyecto ágil esta dado por la estrategia para construcción del producto definida por el Product Owner, (Sin descuidar la excelencia técnica -Sin excelencia técnica no hay agilidad).
• Aunque este solo fue un ejercicio académico, el resultado de hacer ágil no es solo económico, existen entre otros:
• mejor satisfacción del cliente
• mayor visibilidad
• mejor gestión del riesgo
• Incremento en la felicidad del equipo
• ver más en http://stateofagile.versionone.com/

10th State of Agile 2015 - Versionone

Y para cerrar una idea

Ya le hemos dado muchas oportunidades a la forma tradicional - o cascada-  de hacer proyectos de software y hemos perdido, tiempo, dinero, clientes, amigos, trasnochos, ingenieros que han renunciado y familias que se han desintegrado(1), entonces ¿qué te impide hacer tu próximo proyecto de forma ágil?

Aclaraciones

1. Este dato lo he comprobado en dos ocasiones, en los que el ingeniero desarrollador me compartió que no estuvo por más de un año en su hogar, pues trabajaba de continuo sábados, domingos y festivos  en un proyecto, siendo esta  una de las causas raíces para que se generara el divorcio y por ende la desintegración de su familia.

[Agenda Scrum] Pasos para Realizar el Refinamiento

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Refinamiento(2), actividad que se sugiere realizar en la mitad del sprint:

1. El Scrum Master (SM) comparte el propósito, dinámica y timebox de la sesión
2. El Product Owner (PO) comparte el objetivo del siguiente o subsiguientes sprints
3. El PO comparte cada una de las historias de usuario con el Team
4. El Team hace preguntas buscando que las historias estén en Ready (3) para el planning correspondiente ( requisitos claros, tecnología y herramientas claras, dependencias externas resueltas)
5. El PO responde las preguntas
6. En caso de que el PO no pueda responder una pregunta, toma nota para resolverla para el planning en que está programada
7. El Team puede realizar sugerencias sobre estrategias de construcción del proximo Sprint Backlog, el PO decide si las acoge o no.
8. Cuando se terminen las historias planeadas a compartir se termina la reunión.
9. Actualizar las herramientas de gestión.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo
2. Esta reunión no tiene como objetivo escribir las historias de usuario, aunque algunas pueden ser escritas, divididas o fusionadas.
3. Recomiendo este post - La Definición de “Ready” es tan importante como la Definición de “Done”

[Agenda Scrum] Pasos para Realizar la Retrospectiva

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para la Retrospectiva:

• Antes del Review identifique que retrospectiva quiere realizar con su equipo  y que objetivo quiere lograr, una buena herramienta para planear una retrospectiva es Retromat (http://plans-for-retrospectives.com/)
• En la retrospectiva siga los siguientes pasos
1. El Scrum Master (SM) Explique el propósito de la sesión y el Timebox que se tiene para ella y los pasos a seguir.
2. Arme el escenario (identifique como entran las personas a la retrospectiva)(3)
3. Recolecte y presente datos
• ¿Se cumplió el objetivo del sprint?
• ¿cuántos puntos e historias se lograron?
• ¿cuál fue la calificación del Product Owner (PO) para el Sprint?
• ¿cómo estuvo la calidad y la deuda técnica?
• ¿funcionó o no la mejora planeada para este sprint?¿que resultados se obtuvieron?
• use una activdad para obtener temas de sensaciones, efectividad como equipo, efectividad tecnica (3)
4. Indagar y logre un entendimiento profundo  de que fué lo que pasó, por que les fue bien o no tan bien como lo esperaban(3)
5. Decidir que hacer, (3)
• elijan los siguientes pasos a seguir 2 o 3 mejoras a realizar
• cree un plan evidenciando
• quien
• que (experimento)
• cuando
• resultado esperado
• resultado obtenido (util para el punto 3)
6. Cerrar o culmilar la retrospectiva (3)
7. Actualizar las herramientas de gestión.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo
2. Este post esta basado en las sugerencias de Ester Derby y Diana Larsen - Agile Retrospectives  
3. Puede usar una activdad de Retromat (http://plans-for-retrospectives.com/)

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para la Revisión o Review:

Forma 1: El equipo entrega el producto al Product Owner (PO)

1. El Scrum Master (SM) comparte el propósito de la reunión, timebox y pasos a seguir.
2. El SM invita a que el equipo muestre el incremento al PO y los interesados
3. El Equipo muestra cada una de las historias planificadas que fueron terminadas en un orden que sea coherente para el PO y los interesados
4. El PO puede solictar que muestre algún caso o funcionamiento en especial (recordar que no es una reunión de testing, sino de muestra de lo logrado)
5. El PO acepta o rechaza la historia de suario, y se retorna al paso 3 hasta que se completan todas las historias de usuario
6. El SM solicita al PO la calificación del Sprint (ver más en - http://www.lecciones-aprendidas.info/2016/09/tip-de-scrum-la-calificacion-del-po-al.html)
7. El SM solicita a los interesados, developers y PO retroalimentación hacia el product backlog (cambios, eleminaciones, repriorizaciones)
8. Se actualizan las herramientas de gestión.

Forma 2: Como lo propone la Guía de Scrum (http://scrumguides.org/)

1. El Dueño de Producto explica as los interesados qué elementos de la Lista de Producto se han “Terminado” y cuales no se han “Terminado”;
2. El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas;
3.  El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” (increments) y responde preguntas acerca del Incremento;
4. El Dueño de Producto habla acerca de la Lista de Producto en su estado actual. Proyecta fechas de finalización probables en el tiempo basándose en el progreso obtenido hasta la fecha (si es necesario);
5. El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para reuniones de Planificación de Sprints subsiguientes (retroalimentación al product backlog).
6. Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación; y,
7. Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

[Agenda Scrum] Pasos para Realizar un Daily

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Daily:

1. El Scrum Master (SM) comparte el propósito de la reunión, timebox y pasos a seguir
2. El SM invita a que alguien tome la palabra y pone a contar el cronómetro
3. Un team member toma la palabra y contesta las tres preguntas que pueden ser
• Opción 1: las preguntas populares
• ¿Qué hice ayer?
• ¿Qué voy a hacer hoy
• ¿Qué impedimientos tengo?
• Opción 2: las preguntas de la guía de scrum -(http://scrumguides.org/)
• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?
• Opción 3: Enseñadas por Carlos Gil - @cafegifo
• ¿Qué logré ayer?
• ¿Qué voy a lograr hoy?
• ¿Qué me lo está impidiendo?
• Opción 4: Guía Scrum 2020
• ¿Cómo son mis tareas de hoy?¿si creo que vamos a lograr el objetivo del sprint?¿y cómo podemos hacerlo?
4. A la par el SM toma nota de los impedimentos
5. Luego le da la palabra a otro team member, retornando al paso 3 hasta que todos los team members del equipo de desarrollo del producto hayan contestado el daily
6. El SM comparte cuanto tiempo fue invertido en el daily
7. El SM dice fin del daily
8. El SM realiza una invitación similar a la siguiente: "quien requiera solucionar temas con sus compañeros o pueda solucionar temas lo invito a quedarse para resolverlos, de resto pueden retornar a sus actividades"
9. Se actualizan las herramientas de gestión

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

[Agenda Scrum] Pasos para Realizar un Planning

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Planning

Forma 1: A cada historia se estiman sus puntos y tareas a la vez

1. Preparar la reunión
2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
4. El Produt Owner(PO) comparte el objetivo del Sprint
5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
6. El PO lee la historia de usuario
7. El equipo hace preguntas
8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
10. Se identifican las tareas técnicas para realizar la historia de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
11. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
12. Se valida si la capacidad del equipo es alcanzada en horas y en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario
13. Si la capacidad en horas o puntos es alcanzada se finaliza el Planning
14. El SM comunica entonces:
1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
2. las historias planeadas
3. las fechas para refinamiento, review, retrospectiva.
15. Se actualizan las herramientas de gestión

Forma 2: A todas las historias se les estiman sus puntos y luego sus tareas

1. Preparar la reunión
2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
4. El Produt Owner(PO) comparte el objetivo del Sprint
5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
6. El PO lee la historia de usuario
7. El equipo hace preguntas
8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
10. Se valida si la capacidad del equipo es alcanzada en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario.
11. Si la capacidad  puntos es alcanzada se identifican las tareas técnicas para realizar todas historias de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
12. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
13. Se valida que la capacidad en horas no sea superada, en caso de ser superada se informa que es requerido remover una historia de usuario al PO
14. El PO elige que historia no hace parte del sprint
15. El SM comunica entonces:
1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
2. las historias planeadas
3. las fechas para refinamiento, review, retrospectiva.
16. Se actualizan las herramientas de gestión

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo