Tales from the Scrum: Ser easy to work with

Ya sabemos que el avance en Scrum es un trabajo de equipo. Como miembro del equipo, uno tiene que colaborar con los otros miembros para conseguir que el trabajo avance. Una de las cualidades que deberíamos perseguir, para cada uno de nosotros y para el equipo, es lo que en inglés se escribe “easy to work with”: que los demás perciban que es fácil trabajar con nosotros.

Como otros conceptos, puede ser más fácil describirlo con algunos ejemplos negativos:

Si uno llega tarde a las reuniones diarias, reiteradamente y sin buenas razones y no avisa, eso no es ser “easy to work with”.

Si uno hace una tarea y no informa que la terminó, o en qué estado la dejó, el resto del equipo no podrá aprovecharse de ese resultado, y Ud. no será “easy to work with".

Si Ud. codifica algo, y lo envía al repositorio de código, y está mal escrito, de forma que cualquiera que tome la última versión, encuentre una solución que no compila, eso es no ser “easy to work with”.

Si cada tarea que Ud. termina, al revisarse para verificarla, se encuentra que tiene muchas correcciones a hacer, y esta situación se repite, entonces, Ud. no será “easy to work with”.

Si lo que escribimos produce un aumento en las infracciones de Code Analysis, y otro tienen que pasarse un tiempo corrigiéndolas, y eso se repite, entonces no seremos “easy to work with”.

En definitiva, si alguien, con su trabajo, produce un montón de trabajo EVITABLE en los demás, ese alguien no será “easy to work with”.

Si alguien es así, a la larga pasará que nadie va a querer trabajar con él, y no confiarán en lo que produzca.

Lo mismo puede pasar a nivel de equipo. Si como equipo entregamos la nueva versión del software al final del Sprint, y el cliente no tiene instrucciones para instalarlo, o tiene que armar una máquina virtual durante dos semanas para poder ejecutar lo que entregamos, no seremos “easy to work with”. La solución: ir mejorando en cada Sprint, para que lo entregable sea fácilmente consumible, por ejemplo, dándole una máquina virtual ya armada, y el software e instrucciones para correrla.

Pero aparte de estos temas técnicos, hay temas de cualidades de relación con los demás, de los “soft skills” tan importantes en todo grupo. Veamos algunas cualidades para ser “easy to work with”:

- Sea flexible. Si Ud. no es ágil para actuar en un ambiente cambiante, con requerimientos que se van modificando, tendrá problemas. Si Ud. es un cabezón que siempre cree tener la razón, y si no se la dan, se empaca, también tendrá problemas. A veces, hay que ser flexible, entender a los demás, y ver que no siempre se puede seguir el camino que a uno le parece mejor. Explore nuevas formas de hacer las cosas, no rechace algo de antemano solamente por que sí.

- Sea un buen comunicador: no es indispensable, pero es bueno tener buenos comunicadores en el equipo. He visto buenos miembros de equipo, callados, pero que compensan esa escasa comunicación, siendo un “tanque Sherman”: gente que toma una tarea, y la termina, sí o sí y con calidad. Pero volvamos a la comunicación: es importante, porque no todo es código. Recordemos que lo que hacemos lo tenemos que mostrar, tenemos que informarlo, tenemos que interactuar con los clientes. Si todo lo que hacemos es maravilloso, pero no lo comunicamos, es como si no lo hubiéramos hecho. A veces, uno piensa que armar una presentación es una pérdida de tiempo, pero no: puede ser la pieza clave que falta para conseguir apoyo de los interesados en el proyecto. Si Ud. es un buen comunicador, otras partes (otros equipos, product owner, stakeholders, clientes, usuarios) querrán interactuar con Ud. Y será alguien “easy to work with”, no un erizo a evitar.

