Cómo dar un estado de informe diario efectivo al Cliente en la reunión diaria de scrum que crea una buena impresión

Una reunión de scrum standup no es lo mismo que un informe de estado. Se supone que es un breve intercambio de información sobre el estado de los miembros del equipo, centrándose en los problemas que un miembro del equipo no puede resolver solo.

Si todo salió bien ayer, tu contribución podría ser

Ayer estuve trabajando en la tarea T1 de la función A. Una vez finalizada esa tarea, trabajaré en la tarea t2 hoy. No hubo problemas.

Eso es todo. 15-30 segundos. Lo que hiciste ayer, lo que harás hoy, cualquier impedimento. Contarle a la gente más es simplemente perder el tiempo en un standup diario.

Si tienes un problema que no puedes resolver por ti mismo, menciónalo brevemente:

Ayer estaba trabajando en la tarea T1 de la función A. Resultó que necesitamos acceso a la base de datos de nómina para esta función y no tengo acceso. Para continuar hoy, necesitaré acceso o la ayuda de alguien que tenga acceso.

La respuesta natural sería no discutir este problema en la reunión, sino que alguien que dirija la reunión probablemente diría algo como

Ok, anotado, resolvamos este problema justo después de la reunión. El siguiente por favor.

El objetivo de la reunión diaria es tener una breve actualización de estado. No es el lugar para largas explicaciones o volver a contar el trabajo diario de las personas. Se breve. se preciso. No pierda el tiempo de la gente con los detalles.

No estás haciendo scrum. Estás haciendo algo raro que superficialmente se parece a un scrum.

El cliente no debe estar en una reunión diaria de pie. El cliente no debe involucrarse con usted en absoluto al cien por cien . Los objetivos de un scrum no los logran los individuos, los logra (o no) todo el equipo. Y el cliente no debe estar involucrado con el equipo, el cliente debe hablar con el gerente de producto.

Después de que finaliza un sprint, es cuando todo el equipo se presenta al gerente de producto y al cliente. Ahí es cuando el cliente habla con el gerente de producto sobre lo que quiere y cuáles son las prioridades. Pero lo que está pasando en tu lugar, eso es absolutamente ridículo y totalmente contraproducente.

Estoy completamente de acuerdo con las otras respuestas que dicen que es enormemente contraproducente para el cliente estar en un standup diario. Se plantearán todo tipo de problemas que no afectan al cliente, pero a los que podrían tratar de responder, y la entrada del cliente con una frecuencia diaria distraerá y molestará al equipo. Me parece que el cliente no confía en su proceso y quiere tener el control diario de lo que hace el equipo. Eso es casi seguro que empeorará las cosas. Sea cual sea el proceso que estés haciendo, no es Scrum.

Mis sugerencias sobre cómo cambiar esto son las siguientes:

1. Trate de convencer al cliente para que acepte una reunión semanal o quincenal (una vez por sprint) en la que alguien se sentará con él y le dará una cuenta detallada de dónde está el proyecto y qué impactos en la línea de tiempo podría haber. Explique al cliente por qué su aporte diario es contraproducente. Este es un enfoque reconocido y efectivo, pero sospecho que su cliente no lo tomará. Están demasiado concentrados en tener el control.
2. Si no lo hacen, haga todo lo posible para convencer al cliente de que se siente con alguien una vez al día, después de la reunión diaria, para revisar el progreso y permitirle brindar su opinión. Luego, alguien reenvía esa entrada cuando sea apropiado para el equipo. Probablemente no será apropiado tan a menudo. Este es probablemente el mejor resultado que puede esperar.
3. Trate de hacer cumplir la regla de que nadie fuera del equipo debe hablar. El cliente puede proporcionar cualquier comentario a una sola persona después de que la reunión se haya dispersado.
4. Si nada de eso es aceptable, podría considerar tener dos reuniones de scrum diarias. En uno solo se eleva la información apta para la comunicación al cliente. No se debe discutir ningún problema. Sólo "estoy trabajando en esto". El segundo ocurre sin el cliente y permite que el equipo discuta sus problemas reales. Tenga en cuenta que no estoy mintiendo al cliente, simplemente no le dé ninguna información que no necesite. Francamente, esta es una solución terrible y sus desarrolladores la odiarán, pero es posible que la odien menos que tener al cliente interfiriendo a diario.
5. Si todo lo demás falla, recuerde que el cliente siempre tiene la razón y paga por lo que obtiene. Si quieren que el desarrollo sea más lento y complicado de lo que tiene que ser, está en su derecho. Sea muy amable con los desarrolladores y prometa trasladarlos a otro cliente lo antes posible.

¿Hay alguna forma de obtener resultados frente al cliente más rápidamente? Si te reúnes con el cliente todos los días, ¿por qué no mostrarle los cambios del día anterior?

Los grupos externos ven su trabajo como magia negra. Intente involucrarlos más y educarlos (a un nivel razonable) sobre el valioso trabajo que realiza. Sea específico sobre cualquier cuello de botella y barricada.

También puede ser posible que su cliente esté buscando cosas específicas para hacer. ¿Es posible volver a priorizar su trabajo programado y obtener primero algunas de las funciones que buscan?