Responsabilidades del Scrum Master

Scrum Como Modelo de Auto-Coaching para los Equipos

Hola a todos

Hace unos días en una reunión de Ágiles Ecuador - en la que tuve la oportunidad de ser el facilitador de la Sesión de Migas de Pan(1)-, alguien sugería al cierre de la misma que para ser Scrum Master era necesario hacer un coach profesional como primer paso, y después de debatir un poco, decantábamos que no, que no era necesario, pues tanto un Scrum Master, un Agile Coach de Equipos o un Agile Coach Empresarial tienen más de mentor, de experto, de maestro, de líder, de entrenador de equipos, que alguien que a través de preguntas quiere acompañar a un individuo en su viaje de un estado a otro en su vida (y reconozco que este es un punto que aun no se termina de desarrollar en la comunidad ágil).

Pero también en esa discusión observábamos que un equipo que hace Scrum, tiene un ciclo de mejora continua que esta cuestionando constantemente tres ejes:

• La organización
• El equipo
• La persona que hace parte del equipo Scrum

Cíclicamente un equipo que hace Scrum, se enfrenta a su verdad - gústele o no - pues al principio en el Planning hacen una compromiso de lo que creen que van a construir y al final en la Review están mostrando lo que lograron a los Stakeholders y luego se van a la Retrospectiva con su resultado a filosofar que pueden hacer distinto para ser más exitosos el siguiente ciclo. Este ejercicio de:

• hacer una apuesta basados en su capacidad
• ver el resultado
• mostrar el resultado
• enfrentarse al feedback de sus stakeholders
• indagar por que se obtuvo el resultado
• proponer que mejorar internamente para ser más exitosos la próxima vez
• proponer que mejorar externamente para ser más exitosos la próxima vez

Termina cambiando a las personas, equipos y organizaciones.


Esta dinámica genera un circulo virtuoso transformador, pues:

• te va haciendo responsable de tus compromisos
• te hace revisar tus capacidades y buscar nuevas
• te invita a tener mejores interacciones con tus compañeros para tener éxito
• te invita a cuestionarte, cuestionar respetuosamente a los otros y cuestionar a la organización en la que estas inmerso

En definitiva, no te puedes quedar quieto ante un marco que cada semana, dos semanas o máximo un mes te muestra tu verdad tal cual es, o cambias, o cambias (así lo he visto funcionar cantidad de veces)

Scrum por sus ciclos de PHVA(2) continuos, termina cambiando al Equipo, al Scrum Master y al Product Owner, y al final de su viaje en la construcción del producto terminan siendo personas completamente distintas  y quienes hayan vivido este viaje sabrán darme la razón.

Para cerrar es importante aclarar que no solo Scrum puede darte este beneficio, cualquier modelo de trabajo que en ciclos cortos (de no más de un mes) nos esté enfrentando a la verdad y nos esté retando a salir de nuestra zona confort generará resultado similares.

Bonus Track

Ahora, cuando alguien me pregunta ¿que tiene que hacer para ser Agile Coach? lo invito a que comience este camino con corazón (3) siendo Scrum Master - que es el Agile Coach del equipo Scrum-, y enfrente allí sus verdades, junto con su equipo, y luego de al menos cuestionarse, cuestionar, y retar durante un buen tiempo determine hacia donde seguir avanzando.

Bueno, hasta acá esta corta reflexión y compartir.

Si tienes algún comentario bienvenido el feedback en la zona de comentarios

Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Actividad que le aprendí de mi gran amigo Carlos Gil
2. El ciclo Planear - Hacer - Verificar - Actuar, promovido por E. Deming

3."...Cualquier cosa es un camino entre cantidades de caminos. Por eso debes tener siempre presente que un camino es sólo un camino. Si sientes que no deberías seguirlo, no debes seguir en él bajo ninguna condición. Para tener esa claridad debes llevar una vida disciplinada.Sólo entonces sabrás que un camino es nada más un camino, y no hay afrenta, ni para ti ni para otros, en dejarlo si eso es lo que tu corazón te dice.

Pero tu decisión de seguir en el camino o de dejarlo debe estar libre de miedo y de ambición. (...) Mira cada camino de cerca y con intención. Pruébalo tantas veces como consideres necesario.

Luego hazte a ti mismo, y a ti solo, una pregunta: ¿Tiene corazón este camino?

