9 preguntas que los Scrum Masters y Product Owners deberían hacer
Antes de convertirme en Scrum Master, trabajé como líder técnico con una gran variedad de equipos. Parte de ese trabajo era tomar decisiones – y creo que lo hacía bastante bien. La capacidad de decisión y la determinación forman parte de mis características personales.
Sin embargo, estas cualidades no me fueron de mucha ayuda cuando me convertí en Scrum Master. Me di cuenta de que, para tener éxito como Scrum Master, necesitaba hacer menos afirmaciones y en su lugar hacer más preguntas. Como esto no correspondía a mi estilo natural (y no eran las cualidades que me habían traído éxito hasta ese punto de mi carrera), al principio me resultó difícil.
Pero con algo de paciencia fui mejorando en hacer preguntas. Me gustaría compartir algunas de mis preguntas favoritas
con ustedes. La mayoría de las preguntas aplican tanto para Scrum Masters como para Product Owners.
2 preguntas sobre estimaciones
A menudo necesito una estimación aproximada de un equipo. No voy a comprometerlos con ella. (Aquí no pido un compromiso. Las estimaciones y los compromisos no son lo mismo.) Realmente solo quiero una estimación aproximada. En este caso, esta es una buena pregunta:
"No necesito una estimación. Pero si pidiera una estimación, ¿qué unidad se les vendría a la mente? ¿Horas, días, semanas, meses o años?"
Sí, lo sé, estas unidades pueden solaparse – algunas semanas pueden ser más de un mes. Pero una estimación como "Oh, semanas, un par de semanas" suele ser suficiente para tomar una decisión, lo que también puede significar decidir pedir al equipo que estime el trabajo con más precisión.
En situaciones en las que tengo una estimación oficial de un equipo, a menudo hago otra pregunta:
"¿Qué tan seguros están de la estimación?"
Aquí quieres descubrir qué tan segura es la estimación y si los miembros del equipo están de acuerdo. Una estimación en la que el equipo tiene un 90% de confianza será más precisa que una en la que el equipo en general no está muy seguro y las opiniones difieren más.
Los desacuerdos dentro del equipo respecto a la estimación también pueden ser un indicador de que el equipo dio esa estimación demasiado precipitadamente. Eso no tiene por qué ser algo malo, pero debes ser consciente de que la estimación no es tan segura.
3 preguntas sobre decisiones del equipo
Como Scrum Master o Product Owner, a veces quieres tener una idea de lo minuciosamente que el equipo ha reflexionado sobre una decisión. Aquí hay tres preguntas que hago con frecuencia:
- "¿Qué otras tres opciones habéis considerado antes de tomar la decisión?"
- "¿Qué sería lo peor que podría pasar si seguimos en esta dirección?"
- "¿Qué tiene que salir bien para que esta sea realmente la mejor decisión?"
Quizás no debas hacer las tres preguntas a la vez ni las mismas preguntas en cada decisión del equipo.
Además, como Scrum Master o Product Owner no haces estas preguntas porque puedas revertir la decisión del equipo. Sin embargo, tienes derecho a entender qué tan seguro se siente el equipo con la decisión y si estaban de acuerdo.
Estas preguntas deben revelar tales desacuerdos. Si preguntas "¿Qué tiene que salir bien para que esta sea realmente la mejor decisión?" y alguien dice "¡Todo!", eso generalmente significa que hay un problema.
2 preguntas sobre reuniones
No me gustan mucho las reuniones. Si estuviera en un pasillo con un montón de serpientes en un extremo y una reunión en el otro, no sabría hacia dónde correr.
Por eso intento reducir al mínimo tanto el número de reuniones como el número de participantes. Al inicio de una reunión, a menudo hago las siguientes preguntas:
- "¿Necesitamos a todos los que están aquí?"
- "¿Quién más debería estar presente?"
La primera pregunta se hace para descubrir si se puede prescindir de alguna persona. A menudo veo equipos ágiles que se exceden un poco con el trabajo en equipo y la colaboración. Los miembros del equipo sienten que deben participar en cada reunión, aunque sea completamente irrelevante para ellos. Puede ser, por ejemplo, el desarrollador de JavaScript que participa en una reunión sobre si vale la pena migrar a la nueva actualización del proveedor de base de datos.
Si los miembros de tu equipo son un poco demasiado entusiastas con las reuniones, agradece su compromiso con la colaboración, pero al mismo tiempo transmite que no necesitan estar en cada reunión. Establece la regla de que ningún miembro del equipo debería participar en una reunión si no puede contribuir lo suficiente o no puede obtener suficiente valor de ella.
(Sí, esto puede ser explotado. Puede que tengas que dejar claro a algunas personas que esto no significa que ya no tengan que asistir a ninguna reunión. Al final, el equipo en su conjunto debería tener el derecho de anular la decisión de una persona individual de no asistir a una reunión.)
Con la segunda pregunta se busca descubrir si alguien que aún no está presente debería estarlo. Aunque detesto las reuniones (probablemente preferiría las serpientes), a veces necesitamos más personas en las reuniones.
En caso de duda, decantarse por menos reuniones y menos personas, pero algunas reuniones simplemente deben realizarse – y estas reuniones son aún más valiosas cuando las personas adecuadas están presentes.
1 pregunta para caminar por la oficina
Especialmente cuando trabajo como Scrum Master, paso mucho tiempo participando en conversaciones en la oficina. Esto también se conoce como Management by Wandering Around (gestión caminando por ahí). Si, por ejemplo, escucho a un programador y un tester teniendo una conversación aparentemente importante, a veces me acerco para ver si puedo ayudarles con algo.
(Naturalmente, no deberías hacer esto cada vez ni tampoco si parece una conversación privada.)
A veces, las conversaciones que escucho casualmente también son valiosas para otras personas. Quizás el redactor técnico debería saber lo que el tester y el programador han decidido. Por eso pregunto:
- "¿Debería alguien más estar al tanto de esto?"
Si es así, ofrezco compartir esa información si me es posible. Si no, ofrezco traer directamente a la persona correspondiente.
1 pregunta para los Daily Standups
En el Daily Standup miro el Burndown Chart del equipo y a menudo me pregunto cómo planea el equipo completar todo el trabajo antes del final del Sprint. Pero cuando les pregunto si creen que lo lograrán todo, generalmente son muy optimistas.
Si considero que esto es poco realista, miro nuevamente el Burndown Chart y pregunto:
- "¿Sabéis algo que yo no sé?"
Quizás reciba como respuesta que uno de los miembros del equipo aún no ha actualizado sus horas en la herramienta del equipo. O alguien explica que aunque están un poco atrasados, han aprendido bastante y todo se está acelerando de nuevo. (Rara vez considero esto realista, pero lo escucho a menudo.)
Preguntar al equipo qué saben ellos que yo no sé ofrece una excelente oportunidad para sincronizar suposiciones. Quizás ellos asumen que ahora todo se acelerará de nuevo, pero yo no pienso eso. Por eso es una gran pregunta para descubrir suposiciones diferentes.
Conclusión: Las preguntas son mejores que las afirmaciones
Cuando asumi por primera vez el rol de Scrum Master, aún no conocía el poder de las preguntas y perdí muchas oportunidades de aprender más sobre mi equipo y su trabajo. Solo después de un buen tiempo descubrí que puedo aprender más cuando hago preguntas y realmente escucho las respuestas.
Espero que encuentres estas preguntas tan útiles como yo.
Este artículo proviene del blog de Mike Cohn y fue traducido por nosotros al alemán.
