Aunque se habla mucho sobre el trabajo interdisciplinario, muchas veces no se comprende a profundidad. Por encima muchos saben que se necesita la experiencia de personas con diferentes disciplinas que necesitan trabajar juntas para lograr productos y servicios.

Y ya desde ahí, equivocadamente muchos creen que para que esas diferentes disciplinas logren lo que se busca de una manera productiva basta con que cada quién haga la parte que le toca bien y a tiempo, respetando la función de cada quien. Pero esta definición no apoya la dinámica de sinergia que debe de haber para poder optimizar al máximo todos los recursos y aprovechar todo el talento, ya que se define como una relación de independencia donde cada quien crea la pieza que le toca y la une con la de los demás.

En este blog te explicaré por qué lo anterior no funciona y lo enfocaré al trabajo multidisciplinario entre Product Owners, Scrum Masters y Scrum Developers con prácticas y un enfoque que sí funciona.

Las barreras de la sinergia

Pues resulta que nos quedamos muy cortos con la creencia de “que cada quién haga bien lo que le toca” porque, el trabajo multidisciplinario en entornos de incertidumbre no se puede hacer así pretendiendo unir las piezas al final, como si cada quién simplemente se encargara de una pieza del rompecabezas que encajará con facilidad al final y es por ello que al querer juntar esas piezas no funciona, porque lo que hacemos no son rompecabezas, entonces, parte del trabajo no está listo a tiempo, algo de lo que sí se logró avanzar se tiene que volver a hacer porque se interpretó mal y del resto ni siquiera se pudo iniciar porque el tiempo estimado no alcanzó.

Así que eso de “tú haces tu parte y yo la mía” no funciona, la sinergia viene de entender que “tu trabajo genera valor a mi trabajo y mi trabajo genera valor al tuyo”. La primera creencia no necesariamente es colaborativa sino de compromiso individual, los entornos de incertidumbre necesitan la segunda creencia, porque es un ir y venir, una colaboración constante.

Si el Product Owner se limita a llenar el Backlog y lo haga bien, no va a generar valor hacia el equipo sino se asegura de que ese Backlog esté claro para el equipo, sus elementos lo más independizados posibles y priorizado. Ahora, esto no es de un momento, no sólo se hace al inicio, se hace constantemente y la sinergia se manifiesta cuando:

Las dudas del equipo alimentan el trabajo del Product Owner
Product Owner realiza prácticas de análisis y planeación colaborativa con el equipo y dentro de esas prácticas su fin principal es el entendimiento mutuo y la claridad de lo que se persigue.
La priorización se basa no solo en valor de negocio sino en complejidad técnica (o de ejecución).
Product Owner hace negociaciones con involucrados relevantes basado en la capacidad del equipo.
Scrum Master no tiene un rol intermediario entre Product Owner y Developers, sino un rol facilitador para que fluya la comunicación directa (funcionando como moderador).
Scrum Master promueve eventos y prácticas para que la visión de los developers se refleje en la planeación y priorización.
Scrum Master fomenta conversaciones constantes con respecto a restricciones, complejidades y suposiciones desde la perspectiva de negocio del Product Owner y desde la perspectiva de los Developers.

Cuando se logran los puntos anteriores, el potencial que tiene cada uno de los miembros del equipo se multiplica porque cada punto refleja interacciones horizontales, no jerárquicas. Esto no tiene que ver con organigramas ni con “quién le reporta a quién”, el organigrama se puede quedar igual, lo que cambia es la manera de interactuar.

Delegar vs. Empoderar

No es que el Product Owner delegue el trabajo al Scrum Master y a los Developers, o que el Scrum Master le delegue trabajo al Product Owner y a los Developers, es darle el poder al equipo para realizar lo que se necesita, ese poder se da con contexto y con claridad porque aparte, eso es vital para que surja el compromiso.

Es difícil comprometerse con algo sobre lo que no haya claridad ni participación y no es un problema de actitud, no lo veo así, lo veo más como un factor humano, algo natural y cuando lo vemos de esa manera entonces podemos fomentar el compromiso a través de involucrar más al equipo.

Entender que no es que se le asigne el trabajo a los Developers sino que ellos tomen el trabajo y al hacerlo se interesen por conocer el contexto y se atrevan a externar dudas.

Lo que menos empodera a los Developers es el pensamiento mágico de “hay que empezar ya y en el camino vamos resolviendo”. Si bien la agilidad permite incluir el descubrimiento contínuo ante la incertidumbre, ésto también tiene un órden y ese es el objetivo principal del evento Sprint Planning para que los equipos comiencen coordinados y con claridad sobre lo que tienen que empezar a hacer aunque surjan algunas dudas posteriormente, lo cuál no es lo mismo que lanzarse al abismo sin claridad porque las dudas pueden ser tan avasalladoras que provocarán retrasos y retrabajos o la ausencia de dudas por saturación de suposiciones pueden provocar lo mismo.

Delegar la responsabilidad al Scrum Master para que mantenga la productividad en el equipo y fomente la sinergia con el Product Owner no es lo mismo que empoderar para hacerlo, al igual que darle el título de Product Owner a alguien, no es lo mismo de que esté empoderado para ejercer lo que necesita ejercer.

El empoderamiento viene más con conocimiento y confianza de decidir que con sólo el nombre de la responsabilidad. El empoderamiento no es un puesto, es una consecuencia de saber, confiar en lo que se sabe y que otros correspondan a esa confianza apoyando las decisiones con su compromiso.

Conclusiones

Un equipo multidisciplinario es unir experiencia, habilidades y talentos de diferentes tipos, eso implica también gestionar diferentes perspectivas y por ende, los diferentes tipos de conflictos que surgen de esas diferencias para poder converger.

Hacer los eventos que Scrum pide (Sprint Planning, Daily meeting, Sprint Review y Retrospective) no es garantía de que Scrum nos pueda ayudar como marco de trabajo, no es el evento, es lo que se hace dentro del evento.

Por Vanessa Amaya

Vanessa es Ingeniera en Sistemas Computacionales por la UAG. Cuenta con 18 años de experiencia en proyectos de desarrollo de software como consultora para la implementación de prácticas de mejora en equipos, Business Analyst, Instructora, etc. Ha participado en proyectos de implementación y capacitación de marcos ágiles desde el 2012. Es Docente del cuerpo Académico del Diplomado de Ingeniería de Software Ágil en la UNAM.

Más información

Cursos