Anti patrones de Scrum

Hola, mis notas de la clase:

Modelos Adaptativos de Control
Habíamos dicho que se pueden encontrar MAC:

• A nivel de producto
• A nivel de proceso
• A nivel de pprogreso

MAC en producto

Transparencia de producto

• En el Product Backlog
• En el Incremento del Producto

¿Cómo está la transparencia del producto?

• ¿Es el Product Backlog visible y accesible por todos los miembros dentro de la organización? ¿o es un artefacto que está oculto por el Product Owner y nadie sabe qué es lo que hay allí?
• Puede que el Product Backlog sea accesible pero ¿es fácil de interpretar?
• ¿Tenemos un documento con todas las ideas que tiene el Product Owner en su cabeza pero esos criterios de priorización y valor no son accesibles o no son entendibles?
• Cada vez que aparece el Incremento ¿es visible por todos los miembros de la organización, incluyendo a los Stakeholders?

Inspección de producto

• En la Sprint Review

¿Esto se está dando? ¿ocurre una inspección del producto en la Sprint Review?

• Si esto no está sucediendo, aquí tenemos un anti-patron, quiere decir que la Sprint Review no está funcionando y teneos que intervenirla.
• Tenemos que buscar qué de lo que se esta haciendo en la Sprint Review no esta aportando a esa inspección y eliminarlo, así como entender por qué no se esta dando la inspección de producto en el equipo.
• A veces es por simple desconocimiento o porque se viene del paradigma anterior de comando y control, donde el foco está en presentar informes, métricas, etc.
• A veces la solución entra a ser mas bien a partir del sombrero del entrenador, como Scrum Master le explicamos al equipo sobre el valor de la Sprint Review y la necesidad de hacer inspección del producto.

Adaptación de producto

• En la Sprint Planning

¿Está ocurriendo? ¿Esa información que recogimos en la Sprint Review está sirviendo para algo?

• Pasa mucho y es un anti-patrón cuando no hay adaptación de producto a pesar que tenemos información suficiente de inspección proveniente de la Sprint Review y a pesar que nos está demostrando que el camino que estamos siguiendo con el producto no es el que deberíamos seguir.
• Si el feedback del cliente nos esta dando luz sobre que el producto no esta funcionando, deberíamos cambiar algunas características, pero en la Sprint Planning las prioridades del backlog no están cambiando, entonces el producto no se está adaptando.
• En algunas empresas los equipos introducen Scrum a lo que ya venían haciendo con la forma de trabajo tradicional y tienen proyectos con un alcance ya establecido, por lo que les cuesta cambiar ese alcance a partir del feedback proveniente de la inspección de producto.
• En ese caso, analizar si tiene sentido usar Scrum para un proceso lineal, donde sirve el Modelo Predictivo de Control o si bien se está trabajando en un contexto de incertidumbre, donde deberíamos respetar el Modelo Adaptativo de Control de Scrum y permitir la adaptación. En ese caso, ponernos el sombrero de consultor y enseñar a la organización las virtudes de Scrum en ese contexto.

MAC en proceso

Transparencia de proceso

• En el Sprint Backlog
• En el Definition of Done

¿Existen, son visibles y accesibles? ¿Son lo suficientemente claros?

Inspección y adaptación de proceso

• En la Sprint Retrospective

¿Está ocurriendo inspección y adaptación del proceso?

• Es muy fácil hacerlo muy mal, porque las personas inclusive pueden hacer todas las técnicas de facilitación y todos los ejercicios pero no hay mejora del equipo.
• En ese caso puede ser que no sale a la luz la causa raíz, tal vez se están mencionando problemas muy genéricos y no se está bajando de nivel para llegar al nivel de detalle.
• No es suficiente con parecer que estamos haciendo inspección y adaptación, tiene que haber mejora real.

MAC en progreso

Transparencia, inspección y adaptación de progreso

• En la Daily Scrum

La Daily Scrum funciona por si sola como un Modelo Adaptativo de Control que nos permite navegar en la incertidumbre del Sprint.

Si llegamos al final de Sprint y el equipo no esta cumpliendo sus objetivos, entonces hay anti-patrones en la Daily Scrum y no esta funcionando el MAC en progreso.

