domingo, 12 de diciembre de 2021
Divide con coherencia y Vencerás con éxito!

miércoles, 8 de diciembre de 2021
Guia del Scrum Master: Ejecución (Sprint 1 y sucesivos)
La ejecución de un
proyecto o producto ágil basado en Scrum comienza con el Sprint 1. Cada equipo
acuerda la duración de los sprints, que
suelen ser de 1, 2, 3 o 4 semanas, y una vez fijada la duración, debe ser la
misma en todos los sprints. En cada sprint se dan 5 eventos: Refinamiento, Planificación
de sprint, Reuniones diarias (dailies), Revisión y Retrospectiva (¿Es verdad que en Scrum hay demasiadas
reuniones?: Los eventos en Scrum).
Disponer de una lista
de actividades y verificaciones guía al Scrum master (SM) en la gestión exitosa
del proceso Scrum, y como toda guía ágil, debe ser constantemente inspeccionada
y adaptada a las particularidades del equipo, producto y organización donde se
aplica (más sobre el SM en Lecciones Aprendidas con SCRUM. El Scrum
Master (2)).
Guía básica para la ejecución de los eventos
de cada sprint:
#
|
General
|
|
1
|
El SM realiza con anticipación las
convocatorias a cada evento del sprint, incluyendo en cada caso: Propósito,
Agenda, Fecha, hora y duración, Lugar o enlace digital
|
☐
|
2
|
En la reunión el SM facilita las
conversaciones dentro del equipo y modera la sesión para que siga la agenda,
cumpla su propósito y se realice en el tiempo acordado.
Cómo tener sesiones de trabajo productivas en Scrum |
☐
|
3
|
Ayuda que el equipo disponga de una
Sala Obeya para la gestión eficiente de su proyecto o producto
La Sala Obeya: Gestión visual y colaborativa de proyectos |
☐
|
|
Refinamiento
|
|
4
|
El Product
Owner (PO) prioriza el Product
Backlog y documenta las historias de usuario más próximas a realizarse en
la herramienta y formato acordados. Se recomienda tener refinadas las
historias para los próximos 2 sprints
|
☐
|
5
|
El equipo de desarrollo analiza las
historias prioritarias y toma nota de las dudas
|
☐
|
|
Planificación de
sprint
|
|
6
|
El SM verifica que se dispone de
backlog priorizado y refinado para la planificación del sprint
|
☐
|
7
|
En la reunión el SM verifica con el PO la
prioridad de las historias, valida si el equipo de desarrollo tiene cualquier
duda y solicita que estimen las historias que podrían acometerse en el sprint
|
☐
|
8
|
El equipo, guiado por el PO, acuerda la
meta del sprint y conforma el Sprint
backlog con las historias que permiten cumplir la meta y cumplen la definición
de Ready. El Sprint Goal: La meta del Sprint.
Historias de Usuario: DoR y DoD clave para
la eficiencia y productividad del Equipo
|
☐
|
9
|
El equipo de desarrollo verifica que el
alcance del sprint es el adecuado de acuerdo con su capacidad, teniendo en
cuenta velocidad y disponibilidad
|
☐
|
|
Reuniones diarias (Dailies)
|
|
10
|
El equipo debe tener actualizado el
estado de las historias y tareas en las que trabaja
|
☐
|
11
|
Compartir el tablero del sprint activo
y hacer un recorrido del trabajo en curso de derecha a izquierda, dando
prioridad al cierre del trabajo en curso más próximo a completarse
|
☐
|
12
|
El SM toma nota de los impedimentos y
dificultades del equipo de desarrollo para gestionar su solución
|
☐
|
13
|
Verificar el trabajo en progreso que se
encuentra en el sprint activo, asegurándose de que las personas del equipo no
tienen más de 2/3 tareas asignadas (Work
In Progress-WIP). Cómo hacer dailies productivas en 15
minutos
|
☐
|
|
Revisión
y Retrospectiva de sprint
|
|
14
|
El equipo prepara la demo para la
revisión del sprint y durante la revisión se documentan los acuerdos
referidos a cada historia de usuario trabajada durante el sprint. El PO
valida las historias que pasan a Done. Definition-of-Done: Clave de la Calidad del Producto. ¿Qué es una review?
|
☐
|
15
|
El SM prepara la retrospectiva llevando
un registro de las acciones de mejora acordadas en la retrospectiva anterior
para verificar su estado e impacto en el sprint. El valor de las retrospectivas potentes.
Hagamos Retrospectivas potentes
|
☐
|
¿Qué agregarías a esta lista?
¡Gracias por leerme!
Saludos, María Esther
Ig @Soy.agile.coach