Si tiene, el camino es bueno; si no, de nada sirve. Todos los caminos son lo mismo, no llevan a ninguna parte. Son caminos que van por el matorral. Ningún camino lleva a ninguna parte, pero uno tiene corazón y el otro no..." Uno hace gozoso el viaje; mientras lo sigas, eres uno con él. El otro te hará maldecir tu vida. Uno te hace fuerte; el otro te debilita."

El problema es que nadie se hace la pregunta, y cuando por fin se da cuenta de que ha tomado un camino sin corazón, el camino está ya a punto de matarlo.Un camino sin corazón nunca se puede disfrutar. Hay que trabajar duro tan sólo para tomarlo. En ese punto pocas personas pueden parar a pensar y dejar el camino...

En cambio, un camino con corazón es fácil: no te hace trabajar por tomarle gusto. Para mí existe solamente el viajar por caminos con corazón, en cualquier camino que pueda tener corazón. Por ahí viajo, y el único desafío que vale la pena es atravesarlo en toda su longitud. Y por ahí viajo, buscando, buscando, sin aliento". (“Las enseñanzas de Don Juan” de Carlos Castañeda.)

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

• no tiene tiempo para el equipo
• no escribe bien las historias de usuario 
• no está priorizando el product backlog
• no hay un plan de releases
• no se tiene un Producto Mínimo Viable (MVP).
• no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
• entre otras preocupaciones

Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):

Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:

• ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
• Rpta/. Es el SM como experto del marco es el encargado de garantizar que el equipo tenga los ítems de backlog adecuados para trabajar, y es su deber como coach del PO de enseñarle y verificar las historias de usuario para que estas cumplan con un estándar mínimo de calidad (las tres CCC e INVEST). ( leer tambiém :El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog - clic aquí)
• ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
• Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
• ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
• Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.

Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir

Saludos ágiles

Jorge Abad

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-.

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. 

Presentación: Los puntos ciegos del Scrum Master

Los puntos ciegos del Scrum Master - Ágiles 2017 - Chile from Jorge Hernán Abad Londoño

¿Dónde está el problema?¿Por qué mi equipo Scrum falla continuamente sprint tras sprint?

Hola a todos

Muchas veces al visitar equipos de trabajo me encuentro con Scrum Masters en los que su equipo lleva continuamente fallando con los puntos comprometidos sprint tras sprint, y por lo general corresponden a ciertas sintomatologías.

A continuación voy a presentar algunas de las posibles causas raíz y posibles formas de solución, espero esta lista te sea útil al momento de diagnosticar a tu equipo si está atravesando por la misma situación:

