¿Cómo conocer el grado de madurez en Scrum de un equipo nuevo?

Recientemente tuve la necesidad de evaluar el grado de madurez de un equipo nuevo que se iba a incorporar para trabajar en Scrum. Me imaginé que preguntar directamente no serviría de mucho, reconocerán que no están certificados pero dirán que tienen experiencia en Scrum. Tenía claro que lo que tenía que observar es la confianza entre los miembros del equipo, ver cómo interactúan entre ellos y la seguridad con que se muestran como equipo, y para eso la mejor forma sería hacerlos colaborar en alguna dinámica frente a un tablero.

Así que idee una variante del tablero de acuerdos de trabajo y maté dos pájaros de un tiro. En este tipo de acuerdo se les pide a los participantes que escriban lo que no les gustaría que pasase, y para este tablero que idee debían de escribir lo que no les gustaría que pasase durante el proyecto relacionado con el Scrum Master (SM), el Propietario del Producto (PO) y el equipo (TEAM). Dado que lo que escribirían iría directamente relacionado con los roles de Scrum, obtendría de paso la madurez del equipo.

Resultado de un equipo que ha trabajado bajo scrumbut, no han vivido
problemas con el Scrum Master pero si con el Propietario del Producto

Fue una buena experiencia, me encontré con un equipo muy bien integrado y conocedor de los procesos de Scrum. Como podemos ver en la imagen superior hay un claro desequilibro, en la parte de Scrum Master prácticamente no hay post-its, mientras que en la del Propietario del Producto y la del equipo hay muchos, incluida la zona de separación, que en este caso representa la intersección de ambos.

Me llamó la atención que una de sus mayores preocupaciones fuera la interferencia en los sprints, la adición o modificación desde fuera del equipo de la pila de sprint. Con esto supe que el equipo sabe de Scrum, y también cual es su realidad. Me extrañó que la columna del Scrum Master no tuviera apenas post-its, pero todo encajó cuando conocí más a fondo la metodología de la consultora del equipo, habían incorporado los procesos de Scrum en su metodología tradicional. Básicamente no hay post-its en la columna del Scrum Master porque no hay gestión de personas, por tanto me encontré ante una situación de claro scrumbut. Fuere como fuere es un buen punto de partida, es un equipo integrado y conocedor de los procesos de Scrum, el hacerlos evolucionar ya solo depende de este Scrum Master.  :-)