La Guía de Scrum 2017 - En Mapa Mental

Hola a todos

La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.

Mapa Mental - Capítulos

Mapa Mental - Capítulos y Subcapítulos

El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.

Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.

Descárgalo y Úsalo

A continuación, pongo a su disposición varios formatos de descarga y visualización

• Descargar PDF - aquí  (es el más sugerido debido al tamaño, debes descargar y abrir desde un navegador web, como: Chrome, Edge, o Firefox, etc)
• Word - aquí
• PNG Aqui
• SVG - aquí

Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

Disfruten las perlas (las que estan con asterisco (*) y en verde)

Saludos ágiles

Jorge Abad

[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

Tip de Scrum: La calificación del Product Owner al finalizar el Sprint

Hola a todos

Scrum es un framework que se va enriqueciendo en un equipo sprint tras sprint de prácticas y tips , hoy quiero compartirles una pequeña práctica(1) de bajo costo y alto impacto para el equipo, la cual detallo a continuación.

Al finalizar el Review el Scrum Master solicita al Product Owner (PO) que califique el Sprint en términos ¿Qué tan útil y de valor fue el incremento entregado? o ¿Qué tanta alineación tiene el incremento entregado con el objetivo del sprint?

 "sin importar cuantos puntos o historias se entregaron, sino centrándose en el valor recibido", 

el PO lo podrá calificar en un escala de 1 a 5 (o la que elijamos) de la siguiente manera:

5 - El incremento estuvo genial, asombroso
4 - El incremento estuvo bien y satisfactorio
3 - El incremento no era todo lo que esperaba
2 - Al incremento le faltaron elementos importantes
1- El incremento lamentablemente no fue satisfactorio

y luego que nos explique la razón de este valor, esta última parte es de mucho valor para el equipo para que este comprenda el norte hacia el cual se dirige el producto.

Estos dos aspectos calificación y explicación, le sirve de motivación, dirección y feedback al equipo y es un importante insumo para la retrospectiva, pues se pueden dar los siguientes escenarios:

• Hacer menos puntos o historias de los esperados pero generar mucho valor al PO,
• Hacer muchos puntos o historias pero no hacer lo que le genera valor al PO, o
• Cumplir las expectativas del PO para el sprint.

Hasta acá esta sencilla y poderosa práctica, espero me compartan los resultados de usarla y todo feedback será bienvenido.

Saludos ágiles y hasta la próxima

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Escuche esta práctica en el DevHangout  "Técnicas para formar equipos ágiles #devHangout 133 con @chuzzete" donde Jesús Méndez - @chuzzete habla de su libro "Técnicas para formar equipos ágiles" y días después me la recordó mi estimado amigo y agilista Carlos Gil - @cafegifo en la actividad de Migas de Pan.

Buenas y Malas Prácticas en el Review / Demo de Scrum

o El Review no es una reunión de Testing

Hola a todos

En la medida que se va implantando Scrum, sprint tras sprint, el Scrum Master debe enfocarse cada vez más en que cada una de las reuniones de Scrum y la ejecución del mismo conserven el espíritu del agilismo: dar valor al negocio, con la menor cantidad de software posible a pequeños incrementos.

En este ejercicio se debe velar por que no se caigan en malas prácticas durante las reuniones de Scrum, en este post me enfocaré en la reunión del Review / Revisión / Demostración / Demo (la verdad me gusta más la palabra Demo) la cual esta definida según la guía como:

"Una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración."(1)

A continuación comparto unos tips y malas prácticas que he observado en los Demos:

• Malas prácticas
• Creer que la reunión de Demo es una reunión de User Acceptance Testing (UAT), revisando paso por paso los casos de prueba: 
• Esto hace que la reunión se vuelva extensa, que no se cumpla el timebox (2), además ¿Cuándo se logra probar en una reunión de 2 horas el software que se produjo en 2 semanas?, implicando que se desconfía en el "Done" / "Terminado" que asegura el equipo y/o los testers encargados de realizar las pruebas.(3)
• Realizar la Demo con capturas de pantalla (pantallazos) de los casos de prueba que lograron el Done durante el Sprint
• La ventaja del Demo es esa, poder hacer una demo de lo que se hizo, y el hecho de presentar los pantallazos, no cumple con uno de los principios ágiles "software funcionando es la principal media de progreso". Es necesario poder navegar y "jugar" con el software durante la demo.
• No invitar a Interesados / Stakeholders claves a la reunión
• El Product Owner debe trabajar para que haya inspección y adaptación sobre el producto, de esta forma dentro de la reunión del review se brinda a stakeholders claves la posiblidad de realizar feedback sobre el producto y poder dar lineamientos sobre su progreso, el demo es el espacio para realizarlo, y no hacerlo en este tiempo es perder tiempo valioso.
• Buenas prácticas
• Preparar la Demo
• El equipo debe preparar la demo y guardar un tiempo al final del sprint para preparar data a ser usada, ambientes, etc. en caso contrario el review puede llegar a ser fallido, o alguno de los ítems del incremento no funcionar correctamente y no darse por aprobado.
• Cuidar el Timebox
• El Scrum Master debe velar para que el timebox del la reunión se cumpla, proporcionando feedback oportuno a cualquiera de los asistentes cuando alguna solicitud vaya en contra del propósito de la reunión o el tiempo del a misma.
• Realizar revisiones JIT (Just in Time / Justo a Tiempo)
• Esta práctica consiste en que durante el Sprint el equipo cuando alcanza el Done de algún item del Sprint Backlog, lo presenta al Product Owner para recibir feedback, aceptación y/o rechazo del mismo, de forma que no se espera hasta el review, y de esta forma recibir feedback oportuno. 
• Esta práctica tiene la ventaja de hacer un review (o demo) más exitoso y más liviano en el tiempo.

Hasta acá esta pequeña lista, espero sea de ayuda y provecho para los demos en sus equipos

Saludos ágiles

Jorge Abad

Referencias y Aclaraciones

(1) Guia de Scrum - scrumguides.org

(2) Timebox de las reuniones de Scrum - clic aquí -.

(3) Existen equipos que no tienen alguien destinado específicamente al testing y existen equipos en que sí, en general lo que hay que garantizar es que el equipo sea multifucional, no polivalente (cada persona sabe realizar bien todos los roles).

La cara del santo hace el milagro. Efectividad del Planning y Review

Scrum tiene muchas fortalezas, esta cubierto de soluciones para años y años de heridas de guerra de equipos de software a lo ancho y largo del mundo, cada elemento esta puesto allí ayudando a que los otros funcionen.

Una de las cosas que he observado es la fortaleza que tienen el Planning y el Review, y el milagro que logra en el equipo:

• En el Planning: El Team Developer con el P.O. (Product Owner - Dueño del Producto), entiende que se quiere construir y se compromete con unos ítemes de backlog que llevará a la DoD (Definition of Done -  Definición de terminado). La clave acá es que al equipo nadie le impone el compromiso, es un acto de libertad, coraje y confianza en si mismos -un consenso libre entre sus integrantes -. En el esquema tradicional hay un GP (Gerente de Proyecto) que le impone unos tiempos y estimaciones a su equipo, sin otra opción que cumplir o cumplir , ya sea en el tiempo asignado o en el propio después de la jornada laboral.
• En el Review: El Team le presenta al P.O. y a los Interesados* lo construido, y pasan a la gloria, a una ligera vergüenza si algo no sale como lo esperado, o una "humillación" sino cumplieron con poco o nada de lo comprometido (con su respectiva DoD). El que siente la frustración o felicidad es el equipo al mostrar el resultado a sus directos interesados (sin intermediarios o gerentes que cuenten el "chisme" de la típica pregunta ¿como les fue en la entrega?) La cara del P.O. y los Interesados es lo que más compromete y le da propósito a un equipo. 

El equipo toma poco a poco vida, reflexiona para si mismo y dice:

• tenemos que seguir dando la talla o
• no nos puede volver a pasar esta misma situación

(esta puesta la semilla para la retrospectiva)

El milagro del compromiso, coraje, foco y auto-organización poco a poco comienzan a emerger y ahí es cuando yo digo como el famoso dicho:

La cara del santo** hace el milagro

Saludos ágiles

Jorge Abad.

* Interesados: Puede ser los líderes funcionales de los clientes, usuarios, o cualquier persona que le importe en obtener un buen producto
** P.O. + Interesados