Posibles razones Consecuencia y Posible Soluciones Equipos Inestables Cambio frecuente de team members Continua renuncia de team members Consecuencia: Pérdida constante de conocimiento y reinicio de la dinámica del equipo. Posible(s) Solución(es): Hablar con los líderes de la organización buscando remover la causa del constante cambio de personas, esto muy probablemente se debe a creer que el equipo esta compuesto por recursos que pueden remover e ingresar sin ningún problema e impacto. Solicitarle al equipo confíe ante la crisis que se está presentando, que se va a remover la causa raíz que esta generando la renuncia continua de los miembros del equipo, y cumplir lo prometido al equipo. Team members a tiempo parcial Consecuencia: Pérdida de foco de los team members generando desgaste en tiempo para volver a entender el contexto del proyecto.(Esto sucede cuando las organizaciones creen que hacer muchas cosas al tiempo es mejor que hacer una cosa bien hecha a la vez. Es mejor llevar proyectos a los equipos que armar equipos para los proyectos) Posible(s) Solución(es): Hablar con la organización y solicitar la estabilización de los miembros del equipo donde al menos el 80% este a dedicación a tiempo completo.  La tecnología es desconocida o nueva para el equipo Consecuencia: Por más buena intención que tenga el equipo no se cumplen los compromisos pues no sabe como solucionar los diferentes tipos de retos que implica la tecnología. Posible(s) Solución(es): Entrenar correctamente al equipo en la tecnología y darles el suficiente tiempo para que la dominen y maduren. Traer team member expertos para que hagan programación por pares con ellos y haga transferencia de conocimiento. cambiar de tecnología por una que domine el equipo Estamos en un entorno de completa incertidumbre con la tecnología, aunque la dominamos estamos haciendo cosas completamente innovadoras. (Común en equipos de investigación) Consecuencia: Las estimaciones no se cumplen pues no se sabe con certeza si se logrará el resultado esperado. Posible(s) Solución(es): No presionar al equipo, proveerles un entorno de aprendizaje, olvidándose si se logra o no los puntos comprometidos y tener metas pequeñas alcanzables (al menos en teoría), y permitirles fallar. Hay presión por parte del cliente, product owner o el scrum master (en el peor de los casos) en el planning y el equipo debido a esta presión  se sobrecompromete Consecuencia: El equipo se sobrecompromete por temor a los "jefes" Posible(s) Solución(es): Es muy probable que ni el cliente, ni el Product Owner, y con mayor razón el Scrum Master, no entiendan que Scrum es: "Tiempo fijo - Alcance Variable" y que la presión sobre lo entregado solo va a generar una continua fatiga de todos por tener expectativas irreales. Recomiendo este post: [Scrum] Ritmo Sostenible sobre Ritmo Insostenible (clic aquí) El equipo está constituido por novatos o son demasiado optimistas al hacer las estimaciones Consecuencia: El equipo se sobrecompromete ignorando muchos elementos técnicos debido a su baja experiencia en el producto o en la(s) tecnología(s) involucrada(s). Posible(s) Solución(es): Sugiero que los equipos estén constituidos al menos con la mitad de las personas con experiencia, de manera que les enseñen (haya transferencia de conocimiento) y ellos permitan ver aspectos ignorados por los novatos o aprendices. Infraestructura inestable Consecuencia: Los compromisos hechos se vienen al suelo por los impedimentos de la infraestructura. Posible(s) Solución(es): Estabilizar cuanto antes la infraestructura, si es posible destinar tiempo del equipo a hacerlo. El tamaño del sprint es demasiado pequeño para generar valor. Consecuencia: Las historias de usuario continuamente no alcanzan la Definition of Done (DoD). Posible(s) Solución(es): Muchas veces cuando la tecnología tiene muchas capas es costoso alcanzar la DoD en un Sprint, para esto sugiero, las siguientes soluciones Cambiar el Sprint a no más de tres semanas (4 semanas no lo recomiendo de verdad), y tener ese tamaño como estándar de ahora en adelante Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) Impedimentos y/o desenfoques excesivos en el sprint Consecuencia: Los frecuentes problemas frecuentes no permiten lograr el foco en el sprint. Posible(s) Solución(es): Dividir el equipo, o tener otro adicional enfocado en los "desenfoques" Estabilizar el entorno  Detener el proyecto hasta que el entorno esté estabilizado Un producto con mucha deuda técnica Consecuencia: Cualquier estimación es dañada por la mala calidad del producto en la que se está trabajando. (Recomiendo este post : Hablemos de Deuda Técnica - clic aquí-) Posible(s) Solución(es): Identificar y remover la deuda técnica y constituir este esfuerzo como trabajo a realizar durante el sprint. Liberar al equipo de las estimaciones de forma que pueda construir producto y a la par remueve la deuda mínima necesaria que les permita trabajar. Las historias de usuario son demasiado grandes Consecuencia: El equipo falla constantemente sus estimaciones, impidiendo encontrar la Definition of Done (DoD) al final del Sprint Posible(s) Solución(es): Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) Las historias de usuario no están cumpliendo la Definition of Ready (DoR), es decir son aceptadas por el equipo aun sin tener sus definiciones y dependencias resueltas Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso. Posible(s) Solución(es): No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR). Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - El equipo acepta historias de usuario que no tienen sus dependencias construidas.  Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso. Posible(s) Solución(es): Esto sucede cuando existen otros equipos que proporcionarán insumos y estos no son entregados a tiempo al equipo. No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR) y no tienen sus dependencias resueltas o construidas previamente. Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - Tener muy buena arquitectura de componentes y crear contratos, APIs, interfaces de componentes entre el trabajo de los diferentes equipos, de forma que se puedan generar resultados. Crear Mocks basados en contratos que emulen el trabajo de los otros equipos. El Product Owner cambia las historias de usuario durante el sprint aumentándoles el tamaño asociado a las mismas Consecuencia: Las historias de usuario tiene demasiadas sorpresas  implicando que no se cumpla el compromiso. Posible(s) Solución(es): Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint. El Product Owner esta cambiando las prioridades durante el Sprint Consecuencia: No es posible cumplir un compromiso si las prioridades cambian constantemente. Posible(s) Solución(es): Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint. No usar Scrum como forma de trabajo, tal vez sea mejor Kanban.

