Nuevamente en las trincheras del trabajo remoto

Si pues, de momento dejaremos nuestra tónica habitual dedicada a la nube y DevOps para comentar algo que, junto a la cuarentena, ha sido uno de los tópicos en estas semanas: el teletrabajo, trabajo remoto, home office, y similares, que no son lo mismo, hay matices, pero no son sujetos de lo que vamos a ver.

Digo de vuelta, porque para mi no es la primera vez que tengo que pasar por estas circunstancias de desarrollar mi trabajo lejos de mis colegas/clientes/proveedores etc, que es básicamente la situación en la que nos encontramos ahora, para lo cual me basare en mi experiencia personal, que si bien no es la fuente de la verdad única me ha permitido extraer algunas conclusiones que espero sean de utilidad.

Mi primera experiencia fue cuando, transicionando entre proyectos, se me pidió hacer una propuesta comercial para la consultora española en la que me encontraba, me tomo alrededor de una semana el completarla, y la primera vez si que fue complicado, pues estar en mi habitación ponía cerca la disponibilidad de reposar un rato y no enfocarme en mis responsabilidades, pero aun así el documento salió adelante y le gusto a mis jefes, pero desde ese entonces me quedo clara la importancia de separar el ambiente de trabajo del de tu reposo, solo que entonces no era posible pues alquilaba habitación.

La segunda situación, intermedia, correspondió a cuando, al regresar a España desde Sudafrica, tuve que hacerme cargo de un equipo de desarrollo en Madrid, pero por la naturaleza del proyecto, se tenían que hacer coordinaciones con el equipo en Joburg, en ese momento las cosas estaban bastante limitadas:

  • No había nube
  • Las transferencias por VPN eran lentísimas
  • Los servicios de voz por IP eran poco fiables

Aun así, logramos adaptarnos, los correos eran muy fluidos, y eventualmente tenia llamadas interdiarias con el QA en Joburg, pero lo de compartir pantalla sencillamente no era viable. Felizmente esas limitaciones ya son historia, pero queda como punto claro la importancia de la disponibilidad de buenos canales de comunicación para los equipos.

La tercera experiencia fue cuando me tuve que hacer cargo de gestión y mantenimiento de varias aplicaciones para la sede española de una multinacional de investigación de mercado, en este caso sí que estaba en la sede del cliente coordinando con la gente de infraestructura y los usuarios, pero tenía que coordinar y asignar tareas a alguien trabajando en la India, el problema es que las formas de asegurar el entendimiento por ambos lados nunca se formalizaron, ya que tiempo después me di cuenta de que cuando preguntaba “Do you understand?” la respuesta de “yes” casi nunca era cierta, amén de que habiendo posibilidad de usar Webex para efectuar las comunicaciones, o chat para cosas urgentes, mi contraparte prefería llamadas por teléfono convencional (con menor calidad de audio), lo cual sumado al hecho de que estaba en un proceso cross o multiprojecto, no permitía un flujo adecuado en el desarrollo de nuestras actividades, esto, en retrospectiva hace clara la importancia de definir o setear los “protocolos” y canales que se usaran para las comunicaciones, y en todo caso generar “actas” que aseguren el entendimiento común de las conclusiones de la reunión.

En los siguientes años la experiencia fue mas frecuente, de la mano con mi regreso al Perú y al trabajar en la mayoría de los casos en proyectos que trataban de seguir marcos agiles, pero con la peculiaridad de que nuestros clientes estaban fuera del Perú, no siendo raro que la mitad del equipo estuviera en Lima, y el resto en otro país (Costa Rica, Argentina, España, USA) solo que en este caso se mezclaba la peculiaridad de ir unos días a la oficina, y a veces trabajar desde casa, por lo que las lecciones en este caso son variadas:

  • Si quieres poner a tu equipo en una sala (para hablar con la otra mitad del equipo), asegúrate que has validado bien el alcance de tus dispositivos para no tener a tu gente gritando.
  • Tener dos pantallas es bueno, pues por un lado ves a tu contraparte, y en la otra pantalla están ambos haciendo el code review o similar.
  • Por otro lado, una segunda pantalla también tiene el riesgo de que ayuda a no ponerle total atención a la reunión en curso.
  • Saber que tienes a tu contraparte a un clic de distancia para tener un chat, y de ser necesario una llamada, ayuda mucho a generar una sensación de equipo pese a la distancia.
  • Una cultura de Pull Request y aprobación/rechazo rápido ayuda mucho, mucho.

