1. Answer this question: What is your product?

Este artículo de Ellen Gottesdiener destaca la importancia de definir bien el producto para evitar problemas habituales como:

• Productos fragmentados y con dependencias.
• Excesiva influencia de los departamentos que resta efectividad al Product Owner.
• Menor capacidad del equipo para tomar decisiones de valor según una visión.

Tres principios que recomienda Ellen para definir tu producto, algunos coinciden con LeSS, son:

1. Definir el producto con perspectiva de usuario, no de la organización interna.
2. Considerar el ciclo de vida completo del producto y no una sucesión de proyectos inconexos.
3. Definir el producto lo más ampliamente posible para darle coherencia.

Saber cual es tu producto crea la base necesaria para tener éxito en la entrega de productos con Scrum.

 2. The five stages of Product Backlog Item sizing

Scrum es un sistema pull y el equipo es responsable de estimar cuanto trabajo puede asumir en los Sprints. Ello requiere un refinamiento efectivo y una estimación de los PBI. Len Lagestee describe un modelo de 5 pasos en las estimaciones grupales basadas en puntos de complejidad, que puede ser útil para ayudar a algunos equipos a mejorar sus estimaciones.

1. Perspectiva individual: se escuchan todas las opiniones, generando seguridad psicológica para todo el equipo.
2. Comprensión individual: los desarrolladores relacionan las perspectivas de los demás con su contexto.
3. Relatividad en las estimaciones: aquí aparecen opiniones como “lo hemos hecho antes”, “se parece a eso”, “es nuevo”, etc.
4. Alineamiento del equipo: a partir de las opiniones anteriores se escoje una puntuación en la escala escogida, usualmente usando Planning Poker.
5. Sabiduría del equipo: el aprendizaje de los pasos anteriores, que se consolida Sprint a Sprint, permite mejorar la precisión y entendimiento compartido en las estimaciones.

Un hecho que pasa desapercibido en muchas discusiones simples sobre “estimaciones vs #NoEstimates” es que las estimaciones individuales suelen ser menos importante que la generación de endendimiento compartido en el equipo, como este artículo recuerda.

 3. Automating Agility

David Starr escribe este artículo tan sencillo como valioso. Las prácticas modernas de ingeniería de software, como integración continua y despliegue continuo (CI / CD) llevan al equipo a hacer mejor Scrum “casi por accidente”. La integración contiua obliga a una colaboración frecuente entre los miembros del equipo, aumentando la transparencia del Sprint plan, la sensación de equipo y el flujo del trabajo. El despliegue continuo acorda el tiempo de feedback y permite obtener feedback técnico y de uso del producto durante el Sprint. Nada en la Guía Scrum dice que el incremento deba desplegarse únicamente al final, es un mito. Tanto CI como CD hacen mejores los eventos de Scrum, especialmente el Daily.

La regla “No rompas el build” mejora la colaboración de los equipos.

 4. Anatomy of an impediment

Este es el segundo artículo de Len Lagestee que destaco. Len analiza el concepto de impedimento desde el punto de vista Lean “la abilidad de productir y entregar resultados valiosos dentro de un ecosistema de flujo y agilidad”. Así pues, clasifica los impedimentos como:

1. Cualquier restricción del flujo o del “pull” en el sistema. Aspectos como las aprobaciones jerárquicas, la falta de capacidades en el equipo o no empoderar al equipo para gestionar autónomamente el trabajo que realizan son impedimentos.
2. Cualquier tensión en el equipo que supere un nivel constructivo. Los conflictos pueden ser creativos si el equipo los reconoce y sabe canalizarlos. Otros conflictos basados en las personalidades o estilo de trabajo pueden ralentizar o destruir un equipo.
3. Cualquier cosa que impdia al equipo auto-curarse. La capacidad de los equipos para mejorar contiuamente y buscar sus respuestas ante las dificultades hace que los equipos sean resilientes. Si las retrospectivas no funcionan bien o el equipo no puede implementar las mejoras identificadas, probablemente revertirá a malas maneras de trabajar cuando haya dificultades.

La Scrum Guide dice que el Scrum Master tiene la responsabilidad de ayudar al Equipo Scrum con los impedimentos. Pero, ¿qué es un impedimento?

 5. Use Brain Science to make your Scrum events stick

Me ha gustado leer este artículo de Evelien Acun-Roos, coincidí con ella en el curso de preparación para Professional Scrum Trainers en 2015. Evelien ofrece cursos del modelo “Training from the back of the room” (TBR) de Sharon Bowman, y en este artículo explica como los principios de TBR le ayudan a tener eventos más efectivos.

1. Hablar triunfa sobre escuchar. Los eventos participativos se asimilan mejor.
2. Escribir sobre leer. Los eventos donde los participantes escriben (p.e. post-it) ayudan a aprender más.
3. Moverse triunfa sobre estar quieto. Los eventos donde los participantes se mueven generan más energía.
4. Los eventos más cortos triunfan sobre los más largos, ya que aprovechan mejor los espacios de atención de las personas.
5. Lo nuevo triunfa sobre la rutina. La variación en técnicas de facilitación, agendas, etc. ayuda a mantener a las personas animadas y atentas.
6. Las imágenes triunfan sobre las palabras, ya sea en post-it, presentaciones, etc.

