Indicios de que un equipo no es realmente… muy equipo

Mr. NoBody me contó, en estas semanas, que es mas que evidente que sus equipos, quizá por falta de madurez (como cuenta el modelo de Tuckman), tengan un problema de conexión, quizá de visión muy individualista, que tengan el problema de no ser realmente un equipo. 

NoBody tenía entre sus manos un post-it arrugado, que acabó enseñándome mientras hablábamos y en el que había apuntados ciertos comportamientos que él había observado y que le habían llevado a pensar así.

Hablamos bastante tiempo, y, al final de nuestra conversación, me dijo que no tenía problema con que compartiera un resumen de las sospechas y comportamientos que, con mucha razón, le habían llevado a pensar así…

1 – Que, en el equipo, cada uno tenga «sus» Historias

Probablemente esto venga de algo que ya conté aquí, de que directamente alguien asigne Historias a personas, que suena muy mal, es muy Lado Oscuro o, también, puede haber sido decisión del propio equipo.

Ya sabemos que el camino del yo al nosotros es complicado, pero, como todo, aun habiendo especialización y gente a la que se le da mejor hacer unas cosas que otras, cualquier Historia es cosa de todo un equipo.

2 – Que no sea todo el equipo quién opina sobre una Historia

Derivado de lo anterior, en este caso hablamos de que sólo puede opinar del estado del desarrollo de una Historia, y si es que lo hacen, aquellos que están trabajando en ella. Privándonos de ayuda, de terceras opiniones, del sentimiento de que la Historia es responsabilidad de todo el equipo, etc. 

3 – Que cuando alguien termine «sus» Historias empiece con otras… en vez de ver si puede ayudar a sus compañeros

Otro clásico, que no es que solo lo haya observado Mr. NoBody, que la falta de desconexión, multifuncionalidad, objetivo común, etc., genere que una ves termino «mis» historias, empiezo con otras del Product Backlog en vez de primero pregunta si puedo ayudar a terminar las que están en curso. 

4 – Que en los Dailys se hagan por hacer

Y cosas como la anteriores se evidencian mucho en los Dailys, porque, típicamente, cuando pasan cosas como estas, veremos Dailys en los que los equipos no son conscientes del Swarming, los Dailys son meros reportes al Scrum Master o al Product Owner, los turnos de hablar se estableces «en circulo», etc., y carecen mucho de el secreto de los Dailys en equipos de alto rendimiento.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

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