Métodos para mejorar el scrum/standup diario

Ha olvidado decir si su equipo está cara a cara o trabajando distribuido y comunicándose a través de Lync, etc., por lo que, por el bien de esta respuesta, supondré que está distribuido.

Etapa 1: Disciplina Básica

• Tome una línea dura con el propietario del producto y dígale que facilitará la sesión y se asegurará de que sea productiva. Compartir el deber es confuso para el equipo.
• Si el PO requiere una actualización, puede hablar con los desarrolladores individualmente después del stand-up, pero el rastreador de boletos (Jira, tablero físico) debería ser una guía suficiente.
• Tenga el tablero con los boletos visibles (en la pantalla o en persona) y vincule los boletos al desarrollador para que todos puedan verlo y comprometerse con sus compañeros de equipo.
• Mantenlo conversacional pero enfocado (por ejemplo)

Hola Dave, ¿cómo estuvo tu día ayer? ¿Hay algo sobre lo que pueda actualizar al equipo? ¿Trabajaste en Ticket 267, verdad? ¿Como le fue? Fantástico. ¿Continúas con eso hoy o te están empujando a algo más? ESTÁ BIEN. Buen material. Por último; ¿Hay algo que necesites de mí o del resto del equipo?

Aunque sea más largo, este tipo de interacción fluirá mucho más suavemente una vez que el equipo adquiera el hábito.

Etapa 2: Manteniéndolo accesible

Recuerde que su objetivo es crear un equipo autoorganizado, no presidir ceremonias.

• Pida a los desarrolladores que nombren al próximo desarrollador para que hable y que pregunten en qué trabajaron ayer.
• No hagas que la gente realmente se ponga de pie. La gente tiene problemas de espalda, lesiones, reemplazos de cadera y todo tipo. Uno de los miembros de mi equipo por 62 y odiaba estar de pie. Por supuesto, nos sentamos con un café todo el tiempo.
• Asegúrese de que los desarrolladores muestren un comportamiento de apoyo (Oh, Dave te ayudó en eso, ¿verdad, Karen? Impresionante. Gracias por informarnos. Gran trabajo en equipo, muchachos; gracias por hacer esa tarea de Gatekeeping tan rápido, etc.)
• No seas demasiado estricto con la caja de tiempo. Se impuso el límite de tiempo de 15 minutos para detener reuniones de 40 minutos. No fue diseñado para interrumpir agresivamente a las personas a los 16 minutos y disolverlas. Ya tiene a todos en la llamada, simplemente descarte aquellos que no son necesarios y continúe usando su juicio
• Como ScrumMaster; confirma a tu equipo lo que harás ese día también
• Asegúrese de abrir la reunión al final o al principio con un pequeño constructor de relaciones (Hola equipo, ¿todos disfrutan del buen clima? ¿Alguien hizo algo bueno el fin de semana? ¿No? OK, comencemos)
• Asegúrese de actualizar las comunicaciones del equipo durante el stand-up (Hola equipo, solo para que todos sepan, los muchachos de back-end podrían estar actualizando XYZ hoy, así que revisen sus bandejas de entrada o Slack para ver los avisos).
• Termine la reunión con el PO (Hola, PO, ¿algún mensaje importante de las partes interesadas o cambios para informar al equipo antes de la pausa?)

La parte clave siempre es recordar que sus codificadores administran la canalización del código; tú administras la canalización de relaciones. Olvídate de Scrum y el Stand-up y habla con tu equipo como si fueran seres humanos trabajando en algo valioso; porque eso es exactamente lo que son.

Otros consejos y sugerencias para formar un equipo