• Puede ser la transparencia: el Scrum Master debe analizar si están saliendo a la luz todos los elementos que tienen que salir para que podamos adaptar la forma de trabajo a tiempo de forma que no comprometamos el objetivo del Sprint.
• Puede ser la inspección: ¿Están saliendo a la luz esos datos pero nadie está haciendo nada con eso? ¿Alguien los esta analizando? Muchas veces en la daily algunas personas son muy transparentes y comparten los bloqueos que tienen, pero esperan que alguien se los resuelva o quedan en la conversación y se pierden en el día a día.
• ¿Hay adaptación? Si nos estamos dando cuenta que algo no esta funcionando, estamos teniendo algún tipo de bloqueo o que la estrategia inicial no esta funcionando y no hacemos nada para corregirlo, nos estaremos volviendo cómplices de un resultado final no exitoso del Sprint.
• Todas las personas, en especial en este caso los developers, son responsables del resultado final del Sprint y si alguien esta alzando la mano y los demás no hacen nada para adaptar la estrategia, estamos teniendo un problema de adaptación y ademas un anti-patron a la hora de colaboración del equipo.

Toda esta teoría sobre los anti-patrones no solo sirve para entender en forma mas profunda todos los elementos sino como una herramienta para analizar la salud de la implementación del equipo Scrum.

Si no existe Transparencia, Inspección o Adaptación estamos en un Antipatron

Hola, mis notas:
Si estos pilares no se cumplen en las ceremonias se está incurriendo en un anti patron en Scrum:

1. Transparencia: Se debe dar en el Product Backlog, Increment, Sprint Backlog, Definition of Done, Daily Scrum
2. Inspección: Se debe dar en el Sprint Review, Sprint Retrospective, Daily Scrum
3. Adaptación: Se debe dar en el Sprint Planning, Daily Scrum, Sprint Retrospective

"No solo debe parecer que estamos haciendo inspección y adaptación, es necesario que exista mejora

Hola a tod@s.

De acuerdo al caso de estudio a continuación les comparto anti patrones y oportunidades de mejora que identifico:

1. La daily Scrum se usa para rendición de cuentas y no para manifestar stoppers o información de valor que ayuden al logro del objetivo.
2. El product owner no participa de todas las daily scrum
3. El product baclok no cumple con el criterio de transparencia pues este lo administra únicamente el PO en un archivo de excel al cual ningún miembro de la organización tiene acceso.
4. No hay inspección en la sprint review ya que dedican el espacio a presentar historias de usuario y puntos completados , pero no se involucra al cliente y no hay un ejercicio de prueba real del producto para tener feedback del cliente y del equipo respecto de lo desarrollado durante el sprint.
5. No hay transparencia respecto del definition of done pues no están las reglas claras para determinar el concepto de “terminado”
6. No hay inspección ni adaptación en la sprint retrospective pues no asisten todos los integrandes del scrum team, por lo que los aportes del equipo están incompletos, en ese sentido la recolección de datos e información no seria del todo valida.

Saludos.
Magda 😉

Antipatrones:

• Al momento del Sprint planning, que el rol del Product Owner asigne el trabajo a los desarrolladores.
• El evento Daily meeting scrum, no debe usarse para hostigar o para realizar seguimientos de trabajo.
• En el evento Sprint review, convocan a product owner o usuarios sin conocimiento de lo que se hace.
• Los product owner se comportan como jefes de equipo.
• Algunos confunden los Sprint planning como cronogramas.

Anti patrones de scrum:
.
Son los comportamientos contrarios a la Transparencia, Inspección y Adaptación.
Pueden ocurrir en el MAC a nivel de producto, proceso o progreso.
Muchas veces los anti patrones pasan por el desconocimiento, de algún evento o porque se viene del paradigma anterior de comando y control y de presentar informes y métricas.

La importancia para evitar antipatrones:

1. Adaptación
2. Inspección
3. Transparencia

Antipatron comportamientos adversos que no cumplen con los patrones de transparencia, la inspección y la adaptación

Scrum es un modelo adaptativo de control, es decir si desde el inicio sabes exactamente que es lo que se quiere sin cambios, esta metodológica queda fuera porque no aplica, no hay incertidumbre; sin embargo con proyectos de desarrollo la interacción con el cliente puede ir cambiando los requerimientos, pero no deben ser cambios muy alejados de lo planteado en un inicio.

La estrategia del producto debe ser conocida por todos los integrantes del Scrum team, esto es transparencia.
Gestión de HU, Criterios de aceptación, objetivos del producto, nos permiten realizar inspección.
Feedback del cliente debe tener cierta influencia en la priorización del product backlog, esto es adaptación.