Involucrar al diseñador gráfico en las reuniones diarias de Scrum

Basado en su declaración "se siente más relacionado con el equipo técnico, ya que también crea cosas y trabaja con nosotros en la producción de las funciones de nuestra aplicación en línea", lo animo totalmente a unirse al stand-up diario.

La pregunta más importante es si se va a unir al equipo o no... podría ser una gran ventaja para su diseñador ser un miembro de pleno derecho del equipo, compartir la responsabilidad del compromiso del equipo, etc. Mi recomendación general es "sí". , debería", pero hay razones legítimas por las que no tendría sentido. Tenga en cuenta que hay MUCHAS excusas por las que no funcionaría tan bien y, como recomienda @Pawel, debe experimentar con él durante 2 o 3 sprints y ver si es mejor para la comunicación o si daña la comunicación con el resto. de la compañia.

En primer lugar, todos son bienvenidos a las reuniones de Scrum. Incluso puede tener un CEO en las reuniones también. La única regla es que mientras alguien no esté directamente involucrado en un proyecto, no hable, solo escuche.

Sin embargo, por lo que escribe, su diseñador gráfico trabaja para sus proyectos, por lo que podría adaptarse perfectamente a las reuniones diarias como miembro habitual. Por supuesto, significa que en algún momento tendría poco que agregar, ya que estaría trabajando en algunas cosas de marketing, pero esa también es información importante para el equipo del proyecto. Significa "Ahora estoy haciendo otras cosas, así que deberías tenerlo en cuenta en tus planes, ya que no podré trabajar para el equipo en este momento".

También hay otra cosa: si el diseñador gráfico quiere unirse, simplemente llévelo a las reuniones y trátelo como un experimento. Si funciona para él y para el equipo, sigue así. Si no piensa si quieres cambiarlo u omitirlo por completo.

Siempre es una cuestión de tiempo invertido por un individuo para asistir a la reunión y el valor que él y el resto del equipo obtienen. Personalmente, diría que hay muchas posibilidades de que el resultado neto en este caso sea positivo, así que definitivamente lo intentaría.

El único desafío que veo al incluir a otras personas en las reuniones de scrum es la dedicación. En este caso, asumo que los desarrolladores que forman parte de este equipo Scrum son todos recursos dedicados a su proyecto. Esto significa que dedican más del 95 % de su tiempo y energía al avance de su proyecto.

La pregunta que tengo es si su diseñador es o no un miembro de tiempo completo de su proyecto. ¿Este diseñador tiene otras responsabilidades conflictivas? Si es así, agregar a esta persona al equipo puede no ser muy útil, ya que puede estar sujeto a compartir el tiempo de esta persona con otros departamentos. En casos como este, el diseño puede pasar a un segundo plano para su proyecto.

Por lo tanto, las preguntas que le gustaría responder primero son:

• ¿Cómo manejará las situaciones en las que el diseñador se pierda la reunión?
• ¿Cómo manejará los escenarios en los que un diseñador no puede terminar el trabajo a tiempo, no por el alcance, sino porque el gerente de marketing quiere que esta persona trabaje en otra cosa esta semana?
• ¿Cómo se verá afectada la dinámica del equipo por alguien cuyas contribuciones y dedicación al proyecto parecen fluctuar de un período a otro?

Si el diseñador está realmente dedicado a trabajar en su proyecto, le sugiero encarecidamente que incluya a esta persona en las reuniones, ya que ninguno de estos desafíos se aplicará. Si no, solo prepárate para manejar esas situaciones.

Esta es una gran pregunta sobre cómo adaptar Scrum cuando tiene dependencias externas en otros equipos. En los proyectos de grandes empresas (y en los pequeños), el mejor enfoque que he visto es incluir un representante del equipo si depende de un equipo externo , como el trabajo del equipo de diseño gráfico.

Esta puede ser la persona que hace el trabajo por sí misma, pero por lo general es más útil que el equipo lidere, porque brinda información más amplia (por ejemplo, el miembro del equipo dedica el x% del tiempo a su trabajo debido a A, B, C, otros prioridades).

Creo que con demasiada frecuencia el diseño gráfico y los elementos de la interfaz de usuario de los proyectos de software se consideran una tarea ajena al desarrollador. Descubrí que cambiar el nombre de los miembros del equipo (que diseñan y, a menudo, generan html o CSS como resultado) como desarrolladores front-end ayuda a darles un rol definido en el desarrollo de software.

Si tienes desarrolladores front-end que están entusiasmados, creo que definitivamente deberías invitarlos a los stand-ups diarios; si deberían estar allí, se volverá rápidamente obvio.

Asumiendo que "él es entusiasta" (como dijiste anteriormente), la verdadera pregunta aquí es cuáles son las desventajas de involucrarlo en reuniones regulares. Veo lo siguiente:

• riesgo de hacinamiento (especialmente si es un hablador activo)
• brecha de seguridad (si tiene diferentes "niveles de autorización")
• pérdida de enfoque (los miembros del equipo pueden comenzar a pensar en el diseño gráfico más de lo que deberían)

Estoy a favor de esto; Una queja común de los "equipos de desarrollo" es que cuando llega el momento del lanzamiento, se encuentran con la resistencia del control de calidad, los administradores de bases de datos, los administradores de red, el personal de soporte y cualquier otra persona afectada por el lanzamiento. En mi humilde opinión, todas estas personas deberían estar representadas en el 'equipo de desarrollo de productos', no solo los programadores.

Llevar a las personas a las reuniones diarias de scrum ahorra la cantidad de tiempo perdido debido a los rediseños necesarios para abordar las preocupaciones de otros equipos y los retrasos en la implementación cuando otros equipos necesitan ponerse al día; lamentablemente, se puede ver su "diligencia debida". como obstrucción.

Llevando esto al contexto del diseñador gráfico, los diseños gráficos están influenciados por las ideas que representan (como lo es idealmente el arte de marketing), por lo que el aviso diario de lo que está cambiando en la lógica les ayuda a seguir el ritmo de los cambios y evitar retrasos. mas tarde. De manera similar, los otros desarrolladores de productos se beneficiarán de la información sobre lo que funciona desde el punto de vista de las ilustraciones/marketing, ahorrando en rediseños.