Tales from the Scrum: cualidades de los miembros del equipo

A veces me preguntan: cuántos desarrolladores senior se necesitan en un equipo Scrum? Yo veo que Scrum puede aplicarse no sólo para desarrollo de software. Pienso que es más interesante, ver algunas características de capacidad y actitud, que he visto en los equipos en los que he trabajado o he visto trabajar.

A) El talentoso: es el desarrollador (o diseñador gráfico, o arquitecto) que se destaca en lo suyo. Todos los miembros del equipo lo reconocen con excelente en su especialidad. Es el que saca las papas del fuego, cuando hay algo que no funciona, y que encuentra soluciones viables y originales a problemas bloqueantes. Su vida es la programación o el diseño, o lo que sea en lo que se destaque.

B) El entusiasta: es quien cada día pone todas las ganas para hacer avanzar el trabajo, el que está dispuesto a aprender algo nuevo, a enseñarlo, a ayudar a alguien con trabas en su trabajo. Está consciente de la dinámica del trabajo y del equipo, y siempre está dispuesto a estar ahí, para apoyar, ayudar en algo, y avanzar en el desarrollo de la etapa.

C) El ordenado: su vida pasa por otro lado (el ajedrez, la música de cámara, la fotografía, la colección de bolitas), y trabaja en el desarrollo de software porque es su medio de vida. Pero es ordenado. Cuando se le pide hacer algo, lo hace bien, o si se traba, informa adecuadamente. Es un pequeño tanque sherman, alguien que avanza, despacio pero sin pausa, y que no se desvía de lo que tiene que hacer.

D) Los demás: los que no tienen talento, tampoco demuestran entusiasmo por lo que hacen, y además, son desordenados: toman un trabajo y no lo terminan nunca, no informan del estado, se desvían a cada momento, y están en la suya. Tampoco demuestran entusiasmo en mejorar.

Varios puntos, para aclarar esta tipología:

- En el equipo, debería haber gente del tipo A, B, C. Si no tienen A, deberían estar disponible alguno, como consultor, mentor, como alguien que ayuda a los equipos, aunque no sea miembro.

- Reconozcamos, son pocos los A. En nuestra profesión, hay gran dispersión de nivel, no todos llegan a A.

- Esto es una tipología, no una clasificación. Una persona no es A o B o C o D, con o exclusivo. No, alguien puede ser A en un tema, B en otro, y D tal vez en otro. Alguien puede ser A en desarrollo, B en diseño de software, pero no dotado especialmente en eso, C en escribir documentación, y D en deployment.

- Cada miembro del equipo, debe, en el tiempo, reconocer en que tipo está para cada actividad que necesita encarar.

- Un junior entusiasta, puede llegar a ser talentoso en un ámbito. Pero muchas veces, el talento se detecta en la etapa de recruiting.

- Si alguien está en D en algún ámbito, debe trabajar para llegar a B o C, y ser ayudado por el equipo. Por ejemplo, si alguien no le gusta documentar y se pierde en esa tarea, debería trabajar su capacidad y sus inclinaciones, para llegar a ser por lo menos ordenado en la documentación que escribe, si no puede llegar a entusiasmarse por la tarea.

- Si alguien está en D en alguna tarea, cuando le toque esa tarea, sería bueno que la comparta, en “pair programming”, con alguien C o B. Si alguien no está entusiasmado por el tema deployment, cuando le toque una tarea de ese tipo, podría hacer par con un entusiasta del tema, o con alguien ordenado, alguien que lo va acompañar para que la tarea se realice y se compruebe, sin desviarse en el camino.

- Esto de trabajo a pares complementarios, se puede extender. Hay veces que tenemos entusiastas desordenados. Gente que pone toda la fuerza en llevar a cabo algo, pero que no se concentran o se desvía o no tiene claro el camino. Puede hacer par con un ordenado o con un talentoso, para que el entusiasmo se encamine por el camino correcto. Muchas de las motivaciones del “pair programming”, el trabajo de a pares, se debe a la compensación de las distintas cualidades de los miembros del equipo.

- Lo más difícil, es cuando alguien con D en un tema, no muestra ni siquiera la inclinación de mejorar en eso con el equipo. Es el caso de la gente que se queja de algo, pero no hace nada para ver en qué puede él mejorar para que la queja disminuya, o qué puede sugerir para que eso mejore. O que siempre rehúye una tarea, poniendo excusas. Es un tema difícil, habrá que ver cada caso en particular. Pero desde ya, hay que disminuir la posibilidad de que haya un D “encallado”, alguien que no quiere salir de esa zona personal suya, para pasar a alguna otra letra. Desde el punto de vista de manejo del equipo, el trabajo de pares puede mitigar el efecto de un “D encallado”.

Pero hay una cualidad que no debe faltar, algo que es fundamental, para que Scrum pueda avanzar: cada miembro DEBE SER UN JUGADOR DE EQUIPO. Debe tener la capacidad y la inclinación (y sino, debe cultivarla) de trabajar en equipo. No hay “prima donnas” en un equipo Scrum. No hay gente que no practique la comunicación. No debe haber “camarillas”, o “yo me corto solo con este tema”. Cada miembro del equipo debería estar al tanto de lo que hacen los demás (de ahí la importancia de la reunión de daily standup).

Antes de clasificar a los demás miembros de su equipo, primero, en qué tipo está Ud, para desarrollo, documentación, comunicación, instalación, comprobación, diseño?

Nos leemos!

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

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

One Response to Tales from the Scrum: cualidades de los miembros del equipo

  1. Elena says:

    Puedo citar como ejemplo de un equipo de trabajo a un equipo de futbol, se necesita un portero, defensas,…Si faltaré alguno es casi imposible ganar. Todos dependemos de todos, y es bueno a potenciar que el A, desarrolle cualidades del B o C y viceversa, si bién cada uno debe desempeñar su papel.

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>