Scrum Master velando por el equipo |
I. El rol del Scrum Master
- El Manifiesto Ágil menciona "Personas sobre procesos". ¿El Scrum Master, como un rol para hacer cumplir "el proceso", no está en contradicción con el Manifiesto?
- ¿Cuáles son buenos indicadores de que la "Agilidad" está funcionando en tu organización? ¿Que muestren que tu trabajo es exitoso?
- ¿Cuáles serían métricas típicas a seguir? y si las hay, ¿qué métricas seguirías y con qué propósito?
- El rendimiento de tu equipo no cumple una y otra vez con los compromisos adquiridos y la velocidad es muy variable. ¿Cuáles pueden ser las razones de ello? ¿Y cómo abordarías esas cuestiones?
- ¿El equipo debe de estar involucrado en el proceso de incepción de productos? y, si es así, ¿Cómo?
- Por su diseño en Scrum el rol del Propietario del Producto puede ser un cuello de botella. ¿Cómo puedes apoyar al Propietario del Producto para que sea el maximizador de valor?
- ¿Cómo puedes asegurar que el equipo tenga acceso a los interesados?
- ¿Cómo puedes difundir la mentalidad ágil a lo largo de diferentes departamentos de la compañía? y ¿Cuál sería tu estrategia para hacer coaching a esos interesados que no son de TI?
- ¿Cómo introducirías Scrum a los directivos senior?
- Se realizó la formación de Scrum para todas las partes interesadas. Después de una fase inicial para tratar de aplicar los nuevos conceptos, cuando se producen los primeros impedimentos, se produce una resistencia seria para continuar con la adopción Scrum por parte de los compañeros. ¿Cuál sería tu estrategia/experiencia para manejar esta situación?
- El Propietario del Producto de tu equipo suele convertir los documentos de requerimientos de las partes interesadas en tareas y pide que se estimen. ¿Estás de acuerdo con este procedimiento?
- ¿Qué tipo de información requerirías del Propietario del Producto para poner al día al equipo sobre el producto y la situación del mercado?
- ¿Quién debe de escribir las historias de usuario?
- ¿Cómo debería de ser una buena historia de usuario? ¿Como debe de ser su estructura?
- ¿Qué debería incluir una "Definición de Listo (DoR)"?
- ¿Porqué no se estiman las historias de usuario simplemente en horas/hombre?
- El Propietario del Producto de tu equipo tiende a añadir ideas de todo tipo a la pila de producto para trabajar en ellas en una etapa posterior. Con el tiempo esto ha llevado a una pila con más de 200 elementos en diferentes etapas. ¿Cuál es tu opinión? ¿El equipo de Scrum puede trabajar en 200 entradas?
- ¿Cómo puedes contribuir como Scrum Master en la planificación de sprint para que el equipo realmente trabaje en las historias de usuario de más valor?
- ¿En qué métricas basarías la evaluación del valor de una historia de usuario y qué métricas no serían aceptables?
- ¿Cómo facilitarías el proceso de selección de historias de usuario de manera que se eligieran las historias de más valor sin anular la prerrogativa del equipo para crear compromiso?
- ¿Cuánta capacidad consideras adecuada para refactorizar, solucionar bugs importantes y explorar nuevas tecnologías o ideas?
- ¿Cómo lidiarías con un Propietario del Producto que asignase historias de usuario o tareas directamente y de forma individual a los miembros del equipo?
- Una historia de usuario carece de los diseños finales, pero el departamento de diseño promete entregarlos el segundo día del próximo sprint. El Propietario del Producto de tu equipo está de acuerdo e intenta que la historia de usuario entre en la pila de sprint. ¿Cuál es tu opinión al respecto?
- Uno de los miembros del equipo no quiere participar en la planificación de sprint porque considera que es una pérdida de tiempo. ¿Cómo lidiarías con esa actitud?
- ¿Recomendarías las reuniones diarias a todos los equipos independientemente de su tamaño y nivel de experiencia?
- ¿Esperarías de los miembros de equipo experimentados que esperaran a la siguiente reunión diaria para pedir ayuda con los impedimentos?
- ¿Cómo manejarías a miembros de equipo que "dirigieran" las reuniones diarias convirtiéndolas en sesiones de reporte hacia ellos?
- ¿Cómo manejarías a miembros de equipo que consideraran las reuniones diarias una pérdida de tiempo y por ello llegaran tarde, no cooperaran o no asistieran en absoluto?
- Ningún interesado atiende a las reuniones diarias de tu equipo. ¿Cómo cambiarías eso?
- ¿Cómo enfocarías reuniones diarias con equipos distribuidos?
- ¿Podrías dibujar un borrador de un tablero Kanban físico para un equipo de Scrum?
- ¿Quién debería de participar en las retrospectivas?
- ¿Revisas la salud del equipo en la retrospectiva? o ¿Crees que no es necesario? si es que si, ¿Cómo lo harías?
- ¿Qué formatos de retrospectiva has utilizado en el pasado?
- ¿Cómo se puede evitar el aburrimiento en las retrospectivas?
- Un equipo siempre selecciona acciones de mejora razonables pero después nunca las implementa. ¿Cómo manejarías esta reincidencia?
- ¿Cómo recomendarías que fuera el seguimiento de las acciones de mejora?
Encontrado al Scrum Master - cortesía de Pixabay |
No hay comentarios:
Publicar un comentario