El libro de reglas reflexivo

---

En los últimos meses, creo que he llegado a un lugar en mi viaje ágil en el que comencé a cuestionar las normas e innovar en mi práctica. No lo digo con arrogancia, de hecho lo digo de manera humilde porque últimamente parece que tengo más preguntas que respuestas. Esta publicación de blog es en realidad más para mí (en el momento de escribir esto ni siquiera estoy seguro de planear compartirla), para obligarme a explicar de manera coherente mi pensamiento sobre las mejoras de Scrum. Advertencia justa, no espere ninguna respuesta de este blog. Mi objetivo es la reflexión personal y nada más.

Hace aproximadamente un año, desafié a un Scrum Master experimentado con una pregunta. Recientemente, en un escenario completamente diferente con una persona diferente, esa pregunta volvió a surgir, y por eso quise escribir sobre ello. Esa pregunta era:

'¿Existe un punto en el que el propio marco Scrum se convierte en un impedimento para la mejora continua?'

Sé lo que estás pensando. Estás pensando que estoy loco. Pero déjame explicarte por qué hice la pregunta y luego podrás emitir tu juicio.

Para mí, Scrum se trata de realizar empíricamente pequeñas mejoras tanto en un Producto como en el proceso que utilizamos para entregarlo. Scrum es increíble, sus resultados están comprobados, estoy vendido 100%. No es prescriptivo (después de todo, ¡es un marco!), pero proporciona una guía ligera sobre cómo avanzar hacia la maximización del valor. Sin embargo, también soy un defensor de la forma de pensar Shu-Ha-Ri (SHR), por lo que la pregunta que hice surgió de cómo podrían coexistir Scrum y SHR (como me han dicho innumerables veces que trabajan "mano a mano"). -en-guante').

En un nivel básico, SHR es 'Tradición' (siguiendo las reglas), 'Innovar' (desafiando el status quo) y 'Trascender' (creando tus propias reglas). Como Scrum Master, mi objetivo siempre ha sido crear un entorno donde la creatividad y la autoorganización sean fundamentales. Por lo tanto 'Shu', donde el equipo observa el 'normas que crearon nuestros antepasados' ¿Es aplicable 100%? Sin embargo, más allá de eso, no estoy seguro de qué tan aplicables son Ha y Ri a Scrum. He estado entrenando a muchos equipos recientemente en el marco Scrum y ni siquiera puedo contar la cantidad de veces que he dicho "autoorganizarse, pero dentro de los límites de Scrum'. Si reflexiono sobre decirles eso, ¿los estoy restringiendo a 'Shu'? ¿Estoy impidiendo su capacidad de 'Innovar' y 'Trascender'? Si el 'Los formularios pueden estar rotos. (Ja) o 'apartarse completamente de las formas' (Rhode Island), ¿eso significaría que no están haciendo Scrum si operan fuera de los límites? ¿Es eso un problema? ¡AHHH! ¡Muchas preguntas!

Creo que ya me he decidido por mi opinión de que incluso si el Producto es 'complejo y adaptativo' y es la opción perfecta para Scrum, restringir al equipo a organizarse únicamente dentro de los límites corre el riesgo de crear un techo de cristal para el progreso. La razón por la que pienso esto (mi opinión probablemente flotará como una pluma en el viento en este asunto) es porque considero que "seguir Scrum" significa simplemente, 'haz que tu proceso sea empírico'. Si la evidencia sugiere que un equipo puede mejorar la aplicación de Scrum en su dominio… ¿deberían confiar en su empirismo y adaptarse?

En el futuro, si mi equipo fuera: entregando consistentemente incrementos potencialmente liberables; mejorar constantemente su calidad y procesos; viviendo los 5 valores de Scrum (sin dejar de ser empírico) y dijo: 'Sabemos que X está fuera del marco de Scrum, pero creemos que nos hará mejores', ¿intentaría recordarles los límites del marco? El viejo yo definitivamente lo habría hecho, y creo que todavía lo haría ahora. ¿Pero intentaría que siguieran la aplicación Scrum del libro de texto incluso si creen que pueden hacerlo?Trascender'? Probablemente no.

Al inicio de este blog dije que el propósito de escribir esto era hacerme reflexionar. Y yo tengo. La pregunta que le hice a mi colega principal era errónea. Scrum no es el impedimento; de hecho, el marco nos dice claramente qué hacer cuando hayas entregado tu trabajo a Listo.inspeccionar y adaptar'.

Me gustaría comparar mis pensamientos sobre este tema con un 'huevo de Pascua' en un videojuego. Cuando hayas llegado lo más lejos que puedas siguiendo la trama (reglas del marco Scrum; Shu), debes buscar otras oportunidades para hacer que tu experiencia sea interesante (innovando y adaptándote con libertad; Ja). Con el tiempo, dejarás atrás el juego y buscarás algo mejor (Ri).

Dicho esto, me gustaría cambiar mi pregunta, por favor:

'¿Existe un punto en el que un equipo pueda superar el marco de Scrum?'

….y creo que ese es un tema para otro blog.