Parece fácil entender el trabajo en equipo, pero no siempre es así. Hay motivos que facilitan que pensemos en «yo» antes que «equipo» ¿Cómo lo podemos solventar?
«SOMOS MUY YO ANTES QUE EQUIPO»; Esta es la frase que surgió en una retrospectiva y que nos hizo trabajar para evitar que se volviera a repetir.
Como ya he comentado en otros post sobre trabajo en equipo, muchas veces cuando preguntas al equipo si lo son, te dicen que sí, porque son un grupo de personas que trabajan juntas en el mismo producto, están ahí cuando se necesitan…
Un día en una retrospectiva alguien se atrevió a comentar que éramos muy «yo» antes que «equipo», y aquí empezó un gran cambio.
Causas
¿Qué causas pueden hacer que un equipo se sienta así? Desde mi experiencia, puede suceder en casos como los que comento a continuación.
Equipos en los que hay diferentes roles técnicos
Si no se crean historias en las que puedan trabajar todos los roles técnicos (desde integraciones hasta experiencia de usuario), se pueden crear mini-equipos para tratar mini-temas dentro de un sprint, y que se haga muy complicado que vayamos todos a una para conseguir nuestro sprint goal. Cuando uno de los roles termina su trabajo, se van al backlog a buscar más tareas antes de preguntar al resto del equipo si se puede ayudar en algo, en lo que sea, para echar una mano. Básicamente puede pasar que un rol no sepa lo que está haciendo otro.
Equipos en los que se trabaja en diferentes épicas a la vez
Es posible que en alguna ocasión os hayáis encontrado bajo la deducción de que si trabajamos con diferentes cosas a la vez, podremos entregar más cosas a la vez. Una de las consecuencias negativas de pensar así es que el equipo se sentirá divido. Seguramente el daily será una suma de monólogos que nadie escucha. En este caso el problema será que un miembro del equipo no sabrá lo que hace otro.
Personas nuevas en el equipo
Hay riesgo de que cuando una persona entre en el equipo, si no conoce muy bien el método confunda al PO con la persona a quién tiene que «pedir trabajo» si acaba «sus» tareas. Incluso este sentimiento se puede agrabar en trabajo en remoto si no cuidamos mucho la comunicación con los que llegan al equipo.
En este caso es trabajo de todo el equipo el que esto no suceda así, predicando con el ejemplo día a día y ayudando a las personas nuevas a integrarse en nuestra forma de trabajar.
Actividad de equipo
Para que fueramos un poco más conscientes de nuestro problema, me ayudé de una actividad que sirve también para mejorar la comunicación; el dibujo descompuesto. En este caso podemos usarla con otro propósito: ¿cómo de atentos estamos a lo que dicen nuestros compañeros?…o ¿sólo nos oímos a nosotros mismos?.
NOTA: Para realizar el ejercicio de forma remota, lo que hago es que se lo vayan explicando en cadena sin que lo oiga el siguiente. Se van llamando online… No se me ha ocurrido una forma mejor 🙂
Tras la actividad, pido que por un instante cada uno se concentre en el momento en el que el/la compañer@ le estaba dibujando en la espalda o explicando el trazo (no el dibujo) vía llamada, y que recuerden cómo estaban de atentos. ¿Estamos todos concentrados en ese momento? Entonces vamos a reflexionar sobre los siguientes puntos (podemos dividirnos en dos grupos y que se discutan los puntos en cada grupo):
- Cuando este/a mismo compañer@ habla en los dailys ¿le prestamos la misma atención?
- Si termino “mis tareas”, ¿siento que ya he cumplido en el sprint?
- Cuando termino “mi trabajo”, antes de pedir al/ a la Product Ownwer algo más… ¿pienso en la persona que me ha dibujado en la espalda?
- ¿Y en alguna otra persona que no sea ésta? Si es que sí ¿en quién?
- ¿Qué crees que podéis mejorar como equipo para que cambie esta sensación de ser más “yo” que un equipo?
Yo pido sacar una acción por persona o grupo (en el caso que hayamos hecho grupos). Luego compartimos las acciones y decidimos por cuál/les empezar a probar.
Acciones
Éstas son algunas de las acciones que han salido durante las veces que lo he hecho:
| Actualizar la pizarra | Ya sea de forma física o virtual, si los componentes del equipo no mantienen la pizarra actualizada, cuesta más que sepamos cómo podemos ayudar a un compañero que puede estar bloqueado, si además no ponemos la atención suficiente durante el daily. |
| Preguntar al equipo qué coger antes que al PO | Cuando se termine una tarea, preguntar al resto del equipo si alguien necesita ayuda en lo que esté haciendo, o con qué tarea es mejor seguir de nuestro Sprint Backlog. Recordemos que el Sprint Backlog pertenece al equipo de desarrollo. Si trabajamos en Kanban seguramente tendremos las primeras tareas del Product Backlog ya priorizadas. |
| Pedir ayuda / levantar la mano | Está bien que nos sintamos orgullosos de solucionar un problema solos, pero todo tiene un límite y que no se nos olvide que trabajamos como equipo. Si alguien se encalla, que levante la mano. |
| En el daily, hablar por historia, no por persona | Mientras hagamos el daily, repasemos el estado de las historias por la prioridad que hayamos marcado. De esta forma pasamos de hablar uno por uno a hablar de la historia en sí, sea quien sea. |
| Reducir las épicas en curso | A menos épicas hechas a la vez, más cosas en común que tendrán los miembros del equipo de desarrollo. |
¿Os ha servido el artículo? ¡Espero que sí! Os invito a compartir vuestra experiencia en los comentarios o de forma privada a través de la página de contacto aquí.