Mención aparte es un problema sobre el cual no he tenido mucha respuesta que ayudara en algo, y es el tema de las Retrospectivas cuando tienes equipos distribuidos (ya sea en casa o en distintas sedes de trabajo), pues cuando empecé con esto de los marcos ágiles, casi todas las dinámicas que se enseñaban o comentaban partían del supuesto de tener todo el equipo en un mismo sitio (recuerdo un libro de varias dinámicas muy interesantes, pero ninguna orientada a equipos distribuidos), que si, que habían herramientas para ayudar en el tema, que básicamente te permitían escribir tus comentarios (Que se hizo mal, Que se hizo bien, Como mejorar) de manera oculta y luego destaparlos, lo que ocasionaba que las retros terminaran convirtiéndose en un Dia de la Marmota.

Si recordamos lo que aprendimos en agilidad, mucho se basa en el ir aprendiendo, evolucionando, mejora continua y todo eso, siendo que si una actividad se vuelve repetitiva… poca ganancia se puede sacar. Una de las pocas mejoras que conseguí en un equipo fue que se rotara al facilitador, lo cual logro que el diferente “estilo” cada vez lograra un mayor dinamismo por parte del equipo, pero eso no es suficiente; así que en esa época en la comunidad consulte a diversos coaches, y gurúes que venían a compartir sus conocimientos y experiencia (en algunos caso muy valiosos), obteniendo generalmente miradas al techo… y alguno en algún arranque de sinceridad me dijo que siempre en sus clientes había trabajado con todo el equipo de manera presencial, y claro es que los equipos que trabajamos offshore nunca habíamos sido el “blanco” de sus actividades, situación que ahora veo que cambia a toda prisa, debiendo improvisar en campos en los que no habían incursionado, ojala que en esta ocasión se escuche a quienes han tenido experiencia real en este aspecto y que hayan podido resolver este impedimento (*).

En todo caso, lo que he comentado hasta el momento tenia una peculiaridad muy muy fuerte, y es que estos equipos en los que participaba estaban orientados hacia un único proyecto/producto, por lo que siempre se tenia el foco de manera clara, pero mi situación actual es diferente, y se podría decir que estoy en un proceso de aprendizaje.

¿Por qué? Desde hace un tiempo he asumido un rol de arquitecto cloud, lo cual por su naturaleza obliga a trabajar en varios frentes de batalla a la vez: revisión de iniciativas para su aprobación, apoyar proyectos en curso, coordinar actividades con otras áreas para establecer algo en conjunto, etc., un reto interesante que obliga a tener otro tipo de orden, en el cual te acostumbras a las charlas de pasillo y a sacarle partido a ellas para aprender mas de los distintos contextos con los que hay que lidiar.

El detalle es que cuando pasas de golpe a un escenario de Home Office colectivo, todos pasamos a un proceso de aprendizaje, reinventando reglas, nuevas formas de coordinar, a lidiar de otra manera con el context switch, con la gestión de las agendas, es un camino que vamos empezando, del cual espero dar conclusiones u opiniones mas definitivas como las he dado para mis escenarios anteriores.

¿Y uds? ¿Qué experiencia o buenas practicas pueden compartir respecto al trabajo distribuido o remoto?

(*) Me comentan que en los últimos dos años han surgido herramientas que ahora si apoyan el poder hacer una buena retro con los equipos distribuidos, soy todo oídos.

Agilidad al borde del nuevo año

El 2019 se cumplirán 10 años que estoy metido en estos temas de la agilidad, escena/movimiento que ha ido cambiando y readapatandose con una velocidad asombrosa, cayéndose, aprendiendo sobre la marcha, generando cuestionamientos, así que este fin de año es una buena ocasión para repasar algunas de las cosas que se han visto en este año en este entorno y comunidad.

