Mi Video de Explicación de Scrum

Conversaciones del Scrum Master según la Madurez del Equipo

Hola a todos

Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar  del lider (recomiendo ver (1)).

El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe  

"Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)

Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:

• Equipo en Formación - Conversación tipo: Comando y Control
• "-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
• Equipo en Conflicto - Conversación tipo: Persuación
• "- ¿Les parece si revisan el log de transacciones?"
• Equipo en Normalización - Conversación tipo: Participación
• "-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
• Equipo en Desempeño - Conversación tipo: Delegación
• "-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?

Respecto a la Caducidad del Scrum Master

Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:

¿El Scrum Master caduca, o deja de ser necesario?

Es como si se afirmara,

como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico

Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación-  las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.

Para cerrar te comparto algo que me ha mostrado la experiencia,

• En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
2. Guía oficial de Scrum- https://scrumguides.org/
3. Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos - clic aquí-
4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - clic aquí -.
5. Lecturas recomendadas:
• La caducidad del Scrum Master… y por extrapolación del coach ágil - clic aquí-.
• El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo - clic aquí -.

Sketch - Explicación de Scrum

Hola a todos

les comparto este boceto que realicé hace poco explicando el marco de Scrum

les comparto este boceto que realicé hace poco explicando el marco de Scrum


También puedes descargarlo en png de alta resolución del siguiente link - clic acá- .

Saludos ágiles

Jorge Abad

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.

• Vista 1 - Descubrimiento (Discovery):
• En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
• expertos del negocio
• arquitectos de software y arquitectos empresariales
• Expertos en UX / UI
• clientes
• posibles suarios
• expertos en Seguridad y Riesgos
• expertos en Procesos
• gerentes de Producto (Product Managers) 
• otros PO e interesados claves
• Para definir:
• el producto,
• la visión del producto
• la lista ordenada del producto (Product Backlog)
• el producto minimo viable (Minimum Viable Product - MVP) 
• las versiones, 
• los prototípos,
• los indicadores,
• los esquemas de ROI
• las hipótesis, etc.
• Para esto se vale de:
• visitas a clientes y usuarios
• conocer donde va a ser usado el producto (gemba walks)
• investigaciones de mercado
• análisis de la compentencia (benchmarks)
• estrategias de construcción del producto
• dependencia de otros productos o soluciones, etc.
• Vista 2 - Desarrollo (Development): 
• En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
• Vista 3 - Producción (Production): 
• En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.

De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:

• Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• problemas de rendimiento y funcionamiento
• estadisticas de desempeño
• problemas de seguridad
• deuda técnica identificada y que debe ser priorizada
• Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
• El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
• funcionalidades innecesarias
• funcionalidades a adicionar
• estrategias de implementación
• deuda técnica identificada a ser priorizada
• incidentes y bugs a ser priorizados
• retos técnicos
• estimaciones
• nuevas dependencias técnicas
• nuevas dependencias funcionales con otros productos o equipos de trabajo
• Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• valor o ROI generado vs. el esperado
• datos que se obtienen de la validación de hipótesis
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• estadisticas de desempeño
• problemas de seguridad identificados
• problemas de experiencia de usuario identificados
• deuda técnica identificada y que debe ser priorizada
• estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
• Dual Track Development is not Duel Track - clic aquí
• Dual-Track Agile: Why Messy Leads to Innovation - clic aquí
• Dual-Track Agile - clic aquí
• How to set up Dual-Track Scrum in Jira - clic aquí
3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.

Product Owner's Views