En el artículo Quién es el Equipo de Desarrollo de Scrum, escribimos sobre las características un rol muy importante. En este artículo trataremos las disfunciones más habituales a las que puede enfrentarse.
Squad
Antes de entrar en este tema, quiero dejar claro que no tengo nada en contra del nombre Squad. Cuando una empresa esté realizando una transformación organizativa, habrá ocasiones en las que querremos marcar un punto de ruptura con el status quo.
El intercambio de títulos puede ser una buena forma de hacerlo. El problema es cómo algunas empresas han utilizado el título.
Trayendo un poco de historia. En 2014, Henrik Kniberg presentó la forma en que algunos equipos de desarrollo trabajaban en Spotify (servicio de streaming de música – consulta los artículos originales aquí y aquí). A muchas empresas les gustó la idea y comenzaron a implementar el “Modelo” Spotify.
Puse el término entre comillas porque el propio Henry dijo en 2015, en otra ocasión aparentemente menos famosa, que no hay un Modelo Spotify (mira el vídeo aquí, casi en el minuto 45).
En los artículos originales, relata la forma en que trabajaron y los años de experimentos por los que pasaron hasta llegar a ese estado.
Esto no impidió que varias empresas ignoraran los años de experimentos, fracasos y éxitos y comenzaran a “instalar” este “modelo”. De la noche a la mañana, los nombres de los equipos, unidades de negocio o departamentos se convirtieron en Squads.
Como por arte de magia, al llamar a un grupo de personas de Squad, todos los problemas se resuelven y nos volvemos ágiles.
Pero no funciona así. Un grupo de personas incapaces de construir un producto de principio a fin permanece en esta situación, independientemente del nombre.
Para crear un equipo verdaderamente multidisciplinario se requieren acciones firmes, objetivos claros y mucho trabajo.
Juan, el experto inmortal
Durante muchos años nos hemos acostumbrado a tener personas ultra expertas en un determinado tema. A menudo, cuando formamos un Equipo de Desarrollo, mantenemos esta estructura altamente especializada dentro del equipo.
Pondré un ejemplo y me gustaría llamar a nuestro experto Juan, quizás te identificas con él o conoces a alguien que se parezca al personaje de esta historia.
El equipo está en manos de Juan, el experto. Si él está ahí, las cosas van, si no está, nada va. Inicialmente Juan está feliz, porque es el Héroe del Equipo.
Pero no todo es maravilloso en la vida de Juan: de camino a las ansiadas vacaciones en el Caribe, suena el teléfono. Es el equipo que depende de Juan y le tienen 2 horas para consultarle sobre un “pequeño problema”.
Juan desembarca en Miami, se conecta a la wifi y recibe 265 mensajes que tiene que contestar porque el equipo depende de él. Mientras espera una conexión a Bahamas, Juan contesta todos los mensajes.
Al llegar a Bahamas, vuelve a conectarse a la Wifi para ver la dirección del hotel y ahora tiene 367 mensajes nuevos porque al intentar solucionar el “pequeño problema”, el equipo creó un gran problema.
Juan intenta desesperadamente responder a cada mensaje, pero recibe una llamada del jefe: “Juan, tienes el ordenador portátil a mano.
Accede a nuestra red desde allí para ver el informe XYZ, es que el personal no sabe generarlo”. Desesperado, Juan intenta encontrar el ordenador en medio de las maletas y el lío de la salida del aeropuerto.
Su esposa lo ve abriendo el ordenador y ya le lanza una mirada fulminante. El hijo menor vomita a los pies de una señora que grita palabras que ni siquiera Juan las comprende y la hija mayor casi llega a la puerta de salida. Juan sabe que las vacaciones se acabaron (bueno, en realidad no empezaron).
Pánico total, Juan le grita al jefe, y mientras sale por la puerta le pide disculpas a su hija, le da el informe a su esposa y ni siquiera recuerda que tiene un hijo. Juan sufre un infarto y muere.
Pero la empresa no puede parar y Juan es fundamental. Ahora hay sesiones “mediúnicas” todos los días a las 11h de la mañana para que el equipo le haga preguntas a Juan, que no descansa incluso después de su muerte.
Bromas aparte, la especialización excesiva de las personas tiene graves consecuencias para el Equipo de Desarrollo. El primero es la dependencia del experto, el segundo es la baja eficiencia del equipo, ya que el ultraexperto se convertirá inevitablemente en el cuello de botella del equipo.
La situación es peor si el equipo está muy segmentado en varios expertos. Volviendo al texto anterior. Es como si tuviéramos a Juan, María, Ana, José y cada uno hace una sola cosa y nadie sabe hacer el trabajo del otro.
Una manera de reducir esta dependencia es empezar a terminar con los silos de expertos. Trabajo en pareja, Dojos, formación interna, talleres y muchas otras formas de convertir profesionales tipo I (Experto) en profesionales tipo T (Generalistas Expertos).
Equipos de Expertos
Tener un experto en el equipo es malo, pero tener equipos completos compuestos solo por expertos de una determinada área del conocimiento es igualmente malo.
Ejemplo: Para una entrega, el responsable es el Equipo A. Sólo que el Equipo A depende del Equipo B para este fin. Lo que no saben es que el Equipo B depende del Equipo C. A su vez, este depende del Equipo D y así sucesivamente.
Label: Dependencia entre los equipos
Ejemplos comunes en el Desarrollo de Software: Equipo de UX, Equipo de Front-End, Equipo de Back-end, Equipo de Base de Datos, Equipo de Producción, Equipo de Negocios…
Nadie es responsable de entregar el producto, todos son responsables de hacer una parte mínima y “pasar el balón” al siguiente de la fila.
El equipo pasa el “balón” al otro
Este problema es aún mayor si existen dependencias circulares.
Label: Ejemplos de dependencias circulares entre equipos
La solución a este tipo de problema es la creación de equipos multidisciplinares. Cuanto menor sea el número de handoffs (pase de batuta) más eficiente será el equipo.
He hecho mi parte
Cuando adoptamos Scrum, existe el rol del Dueño del Producto (Product Owner). Sin embargo, también es necesario que el Equipo de Desarrollo tenga un sentido de propiedad del producto. Hay una gran diferencia entre ser el dueño de algo y no serlo.
Imagina que apareciera una mancha de humedad en el techo de tu cocina. Probablemente no esperarás a que la humedad empeore con los brazos cruzados. Como el apartamento es tuyo, solucionarás inmediatamente el problema.
Ahora piensa en la situación en la que fuiste a visitar a un amigo y notaste que en su casa había una mancha de humedad en el techo de la cocina. ¿Qué haces? ¿Le avisas del problema? ¿Le dices que conoces a alguien que puede ayudarle? ¿Te quedas en silencio porque no quieres inmiscuirte en la vida de los demás?
Date cuenta de que, en el primer caso, cuando estás en tu casa, tomas alguna acción para solucionar el problema: arreglas la humedad o llamas a alguien que sepa arreglarlo. Ahora, cuando la casa no es tuya, lo máximo que puedes hacer es hablar del problema, pero resolverlo es responsabilidad de la otra persona.
Lo mismo ocurre cuando hablamos de productos y servicios en nuestras empresas. Si tenemos la sensación de dueños del producto, le tenemos cariño y queremos que sea el mejor producto del mundo: útil, agradable, bonito, seguro, con calidad, etc. Cuando no tenemos este sentimiento de pertenencia, cada uno hará su parte y los problemas serán siempre del “otro”.
Dos cosas son importantes para crear este sentido de propiedad. La primera, nuevamente, está relacionada con la multidisciplinariedad del equipo.
La segunda está vinculada con la Programación Neurolingüística (PNL). No refuerces las declaraciones negativas sobre el producto. Ejemplo:
- Este producto vive presentando defectos.
- Es verdad, ¿recuerdas ese problema que tuvimos en 1998?
- Pasamos la noche aquí, fue un infierno.
- Es mejor tirarlo y construir uno nuevo.
Parece una tontería, pero afecta bastante. Esto crea un ambiente negativo, cada miembro del equipo refuerza los aspectos negativos del trabajo y ayudan a construir un estigma para el producto. Prueba a cambiar la queja por acciones.
- Este producto vive presentando defectos.
- ¿Qué sucedió? ¿Cómo podemos resolverlo? ¿Puedo ayudarte?
Atareados
Existe una gran brecha tanto en la eficacia como en la eficiencia cuando se comparan equipos destinados a generar valor y equipos atareados. Este tema fue bien explotado por Andressa Chiara en el artículo El equipo “hacedor de tareas” y el equipo de producto. Así que resumiré qué son.
En métodos ágiles queremos entregar el producto de manera iterativa e incremental con el valor más alto disponible en las primeras iteraciones. Por lo tanto, los elementos más importantes están en la parte superior de mi backlog. Imagina que el equipo está trabajando en el elemento de mayor prioridad y ocurre algo inesperado y el equipo se ve impedido de dar continuidad a ese elemento. ¿Cuál es la diferencia en el comportamiento de los dos equipos?
Equipo de desarrollo enfocado en la entrega de valor
Tenemos que eliminar el impedimento, ya que este es el elemento más importante que debemos entregar. No hay nada en el backlog que sea más importante que eso.
Equipo atareado
Vamos a coger otro elemento, ya que éste está impedido.
Desafortunadamente, no habrá un solo impedimento en la vida de un equipo y stock de elementos iniciados y no terminados por el equipo “hacedor de tareas”.
El que está atareado también puede estar libre de obstáculos. Por ejemplo, si tengo un experto en mi equipo y su participación en el elemento de valor es corta, la tendencia es que intente “adelantar” el trabajo.
Trabajará en el elemento 5.778 del backlog mientras que el resto del equipo estará en el elemento 4. Este avance es ilusorio y es muy probable que tenga que rehacer los 5.774 elementos.
Tener demasiados elementos comenzados y no terminados significa que tu “stock” es muy alto y como cualquier stock, se perderá. Cambio de mercado, resultados anteriores, cambios en el perfil del cliente, etc.
No tenemos tiempo para…
“Aquí se trabaja, trabaja y trabaja. No tenemos tiempo para otra cosa.”
(Ancelmo, 22 años)
Suele ser consecuencia del equipo atareado. No tenemos tiempo para planificar, hacer mejoras, estudiar nuevas tecnologías, pensar en diferentes soluciones. Sólo trabajar, trabajar y trabajar para cumplir.
Al principio, trabajar en exceso en un nuevo proyecto, producto o servicio parece una buena idea, pero con el tiempo se convierte en una carga.
Es necesario insertar recesos en el flujo de valor para que el equipo pueda mejorar su forma de trabajar, innovar y aprender.
Conclusión
Las disfunciones son comunes en los Equipos de Desarrollo, pero no debemos aceptarlas pasivamente. Es responsabilidad de todos, Equipo de Desarrollo, Scrum Master, Product Owner y gestores terminar con ellas.
Espero que hayas disfrutado de este artículo. ¿Quieres saber más sobre los roles de Scrum? Te invito a participar en nuestra formación de Certified Scrum Master (CSM).
