Cómo mezclar diferentes habilidades dentro del mismo equipo Scrum

Realmente hay dos respuestas a su pregunta: la respuesta Scrum “por libro” y la respuesta herética “hacer lo que funciona”.

En el Scrum tradicional e idealista, cada equipo debe estar lleno de generalistas que sean igualmente capaces de realizar todas las tareas a las que se compromete el equipo. Ahora, eso no es realmente realista, por lo que el enfoque más “realista” pero aún más dogmático es dotar al equipo de recursos suficientes para que puedan ofrecer una funcionalidad útil de extremo a extremo en una “porción” de una característica durante una sola iteración . Sí, esto significa que un desarrollador de back-end debería “ayudar” a los desarrolladores de front-end, pero solo si su asistencia no disminuiría la velocidad del equipo.

En el mundo de “haz lo que funciona”, donde encuentro que la goma realmente toca la carretera, a menudo es mejor “cortar” tus características de modo que los diferentes equipos puedan centrarse en sus fortalezas, en lugar de tratar de hacer que cada equipo sea completamente independiente de los demás. . Sí, esto presenta algunos inconvenientes: si el equipo “backend” no logra hacer algo en lo que se basa el equipo “frontend”, puede haber problemas. Pero he visto que este enfoque funciona mucho más eficazmente en ciertos entornos que el enfoque Scrum más tradicional de las habilidades de desarrollo general en cada equipo. Sin embargo, diré que tener equipos especializados como este solo funciona bien si hay una persona que maneja los hilos (un buen arquitecto de software) y un conjunto muy diligente de ScrumMasters o propietarios de productos que vigilan de cerca cualquier trabajo dependiente y puede pivotar a los equipos si sucede algo para que todo avance.

Um, es bastante fácil: formar un equipo de personas que tengan diferentes conjuntos de habilidades 🙂 Esto se llama un “equipo multifuncional”, y es el camino a seguir. Tiene muchas ventajas y casi ninguna desventaja. Escribí un poco más sobre eso aquí: https: //www.extremeuncertainty.c