Una de las cosas que afecto la escena agil mundial en los primeros meses del año fue el asesinato de Mike Beedle, firmante del Manifiesto, el cual poco antes había publicado esto

 

Reflexión totalmente valida (sumada a otra en la que proclamaba “arreglar” Scrum para seguir avanzando *) en un contexto en el que se hizo énfasis el ver la agilidad como algo solo organizacional y/o cultural, olvidándose de que el pilar técnico es importante el proceso de desarrollo de software, lo cual de la mano con el omnipresente “cargo cult” derivo que el rol mas demandado el año pasado y principio de este fuera el de Agile Coach y derivados, es que claro, si se quiere seguir escalando ser Scrum Master ya no es suficiente.

La consecuencia de ese boom fue que se empezó a dar una imagen de que para lograr hacer cambios hacia la agilidad lo importante era tener buenos coaches (externos, claro esta) y Scrum Masters, que no tenían porque entender (que no es lo mismo que ser expertos, ojo) las complejidades del desarrollo de software en un problema en concreto, sino en procurar la búsqueda de la felicidad de los equipos, y si al final del PI se tenia un bonito tablero frente al que sacarse fotos, mejor que mejor… y claro, este fenómeno se replico en las comunidades y eventos, generando una saturación del tema coach y relacionados, olvidándonos de como hacer bien software (en un momento en que todos p. ej. quieren hacer microservicios porque esta de moda, y no hay quien les pare la mano).

Este problema, porque hay que reconocer que es un problema, derivo en otros dos fenómenos relacionados, por un lado los mas hardcore empezaron a sentir que ya no tenían su lugar en la agilidad por lo que procuraron consolidar espacios para hablar en profundidad de los temas de software, y por otro lado el empezar a apuntar que algo esta mal, lo cual se hizo mas evidente con el ya famoso discurso de Martin Fowler en Australia, donde básicamente instaba a afrontar los siguientes retos:

  • Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
  • Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
  • organize around products.

Ah si! porque me olvide de algo, es que durante este tiempo (junto a los coaches) no falto quienes se subieron al carro para venderles a las empresas (ansiosas de comprar, hay que decir) el como volverse ágiles, pero para variar, aplicando estrategias top down que generalmente dejan intactos los esquemas, pero claro, queda muy bien decir que se esta muy involucrado con la agilidad por ir contratando varios SM y coaches.

El discurso de Fowler tuvo su impacto (por ejemplo la respuesta de Uncle Bob) a nivel global y debate a nivel de la comunidad, en la que si por un lado se paso a revalorar (**) la importancia técnica en el desarrollo de software, por otro lado se ha dado una vuelta de tuerca con el mensaje de que “Agilidad no es Agile”, que Agile solo es a nivel de software, que agilidad va mas allá, “esto no lo logras  en la agilidad de equipos”; todo este nuevo buzz me parece que puede salirse de control, pues empuja la idea de que esto de lo que hemos tratado de hablar en estos años solo corresponde al “nivel estratégico”, lo cual termina dando un carácter secundario a objetivos como los de empoderar a los equipos y sus miembros o valorar el trabajo real sobre la imagen … , suma esto al hecho de afirmar que los coaches requieren “espacios seguros” para perfeccionarse, y tenemos una receta perfecta para segmentar a una comunidad que debería empujar un proceso de construcción colectiva.

Hay esperanzas, por un lado algunas organizaciones ya no están cayendo en la búsqueda de coaches (o SM) al peso, sino valorando sus meritos per se, aunque claro… el cargo cult terminara buscando nuevas figuras para asegurar la relevancia cuando un termino ya dejo de ser cool; por otro lado esta nuestra responsabilidad y consciencia de asegurar que los tópicos vinculados a la excelencia en nuestros ámbitos de dominio sigan presentes, y eso es tarea de todos en la que seguiremos.

(*) Lo cual hace inevitable recordar el como hay quienes saltan diciendo “eso no es Scrum” cuando ven que algunos equipos han evolucionado a practicas que les son mas eficientes en su contexto, pero que ya no siguen Scrum al pie de la letra.

(**) Por ejemplo en el HT #PorfaArgentina salto la importancia de asegurar espacio para el contenido técnico en el próximo Ágiles 2019.