El Equipo Scrum

Aquí volvemos a la carga con un nuevo artículo sobre algunas de las características del equipo Scrum. Las ideas que aquí mencionaré salen de pensar un poco las indicaciones generales que da la Guía Oficial de Scrum. Aquí el link por si te interesa.

Como ya sabes, por equipo Scrum se conoce a la unión formada por el equipo de Desarrollo, el Scrum Master y el Product Owner. Juntos forman un equipo que tiene como objetivo entregar mejor software en cada iteración. Es importante entender que el cliente, al estar representado por el Product Owner, está también dentro del equipo. Esta es quizás una de las grandes diferencias con otro tipo de metodologías. El cliente muchas veces tiene cierta desconfiada y temor a no ser comprendido o a recibir algo que no cumpla sus expectativas, mientras que el equipo de Desarrollo tiene cierto miedo a ser exigido con algo que no ha sido solicitado o incluso a ser puesto a prueba por encima de sus capacidades. El Product Owner es la figura clave para mitigar esos miedos y desconfianzas entre cliente y equipo. Es sin duda alguna un punto de unión. Es importante que los miembros del equipo lo vean como pieza fundamental para desarrollar esa actividad, y por tanto, valorarlo y agradecerlo.

Las dos características básicas del equipo Scrum son: auto-organización y multifuncionalidad. Puede haber muchas más, pero si no hay estas dos, el equipo no será lo que tiene que ser. Estos dos conceptos tienen mucho que aportar al equipo, y todo lo que vaya enfocado a ganar en esos dos aspectos contribuirá a construir un equipo fuerte y especial.

En cuanto a la auto-organización, la mejor manera que se me ocurre para explicarlo, es lo que hace que el equipo se saque a sí mismo las castañas del fuego: ayudándose de todos los componentes, por supuesto el Scrum Master tiene mucho que ayudar aquí. El equipo auto-organizado es el que se crece ante las dificultades, es el que muestra una proactividad fuerte ante las tareas del día a día, el que prueba (innova) buscando nuevos resultados, es el que recibe cada proyecto nuevo como un reto, como una nueva oportunidad de triunfar juntos, no como un problema o como algo costoso, incluso si es algo que no domine y le obligue a salirse de su zona de confort.

Un punto concreto que ayudará a ganar en auto-organización es tener la reunión diaria sin el Scrum Master de vez en cuando. Obviamente esta actuación es solamente recomendable cuando el equipo haya adquirido la madurez necesaria para poder realizarlo sin ninguna frustración. Además, el Scrum Master no tiene porque asistir a todas las reuniones. Es bueno, es conveniente. Pero no es obligatorio que asista a todas. Así el equipo será más consciente si cabe de que las historias de usuario que se han acordado para ese sprint deben salir adelante, y que los que las van a sacar adelante son los que están en esa reunión, como digo sin el Scrum Master en algún momento puntual.

Por supuesto, si en alguna de esas reuniones se detecta algún problema o que se comprometa el product backlog a entregar en ese sprint, ha de comunicársele al Scrum Master cuanto antes para que sea trasparente con el Product Owner desde el momento en el que se detectó esa situación.

La multifuncionalidad es lo que hace que un equipo no necesite de nadie más para realizar las cosas que tiene que hacer. Internamente, conjugando todas las habilidades de todos los “jugadores”, el equipo es capaz de sacar las cosas adelante o de conseguir los conocimientos y habilidades necesarios. Aquí claramente se entiende que si un miembro del equipo está bloqueado con algo, por el motivo que sea, cualquier miembro del equipo, de un modo proactivo tras detectarlo en las reuniones diarias, se podrá ofrecer para desatascar el tema en concreto.

Pero eso no significa que todos los miembros del equipo deban saber hacer de todo. Esto solamente significa que internamente el equipo ha de ser capaz, juntando conocimientos y habilidades, de sacar las cosas adelante. Un amplio horizonte son las formaciones. Los desarrolladores no nacen sabiéndolo todo. Lo han ido adquiriendo. Y las formaciones, o tiempo de pruebas e investigación, son necesarios para que ese conocimiento siga creciendo. Por tanto, suele ser bastante útil que se contemplen dentro del sprint (o incluso sprints específicos) ciertos entregables de pruebas de concepto o de análisis de nuevas posibilidades.

Otras tres características, que afianzan las primeras son: la Flexibilidad, la Creatividad y la Productividad. Y quizás pueda ayudar analizar los dos pilares del equipo (auto-organización y multifuncionalidad) revisando estos tres:

  • ¿Cómo de flexible es tú equipo? ¿Cómo reacciona ante al cambio? ¿Lo ve como un riesgo o como una oportunidad de hacer un producto mejor? Es importante tener en cuenta que esto no significa meter en medio de un sprint nuevas historias de usuario.
  • ¿Se nota la creatividad en el equipo? ¿EL ambiente de la empresa lo promueve? ¿Puede un miembro del equipo sugerir nuevos modos de hacer con total naturalidad? ¿Se anotan esas sugerencias? ¿Se implementan algunas?
  • Y por último: ¿Cómo es el compromiso de los miembros del equipo con los objetivos del sprint? ¿Se alcanzan habitualmente?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑

A %d blogueros les gusta esto: