El Scrum Development Team perfecto

20/03/2021
Llevo tiempo dando vueltas a este tema del Development Team. Muchas conversaciones y debates sobre cómo debemos de enfocar esto. A día de hoy me encuentro con dificultades para llegar al punto que quiero compartir contigo. No obstante, no pienso desistir, seguiré este camino porque confío en esta perspectiva plenamente. Así que, veamos antes ciertas cuestiones.
Un equipo de desarrollo o Development Team en Scrum perfecto

¿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?

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

Dev Team perfecto, o el equipo de desarrollo ideal en Scrum

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.

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 5 / 5. Recuento de votos: 1

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Otras publicaciones

Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!

Applying Flow Metrics for Scrum

By ProKanban.org

Código de descuento (21 %) QAF1UZZ1

You have Successfully Subscribed!