"Cualquier parecido con la coincidencia es pura realidad"☺

Ahora para ser sincero, la no identificación oportuna de estas causas es responsabilidad del Scrum Master.(les recomiendo este post: El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje -clic aquí-)


Si tienen más razones y posibles soluciones, bienvenidas sean en la zona de comentarios.

Comos siempre, bienvenido el feedack.

Saludos Ágiles

Jorge Abad

Es inútil, no trates de uniformizar tus equipos Scrum

Hola a todos

Algunos de nosotros hemos tenido la experiencia de empezar en un equipo Scrum desde cero, ya sea como Product Owner, Scrum Master o Team Member, y hemos intentado traer prácticas que hemos aprendido (y que nos han funcionado muy bien) en otros equipos pero en este:

• no son acogidas, 
• las usas pero no tienen el mismo impacto.
• las usan y pronto las desechan

Lo cierto, es que cada equipo es un universo único de relaciones únicas entre sus integrantes y aunque empezaramos dos equipos con el mismo scrum master el mismo día y para el mismo producto, es muy probable que pronto (al segundo sprint - tal vez-) comiencen a existir diferencias entre las prácticas adoptadas, pues cada equipo (de acuerdo a su inteligencia colectiva) en las retrospectivas o en el avanzar de los sprints encuentra:

• accionables
• acuerdos
• experimentos y 
• prácticas

Que le son útiles en su contexto único, para esos integrantes en ese momento del tiempo y para nadie más.

Por lo tanto, y cerrando rápido esta corta reflexión

• lo que le sirve a un equipo, no tiene necesariamente por que servirle a otro
• (igual en las organizaciones) lo que le sirve a una organización no tiene necesariamente por que servirle a otra
• cada equipo es un mundo diferente
• los equipos van encontrando su propia forma particular de responder al contexto y es deber del Scrum Master guiarlos en este reto.
• es necesario hacer inspección y adaptación para ir respondiendo al entorno complejo

y la obvia

• es inútil tratar de uniformizar tus equipos scrum.

Hasta acá esta corta reflexión, bienvenido el feedback y tus experiencias en la zona de comentarios.

Saludos ágiles

Jorge Abad

Notas

• Me he encontrado con equipos a los cuales les funciona bien el burdown y otros no, se contentan con el kanban.
• Este post no va en contra de las prácticas definidas por la organización, en ese caso los equipos trabajan con los artefactos, y herramientas asignadas por la organización, es más dirigido a nuestro es fuerzo de copiar y pegar indiscriminadamente sin ningún contexto.

Antipatrón de Scrum : El Scrum Master Dirige la Retrospectiva en Lugar de Facilitarla

Hola a todos

Una de las disfuncionalidades  y punto de mejora que he encontrado en los equipos Scrum, radica en que el Scrum Master  (SM) (ya sea que venga del mundo de la gerencia de proyectos, o acostumbrado a un liderazgo impositivo) al momento de realizar la retrospectiva reúne al equipo (1), y aunque realiza las actividades propias de una retrospectiva (2)(3), cada actividad cierra con sus conclusiones, es decir:

• decide cuales fueron las causas principales de por qué les fue bien o mal durante el sprint
• decide cuales son las acciones de mejora, acuerdos y experimentos a realizar
• el equipo esta allí solo para estar de acuerdo con sus decisiones.

Es decir, dirige la sesión en lugar de facilitara.

Problemas de este enfoque

• no permite la auto-organización
• queda el SM como el único responsable de decidir que se hace, y por ende a quien culpar [les sugiero leer este post de Martín Alaimo sobre la responsabilidad del equipo y el único responsable (4)] de una buena o mala estrategia.
• el equipo solo sirve para hacer lluvia de ideas pero no decide, pues el SM decide por el equi
• el equipo no esta empoderado tiene voz pero no voto
• el equiipo no madurará, pues siempre le dirán que hacer y no asumirá consecuencias.
• El SM no es un facilitador, es más alguien que dirige al equipo y este depende de él para todo (se sigue un esquema de Comando y Control - típico de la gerencia de proyectos - )
• Se esta trabajando con un grupo y no con un equipo (4)

Soluciones

