En nuestra experiencia trabajando con equipos de desarrollo de producto, en una amplia variedad de sectores, vemos que se repiten los mismos problemas, una y otra vez. Independientemente del país (trabajamos con equipos en diferentes continentes), del stack tecnológico, estos son problemas endémicos de los desarrolladores de producto, ya sean startups o empresas consolidadas. La realidad es que no existe la perfección, siempre vamos a encontrarnos un cierto nivel de caos. Vamos a ver cuáles son los puntos de dolor comunes y qué podemos hacer al respecto.
El “time to market” suele primar sobre todo lo demás, aun cuando no hay manera de justificar la fecha de entrega elegida para un determinado lanzamiento. Así pues, la gente hace lo que puede y trabaja como sabe, cada cual se centra en lo suyo para intentar ser lo más eficiente posible. Paradójicamente, el resultado suele ser el opuesto, ya que, como bien hemos aprendido de lean manufactoring, los intentos por optimizar partes aisladas merman la eficacia del sistema en su conjunto.
La vorágine del día a día nubla la visión del medio y largo plazo; cuesta mucho darse cuenta del impacto de las acciones cotidianas, tanto en el código, como en las relaciones. Pocos equipos tienen la madurez y la disciplina de hacer una gestión deliberada de la deuda técnica, así como de planificar cambios de arquitectura, de diseño, o mejoras en la calidad.
La sensación de urgencia permanente deja poco espacio para reflexionar sobre actitudes, hábitos, técnicas o procesos. Como consecuencia, hay poco margen para la mejora del equipo y del producto, lo cual produce estancamiento. Con frecuencia, esta sensación de urgencia y de prisa es autoimpuesta, es una inercia, sin fundamento real detrás. De hecho, en estos ambientes llega un punto en que ni nos damos cuenta del ritmo frenético que llevamos ni de la ceguera mental que nos induce.
Por otro lado, aquellos grupos que tienen un rendimiento sobresaliente se distinguen, justamente, por su eficacia trabajando como equipo. No es el código fuente lo que diferencia a un equipo de otro, sino la habilidad de mejorar continuamente. Un equipo solo evoluciona cuando las personas que lo forman evolucionan. Así pues, para alcanzar un alto rendimiento, hay que trabajar de manera deliberada las dinámicas de equipo y el desarrollo de los individuos. La evolución no llega por arte de magia, es el fruto de un trabajo específico, deliberado.
Una de las consecuencias de olvidarnos de los pequeños detalles que humanizan el trabajo, en el día a día, es la pérdida de sensación de pertenencia al grupo. La desconexión de las personas que no se sienten cuidadas, o con un futuro próspero en la organización, termina con su marcha a otro equipo, a otra empresa. Es cierto que el dinero es un buen incentivo para el cambio, sin embargo, muchas personas se mueven porque no se sienten suficientemente valoradas o reconocidas. La cultura del cuidado de las personas y de las relaciones, se construye con acciones, con hechos, no con palabras. Si los valores de la organización no son explícitos, o no se demuestran con autenticidad e integridad en las acciones, no habrá conexión con las personas.
Cuando alguien se marcha y acumula mucho conocimiento del negocio y del código, la situación puede convertirse en una tragedia. La salida de este tipo de perfiles tiene un coste económico altísimo para la empresa, así como un coste emocional para las personas que se quedan. La marcha de talento genera una sensación de incertidumbre que en ocasiones dispara la salida de más personas.
La rotación de personal es un fracaso en la relación y todas las partes involucradas son corresponsables del mismo.
Al igual que la salida inesperada es dolorosa, la llegada de nuevos compañeros y compañeras suele ser estresante, tanto para quien llega como para quien está. Es que, además de las tareas del día a día, alguien tiene que explicar todo a los nuevos, intentando que se sientan bien recibidos. En la mayoría de los equipos no existe un manual de onboarding, ni videos ni documentación de ningún tipo que explica la cultura. La gente nueva se adhiere como puede, haciéndose una idea muy sesgada de la empresa y del equipo.
Los equipos con una cultura fuerte, con valores y principios bien definidos, sufren menos los onboardings, ya que preparan la dinámica de manera explícita, documentan y pulen el proceso con cada incorporación. Además, resulta más fácil enseñar con el ejemplo y aprender por imitación.
En los ambientes caóticos en los que la gente tira para adelante como puede, suelen formarse naturalmente islas de conocimiento, porque la gente siente que no tiene tiempo para nada más. Es pura inercia. Según qué problema surge, se suele recurrir a una persona, o a otra, para que lo solucione. Siempre hay alguien que se termina sobrecargando de responsabilidades, a quien todos llaman cuando hay algún problema complicado. Esta persona vive con mucho estrés y sin querer, impide que los demás crezcan, porque no delega. A este rol le llamamos el héroe quemado.
Hay que darle apoyo a estas personas, así como formación en habilidades no técnicas; liderazgo, gestión, comunicación…
Hay que fomentar la colaboración para que el conocimiento se comparta y que cualquier persona pueda trabajar en cualquier parte del producto.
Por más que la empresa o el equipo quiera que haya una estructura organizacional plana, la formación de estructuras jerárquicas es natural en los grupos humanos (y en otras muchas especies). Aunque no haya figuras con poder oficialmente reconocido, es inevitable que emerjan roles con cierto poder y cierta autoridad. Lo deseable es que la autoridad proceda de la capacidad de liderar, sin embargo, con frecuencia no es así. La autoridad suele adquirirse por la antigüedad, por los méritos pasados, el carisma… Entonces aparecen los cultos del cargo (”aquí las cosas se hacen así”). El inconveniente de estas estructuras es que dejan poco espacio para otras voces. A la gente que no tiene esa autoridad de facto, le cuesta aportar sus ideas, participar. Su talento se infrautiliza. Unos pocos acaparan la atención, definen la estrategia y toman decisiones, aunque nadie lo haya predispuesto así de manera explícita. El resultado es que hay personas con un alto nivel de responsabilidad, tomando decisiones y gestionando, sin tener formación específica para ello. Para ellas puede resultar muy estresante, para las demás puede resultar asfixiante y para la organización puede suponer un desvío en la misión, así como una limitación.
Hemos observado que en las culturas sanas se ocupan de definir de manera explícita roles, responsabilidades y acuerdos de equipo. Las estructuras se hacen explícitas y con un propósito.
Dice Daniel Pink que la maestría es uno de los tres pilares de la motivación. Maestría se refiere al camino del aprendizaje, el que te conduce al dominio de una técnica, o área de conocimiento. Efectivamente, muchas personas atenúan su motivación porque no ven un camino para progresar profesionalmente. Hay que planificar el desarrollo personal de manera explícita, individuo a individuo, para que ese pilar de la motivación sea fuerte.
Esta es una derivada común de los silos de conocimiento y de la aparición de heroicidades innecesarias. La gente quiere hacer su trabajo lo mejor posible, a veces hasta el punto de no darse cuenta de que los demás también quieren lo mismo, y no les están dejando. Es aquí cuando surge el conflicto, supertípico, entre product owners y developers (entre negocio y desarrollo). Dicho conflicto se resuelve mediante la empatía, la asertividad y la inteligencia emocional. Para ello recurrimos a prácticas como las retrospectivas, facilitadas por personas con mucha experiencia. Hay que trabajar la confianza en los demás, eliminar las suspicacias y trabajar la comunicación no violenta. La agilidad nació con la aspiración de reducir la brecha entre negocio y desarrollo, sin embargo, más de dos décadas después, seguimos teniendo grandes brechas en todo tipo de organizaciones, independientemente de que utilicen métodos como Scrum o Kanban.
Se suponía que en remoto íbamos a ser más productivos, sin embargo, las notificaciones permanentes están matando la productividad, no dejan margen para los espacios de foco. Las mejores ideas aparecen cuando la concentración es plena. El mejor código se escribe cuando ponemos toda nuestra atención en ello. Desgraciadamente, vemos cada vez más equipos que viven esclavizados a las notificaciones de Slack/Teams/Meets, Telegram, Whatsapp, Twitter,… Estamos viviendo la época de la productividad en ruinas. El origen está en el deseo de mantenernos disponibles en todo momento para ayudar a los demás. La intención es buena, pero el resultado es muy contraproducente. La interrupción constante eleva los niveles de estrés. Hay mil formas de corregir esto, el primer paso es darse cuenta de que hemos perdido el control de nuestro espacio de trabajo. Luego podemos establecer acuerdos de equipo explícitos, que permitan satisfacer las dos necesidades. Hay mil formas de ayudar y a la vez estar en foco, por ejemplo practicando pair programming o mob programming.
La falta de foco dinamita incluso las reuniones. Cada vez es más frecuente entrar a reuniones por videollamada, en las que vemos a la gente intentando simultanear el chat, el email, etc, aun cuando nuestro cerebro solo tiene un core, es imposible hacer multitarea. El resultado son reuniones pobres, aburridas, y personas que no se sienten escuchadas. Se merma la autoestima e incluso se añora la dignidad. Los acuerdos de equipo también deben abordar la cultura que tenemos sobre las reuniones; ¿cuántas hacemos, cómo las hacemos?
Los humanos somos capaces de acostumbrarnos absolutamente a todo. Prueba de ello fueron los guardias de los campos de exterminio del holocausto, o simplemente, la rutina de trabajo en un matadero. El proceso de acostumbrarnos lleva tiempo; primero nos quejamos hasta N veces de disfunciones y de incomodidades. Luego vamos insistiendo con menos fuerza y menos fe cada vez, hasta que lo asimilamos y hasta nos olvidamos de que están ahí. Es como un mecanismo de defensa que nos permite centrarnos en las áreas en las que creemos que podemos aportar más. Es realidad es útil, para no quedarnos paralizados en lo que no funciona. El tiempo pasa y se termina perdiendo la esperanza de que ciertas cosas cambien. Por eso, en mi opinión, no es sano que un mismo equipo se mantenga con las mismas personas durante años. No en nuestro sector, donde tenemos que renovarnos con mucha frecuencia. Una pizca de rotación (sea con personal interno o externo), aporta una mirada fresca que se atreve a señalar puntos de mejora obvios y altamente rentables, así como energía e ilusión para trabajar en ellos.
Es muy común que un equipo de desarrollo desbordado y magullado por el código legado, pida un gran reset. Es la solución más aclamada ante la desesperación, volver a empezar el proyecto de cero. Reiniciar el desarrollo no suele ser la opción más realista ni más rentable. Sin embargo, este hito es información relevante, pues indica que muy posiblemente ha llegado la hora de pedir refuerzos externos.
Si bien es cierto que cada día hay más profesionales bien preparados en materia de agile coaching, en métodos como Scrum, Kanban, o simplemente facilitación y sentido común, aún se encuentran con resistencia en algunos equipos de desarrollo. Si la figura de agile coach no sabe programar, o lleva muchos años sin hacerlo, puede que arranque con menos credibilidad y menos respeto al trabajar con un equipo técnico, al animarles a trabajar con buenas prácticas de ingeniería. La mejor forma de liderar es mediante el ejemplo, por tanto, a veces hace falta remangarse y sentarse a programar en pares o en mob. Desde mi punto de vista, alguien que trabaja de agile coach podría basarse en XP también, pero no suele ser lo común. Cuando se provee de entrenamiento en XP, se suele hablar de technical coaching. Hay que entender la terminología que se usa en cada sitio. Para mí agile es XP, pero cada vez observo que más developers piensan en agile como metodologías de gestión, alejadas de lo técnico. Hay ciertos prejuicios. Sinceramente, no creo que la figura de agile coach requiera necesariamente conocimientos de programación, dado que en las organizaciones hay muchísimo trabajo que hacer a nivel de comunicación y facilitación (pero mucho mucho). Lo que quiero decir es que en algunos lugares hay una fricción, además de una necesidad de entrenamiento en buenas prácticas técnicas.
Pocas cosas nos frustran y desesperan más que un bug que reaparecen en producción cada cierto tiempo. Los bugs son tediosos cuando somos usuarios. En cierto modo, estos defectos que regresan cada cierto tiempo dejan en evidencia la pericia técnica del equipo. Son muy malas credenciales y merman la confianza de cualquier stakeholder. Aunque cualquiera puede entender un error humano, también es cierto que la reiteración del mismo fallo produce desesperación. En un puesto de gestión de alta responsabilidad, una error reiterado puede ser motivo de despido, fácilmente. En desarrollo la gente se resigna al fallo reiterado, pero es igual de fastidioso. Si un bug en producción es caro, los errores regresivos lo son aún más.
¿Cuántos equipos de producto son esclavos de un stack tecnológico obsoleto? Muchísimos, demasiados. Ya sea por un lenguaje de programación antiguo (como COBOL), una versión del lenguaje antigua (como Java 1.4), una versión de framework antigua (como Struts, Angular.js, WPF…), una infraestructura antigua (como instalaciones on premises, SOAP…). También pasa por depender de tecnología propietaria que ha envejecido muy mal (no citaré a ninguna empresa, pero suelen ser empresas muy grandes y pesadas). Es tecnología que han intentando parchear para que parezca moderna, pero que ni siquiera se presta a ser sometida a unit testing. Otro escenario es el de haber adoptado un ERP obsoleto o cualquier tipo de integración con una herramienta propietaria que se ha quedado obsoleta.
La falta de modernización tecnológica suele ser causada por falta de conocimiento para escribir código desacoplado, así como falta de tiempo para planificar y ejecutar mejoras. Si esperamos a renovar el soporte tecnológico al momento en que ya está obsoleto, estaremos ante un problema grande, lo que se conoce como un secuestro tecnológico. Cuesta mucho salir de ahí, así que lo mejor es prevenir.
Para solucionar muchos de estos problemas se requiere sustituir unos hábitos por otros. Y para cambiar de hábitos, lo mejor es contar con el acompañamiento de personas que ya los tienen bien interiorizados. Que pueden instruir e inspirar mediante el ejemplo, trabajando en el mundo real. Sin excusas. Las personas que trabajamos en Lean Mind estamos entrenadas para enfrentarnos a estos problemas sistémicos; los hemos enfrentado mil veces. Nuestro método funciona porque el foco está en las personas, en empoderarlas para que cambien esos hábitos, para que crezcan hasta conseguir sus objetivos. Nuestro fuerte énfasis en las “soft skills”, hace que abordemos estos problemas con una perspectiva diferenciadora. Dominamos las prácticas de ingeniería de XP, que nacieron para solucionar muchos de estos problemas clásicos, pero no entramos como elefante en cacharrería. No le decimos a la gente lo que tiene que hacer, sino que primero mostramos curiosidad por comprender el contexto y respeto por el trabajo de las personas. Lo primero es ponernos en el lugar de los demás, para luego avanzar juntos, aprendiendo y progresando como un equipo bien cohesionado.
No todas las consultoras son iguales, existe una amplia gama. Lean Mind es una consultora con valores y propósito, compuesta por personas que demuestran integridad y profesionalidad cada día. Si confirme has ido leyendo los problemas enumerados en este artículo, identificaste que tu equipo está sufriendo algunos (o muchos) de ellos, es un buen momento para que os ayudemos. No dudes en escribirnos para que podamos tener una conversación en la que conocernos; nos encantará conoceros.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
