¿Qué es más difícil ser autoorganizado o multifuncional?

Dos de los conceptos más relevantes que introduce Scrum son la autoorganización y la multifuncionalidad o multidisciplinaridad. Ambos nacieron del famoso artículo “The new new Development Game” de la Harvard Business Review de donde se plantó la semilla de Scrum.

La autoorganización tiene varias características. Por un lado eliminamos etiquetas del equipo, fomentando de esa manera que el trabajo no tienda a repartirse de manera autómatica. Así forzamos que haya conversaciones sobre cómo nos vamos a organizar. La autoorganización es una manera genérica de decir que los equipos son los responsables de buscar la manera de acometer el trabajo. Cierto es, que ese trabajo viene tras un pacto, un acuerdo en una planificación sobre lo que prevemos que haremos en el Sprint.

De hecho, si algo he aprendido gracias a Scrum.org y Management 3.0 es que hay niveles de autoorganización. Estos niveles dependen del grado de libertad que se les quiera dar a los equipos. Desde no dejarles hacer nada y el equipo simplemente recibe órdenes hasta que el equipo decida sobre al propósito de la compañía y su funcionamiento. En medio hay miles de opciones, y cuanta más libertad mayor será el grado de responsabilidad que asuman las personas.

En segundo lugar tenemos la multidisciplinaridad. Que un equipo sea multidisciplinar significa que incorpora todas las habilidades necesarias para poder sacar adelante un producto. No significa (y en esto me equivocaba mucho) que todos los miembros del equipo hagan de todo.

Por ejemplo, si tenemos un equipo que para la parte de Diseño subcontrata a otra compañía ese equipo no sería multifuncional. Existirá una dependencia clara con ese proveedor lo que provocará reuniones con poco aporte de valor como son: definir hitos, explicar los entregables, revisar entregables, revisar los errores, reuniones cuando no se cumplen hitos y un largo etc. Todo esto se reduce muchísimo cuando tenemos a las personas con esos conocimientos en el equipo y podemos hablar directamente.

Este tipo de dependencia favorece la eficiencia de recursos pero de no ayuda a la eficiencia de flujo. Esto provoca que aumente nuestro time-to-market lo que retrasa la entrega de valor y por eso no favorece nuestro Scrum.

Conseguir equipos multidisciplinares en empresas pequeñas suele ser sencillo porque es fácil romper silos, el número de personas afectadas es bajo. Sin embargo, en empresas muy grandes es tremendamente complicado porque tendremos a la optimización de las personas y por eso se suelen juntar por áreas de conocimiento. Todos los front, todos los back, los de base de datos… Para poder crear equipos con todas las habilidades tenemos que romper esos silos y muchas veces los mandos intermedios pueden ponerse en contra de la transformación para evitarlo. Jeff Sutherland hablaba de que los managers no quieren que nadie sepa lo que ocurre en su departamento porque en todos hay problemas. La manera de proteger la información es evitar que se creen equipos transversales.

La auto-organización requiere muchísimo de actitud personal, que cada uno de los miembros del equipo quiera colaborar con los demás para alcanzar los objetivos. Por contra la multifuncionalidad depende de la propia organización ya que está más relacionada con una Transformación Organizacional que nos permita reestructurar la compañía.

Sin embargo, la multifuncionalidad también se puede resolver cuando personas del equipo desean aprenden diferentes skills que no son las propiamente suyas con el objetivo de poder sacar producto. Por ejemplo “pues yo quiero aprender un poquito de Diseño porque así de esa manera no tenemos que esperar a ese tercero que nos haga la pantalla”.

Para la auto-organización la compañía tiene mucho que decir ya que a veces la organización apunta a una persona a la que marca como líder y le pide cuentas de todo el equipo lo que evita que el propio equipo asuma responsabilidades y por tanto que se auto-organice. Un ejemplo claro son las vacaciones, podemos dejar que el equipo las decida o podemos decirle a nuestros Scrum Master que las organice.

Un Scrum Team necesita tanto de la auto-organización como de la multidisciplinaridad para funcionar. Los valores de Scrum están muy presentes, al tener todas las habilidades necesarias para sacar producto podremos poner foco y conseguir un alto grado de compromiso. La autoorganización ayuda a que aparezca el coraje en querer afrontar los retos que se nos planteen y la franqueza nos ayudará a trabajar los problemas que tengamos entre nosotros con el respeto entre los miembros del equipo.

Podemos hacer diferentes ejercicios para fomentar la autoorganización y la multidisciplinaridad. Para el segundo podemos crear un cuadro de habilidades para conocer las habilidades que necesitamos en el equipo, las que dominan varias personas y las que solo las conoce un miembro (lo que genera un riesgo de que se vaya y el producto se resienta).

Para la auto-organización podemos tomar diferentes decisiones como Scrum Master. Por ejemplo, podemos no ir a la Daily Scrum o ausentarnos en la Sprint Planning y estudiar cómo reacciona el equipo en ese caso. Puede que se queden esperando a que aparezcas o que se remanguen y se pongan a trabajar.

Sinceramente, no se si es más difícil conseguir que un equipo se auto-organice o que sea multidisciplinar. Lo que sí tengo claro es que como Scrum Master necesitamos de ambas para funcionar y que tendremos que trabajar en nuestras organizaciones para que ocurra. Recordemos que un Scrum Master ayuda a la transformación de la organización y que pongamos sobre la mesa las consecuencias cuando nos falten habilidades en el equipo o cuando la compañía no ayude a la autorganización. Si somos capaces de mostrar el impacto que esto tiene en la entrega de valor podremos tratar de conseguir cambios organizacionales que favorezcan a los equipos Scrum.

Y tu equipo ¿Cómo de autoorganizado y multidisciplinar es tu equipo?