• El SM es realmente un facilitador de la reunión(5), es decir el SM esta ahí, para ayudar al equipo a encontrarse,  ser su espejo, no dirige sino que facilita, es alguien que cuenta con instrumentos y experiencias para facilitar correctamente la sesión de retrospectiva de su equipo (6).
• Al finalizar cada paso de la retrospectiva (3) el SM invita al equipo a que priorice, reflexione y tome decisiones sobre:
• problemas
• oportunidades de mejora
• experimentos
• planes
• acuerdos
• cambios a realizar entre otros.

Beneficios de la Solución Propuesta

• El equipo se empodera de sus problemas y soluciones
• Todos adquieren un compromiso entre pares, nadie les dice que hacer, ellos acuerdan que ahcer.
• El equipo tiene voz y voto
• Si el equipo falla, el equipo aprende y mejora (en el esquema anterior el SM es el culpable de elegir una mala estrategia)
• El equipo comienza a sentirse responsable y emerge la autoorganización
• Si el equipo durante el sprint no esta tomando las acciones que se comprometieron,
• entre ellos pueden llamarse la atención (es más fuerte la presión social que el compromiso ante una orden) o 
• el SM puede interpelarlos con una pregunta poderosa puede hacerlos conscientes de la desviación de lo comprometido por ellos
• El equipo se escucha entre sí (recordemos que las mejores ideas vienen de cualquier parte)

Bueno hasta acá este corto compartir, bienvenido el feedback, los comentarios y las experiencias.

Saludos ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Recordemos que el equipo Scrum esta constituido por Product Owner, Equipo Desarrollador (el cual es multidisciplinario), y Scrum Master
2. En esta página podrás encontrar cientos de actividades https://plans-for-retrospectives.com/es/
3. Recordemos que un buen guión de retrospectiva (según el libro Agile Retrospectives de Diana Larsen y Ester Derby) cuenta con:
• Armar el escenario
• Recolectar datos
• Indagar
• Decidir que hacer
• Cerrar
4. Compartiendo la responsabilidad. Hacia Un Equipo Real.por Martín Alaimo (clic aquí)
5. Según comparte Martín Alaimo en su libro "Facilitador de Equipos Ágiles: El Camino de un Coach hacia la Agilidad Empresarial" 

• La facilitación  de grupos: es un proceso por el cual una persona cuya elección es aceptada por todos los miembros del grupo, que es neutral y no tiene autoridad sustancial en la toma de decisiones, diagnostica e interviene para ayudar al grupo a identificar y resolver sus problemas y tomar decisiones y para así, aumentar su efectividad. (Schawarz, 2002)

6. La posible agenda de una retrospectiva puede ser algo como [Agenda Scrum] Pasos para Realizar la Retrospectiva

Cómo Contratar, Encontrar o Formar un Scrum Master

Hola a todos

Sigamos con el post anterior: Las habilidades blandas -Soft Skills- de un Scrum Master 

Primero aclaremos algo que siempre es bueno resaltar:

"con dos días de entrenamiento nadie se hace MAESTRO de Scrum o Scrum MASTER"

Estos dos días y el posible examen de certificación que se presente, son el primer paso, y solo se acreditaría el conocer el framework, pero no implican una maestría y el dominio del mismo, esto es importante remarcarlo pues Scrum no es una metodología, es un framework (lo que implica que no es prescriptivo ni detallado) y como tal deja muchas cosas sin definir y según el contexto y la experiencia se adoptarán unas prácticas y otras no.

Volviendo al tema, como se contrataría o formaría un Scrum Master, vamos por partes:

¿Cómo contrataría a un Scrum Master?

Bueno, pues para contratar a alguien como Scrum Master tendría los siguientes pasos

1. validaría el conocimiento del marco de Scrum
2. validaría la experiencia, acá opino que es necesario al menos seis (6) meses de experiencia continuos de haber aplicado el framework para comprenderlo y saber adaptarlo
3. le haría una entrevista similar a esta -http://www.lecciones-aprendidas.info/2016/05/entrevista-para-un-scrum-master.html -
4. y cerraría con un Assesment Center (o centro de evaluación), que es un juego de roles donde las personas muestran su forma de priorizar, interactuar, decidir, etc., buscando identificar las habilidades blandas presentadas en el post anterior - http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html -
5. (para los que tienen equipos avanzados) sugeriría que el candidat@ comparta con el equipo al que llega un día o dos, buscando que  facilite algunas reuniones  para determinar si tanto equipo como Scrum Master se sienten cómodos mutuamente.