- Esté disponible. No hace falta estar disponible 24 horas, 7 días. Si el equipo se organiza, se debería organizar todo para cinco días a la semana, y 10 a 18hs. Pero en ese tiempo, si alguien necesita su ayuda, tenga planeado tiempo libre para poder ayudarlo. En la reunión diaria no tiene que comprometer las 8hs de trabajo: es de profesional, reconocer que hay tareas que pueden surgir, y reservar entonces tiempo para esos casos que pueden aparecer en el transcurso del día. Cuando alguien vaya a preguntarle algo o a pedirle ayuda, irá con la expectativa “Fulano me va a ayudar”. Otra forma, indirecta, de estar disponible, es haber escrito instrucciones de cómo usar algo, o dejado información sobre lo que uno hizo. Por ejemplo, si Ud. diseñó un parte del sistema, si alguien quiere preguntarle sobre una decisión de diseño, puede hacerlo, pero si no está disponible (está enfermo, de vacaciones), que por lo menos pueda encontrar fácilmente un documento (no tiene que ser extenso ni “fancy”) que explique lo que hizo.

- Sea positivo: Si cada vez que abra la boca, es para tirar abajo algo, pasarán dos cosas: la gente lo evitará, o dejarán de tomarlo en cuenta. “Ahí viene el tiramerdis” pensarán cuando lo vean venir. No confundir una actitud positiva con un “está todo bien” a ultranza. Hay que reconocer los problemas. Solamente hay que ser también, parte de la solución, o por lo menos, ayudar a que en equipo consigamos la solución. A quién quiere tener al lado al naufragar en una isla desierta? Alguien que diga: “Viste, yo te dije que no teníamos que venir, ahora está todo mal, no me hicieron caso…”, y se pase todo el día lamentándose así, o a alguien que diga: “Tenemos un problema, veamos como lo podemos solucionar”.

- Sea honesto: si Ud. ve un problema, o tiene un bloqueo, o no sabe como encarar una tarea, dígalo. En el equipo tiene que reinar la honestidad y la comunicación. Acá no se busca castigar al que no sabe o no tiene tal capacidad. Si hay un problema en ciernes, lo mejor es comunicarlo. Si ve que hay algo mal en el equipo, dígalo. Pero también combine esto con todo lo de arriba: comuníquelo bien, sea positivo, no señale con el dedo a personas sino a problemas, vaya con algún atisvo de solución.

- Diviértase: nadie quiere a un “caracúlico” al lado todo el día… :-)

Habría tanto para comentar. Pienso que en todas las relaciones, más allá de un equipo de Scrum, tenemos que ir cultivando el ser alguien “easy to work with”. Ud. puede ser el gran gurú en un tema, pero estará solo y no conseguirá nada, si los otros no ven en Ud. alguien en quien pueden confiar, alguien con quien sea fácil trabajar.

Para las últimas cualidades, consulté y expuse a mi manera, lo del post:

Be easy to work with

Nos leemos!

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

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

3 Responses to Tales from the Scrum: Ser easy to work with

  1. Jajaja… excelente Angel. A veces ser autocríticos para reconocer que no somos “easy to work with”, cuesta…

    Espero que este artículo haga reaccionar a muchos. Al final será mejor sentarnos y pensar un rato, a quedarnos fuera de cualquier grupo.

    Un abrazo, Omar

  2. No se qué pasó con mi comentario.. se perdió, no ha sido easy to work with.. ;)

    En fin, excelente artículo, solo eso.. felicidades…

  3. Muy buen post. Me hace acordar a la expedición de kon tiki (http://es.wikipedia.org/wiki/Kon-tiki_(expedición)), quienes cruzaron el pacífico en balsa. Lo curioso es que el líder de la expedición no seleccionó marineros, todo lo contrario, buscó gente con perfiles variados pero que sobre todo se llevara bien. Es decir, priorizó ante todo el easy to work.

    saludos!
    pd: Otras similitudes entre metodologías ágiles y el mundo de la aventura http://toclasaas.blogspot.com/2009/07/agilidad-y-equipos-de-trabajo.html

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>