jueves, diciembre 28, 2017

Tipos de Salida de una Retrospectiva



Hola a todos

Hace un tiempo leí un gran post de  Damian Buonamico - Retrospectivas Ágiles: No sólo Accionables - que referencio frecuentemente en mis entrenamientos de Scrum, en el Damian explica que de toda retrospectiva hay como resultado

  • Tareas (o acciones)
  • Acuerdos de equipo 
En esa misma taxonomía yo quisiera añadir, como muchos ya lo han expresado un tercer elemento que no pueden perder de vista los equipos ágiles,
  • Los experimentos
Basado en lo anterior, entremos pues en  las definiciones:

Las tareas: son acciones que tienen inicio y fin, y un resultado claramente definido, ejemplos
  • Migrar de servidor la base de datos pues su memoria se esta copando
  • Actualizar la versión del framework
  • Mover el tablero de ubicación
  • Crear un tablero kanban para mejoras
Las tareas dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los acuerdos: son conductas, políticas, actividades o procesos que un equipo decide realizar frente a diferentes circunstancias, ejemplos:
  • De ahora en adelante después del planning los PO y los testers se reunirán a identificar cual va a ser la estrategia de pruebas del sprint.
  • Si alguien va a salir temprano por alguna razón laboral o no, deberá pedirle autorización al equipo y garantizar que el equipo queda enterado sobre los pendientes, acciones a realizar y la persona queda localizable para solucionar alguna duda.
Los acuerdos dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los experimentos:  Aunque podrían ser tareas, su resultado no es predecible y  puede ser apropiado, inapropiado, o indiferente para el equipo.

Es recomendable que para todo experimento se tenga:
  • Responsable
  • Fecha o cuando se ejecutará
  • Resultados esperados
  • Resultados obtenidos
Algunos ejemplos de experimentos pueden ser:
  • Probar pomodoro como técnica para gestión del tiempo del equipo
  • Determinar si el uso de un determinado framework acelera o reduce la velocidad de desarrollo
  • Realizar pair programming y validar si la tecnica es adoptada por el equipo o no.
Los experimentos dentro del framework de Cynefin se encontrarian en el terreno de lo Complejo (1).

Unas últimas sugerencias

  • Es importante recalcar que por lo genera toda mejora se da en el plano de la personas, procesos o herramientas (2)
  • Y aunque algunas mejoras sean tareas o acuerdos, es bueno redactarlas a nivel de experimentos para validar si su uso fue fructífero o no



Este es la taxonomía que hasta el momento he identificado, bienvenido el feedback.


Saludos ágiles y un exitoso 2018

Jorge Abad


Notas, Referencias, Comentarios, Aclaraciones

  1. Hablemos de la Complejidad, la Gestión de Proyectos y Cynefin - clic aquí para ver- 
  2. Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo  -clic aquí para ver-.

El Cambio en la Guía de Scrum: Asegurando que el Equipo Mejore



Hola a todos

Este año vimos cambios en la guía de Scrum que se enumeran en este post: Revisión a la Guía de Scrum 2017 de Lucho Salazar. pero dentro de los cambios que más me gustan es que se evidencie la necesidad de priorizar la mejora como un elemento clave del Sprint Backlog, de forma que el equipo no lo pierda de vista y logre mejorar sprint tras sprint.


El texto de la guía reza de la siguiente forma:

"Para asegurar el mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior" - La Guía de Scrum

Este texto se podría ilustrar como


De esta forma se observa que:
  1. Se garantiza que los equipos realmente mejoren, antes aunque esta practica era conocida como "Scrumming the Scrum" - Propuesta por Jeff Sutherland -(1), no era manejada por todos los Scrum Master.
  2. Se obtiene que en los equipos sprint tras sprint "algo" cambiará, algo mejorará, logrando que las prácticas, acuerdos, accionables sean completamente diferentes entre el sprint 5 y el 25
  3. Que se destine tiempo efectivo dentro del sprint a la mejora, lo que implica que una o varias personas durante el sprint tomaran tiempo laboral y harán algo que esperan que mejore los resultados del equipo, aclaro:
"La mejora debe hacerse en horario laboral, no es un trabajo extra, y bien realizada le agrega calidad, velocidad, felicidad y desempeño al equipo"

Ahora respecto a esto unos consejos
  1. No priorice demasiadas acciones de mejora, mi consejo es que sea entre 1 y 3 acciones de mejora, (las más importantes) de forma que identifiques que acciones fueron las que cambiaron la dinámica del equipo.
  2. La(s) mejora(s) debe tener la máxima prioridad dentro del sprint backlog, sino se diluirá en el día a día. El Scrum Master debe cerciorarse que estas mejoras se realicen sprint tras sprint. 
  3. Las mejoras pueden darse dentro del campo de los procesos, las personas o herramientas (2). Estas mejoras realizadas de forma priorizada, sistemática y orientada por el scrum master puede llevar al equipo a realizar un salto cuántico en su desempeño, resultados y generación de valor.
  4. Es una buena práctica que las mejoras tengan 
    • Responsable(s)
    • Fecha o cuando se realizarán durante el sprint
    • Resultado Esperado
    • Resultado Obtenido

Hasta acá este compartir

Saludos ágiles

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1.  Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum - clic aquí para ver- 
  2.  Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo  -clic aquí para ver-.



domingo, diciembre 10, 2017

Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning





Hola a todos

Hoy quisiera compartir un cuarto método de los tres anteriormente compartidos en el post "Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning" - (clic aquí para leerlo).

Es muy parecido al ojo de buen cubero.

El proceso es sencillo


  1. Se toma una historia de usuario que todo el esfuerzo (1) requerido para construirse tome entre uno y dos  días-persona (o sea, si sumas todas las horas usadas para construir la historia de usuario sin considerar tiempos muertos tome entre uno y dos días) - Consejo: entre más cercano a un día de esfuerzo es mejor - de ahora en adelante esa será la historia pivote (2) y tendrá el tamaño de un punto
  2. Luego pregúntale al equipo. ¿cuántas historias pivote o de un punto son capaces de hacer en un sprint?
  3. El equipo hará su estimación y dirá por ejemplo somos capaces de hacer 20 de esas.
  4. Ok, acabas de tener la capacidad de tu equipo
  5. Ahora si, con esta información comienza el planning y compara todas las historias con respecto a la historia de usuario pivote, preguntando por ejemplo ¿esta nueva historia es 1,2,3,5,8 veces la historia pivote?, El equipo realizará planning póker y sumaras los puntos hasta que llegues a un número cercano a 20.
Otro punto importante a tener en cuenta, también determina cual es tamaño máximo que el equipo puede aceptar de historia de usuario, es decir
  • Si el sprint es de 2 semanas, es decir 10 días hábiles, y 8 de ejecución quitando las reuniones de planning, dailys, refinamiento, review, retrospectiva
    • si la historia es de aproximadamente 1 día, el tamaño máximo deberá ser 8 puntos, 13 puntos sería imposible de lograr
    • si la historia es de aproximadamente 2 días, el tamaño máximo deberá ser 5 puntos (y eso con un alto riesgo de no lograrse)
Y recuerda una buena práctica es que tu sprint backlog tenga entre 6 a 10 historias de usuario de similar tamaño

Hasta acá este corto compartir.

Saludos Ágiles 

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. Esfuerzo es diferente a Duración, algo te puede tomar 2 días de esfuerzo pero la duración puede ser 3 pues hay tiempos muertos entre una tarea y otra hasta completar la historia de usuario
  2. Hace un tiempo realice una tabla de tamaño de historias de usuario de acuerdo al tamaño del sprint (http://www.lecciones-aprendidas.info/2017/05/Tamanos-sugeridos-de-historias-de-usuario.html ), cada vez me convenzo más que deben ser lo más pequeñas posibles.