Con estos elementos determinaría si se puede contratar o no al Scrum Master candidat@.

¿Cómo formaría un Scrum Master? (aplica en caso de que alguien dentro de la organización se postule a ejercer el rol por primera vez) (1)

En general comenzaría con dos premisas

• validaría conocimiento y dominio del marco de Scrum
• validaría que tenga las habilidades blandas presentadas en el post anterior - http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html con un Assessment Center o con conversaciones con el equipo al que pertenece, sus compañeros o líderes que actualmente trabajen o hayan trabajado con el/ella.

Luego comenzaría el acompañamiento, que puede darse en dos modalidades

• acompañamiento de un  Agile Coach
• Para esto se puede usar el modelo Shu-Ha- Ri de artes marciales

• Shu
• El Agile Coach realizaría y mostraría como realizar al SM las siguientes ceremonias
• Al menos dos planning (esto implica al menos dos sprints)
• Al menos dos dailys (luego los otros dailys dejaría al SM los realice)
• Al menos dos refinamientos  (esto implica al menos dos sprints)
• Al menos dos reviews  (esto implica al menos dos sprints)
• Al menos dos retrospectivas  (esto implica al menos dos sprints)
• Luego el Coach acompañaría al alumno en dos sprints, invitando a que el facilite las ceremonias de modo que observen puntos de mejora y puntos a conservar.
• Luego se le dejaría sol@ con su equipo y se le visitaría esporádicamente o por demanda
• Ha y Ri 
• Se requieren de constante comunicación  (muchas lecturas, mucho aprendizaje ) entre el Scrum Master y el Agile Coach para subir a estos niveles
• Acompañamiento de otro SM con experiencia
• en este sentido se darían los siguientes pasos:
• El SM nuevo acompañaría al SM con experiencia al menos durante dos sprints de forma que vea como este realiza las sesiones con su equipo, resuelve los impedimentos, y se desenvuelve en el día a día.
• Asignar al nuevo SM su nuevo equipo de trabajo
• El SM nuevo acompañado por el experimentado realizaría durante los dos primeros sprints las ceremonias de Scrum, de forma que se se den recomendaciones sobre facilitación y mejores prácticas
• Luego el SM experimentado asistiría por demanda o por iniciativa del SM nuevo al equipo buscando ver puntos de mejora
• Cierre del proceso

Hasta acá este compartir.

Saludos ágiles

Jorge H. Abad L.

Notas, Aclaraciones, Comentarios y Referencias

1. Un Scrum Master en formación le sugiero seguir las reglas hasta que las domine  y pueda obviar cosas, pero mientras esto llega le sugiero seguir las agendas de scrum  http://www.lecciones-aprendidas.info/search/label/agenda%20scrum

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




Importante: compartí un cuarto método en: Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning (clic aquí)

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í)

Leído y Recomendado: Toolbox for the Agile Coach - Visualization Examples

Gran post sobre herramientas de visualización para un equipo.

Imperdible

Toolbox for the Agile Coach - Visualization Examples (Clic Aquí)

Tarjetas que ayudan a identificar y remover impedimentos: Impediment Cards

Hola a todos

En un gran equipo del cual tuve la fortuna de ser parte de ellos durante un año como Scrum Master generamos una base de conocimiento para ayudar a identificar impedimentos en el proceso de desarrollo, de forma que la consultaba el team member:

• cuando algo no funcionaba
• cuando no sabíamos que pasaba con el sistema
• cuando estaba el desarrollador bloqueado y no se le ocurría como solucionar el impedimento
• y en especial para ayudar a los novatos en su búsqueda de respuestas, pues muchas veces estos no querían cubrir su curva de aprendizaje y preguntan incesantemente al programador experto hasta colmarle la paciencia (¿o no les ha ocurrido esto en sus equipos?).

La estrategia consistía en primero revisar la base de conocimiento y si esta no ayudaba a resolver el problema, sí pedir ayuda a un compañero experimentado, o a todo el equipo en pleno. (en algunas ocasiones a los novatos, sino cumplían revisar la base de conocimiento no se les ayudaba - este fue el acuerdo de equipo -).

