Nadie. Fin del artículo.

No, es broma. Voy a explicar un poco más sobre el porqué.

Es común escuchar que hay gente haciendo Scrum en equipos en los que resulta que el equipo estima pero luego el Scrum Master hace una asignación de las tareas a los miembros del Development Team. Yo mismo reconzco que antiguamente solíamos hacer eso.

Cuando empecé a estudiar como Scrum Master fue de las primeras cosas que me cargué y no fue nada sencillo. Hubo bastante reticencia a que dejasemos de hacerlo. Pero como siempre digo, creo que era normal. Era un viejo hábito en los equipos que venía de antes de que empezasemos realmente a hacer Scrum y desde management se tenía miedo de que los equipos no pudiesen organizarse el trabajo y ponerse de acuerdo. Y los desarrolladores tampoco lo acababan de ver claro al principio. Empecé por un equipo y luego lo fuimos exportando a los demás. Ahora mismo por supuesto que nadie lo pone en duda y ya sería impensable volver a eso.

La Guía de Scrum, cuando habla del Development Team lo dice bien claro en un solo párrafo.

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.

Lo de “ni siquiera el Scrum Master” es clave. El equipo de desarrollo es autónomo, nadie les dice cómo convertir el Product Backlog en un incremento.

Bien ¿qué hay más intrusivo en el trabajo de alguien que decirle cómo tiene que organizarlo y quién hará cada cosa? El Development Team tiene a todos los miembros que necesita para sacar adelante el desarrollo del producto y depende de mil factores, a veces incluso de condiciones diarias, decidir quién es más adecuado o cual es el mejor momento para acometer cada tarea.

Si estás pensando en el tema de asignarle los tickets de Front al de Front y los de Backend al de Back … la cosa tampoco va de eso. No es una cuestión de “yo acabo lo mío y te lo paso y luego sigo con otra cosa y tú te buscas la vida”. El equipo debe trabajar como un equipo y no como un grupo simplemente.

“Sería bueno que hoy te pusieras a mirar esto conmigo porque así mañana podemos dividirnos esto otro. Voy a investigar cómo enganchar lo que has hecho tú con lo mío y así ahorramos tiempo para lo del otro. Me gustaría hacer esto a mí contigo que nunca lo he tocado y así la próxima vez puedo empezarlo yo sólo. Si nos dividimos esto tú puedes empezar antes lo que tenías y podemos integrar esta parte cuanto antes …”

Todo esto se parece mucho más a lo que debe pasar dentro del equipo y escucharse en el Daily Scrum que frases que me chirrían un montón y que antes oía mucho como “yo estoy con mi ticket y luego me pondré con el otro que tengo”.

Hace tanto que no lo escucho que al recordarlo para escribirlo me suena súper extraño.

Pretender hacer un cuadrante con tickets para cada persona creeme que no sólo va totalmente en contra de conseguir que un equipo se auto-gestione, sino que además es pegarse un tiro en el pie. No te van a salir las cuentas por horas para cuadrarlo, es un sistema con una capacidad cero de modificación ante imprevistos, roba responsabilidad al equipo sobre algo de lo que tienen que responder, añade responsabilidad al Scrum Master sobre algo de lo que no tiene que responder … es una locura.

Si lo estás haciendo, dejad de hacerlo ya. En el siguiente Sprint. Puede que el equipo tarde un poco en acostumbrarse y les de un poco de vértigo, pero es el paso uno imprescindible a la auto-gestión.

Pueden empezar siendo un poco conservadores, sin locuras de cantidad de trabajo en el Sprint Backlog y poco a poco puedes ayudarles a descubrir maneras de ver cuando se están necesitando y no lo ven porque están encerrados en su tarea. En la daily, puedes ver cuando alguien se está enganchando y podéis tratar de establecer una dinámica para que vean que es super sano que esa tarea se vuelva a dividir o aprendan a compartirla. E incluso pasará que con el tiempo alguno se ponga firme con ayudar a otro porque ve que hay algo que si no es así, no van a conseguir sacar del sprint.

Es una cuestión de dar pasos hacia la toma de responsabilidad. Ellos son los responsables que tienen que dar la cara por entregar o no el incremento de producto y no se van a hacer responsables de hacerlo ejecutando un plan que es impuesto ¿no? El Sprint Backlog es suyo ¿cierto? Pues el plan para llevarlo a cabo también.

Anuncios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.