Saber como el cerebro procesa la información puede ayudaros a mejorar la experiencia de aprenizaje y razonamiento de los asistentes a los eventos Scrum.

 6. The effects of working from home

Mucho se ha hablado del teletrabajo desde que llegó la pandemia. En este artículo Daniel James Gullo habla de los efectos del teletrabajo en Scrum. Cuando el Agile Manifesto cita como principio la comunicación cara a cara, está basándose en la investigación psicología y social de las últimas décadas. La comunicación asíncrona es mas lenta y disminuye la sensación de pertenencia al equipo. Las nuevas herramientas de videoconferenica y colaboración aceleran la toma de decisiones y mejoran la sensación de equipo, pero aún así la gran mayoría de la investigación académica afirma que sigue siendo menos efectiva que la comunicación presencial. El autor destaca los riesgos del teletrabajo permanente, como incrementar las horas trabajadas, la sensación de aislamiento o el síndrome del “siempre alerta”.

El sexto principio del manifiesto ágil: “la manera más eficiente y efectiva de transmitir información en el equipo de desarrollo es la comunicación cara a cara”.

 7. Five sublime aspects of being a more humane Scrum Master

Hiren Doshi comparte las 5 cualidades que le han permitido crecer como Scrum Master, además del estudio sobre Scrum o las certificaciones profesionales.

1. Empatía. Respetando y pretendiendo entender a las personas, pensando que quieren hacer lo mejor posible.
2. Humildad. Trabajando para ayudar a los demás, sabiéndote vulnerable y no juzgando.
3. Compasión. Siendo tolerante, amable y cercano con las personas.
4. Autenticidad. Mostrarse como uno es, no apropiándose de las ideas de los demás.
5. Perdón. Admitiendo que todos, incluido uno mismo, cometen errores, y que la única manera de avanzar es perdonar.

Being mindful and practicing these values has helped me to be a better Scrum Master… and I sincerely hope they can help you too.

 8. The “MetaScrum” pattern to drive agile transformation

Allan O’Callaghan nos explica el patrón MetaScrum, parte del proyecto Scrum Patterns Group. Su objetivo es facilitar la transparencia de los impedimentos con la alta dirección y el management intermedio, Estos impedimentos son frecuentemente los que frenan o hacen descarrilar las adopciones de Agile. El MetaScrum es un foro donde el management de todos los niveles de la organización escucha los impedimentos que presentan los Product Owners. Es importante que en este foro se mantenga la autoridad de los Product Owners. No se trata únicamente de eliminar impedimentos, sino que los Product Owners pueden entender la estrategia y restricciones del contexto organizativo, resultando en una colaboración bidireccional basada en la transparencia.

El patrón MetaScrum, cuando es aplicado, crea un suelo fértil para una más rápida evolución de la organización hacia la agilidad de negocio.

 9. The “Standing meeting”

Este artículo de Bob Warfield habla sobre los orígenes de Agile. Hay algún otro artículo parecido que os sorpenderá mucho, pero que no comento para no hacerle “spoiler” al libro de Gunther. 🙂 Bob comenzó a hacer Daily meetings a *principios de los 80* después de asistir a una charla de Bob Feldman (el creador de la herramienta MAKE de UNIX). En esa charla Feldman afirmaba que era difícil que un grupo de 7∓2 personas (¿os suena de algo este rango?), y que la principal limitación al crecimiento de los equipos era la complejidad de la comunicación. Para reducir al mínimo el coste de la documentación y tener buena comunicación, puso en marcha estas reuniones informales. El nombre no sugiere que necesariamente se tengan que hacer de pié, pero si que sean sistemáticas y no tengan que organizarse.

Regardless of what are they called, a Daily is a developer’s meeting, not a place for marketers to try to have developers accountable. That is one of the main ways I have seen Agile go wrong over time.

 10. Agile in Education with eduScrum.

En 2013 ya había oido hablar de eduScrum por parte de un alumno a un curso, aunque no le presté más atención hasta que en agosto de 2015 me contacto un consultor que trabaja en la Comisión Europea. Me proponía participar en un proyecto Erasmus+ para pilotar la metodología eduScrum en institutos y universidades españolas. En una semana montamos un consorcio con mi amigo PST Jean Pierre Berchez y presentamos la oferta, pero perdimos. En este artículo Willy Wijnands, un profesor de química en un instituto de Holanda, explica los principios de aplicación de eduScrum, como un grupo de estudiantes a los que se lanza un reto y se les da libertad, pero también se les pide cuentas, sobre la gestión y la reflexión sobre su proceso de aprendizaje. En breve, en eduScrum el profesor actúa como coach, facilitador y mentor de los alumnos, marcando unos objetivos de aprendizaje a realizar en un Sprint. El profesor intenta ser lo menos intrusivo posible durante la realización del Sprint, y al final de éste actúa como Product Owner revisando el valor de lo aprendido, y como Scrum Master ayudando al equipo de estudiantes a crear transparencia sobre su colaboración y a empoderarles para buscar y realizar mejoras. As a teacher I’m only involved when the team gets stuck or moves in the wrong direction. By fully knowing what they didn’t understand the look for knowledge, and this is what the true teaching should be about, in my view.