Esta base de conocimiento decidimos que en vez de manejarla como una lista de verificación (o checklist), sería un grupo de tarjetas individuales con una pregunta a ser resuelta o que da pistas de donde buscar el error o problema al cual se esta enfrentando el desarrollador o team member, poco a poco fuimos engrosando las tarjetas a medida que nos encontrábamos con problemas típicos o ganábamos experiencia. A continuación les comparto el listado que contenía el mazo de cartas "Impediment Cards":

• ¿Revisaste los webconfig, web.xml o el xml de configuración de la aplicación?
• ¿Leíste bien el mensaje de error?
• Insisto: ¿Leíste bien el mensaje de error y comprendiste que te decía?
• ¿las IP son las correctas?
• ¿el proxy lo está bloqueando?
• Si es un bug ¿le preguntaste el correcto funcionamiento al Product Owner?
• ¿revisaste si las contraseñas cambiaron?
• No tiene lógica pero: reiniciaste ¿el IDE, El PC, El server, y/o bd?
• ¿borraste caché?
• ¿Reiniciaste el server para que reflejara los cambios?
• ¿Seguro revisaste detalladamente el archivo de configuración?
• ¿Tienes correctamente instaladas las dependencias?
• ¿hiciste una correcta conversión de tipo de dato?
• ¿será que el puerto o la IP están bloqueados en tu PC o en el Server?
• ¿el usuario de cualquiera de los sistemas le quitaron o expiraron los permisos?
• ¿Verifique si la versión del software es la soportada?
• ¿el usuario tiene permisos / no tiene permisos?
• ¿los servicios, bases de datos, etc apuntan a la dirección correcta o al ambiente correcto?
• ¿la memoria RAM esta copada?
• ¿el disco duro esta copado?
• ¿soportamos la versión del navegador y/o del sistema operativo?
• ¿los sistemas base tienen los parches?
• ¿se encuentra sobre la versión del framework correcta?
• ¿la versión del sistema operativo es la soportada?
• ¿la versión sobre la cual se reporta el problema AUN DAMOS SOPORTE SOBRE ELLA?
• ¿El tipo de dato en el software es el mismo que en la base de datos?
• ¿las trazas, logs corresponden a la fecha de análisis del problema (fecha y rangos correctos)?
• ¿hiciste copy-paste?, si es así, ¿no te parece mejor crear una clase, método que haga lo mismo?
• Si la consulta esta lenta: ¿el procedimiento almacenado o consulta tiene un MAX, sobre una tabla de millones de registros?
• ¿revisaste la documentación oficial del framework o componente?
• ¿revisaste si el problema es de TIPO DE DATO?
• ¿buscaste en Google?
• ¿leiste bien el mensaje de error o log? ¿lo entendiste?
• ¿lo solicitado se encuentra dentro de la garantía o del alcance del proyecto?
• ¿estás lanzando y capturando la excepción?
• ¿estás en el BRANCH correcto del proyecto o versión?
• ¿hiciste DEBUG paso a paso?
• ¿estás trabajando con las últimas versiones de los fuentes?
• ¿revisaste conectividad, (incluido el cable)?
• ¿la tabla tiene índices?
• ¿borraste las cookies? (Fuente: Heimar Vega)
• ¿borraste el historial del explorador? (Fuente: Heimar Vega)
• ¿Se desplegó la versión correcta?(Fuente: Heimar Vega)
• ¿Se ejecutaron las pruebas unitarias? (Fuente: Heimar Vega)
• ¿verificaste estar conectado a la vpn? (Fuente: Anónimo)
• ¿Verificaste si el servicio está operativo? (Fuente: Anónimo)
• ¿Verificaste si la estructura del wsdl es la misma? (Fuente: Anónimo)
• Problemas de rendimiento : Millones de registros , sugiere el uso de tablas históricas
• ¿Todos los componentes de la solución corresponden a la misma versión?
• ¿el web server se encuentra arriba? ¿la base de datos se encuentra arribla? ¿hiciste PING?
• ¿preguntaste si esto había ocurrido antes?
• Penúltima opción: Seguro: ¿buscaste en Google?
• Última opción: No siendo más, pregúntale a un compañero

Estas cartas estaban disponibles en el "lugar o zona lúdica del equipo", allí donde teníamos fotos, chistes para leer, dibujos para colorear y descansar, entre otras cosas (¿tienes un espacio para tu equipo en tu zona de trabajo?, es una buena práctica y genera cohesión e identidad de equipo)

