¿Cómo mantener informados a los miembros a tiempo parcial de un equipo de desarrollo de software ágil?

TL;RD

Busco una forma recomendada de actualizar a los miembros del equipo en sus días libres para que estén más o menos informados de los cambios en el producto, el proceso o la empresa.

Historia completa

Fondo:

Soy parte de un equipo Scrum dentro de una empresa que desarrolla soluciones de software. Nuestro equipo está formado por empleados a tiempo parcial y a tiempo completo. Ayudo al propietario del producto (que también es nuestro CTO y está muy ocupado) y al scrum master (que en realidad es un entrenador ágil que visita dos veces por semana). Escribo pruebas de aceptación, documento cosas y se espera que me convierta en un analista de negocios que también cubra la mayoría de las responsabilidades del scrum master. Nuestra empresa no es muy grande (menos de 20 personas en el departamento técnico) pero algunas partes de nuestros productos SÍ se vuelven complejas.

Desde que me uní a la empresa, estoy buscando formas de mejorar el desempeño de nuestro departamento de manera proactiva al proponer cambios en nuestros procesos de desarrollo de software, herramientas, reuniones, etc.

El Problema: Soy estudiante de maestría y no puedo asistir al trabajo dos días a la semana. También hay algunos estudiantes de licenciatura que están capacitados y la empresa los necesita. Tenemos 3 desarrolladores profesionales que en realidad trabajan en otros lugares pero participan en los proyectos después de sus horas de trabajo.

Todos los días ocurren cambios y se toman nuevas decisiones por parte del CTO y de quienes están presentes en la empresa. Pero los que estén ausentes, como yo mismo en esos dos días, no serán informados hasta el día siguiente en que se presenten en la empresa.

Los gerentes de la empresa y yo SÍ sabemos que usar miembros del equipo a tiempo parcial no es eficiente y puede dañar la agilidad del equipo y hemos aceptado los gastos generales. Pero estamos buscando formas de mejorar esto tanto como sea posible.

Nuestro producto tiene una arquitectura de microservicios y cada BC tiene su propio subequipo y su propio proyecto. Por lo tanto, seguir el progreso se ha convertido en un dolor de cabeza (al menos para mí, que me uní hace apenas un mes y no estoy al tanto de toda la información, preocupaciones y decisiones desde el principio). Cada producto tiene su propio tablero y backlog.

Además, nuestras reuniones diarias de pie no parecen ser muy efectivas.

¿Qué sugieres? Yo mismo pensé en un sistema de registro y reuniones asíncronas y un trabajo por lotes programado que envía por correo electrónico todos los registros y la respuesta de los miembros del equipo a las preguntas de scrum diarias asíncronas al equipo.

¿Deberíamos adoptar otros marcos/metodologías?

Respuestas (2)

Una posibilidad sería usar una herramienta como Slack.

Crear un canal de noticias del equipo. Cualquiera que escuche noticias relevantes o anote comentarios/eventos significativos durante el día los agregará como un mensaje en el canal.

Las personas que regresan al trabajo después de haber estado fuera pueden desplazarse hacia atrás a través de las noticias.

Estoy de acuerdo. No usamos Slack por un montón de razones y últimamente hemos adoptado Rocket Chat, alojándolo en las instalaciones. ¿Tiene alguna recomendación sobre este mecanismo para compartir noticias/comentarios/eventos? ¿Cómo lo integramos en nuestro proceso actual y alentamos a nuestro equipo a involucrarse en él?
Creo que su equipo está en mejores condiciones que yo para decidir sobre el mecanismo de intercambio. Tendrán una comprensión mucho más profunda de los detalles del problema que yo. Mi recomendación general en situaciones como esta es hablar sobre ello, acordar un enfoque y luego intentarlo durante algunas semanas. Luego revíselo y decida si algo más podría funcionar mejor.
Hablando contigo, descubrí que existen aún más problemas en nuestro equipo, que son en su mayoría comunicativos e interpersonales. Casi no tenemos retros.
Entreno que la retrospectiva es la reunión más importante de Scrum. No te preocupes por tener problemas, todo el mundo los tiene. ¡El secreto del éxito es aprender de ellos!

He experimentado problemas similares con literalmente todos los equipos con los que he trabajado. He aprendido que el problema no es la falta de una gran herramienta para resolverlo.

Las reuniones diarias de pie son bastante comunes y útiles si se ejecutan correctamente. El problema más común que he visto en los diarios es que todo el mundo se apresura a expresarse y asegurarse de que ha cumplido con su deber ya nadie le importan las otras cosas que dicen sus compañeros; Excepto el entrenador que tiene que saber lo que está pasando en el equipo.

Entonces, personalmente, creo que la solución a su problema es un software de personas actualizado y no un software nuevo: D

El mejor resultado se logra cuando cada individuo comprende y siente la necesidad de saber qué está haciendo su colega y cómo podría ayudarlo. Para propagar este sentimiento en el equipo, todos deben tener responsabilidades como el gerente, lo que en primer lugar lo llevó a sentir la necesidad de saber en qué están trabajando todos.

Y por último, para responder a su pregunta, puede grabar las sesiones diarias y compartirlas con el equipo a través de Slack, correo electrónico o cualquier otra herramienta de uso común en el equipo. Está funcionando para nosotros.

Tienes toda la razón sobre el peopleware. Otro problema es que tenemos un solo grupo de personas que asisten a la sesión diaria de scrum que no están enfocadas en un solo producto. Supongo que en realidad deberíamos tener equipos separados con productos separados y sesiones diarias de scrum, pero debido a algunas decisiones administrativas, esto no está sucediendo.
Tener procesos como diarios, reuniones retrospectivas y delegaciones de responsabilidades ayuda al equipo a decidir separar el equipo por su cuenta.