Equipos Scrum: El equipo es multifuncional, no los team members polivalentes

Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:

• a verificar el producto,
• a aprender de estrategia de pruebas
• a buscar lo que no se ha perdido, 
• es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
• adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
• Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
• a pensar como usuario
• entre otras fortalezas de un buen tester

Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:

• el equipo: pues le reclamarán tempranamente por habilidades que no tiene
• el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
• el scrum master: le dirán que por que no removió este impedimento oportunamente
• el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
• la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.

Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:

• Desarrolladores de software
• Tester
• Tester automatizador (depende del proyecto y producto)
• Base de datos (depende del proyecto y producto)
• Diseñador gráfico  (depende del proyecto y producto)

Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

•  los testers se apoyan en sus compañeros de desarrollo para probar, 
• o que desarrolladores enseñan a testers a programar,
• expertos de bases de datos y desarrolladores
• etc

 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.

Saludos ágiles

Jorge Abad.

Notas y Aclaraciones:

• (1) Guía oficial de Scrum (clic aquí)
• (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores