Tales from the Scrum: Armando un equipo automanejado

Ya sabemos que Scrum es un trabajo de equipo. Pero una cosa que diferencia a Scrum, es que el equipo es automanejado. ¿A qué apunta esto? A que el equipo toma decisiones y se mantiene y mejora como equipo, por sí mismo. Por supuesto, con ayuda, de quien quiera ayudar: desde el Scrum Master, hasta mentores, otros equipos e interesados. Pero el equipo toma decisiones en varios puntos del proceso, el principal es el planeamiento del próximo sprint, iteración.

Ya escribí que me parece importante el desarrollo del equipo; es parte del entregable, aunque no lo parezca:

Tales from the Scrum- su equipo, el próximo nivel

Pero muchas veces, el equipo no tiene toda “la salud” para auto manejarse, o sus miembros vienen de otros ámbitos donde no se fomentó esta actitud. Veamos algunos puntos a revisar, para mejorar en estos puntos.

Primero:

Deje de hacer esto

- No dejar que los participantes del equipo participen en todas las etapas del ciclo de desarrollo. Cuanto más se involucren en todas las actividades, como reuniones con los clientes, planeamiento, toma de requirimientos, diseño, mejor. No todos tienen que estar en una reunión de diseño. Pero hay que ir viendo de que todos los miembros, en algún momento, hayan tomado parte de alguna de las actividades. Un anti-pattern: sólo “los principales” miembro del equipo asisten a al reunión de cierre de Sprint. Si cada miembro del equipo participa de cada actividad, en algún momento del proyecto, verán de embeberse más del proyecto y del proceso, en vez de encerrarse en su zona de confort o “expertise”.

- Asignar tareas a los miembros: es común que alguien vaya asignando tareas a algunos miembros. Hay que dejar de hacer eso. Hay que fomentar que los miembros del equipo vayan tomando tareas, por propia cuenta. Y promover que cada miembro de equipo no se centre sólo en lo que sabe. El especialista en base de datos puede participar de una tarea de diseño de interfaz de usuario, tal vez ayudado por “pair programming” con otro miembro que conozca del tema. Esto permite que los miembros vayan interactuando, conociendo las debilidades y fortalezas de cada uno, y ayudándose y aprendiendo unos de otros al mismo tiempo.

- Decir para cuándo tiene que estar tal tarea lista: hay que recordar que esa es una decisión del equipo, en Scrum. Claro que se espera que el equipo vaya mejorando en la estimación de los tiempos y en la velocidad de avance. Pero es una decisión de los miembros del equipo cuánto tiempo necesitan para terminar con una tarea. Se podrá discutir qué hace falta para avanzar más rápido, qué cambios hacer para mejorar en eso, pero la decisión del tiempo es del equipo. Si Ud. no deja esta decisión en el equipo, no logrará que avance en las cualidades de autogestión.

- En la reunión de planeación de sprint, las tareas propuestas por el producto owner, son aceptadas sin mayor discusión, o sin evaluar si se pueden conseguir en tiempo en forma. Esta es una variante del anti-pattern “asignar tareas”. Una de las funciones principales de la reunión de planeamiento, es que el equipo (no uno, o dos miembros), discuta y tenga en claro los pasos y esfuerzos estimados para cumplir con lo que el product owner pide. Es común (y no debería serlo) que se tome eso tal cual, sin discusión, y sin haber pasado en limpio lo que implica comprometerse a realizar esas tareas.

- Saltearse las retrospectivas: no hay tiempo, siempre se posponen. No: pare de olvidarse de esta reunión. La retrospectiva es una actividad, yo diría fundamental, para que el equipo madure y mejore. Es un “parar la pelota”, ver para atrás, y señalar qué se hizo bien, regular, o simplemente mal. Y, aun más importante: en la reunión se decide qué hacer para mejorar.

Segundo:

Comience a hacer esto

- Limpie el camino para el avance. Haga que el equipo pueda avanzar, y quite los bloqueos que encuentre. Puede ser desde falta de hardware, hasta temas políticos de relación con otros departamentos. Eso permitirá que el equipo se concentre en lo que tiene que hacer, más que luchar con la fricción y los impedimentos. Cuando el equipo esté más maduro, podrán los propios miembros del equipo ocuparse de esto, tal vez rotando en la tarea por Sprint, pero al principio, habrá que permitir que el equipo crezca, sin tener que lidiar tan directamente con estos problemas.

- Sea un facilitador y mentor. Como facilitador, vaya por el anterior punto. Como mentor, observe, comente, señale la actividad y actitud del equipo, proponga mejoras (no las imponga), sea un entrenador de cada persona, reconozca en qué son buenos, en qué son regulares, y trabaje con ellos para ir mejorando.

- Mida el avance. El equipo se auto organiza, pero comience a medir el avance, y difundiendo esa medición. Esto hará que el equipo tenga una imagen de cuán bien o mal están yendo. Cualquier desviación del plan de trabajo, debe surgir lo más pronto posible, para que el equipo autoorganizado pueda detectar el problema, la causa, tomar una acción correctiva, y aprender a no caer de nuevo en ese paso.

En un equipo maduro, cada miembro se ocupará, casi automáticamente, de estos puntos. Pero al principio, habrá que cultivarlos activamente. Con el tiempo, llega el momento en que el equipo “cuaja”: comienzan a entrar en pista, a ganar confianza, a ver que la forma de trabajo que eligieron funciona, y entran “en flujo”: una forma continua, rítmica, de avance, hacia el objetivo final.

Varios de estos puntos los tomé, e interpreté y comenté a mi manera, del post:

How to Build Self-Managed Teams

Imagen tomada de: http://www.skyjump.com/Pages/SkydivingPhotosVideos.html Photo by Phil Robertson

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 2752, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>