Lecciones aprendidas tras mi primer proyecto como Anchor

Acabo de terminar mi primera experiencia como Anchor (aka Team Leader). Hacer un buen trabajo en este rol era uno de mis objetivos del año 2017, y creo que lo he conseguido. Quizás no haya sido el mejor proyecto para empezar, por varios factores que no vienen al caso, pero en general estoy muy satisfecho con todo lo hecho y aprendido.

Me gustaría recoger en este post varias conclusiones que he ido sacando, así como algunas lecciones aprendidas. A lo mejor os parece que no digo más que obviedades. Bien, llevo trabajando muchos años, y muchas de estas cosas no las he visto poner en práctica tanto como podéis pensar.

Nunca confíes en tu memoria, utiliza Trello

Maldita sea, nunca me había parado a pensar la cantidad de cosas que hay que tener en la cabeza al mismo tiempo a modo de TODOs si no te dedicas 100% al desarrollo. A la semana de unirme al proyecto me dí cuenta de la necesidad de utiliar una herramienta en condiciones para recoger y hacer tracking de todas estas acciones. Trello viene que ni pintado, funciona genial, y hay versiones para todas las plataformas.

No llegues tarde a la standup

Lo más normal en nuestros días es arrancar la jornada con la típica standup, y creo que es muy perjudicial para el equipo si el anchor no llega a tiempo, o directamente ni aparece. A no ser que haya un motivo de peso detrás, por supuesto (hijos, percances en el transporte, etc), no es mi intención aquí iniciar un debate en torno a la flexibilidad horaria o conciliación familiar. En algunos casos quizás tener la standup a primera hora no sea la mejor opción, y pueda moverse un poco más tarde.

Personalmente además, he encontrado muy útil llegar algo pronto a la oficina para planificar un poco el día, antes de que empezara la vorágine, pero esto ya es una preferencia personal.

Da los buenos días

Empieza la standup dando los buenos días a todo el equipo. Algo tan tonto sirve para dar un empujón de moral a tus compañeros, normalmente algo dormidos en ese momento.

Pide las cosas por favor

Solicita las cosas con amabilidad, evita meter prisas, y en caso de que lo que pidas sea relativamente urgente comunica el motivo de la urgencia. Nunca digas algo como “necesito esto para YA”.

Da las gracias

Siempre que pidas algo a alguien, o siempre que alguien se acerque a tí para comentarte algo que ha hecho o alguna idea que ha tenido, dale las gracias para terminar la conversación. O mejor aún, da las gracias y pronuncia su nombre detrás.

Sé empático

Ten empatía con todo el mundo, intenta ponerte siempre en su piel y entender los motivos de cualquier forma de actuar, por rara que sea. Os recomiendo el libro Comunicación No Violenta, donde se trata este tema en profundidad.

Utiliza la crítica constructiva

Cuando creas que alguien ha hecho algo mal, y digo creas porque quizás seas tú el equivocado, dirígete a él con educación, pregunta los motivos de lo que ha hecho, y expón los motivos por los que piensas que no es correcto. Nunca seas tajante, y trata siempre de llegar a un consenso conjunto. Por nada del mundo intentes imponer tus ideas.

Para criticar horrores indiscutibles, utiliza las retrospectivas

Si ves algo en el código que es un horror sin ningún tipo de discusión, saca el tema a colación en la retrospectiva, pero jamás menciones a la persona que lo ha hecho directamente. De hecho intenta no mirar el autor del commit si es posible, para no saberlo siquiera (he re reconocer que es difícil resistirse a esto último…).

Estoy hablando de cosas tan horribles como copy-paste coding a lo bestia, no añadir mensajes en los mensajes de commit…repito, horrores clamorosos. Si se habla abiertamente, aunque alguien se dé por aludido, si comentas el problema con empatía nunca debería haber ningún problema, y todo el equipo aprenderá la lección.

Nunca culpes a nadie

Tanto los éxitos como los errores deben ser responsabilidad del equipo. Nunca, NUNCA, culpes directamente a una persona de cualquier error que haya podido ocurrir.

Ten claros tus principios y valores

Los que me conocéis o venís siguiendo en el blog sabéis que yo pongo la calidad software como uno de los valores fundamentales que hay que mantener en un proyecto. Nunca abandonaré esa idea, y es necesario actuar siempre en consecuencia, incluso habiendo plazos o presiones de por medio. Siempre, repito, SIEMPRE, una escasa calidad en nuestro código terminará repercutiendo negativamente en el coste del proyecto.

Nunca abandones tus principios, es la única forma de sentir orgullo del trabajo entregado por el equipo, por encima de las consideraciones que el negocio pueda tener.

Prepara las reuniones

Dedica un tiempo a preparar las reuniones que convoques o a las que seas convocado. Si surge un tema inesperado no debería haber problema en que te quedes un poco “en bragas”, pero el que sea tema principal de una reunión deberías llevarlo totalmente controlado, y si puede ser, con las dudas que haya que plantear ya preparadas.

Documenta

Sí, documenta, y no utilices como excusa que en Agile no se hace, porque no es verdad. Cualquier proyecto necesita tener un fichero README decente, un diagrama de arquitectura que sirva como punto central de discusión para todo el mundo, etc. No estoy hablando de análisis funcionales (jamás pensé que estas dos palabras aparecerían en mi blog), ni de diseños detallados, sólo de documentación que es necesario tener.

Humildad

La humildad me sigue pareciendo la cualidad número uno que debemos tener en nuestra profesión. El día que la pierda, y espero que no ocurra nunca, me gustaría recibir una colleja a tiempo.