Actualmente trabajo como Agile Coach, como comenté en este artículo una de mis labores principales es ayudar a los Equipos Scrum. Siempre que ayudo a algún equipo, les doy una idea, les acompaño en algún evento o les doy feedback, trato de que mejoren. Lo curioso es que, cuando eso ocurre, nunca pienso que es gracias a mí sino al Development Team. Al final son ellos los que lo hacen posible, y si ellos no quieren nada ocurre.
El Development Team es una parte crítica del Scrum Team porque según dice Scrum “ellos hacen el trabajo” (como si los demás no trabajaran). Si Scrum fuera un juego con reglas, ellos son los que deciden cómo jugar y si quieren ganar o dejarse perder.
¿Qué características tiene un Development Team?
Analicemos las características de un Development Team de verdad.
En primer lugar la responsabilidad de un Development Team es generar incremento que potencialmente se pueda poner en Producción al finalizar un Sprint. Por lo tanto, son los responsable de la entrega de valor; sin embargo, el que rinde cuentas sobre lo que es valor será el Product Owner porque es el que prioriza el trabajo del Dev Team.
Son auto-organizados. Ellos deciden cómo conseguir que los elementos del Product Backlog se conviertan en incremento que sea potencialmente desplegable. Ser autoorganizado es una de las cosas más complicadas y un buen Scrum Master pondrá mucho foco en ello, luego explicaremos algunas opciones que podrían ayudar.
El Development Team es multifuncional, es decir, la suma de las skills de todos sus miembros debe permitir crear el incremento. Pero… ¿Esto ocurre siempre? Scrum intenta evitar el tener equipos separados por tecnología; tener equipos de pruebas separados, tener equipos de diseño de otras empresas o tener un equipo que crea web services y otro que los consume. El principal motivo para esto es la colaboración entre equipos y minimizar dependencias, ¿Cuántas veces has pactado con otro equipo cómo iban a ser los web services y luego te encontrabas con situaciones como “esto no devuelve el valor que necesito”, “este error no está contemplado”, “esto no hace lo que acordamos”? Este tipo de situaciones generan desconfianza entre equipos, tensión y reuniones poco productivas para debatir quién tenía razón. Lo peor de todo es que si tienes multiproveedor es poco probable que colaboren si la situación se complica.
Scrum propone que los Development Team sean totalmente funcionales y capaces de entregar incremento que se puede entregar a un usuario final. Por eso Scrum no reconoce sub equipos dentro del Development Team y enfatiza “no hay excepciones a esta regla”.
No tenemos títulos
Otra de las características principales es que los miembros de un Development Team no tienen títulos. Todos son considerados desarrolladores independientemente del trabajo que realice cada persona; no hay excepciones a esta regla. Sin embargo, también dice que los miembros pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Development Team como un todo.
¿Qué diferencia hay entre un título y una especialidad?
El mejor ejemplo que hemos encontrado para explicarlo son los X-Men. Los X-Men no tienen títulos, no hay X-Men Fronts o X-Men QA; A los X-Men se les mira por sus habilidades, cada uno de ellos sabe hacer cosas especiales que ponen al servicio del grupo; sin embargo, todos son responsables de acabar con el malo y ganar la misión. Imaginad a Lobezno, es muy fuerte e inmortal, si hay una batalla aérea Lobezno podría decir “yo me desentiendo porque yo no vuelo”, ¡No! Lobezno iría a la batalla y aunque sea lanzaría piedras, al final, ayudar a tus compañeros no es hacer su trabajo pero es estar ahí para echar un cable.
Este concepto genera mucha confusión, Scrum no dice que todos hagan de todo, que un Front haga de Back o que un UX automatice pruebas. Scrum lo que dice es que todos van a ser responsables de lo que ocurra, y frases como “esa no es mi parte” no valen como escape para eludir el resultado final que se genere.
El Scrum Master es clave para que el equipo funcione
Dado que estos conceptos cuesta interiorizarlos y dependen mucho de la actitud de las personas que compongan el equipo, el trabajo del Scrum Master cobra importancia.. ¿Cómo conseguir que un equipo se autoorganice cuando ni se conocen o nunca han trabajado de esa manera? Voy a comentar algunas acciones que hemos tomado y cuando han funcionado, aunque hay que tener en cuenta que no hay una receta infalible, cada equipo es diferente y si el Dev Team no quiere no se hará.
Lo primero que solemos hacer los Scrum Master es ganar protagonismo, no creo que sea malo, los primeros pasos con un equipo es enseñar Scrum y hay que predicar. Esto aplica a todo, solemos escribir historias de usuario o que dirijamos una Daily Scrum. Un buen Scrum Master tiene que tener cuidado con el exceso porque si no dejas espacio para la autoorganización entonces no ocurrirá. A medida que el Dev Team aprende Scrum empieza a llegar el momento de generar ese espacio y dejar de hacer esas tareas.
Técnicas para acompañar equipos
Una de las mejores técnicas para esto es empezar a ausentarte en eventos. Por ejemplo, llegar tarde a la Daily Scrum y ver si ha ocurrido y si ha cumplido su función. No ir a los refinamientos para dejar que el Dev Team se comunique con el Product Owner sería otro paso que se podría dar. Durante la Sprint Planning puedes agendar otras reuniones para salir de la sala y dejarles que se organicen; podrías aparecer pasado un tiempo para estudiar si lo están consiguiendo. En la Sprint Review es normal ayudando a organizar la parte de mostrar el producto, sin embargo, a partir de cierto punto dejarles a ellos para que decidan cómo organizarlo sin intervenir. Finalmente, en la Sprint Retrospective hacer rotaciones para el facilitador ayuda a entender que es un evento de todos.
Es bastante habitual que un Scrum Master empiece centralizando la comunicación con el Product Owner, pero poco a poco tiene que ir soltando esa labor y dejar que el Dev Team asuma ese papel. Una técnica para comenzar a generar autoorganización es abrir herramientas de comunicación compartida: listas de correo o chats donde estén todos, y si hay que comunicarse por teléfono con el Product Owner que sea compartido en el lugar donde esté el Dev Team.
Recordemos que el artefacto principal de un Dev Team es el Sprint Backlog. El Sprint Backlog es un plan, creado por el Development Team durante el Sprint Planning para decidir cómo acometer el Objetivo que se han marcado en el Sprint. Este plan puede ser físico o digital (esto da para mucho debate) sin embargo, un buen Scrum Master les enseñará ambas maneras y les animará a probar ambas con el ánimo de que busquen su mejor camino. Desde luego, hay que intentar evitar ser el “master del tablero” y acabar siendo tú el que actualiza el Jira o los Postits. Y recuerda, deja que el Dev Team tome sus propias decisiones, si ellos no quieren nada se hará.
No todo el mundo está preparado
Hay un concepto que debemos interiorizar. No todo el mundo vale para trabajar de esta manera, es más, no todo el mundo quiere trabajar así. Un Scrum Master ayudará a que los equipos aprendan Scrum y aprendan a trabajar juntos. Si esto no es posible, hay que saber detectar quien no es compatible con esta manera y ayudar al Dev Team a expulsar a las personas que no desean asumir el reto. Es difícil sentirte responsable de algo si las personas que te rodean no comparten esa responsabilidad. Un Scrum Master siempre tenderá a la integración de todo el equipo, sin embargo, debe ayudar también si alguien no funciona. Por todo ello, un Scrum Master no debe mirar tanto los resultados como las actitudes de las personas, las relaciones entre ellos, los gestos, sus motivaciones, los comentarios de pasillo y todo aquello que le aporte información para conseguir que Scrum funcione. No decimos que olvidemos los resultados, pero poner foco en ellos hará que el Dev Team no lo haga y dificultará que pongamos foco en las personas. ¡Recuerda! Si el Dev Team no quiere no se hará.
Aquí hemos mostrado lo que un Dev. Team hace, si leemos la Scrum Guide parece muy sencillo ¡Pero que difícil es que ocurra! Me gustaría mandar un mensaje de admiración a mis compañer@s que han conseguido ayudar a los Dev Teams con los que conviven a que se autoorganicen, se responsabilicen, sean un equipo y consigan resultados excelentes. Para mi, es algo que por muchos libros que leas o incluso experiencia que tengas, siempre puedes fallar en el siguiente equipo en el que estés, porque al final si el Dev Team no quiere nada se hará.
