¿Te has planteado alguna vez cómo sería un equipo de desarrollo perfecto en Scrum? ¿Qué dice Scrum sobre esto? ¿Cómo están los equipos Scrum a dia de hoy?
Indice de contenidos
El rol del Development Team
Según el marco de trabajo Scrum, un equipo de desarrollo Scrum, tiene las siguientes características:
- Son auto-organizados.
- Los equipos de desarrollo son multifuncionales es decir, contienen todas las habilidades necesarias para crear un incremento de producto cada Sprint. ¿Eso lo has visto de verdad? El DT tiene todas las personas necesarias para desarrollar el producto desde que entra una necesidad en el flujo hasta que llegue a producción.
- Scrum no reconoce ningún título para los miembros del equipo de desarrollo, independientemente del trabajo realizado por las personas. Así que, olvidemos los títulos del arquitecto, el analista, el UX, QA, etc. Son todos miembros del Dev Team.
- Scrum no reconoce sub-equipos en el equipo de desarrollo, independientemente de los skills que necesiten como: pruebas, arquitectura, operaciones o análisis de negocio.
- Los miembros del equipo de desarrollo pueden tener habilidades especializadas y áreas de enfoque, pero la responsabilidad pertenece al equipo de desarrollo como un todo.
Visto esto, ¿te parece que los equipos donde estás sean así?
Cómo están los equipos a día de hoy
A día de hoy, con los cambios organizacionales que están sucediendo, resulta un poco difícil, decir: ¡paremos! y construyamos equipos por producto. Dejemos los departamentos de QA, UX, sistemas, arquitectura, etc. y pongamos foco en el producto que queremos sacar al mercado y las habilidad y personas que necesitamos para tal fin.
Si no ponemos un punto final a esta situación, nuestro time to market, calidad, innovación y otros elementos importantes se alargarán o se perderán. Todo esto se debe a que el día a día nos consume. Pongo un ejemplo, el departamento de sistemas monta los servicios de seguridad necesarios, otro departamento que lleva toda la parte de bases de datos etc. El equipo que programa la parte de servicios, al terminar, avisan al equipo de front para que desarrolle la parte visual (estamos siendo cortos, en grandes empresas podemos entrar en capas intermedias interminables). Claro, todos los departamentos usan Scrum. Cada equipo lleva su desarrollo en su Sprint para evitar riesgos y bloqueos. Imagínate como es el time to market.
Si lo que queremos es tener a la gente trabajando sin parar y asegurar que no haya nadie sin nada que hacer, puede parecer ideal. Pero no, al final, acabamos haciendo mal las cosas, por calidad, que luego generan más bugs que otra cosa, estrés de las personas, desmotivación, y peor aun, sin propósito común. Dejame compartir contigo como lo plantean en Scrum.org
Cómo sería el Dev Team perfecto
Imaginate que el producto que necesitas hacer es un portal de gestión de clientes. En tal portal necesitas varios skills, para ello te recomiendo que hagas una matriz de competencia como la que proponen desde Management 3.0, que permite ayudar a ver qué necesitas para llevar el producto desde la idea hasta el mercado. Entonces, vamos a hacer un producto, que necesitamos alguien que sepa de front, experiencia de usuarios, calidad, de backend, bases de datos, además de seguridad y marketing. Realmente, debemos de poner sobre la mesa todo lo que necesitamos y de ahí vamos trabajando en la construcción del equipo. Muchas veces pecamos con que desde el día 1 sabemos todos los perfiles que necesitamos. Pero, es un error común, la mejor manera es empezar por poca gente que esté disponibile, que confie en esta idea e ir colaborando juntos buscando ese equipo perfecto.
Ahora viene la pregunta del millón: estoy sumergido en un proceso de transformación y no puedo pararlo todo para hacer esto, ¿qué debería de hacer? Buena pregunta, intenta construir los nuevos equipos en base a productos, y haz que el mundo se contagie con este nuevo enfoque. Las mismas personas que no estaban de acuerdo, querrán sumarse y construir productos así.
Conclusión
Como resumen final, me gustaría compartir contigo los posibles beneficios de un equipo enfocado a funcionalidad o producto en lugar de componentes (por capas):
- Decisiones de diseño más flexibles.
- Reducción del desperdicio causado por las capas.
- Reducción del trabajo no planificado.
- Reducir el time to market.
- Reducción de los costes de integración.
- Mayor orientación al cliente.
- Aumento de la calidad a nivel de código y de producto en general.
- Equipo más fuerte.
