Reconozco que muchas veces me cuesta pensar un tema sobre el que escribir. ¿Qué queda sobre lo que ya no se haya escrito? Esta vez no ha sido el caso: Hace unos días hice una formación presencial donde surgió el debate de cómo deberían ser los equipos, donde un asistente preguntaba cómo encajar a los equipos especialistas (y aquí puedes poner desde QA, base de datos, integración, arquitectura, legal, asesores expertos en un tema... elige el que quieras). Esta mañana, abro mi email y veo un correo de Steven Deneir de un artículo en el que desmitificaba que "colectivamente" tenga algo que ver con "todo el mundo sabe hacer de todo". Así que ahí vi la luz y me puse a escribir. ¿Qué nos dice la Guía de Scrum sobre esto? La Guía nos dice: Scrum involucra a grupos de personas que, colectivamente, poseen todas las habilidades y la experiencia necesarias para realizar el trabajo y compartir o adquirir dichas habilidades según sea necesario. Los equipos Scrum son multidisciplinares, lo que significa que sus miembros poseen todas las habilidades necesarias para crear valor en cada Sprint. Esto implica que no existen equipos especializados, sino que tendremos equipos multifuncionales. Por ejemplo, yo no trabajaré en el departamento de QA, sino que seré el QA en el equipo A para el producto X. Por si lo estás pensando, la respuesta es sí, puedes estar en más de un equipo a la vez, aunque el rendimiento empeorará. Valora bien todas las opciones antes de optar por esa solución. Esto no significa, que personas con perfiles similares, no puedan reunirse cíclicamente para compartir herramientas, experiencias, descubrimientos, etc. con el objetivo de mejorar globalmente en la organización. No sólo no está prohibido, sino que sería una práctica altamente recomendable en una organización que fomente la cultura de la excelencia. ¿Qué significa multidisciplinar? La multidisciplinariedad significa que cada equipo tiene todo el conocimiento necesario para realizar cierta tarea. No significa que todos los miembros sepan hacer de todo, sino que el equipo, en su conjunto, con su variedad de perfiles que lo compone, sabe hacer de todo. Esto implica que: Si para entregar valor se necesita una habilidad o conocimiento en concreto, al menos alguien en el equipo debe tenerlo. Si sólo una persona lo tiene, el equipo es frágil y sensible a posibles imprevistos. El trabajo del equipo se verá reducido cada vez que dicha persona no esté disponible por el motivo que sea. Además es una puerta abierta a cuellos de botella. Si varias personas lo tienen aumentará la resiliencia. El trabajo en parejas, la mentoría y la curiosidad ayudarán a difundir el conocimiento a lo largo del tiempo. Si trabajas como Scrum Master, una de tus funciones es la de fomentar el crecimiento individual y colectivo del equipo, por lo que deberías animar a que los compañeros del equipo sigan creciendo en aquello que controlan, pero que también se interesen en perfiles en los que puedan ser útiles al resto del equipo. Con ello no se pretende que todo el mundo sepa de todo, ni que podamos sustituir a un especialista, pero sí que conseguiremos evitar bloqueos del equipo. Eso sí, es imprescindible no forzar ni obligar a los compañeros a aprender aquello que no quieren hacer, sino convencer de la importancia del crecimiento continuo para que sean ellos los que elijan aquello que más les llame la atención. Algunas de las preguntas que puedes hacer en el equipo, probablemente en la Retro, son: ¿Qué habilidades son absolutamente esenciales para aportar valor en cada Sprint? ¿En qué casos dependemos demasiado de una sola persona? ¿Quién quiere desarrollar una nueva habilidad? ¿Quién quiere ser mentor? ¿Cómo hacemos que el aprendizaje sea visible y llegue a todos los interesados? La multidisciplinariedad es un proceso continuo e infinito en el equipo. Comienza con una persona que tiene un perfil o habilidad concreta y va creciendo a medida que otros aprenden, comparten y adquieren dicha habilidad. El rápido auge y evolución de la tecnología, mercados y necesidades de los usuarios nos obliga a esta evolución constante. Así que ya sabes, la próxima vez que alguien te pregunte por "¿Y el equipo de pruebas dónde encaja?", ya sabes que la respuesta es "ese perfil ya existe dentro del Scrum Team, y de no haberlo, alguien de pruebas se incorporará al Scrum Team.