Hasta acá este pequeño y poderoso compartir, si tienes más causas de impedimentos típicas que puedas compartirme para agrandar la lista te lo agradecería, y si lo ves útil compártelo y con base en este listado crea tu propio mazo de cartas de Impediment Cards.

Las ImpedimentCards las puedes descargar aquí

Saludos ágiles

Jorge Abad

El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje

Hola a todos

Hace poco le escuche a un médico amigo de la familia la siguiente frase:

 “El paciente se enferma de lo que el médico sabe”  

y él me explicaba que era necesario que los médicos estén repasando lo aprendido y estudiando sobre lo nuevo, pues cuando llega un paciente con unos síntomas determinados, si ellos poco “saben” o “conocen” de esos síntomas, diagnosticarán mal al paciente y por ende le recetarán un tratamiento inadecuado (obvio, no se puede recetar sobre lo que no se conoce, por eso ellos envían a especialistas, pero si fueron muy livianos en su diagnóstico no identificarán correctamente la enfermedad, padecimiento o problema de su paciente).

En esta misma línea va este post, y es animar principalmente a los Scrum Master(1), y en segundo lugar a los Product Owner y Team Members, a que estén actualizándose, leyendo, buscando blogs, siguiendo en Twitter a los referentes de la industria, buscando nuevos enfoques o visiones más profundas que puedan enriquecer su experiencia con nuevas teorías o hallazgos, de manera que al momento que alguien se les acerque tengan argumentos para:

• saber cómo enfrentar el problema
• saber cuándo aplica la máxima de la gestión empírica:“inspección y adaptación”, y cuando no (2)
• comprender que experimentos se pueden proponer o un posible espacio de solución
• realizar las preguntas correctas que orienten y ayuden al coachee, al equipo, o a quienes se les acerque 
• entre muchas otras situaciones

y de esa manera puedan brindar una mejor ayuda a los “síntomas” que se están observando.

Un Poco de Remedio

Como parte del remedio, les comparto algunos blogs y cuentas de twitter que sigo:

• Javier Garzas - javiergargas.com - @jgarzas
• Jeronimo Palacios -jeronimopalacios.com - @giropa832
• Jurgen Appelo - http://noop.nl/ - @jurgenappelo
• Luis Mulato -@luisMulato
• Luis Gonçalves -  http://lmsgoncalves.com/ - @lgoncalves1979
• Martin Alaimo - martinalaimo.com  -@MartinAlaimo
• Lucho Salazar - gazafatonarioit.com/ - @luchosalazarc
• Johnny Ordoñez -johnnyordonez.com  - @johnnyordonez
• Henrik Kniberg - crisp.se - @henrikkniberg
• El Blog de la Scrum Alliance -www.scrumalliance.org/community/articles
• El Blog de la Agile Alliance -  www.agilealliance.org/community/blog/
• Infoq - infoq.com 

Un llamado a la Acción

Por ultimo quisiera hacerles un llamado a la acción (adicional al del propósito de este post que es invitarlos a que estudien y se actualicen constantemente), y es que compartan lo que aprendan y comprendan, sus experiencias y reflexiones son valiosísimas, creen un blog, pero si les resulta pesado tener un blog pues muchos me dicen que no se sienten con la confianza o el tiempo para escribir, compartan por twitter, pues lo que ustedes saben es útil para toda la comunidad(3), es una buena forma de generar conocimiento y de salir del anonimato, cosa por demás útil en el mundo de la agilidad.

Hasta acá esta corta reflexión.

Saludos Ágiles

Jorge Abad

_

Notas, Aclaraciones, Comentarios y Referencias

1. Los Agile Coach también (y cualquier persona que tenga el rol de experto o consultor), pero la verdad un Agile Coach no requeriría este tipo de mensaje, pues sabe de la urgencia de estar aprendiendo y comprendiendo sobre como se mueve el entorno técnico, de equipos, de las personas, del coaching, de los frameworks, de las buenas prácticas, el empresarial entre otros.
2. Les recomiendo leer este post: Por qué losagilistas como los gatos caemos parados
3. Una frase que le digo a mis amigos "no sabemos todo lo que sabemos y creemos que lo nuestro es poco", en general somos inseguros acerca de nuestras experiencias, las creemos de poco valor, pero estoy seguro que son valiosas para alguien que se encuentre en una situación similar a ellas y esté buscando respuestas en la red.

[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