• Se preocupan genuinamente por sus diarios; pregunte cuántas reuniones tienen ese día. ¿Se sienten presionados o agobiados? Pregunte si necesita involucrarse para hacer retroceder algo.
• Cada pocos stand-ups incluye una anécdota personal sobre ti o un miembro del equipo para construir el vínculo. (Oye, ¿sabías que Alice acaba de completar su examen de AWS? Eso es increíble. Deberíamos retomarlo en la Revisión para informar a las partes interesadas, pero por ahora, bien hecho)
• Use el humor para hacer que las reuniones sean soportables. Veo tantos equipos siendo llevados a la muerte a una entrega. Agile se trata de flexibilidad, pero la construcción de relaciones de gestión de proyectos tradicional no ha desaparecido. Conéctese realmente con la gente durante sus sesiones
• Concéntrese en construir una identidad de equipo
• Si están cara a cara, hagan de la ceremonia una reunión genuina; dígale a la gente que deje de trabajar 5 minutos antes y vaya a buscar un trago/café, etc., listo para el standup (como un aparte, también divido mi planificación de Sprint con un descanso de 10 minutos siguiendo este patrón también)
• Asegúrese de que sus equipos tengan la seguridad psicológica para hablar (normalmente hago esto enfocándome en el miembro más tímido del equipo el 25% del tiempo usando la oración "No me importa lo que diga, de verdad, solo díganos lo que piensa Sé audaz". Una vez que han alcanzado un nivel de confianza, cambio el enfoque a otro miembro del equipo durante algunos períodos de tiempo. Esto ha llevado a que los programas me den a los desarrolladores con poca confianza para sacarlos de su caparazón

Dado que ha etiquetado la pregunta con scrum y scrum-master y daily-scrum , supondré que está siguiendo Scrum tal como se define en la Guía de Scrum .

¿Asistirá el Scrum Master al Daily Scrum? Aunque no es un participante obligatorio, uno de los servicios del Scrum Master es "facilitar los eventos de Scrum según se solicite o sea necesario". Esperaría que un buen Scrum Master observe ocasionalmente los Daily Scrums y, cuando se rompa alguna de las reglas del evento, hable y vuelva a encarrilar el evento. También esperaría que Scrum Master hiciera un seguimiento con el Equipo de desarrollo durante las Retrospectivas de Sprint para ayudar a generar ideas.

La Guía de Scrum también dice que una de las responsabilidades del Scrum Master es asegurarse de que cualquier persona ajena al Equipo de desarrollo que asista al Daily Scrum no interrumpa la reunión. Si el Scrum Master asiste al Daily Scrum como observador o realiza un seguimiento con el Equipo de desarrollo sobre la efectividad del Daily Scrum en las Retrospectivas de Sprint, el Scrum Master debe enterarse de cualquier interrupción. ¿Tiene el equipo un timebox de 15 minutos para llevar a cabo el Daily Scrum? ¿El equipo considera perturbadoras las preguntas del propietario del producto? Si el equipo está terminando su Daily Scrum en un período de tiempo de 15 minutos, no hay nada de malo en dedicar tiempo adicional después del evento. De hecho, la Guía Scrum dice que es común que los miembros del equipo (refiriéndose a todo el Equipo Scrum, no solo al Equipo de Desarrollo) "

También es importante darse cuenta de que Daily Scrum no necesita tener el formato de "tres preguntas". La Guía de Scrum incluso dice que "algunos equipos de desarrollo usarán preguntas, algunos se basarán más en la discusión". Sin embargo, independientemente del formato, el propósito es, en intervalos cortos, inspeccionar cómo el progreso compite para lograr los Objetivos del Sprint, ajustar para aumentar la probabilidad de que se alcancen los Objetivos del Sprint y plantear inquietudes al Propietario del Producto si el Sprint Los objetivos están en peligro de trabajar para generar cambios para garantizar que un Incremento potencialmente liberable de valor agregado esté disponible al final del Sprint. El Scrum Master puede asesorar al Equipo de desarrollo sobre diferentes métodos, pero el Equipo de desarrollo debe, en última instancia, impulsar la ejecución del Daily Scrum.

El único punto que no es abordado por la facilitación del Scrum Master del evento y el entrenamiento de las reglas de Scrum es que los miembros del Equipo de Desarrollo no saben qué van a hacer a continuación. Las prioridades del trabajo deben estar impulsadas por el Objetivo del Sprint y los atributos de valor y orden asignados a los Elementos del Backlog del Producto traídos al Sprint. El Sprint Backlog contiene elementos de Product Backlog descompuestos, pero todo el trabajo descompuesto debe estar vinculado a uno o más elementos de Product Backlog (con un valor y un orden) y quizás tener una dependencia técnica. Debería ser trivial para el equipo determinar, una vez que terminan un elemento del Sprint Backlog, cuál debería ser el siguiente trabajo.

El comportamiento negativo generalmente tiene varias razones. Si bien como maestro de scrum su trabajo es moderar las ceremonias de scrum, su objetivo debe ser llevar al equipo a una posición en la que esté esencialmente obsoleto.

1. Comprender

Determinar la causa de estos comportamientos. Puede ser pereza/conveniencia (¿por qué programar otra reunión cuando puedes discutir tu problema ahora mismo?). Podría ser una necesidad que de otro modo no se satisface (visibilidad de progreso insatisfactoria, dificultad real o percibida de discutir problemas con otros). Podría ser un hábito (PO solía ser un PM y preguntar por el estado es lo que solía hacer. O el equipo solía tener reuniones monolíticas periódicas donde todo se discutía en conjunto).

2. Soporte

Vea lo que puede hacer para ayudar con los problemas que descubrió. Tal vez alguien necesite sentirse más cómodo acercándose a otros miembros del equipo para obtener ayuda/retroalimentación. Tal vez mover el standup a un momento posterior permitiría que todos se orientaran por la mañana. etc.

3. Educar

Pídeles educadamente a tus compañeros de equipo que mantengan sus contribuciones cortas y luego discutan cualquier cosa más allá de lo esencial con quien corresponda. Señale al PO que puede ver el progreso en la pizarra después de la reunión. Intente que el equipo resuelva los problemas por sí mismo.

4. Guía

Si todo esto falla, el scrum master debe intervenir y dirigir las ceremonias más de cerca hasta que el nuevo patrón quede arraigado. Corte las tangentes llevándolos más de cerca a través de las tres preguntas. Interrumpa el PO si interfiere o incluso anule la invitación si el comportamiento persiste. Establezca pequeñas multas para los miembros del equipo que lleguen sin preparación. Mi entrenador de scrum me dijo que una vez tuvo un equipo con un problema grave con el teléfono móvil. Así que tomó un poco de cinta de pintores y dibujó espacios de estacionamiento en una mesa. Todo el mundo podía colocar sus teléfonos en su libre. Pero cualquier persona sorprendida usando el teléfono o haciendo sonar su teléfono tenía que poner 5 dólares en la jarra de café.

Abordaré sus inquietudes en orden. Veo varios posibles problemas subyacentes aquí. Como siempre, discuta con el Equipo en la Retrospectiva para determinar las causas subyacentes y acordar soluciones.

Tienden a salirse del tema, en lugar de centrarse en lo que hice, lo que voy a hacer y los impedimentos.

Como han dicho otros, el Daily Scrum no tiene que tener el formato de tres preguntas. El propósito de la reunión es servir al Equipo. Si el equipo no siente que necesita ese formato, entonces no se moleste con él.

Sin embargo, es un problema si la reunión se desvía del tema, siempre que las discusiones 'fuera del tema' no sean útiles para todo el Equipo . Una ocurrencia común que he encontrado es tener de 2 a 4 desarrolladores involucrados en un tema secundario mientras todos los demás se sientan desinteresados, pero sin querer interrumpir. Un enfoque que me gusta es que alguien levante la mano cuando sienta que un tema que se está discutiendo no es relevante para él. Una vez que llegue a 2 manos arriba (o 1, o 3, etc., dependiendo de su Equipo), la discusión se detiene y se reanuda después de la reunión solo entre los involucrados.

El propietario del producto habla y les pide "actualizaciones" durante o inmediatamente después del Scrum diario.

Este no es el propósito del Daily Scrum. El Scrum Master (SM) necesita educar al Product Owner (PO) sobre esto. Sin embargo, esto podría tener varias causas subyacentes.

1. El PO simplemente no es consciente de que esto es perjudicial. Solución: educar al PO.
2. La información que necesita el PO no está disponible en un radiador de información, como el Sprint Board. Solución: asegúrese de tener un radiador de información, asegúrese de que la OP tenga acceso a él y asegúrese de que contenga la información que necesita la OP.
3. El PO no sabe que la información que necesita está en el radiador de información. Solución: educar al PO.
4. Las necesidades de información de la OP son tan complejas/únicas que no pueden pasar por el radiador de información. Solución: encuentre una forma menos perjudicial (para el equipo) de entregar esa información a la orden de compra. ¿Quizás el PO habla en privado solo con aquellos de quienes necesita información?

A menudo no saben lo que van a hacer... es decir, no pueden responder a la pregunta durante el Daily Scrum, por lo que dicen que van a decidir qué hacer después del Daily Scrum.

El hecho de que el Equipo no sepa lo que va a hacer antes de la reunión pero lo sepa inmediatamente después me indica varios posibles problemas.

1. El equipo no tiene suficiente tiempo antes del Daily Scrum para orientarse. Solución: mueva la reunión más tarde en el día.
2. El equipo simplemente no tiene ganas de hacerlo. Solución: Informar al Equipo los riesgos de que el resto del Equipo no sepa lo que está haciendo cada miembro del Equipo. Nota: ¡primero asegúrese de que haya riesgos para su situación! Si no los hay, entonces el problema es:
3. La pregunta en sí no es útil para el Equipo. Solución: ¡deja de preguntarlo!
4. El Equipo tiene miedo. No se sienten lo suficientemente seguros para responder a la pregunta. Este es el problema más peligroso y el más difícil de lograr que el Equipo lo admita. Tal vez tengan miedo de que, si comienzan a trabajar en la tarea A, y surge algo con la tarea A, serán penalizados de alguna manera. Es mejor ocultar el hecho de que están trabajando en la tarea A en primer lugar... Solución: averigüe por qué el Equipo se siente inseguro y arréglelo. Esta es una empresa significativa en sí misma, pero de importancia crucial.

Estas son solo las posibles causas en las que pensé. Es muy posible que las causas en su situación sean diferentes. Por eso es importante plantear sus preocupaciones en la Retrospectiva. ¡Para eso está!