sábado, 20 de noviembre de 2021
Guia del Scrum Master: Preparación (Sprint 0)
# |
Actividad |
Status |
1 |
Junto
con el Product Owner (PO), identifica que técnicas y dinámicas realizar, así
como las personas clave que deben asistir, y preparen la agenda del Sprint 0.
How to plan an
inception (or similar workshops)? |
☐ |
2 |
Siguiendo
la agenda, y de acuerdo con la disponibilidad de los participantes, envía las
convocatorias a las reuniones indicando: requisitos, objetivos y puntos a
tratar en cada reunión. |
☐ |
3 |
Asegura
que durante las sesiones de sprint 0 se crea el Mapa de Historias de Usuario. ¿Cómo hacer un User
Story Mapping? |
☐ |
4 |
Si
se trata del desarrollo o evolución de un producto o proyecto pueden necesitar
la elaboración de un Plan de entregas. SCRUM: Release
Planning y Scrum |
☐ |
5 |
En
caso de que sea la primera vez que el PO trabaja con Historias de Usuario,
realiza un taller de escritura de Historia de Usuarios. SCRUM: Cómo escribir historias de usuarios sin morir en
el intento |
☐ |
6 |
Al
disponer de las primeras historias descrita, coordina una sección de
refinamiento con el equipo de desarrollo y el PO. Experiencia: Cómo
hacemos las reuniones de refinamiento (Grooming) |
☐ |
7 |
Facilita
que el equipo Scrum acuerde la Definición de Hecho (DoD) y la Definición de
Preparado (DoR). Definiciones ante de empezar el primer Sprint (DOR y
DOD) |
☐ |
8 |
Apoya
al PO en la creación del Product Backlog y del Plan de entregas. Por
ejemplo, en Jira: Historias, epics e
iniciativas, Aprende a utilizar versiones en Jira
Software |
☐ |
9 |
Convoca
la Planificación del Sprint 1 y las Dailies del equipo de desarrollo |
☐ |
10 |
Recuerda moderar las reuniones para que se
realicen en el tiempo agendado y siguiendo lo especificado en la convocatoria.
10 pautas para
organizar reuniones de trabajo efectivas |
☐ |
Gracias
Saludos
María Esther Remedios
Ig @Soy.Agile.Coach

Agile 2: Continuando con los Valores
Valor 1: Consideración y Prescripción.

lunes, 1 de noviembre de 2021
Agile 2: Valor 2: Resultados y productos (Outcomes and outputs)
Entendamos primero la
diferencia entre resultados (outcomes)
y productos (outputs).
Los resultados son lo
que la empresa quiere o necesita lograr y los productos son las acciones o
elementos que contribuyen a lograr dichos resultados.
En la primera
iteración de Agile, se da mucha relevancia a los Equipos y al Producto.
En Agile 2 se destaca
que los Resultados requieren Productos, y ambos importan; pero los Resultados
son lo que más importa.
Por ejemplo, un outcome o resultado organizacional
podría ser "un incremento en las ventas" y el output o producto un sistema de pedidos en línea.
Hablar de Valor en Agile
se refiere a los outcomes o
resultados, y puede diferir entre lo que valora una empresa, un cliente y un
usuario. Una empresa puede valorar la retención del cliente, el cliente tener
mayor autonomía operacional y el usuario una menor tasa de incidencias que
resolver, resultados que se buscan obtener evolucionando uno o más outputs o
productos.
Luego, para avanzar
hacia el logro de resultados organizacionales, debemos comprender las
necesidades de sus clientes, sus dolencias, limitaciones y prioridades, y con
este conocimiento desarrollar productos que logran cambios positivos.
Cabe destacar, que es
más fácil medir productos que resultados, ya que estos últimos dependen en gran
medida, de la satisfacción de las personas. En todo caso, se deben medir productos
y resultados, a fin de evitar el conocido efecto sandía: indicadores exitosos
en las actividades/productos y rojos en los resultados/satisfacción de clientes.
Imagen tomada de: https://www.bmc.com/blogs/outcomes-vs-outputs/
Agile 2 propone entonces, realizar más reflexiones y dedicar mayores esfuerzos en entregas de valor que generen resultados felices.
Gracias por compartir y comentar!!!
Saludos, Ma.Esther
Ig @Soy.Agile.Coach

Agile 2: Valor 1: Consideración y Prescripción
Gracias por compartir y comentar!!!
Saludos, Ma.Esther
Ig @Soy.Agile.Coach

viernes, 8 de octubre de 2021
La Sala Obeya: Gestión visual y colaborativa de proyectos
Se ha implementado bajo diferentes denominaciones, tales como: “Cuarto de guerra” o “War Room”, “Big Room”, “Salón de programas”, “Sala de control”, “La sala de pulso”, “Sala de trabajo”, “Sala de reuniones”, “Discovery Room”, “Sharing Room”, “Sala de flujo de trabajo”, “Sala de gestión visual”, entre otras.
Una forma de organizar la información del proyecto en una Sala Obeya es siguiendo la estructura del Ciclo de Deming PDCA, disponiendo en distintas “paredes” información sobre la Planificación del proyecto, su Ejecución (Do), Verificación y Actuación.
Pared |
Información |
Eventos |
Planificación (Plan) |
· Básica del proyecto: Nombre, descripción, objetivos, alcance general, entre otros ·
Fecha inicio y fecha fin ·
User Story Mapping ·
Equipo de Trabajo ·
Plan de entregas (MVP y otros releases) |
Revisión de la
Planificación Mensual |
Ejecución
(Do) |
·
Sprint activo ·
Puntos de atención ·
Alertas de interés para el equipo |
Dailies Diario |
Verificar
(Check) |
·
Métricas del proyecto ·
Velocidad media del equipo ·
Porcentaje de predictibilidad del equipo ·
Evolución del proyecto |
Verificación
mensual Mensual |
Actuar (Act) |
·
Tareas de mejora continua ·
Tareas bloqueadas ·
Registro de riesgos |
Actuar para mejorar Mensual |
Para construir y operacionalizar una Sala Obeya, se debe considerar:
- Seleccionar la plataforma tecnológica donde funcionará la Sala Obeya (PowerBI, Confluence, Jira, Teams, Sharepoint, etc).
- Determinar que mecanismos de seguridad se necesitan implementar para el control de acceso a la Sala Obeya.
- Establecer el Alcance y el MVP que facilitará la validación y evolución del concepto.
- Realizar un plan preliminar de trabajo que incluya el diseño, maquetación, interfases, desarrollo, pruebas y puesta en producción.
- Desarrollar la Sala Obeya utilizando un marco de trabajo ágil.
María Esther Remedios
Ig @Soy.Agile.Coach
