Introducción

Esta es la primera de una serie de entradas donde voy a exponer mi punto de vista sobre los skills que debería tener un equipo de desarrollo.

Es obvio que mis resultados están basados en mi experiencia como responsable de diversos equipos y en las necesidades de los modelos implementados, desde XP pasando por lean, scrum y una gran lista, pero al final en todos se busca que las personas (sin personas no tenemos nada…) tengan unas capacidades/habilidades/características = skills 😉 en común para poder aplicar una forma de trabajo muy concreta que además es cambiante y que esta sometida a un ciclo de mejora continua, pero también de incertidumbre y presiones muy variadas.

Esa forma de trabajo es muy concreta y particular porque esta basada justamente en personas y no en procesos, esta afirmación trae de cabeza a muchas (la mayoría) de implementaciones agiles.

Implementar una cultura ágil requiere de un cambio de enfoque radical. Radical de verdad, y el no poder acometerlo por parte de las empresas, staff de dirección, o equipos (y me incluyo en todos ellos) es con diferencia la principal causa que personalmente me ha hecho fracasar en alguna ocasión (si, si nadie es perfecto y obviamente no todo me ha salido siempre a la perfección).

Sin embargo, todos mi éxitos profesionales se los debo, siempre y sin excepción a las personas con las que he formado un equipo y a sus skills personales, mucho más allá de cualquier metodología, producto, empresa, etcétera.

La idea es plantear una serie de estos skills agrupados por áreas de competencia, al final son grandes conjuntos de «inteligencia» que deben funcionar unidos, aunque no todas las personas de un equipo pueden tener los mismos skills, ni tenerlos ni entenderlos de la misma manera (algo obvio y normal) sí es necesario que, al menos, exista el principio de compensación o ecuanimidad, vamos que todo el mundo sea capaz de colaborar y no exista un bloqueo o un problema de toxicidad.

Pero seamos realistas y sinceros; las presiones, los plazos, el entorno cambiante, los egos dentro de los equipos de desarrollo, la comunicación y el aislamiento son los grandes enemigos a combatir, y no es una tarea fácil, sin embargo hay maneras de hacerlo, aunque lo primero seria determinar que es lo que necesitamos de un equipo para después poder hacer crecer ciertas cosas.

Todos juntos

El respeto por cada persona hacia las demás y viceversa es la clave, es algo obvio pero también lo es que hay muchas maneras de no respetarse y a veces ni siquiera nos damos cuenta de ello, cuando hablamos de requisitos, de código, de integración, de sistemas,,, la cosa se lía y esto también es algo obvio y evidente.

También es lógico que aunque no nos guste o no compartamos algo, es necesario entender que NO todo el mundo piensa igual, que cada persona tiene sus inquietudes, motivaciones, puntos de vista, compromiso con el proyecto, relación con los demás, etcétera y que el esfuerzo debe ser continuo dentro del equipo por entenderse y por supuesto respetarse (esto incluye cosas que para alguien pueden resultar molestas y para otra persona diferente no). Ser transparente sobre lo que nos hace sentir bien y mal es super importante y el resto del equipo debería conocerlo.

Dicho esto, creo que al final el papel del «super buen rollo» no tiene porque funcionar en todas las personas, pero sin unos mínimos de positividad, educación, cordialidad, buen humor y empatía difícilmente funcionara un equipo que se considere así mismo como tal. Hago hincapié en el buen humor, porque en mi experiencia con risas las cosas suelen funcionar mucho mejor.

La cuestión es que el equipo debe estar unido y las personas tienen que sentir que se les respeta, ojo que los managers, product owner, CTO, CIO, etcétera también necesitan sentir lo mismo, TODO el equipo lo necesita, no es necesario ser «una gran familia» pero si tener una serie de soft-skills previos o un equipo de desarrollo ágil no funcionara.

Y esto es así porque los miembros de un equipo de desarrollo basado en modelos agile tienen mucha más libertad para tomar decisiones pero también más responsabilidad, y además esa responsabilidad es conjunta y mutua, y esta orientada (o debería) hacia el resultado del proyecto o producto (que no es otro que aportar valor de una manera rápida y constante, con calidad, etcétera, hacia el cliente).

Eso nos lleva a que dicha responsabilidad obliga a las personas a converger y no tienen más remedio que entenderse y afrentar los conflictos de una manera productiva.

Respecto a las tomas de decisiones en común, en mi opinión, el product owner tiene un peso muy importante, sobre todo en transmitir de una manera clara, sin fisuras ni ambigüedades que significa valor para el cliente y de que forma este (el cliente) lo percibe.

En este punto, lo ideal, y lo que mejor me ha funcionado, es prescindir de una figura típica de «jefe de proyecto» o al final las responsabilidades se verán reflejadas en este rol y no el propio equipo.

Este detalle, cuando la responsabilidad es compartida, provoca que no se le puede culpar al «jefe» de una manera tan fácil, todas las personas del equipo asumen lo que esta sucediendo y obviamente el resultado es la responsabilidad compartida (o la rebelión total).

Con ese modelo (no hay «jefe» -> senior -> etc… al que tirar las culpas) es preciso llegar a consensos y acuerdos por obligación.

Obviamente si alguien percibe que hay un «jefe/a» cuando se sienta que algo se está haciendo mal se vuelve al modelo clásico, «el jefe me lo impone», «el  equipo no decide», etcétera y se «mata» la participación y por ende el concepto de equipo ágil.

Un punto clave  es la comunicación transparente y abierta, si se consigue que todo el equipo exprese lo que siente, y se proponen alternativas constructivas, que una critica negativa y una critica constructiva no son lo mismo, se avanzara en el camino del consenso dado que en estos modelos de desarrollo los equipos tienen más autonomía en la manera de trabajar, y una cosa sin la otra (consenso y autonomía),,, en mi experiencia no suele funcionar.

Así que se potencia y motiva al equipo para que tome sus propias decisiones dado que sus miembros son los especialistas, los que tienen los conocimientos, habilidades y experiencias necesarios para llevar a cabo el incremento de valor; vamos que un rol que trabaje bien la capa de infraestructuras, un analista funcional de un negocio concreto, o alguien que conoce el framework X perfectamente puede aportar mucho, eso si, siempre que esas aportaciones se realicen como equipo y no de manera individual y tengan como foco aportar valor y que el cliente lo perciba de esa manera.

Esos planteamientos conjuntos hacen más sencillas de implementar y de ejecutar con éxito las necesidades y problemas que indudablemente van a surgir, permiten mejores soluciones a partir de las sinergias de todos los miembros del equipo, a diferencia de los modelos de gestión clásicos en que las jerarquías establecen quiénes son las personas que deciden, dirigen y controlan, con lo que las soluciones que aparecen están completamente limitadas a la capacidad de estas personas.

La idea que mejor funciona es que las jerarquías se diluyan, pero nunca las responsabilidades, las responsabilidades deberían ser parte de TODO el equipo y nunca de una sola persona, esto, bajo mi experiencia, es de la cosas más complicadas de implantar con diferencia, pero también es de las cosas que impulsan al éxito cuando se consiguen.

Desde luego la figura de un tech-leader o como lo queramos llamar es importante, en este punto, que es muy conflictivo, yo abogo no por el mejor «programador» sino por la persona que es capaz de tener mejores y más desarrollados soft-skills, en los equipos utópicos esta figura no existe, en la vida real se necesita al menos «guiar» a los equipos.

Objetivos comunes.

Si se consigue que las personas establezcan un objetivo común las cosas funcionaran mejor (obvio).

Obvio si, pero para conseguirlo es imprescindible que entre todos los miembros del equipo se decidan (esta es una de esas cosas que es clave para que «la cosa» funcione) cuántos requisitos/objetivos son capaces de completar en una iteración, esta «sencilla» y única acción es de las más importantes dado que representa el esfuerzo del propio equipo y conlleva una autonomía (y responsabilidad) muy grande.

También ayuda, y mucho, que se identifiquen cuales son los impedimentos, mitigaciones y acciones de mejora a realizar que les impiden proporcionar más valor, más calidad, ser más productivos y disfrutar más del trabajo.

Cuantas más decisiones y consensos en común se logren, más fácil será tener ese pegamento tan necesario para tener un objetivo en común, al final un equipo debe comportarse y sentirse como tal, y estos dos puntos (estimación y critica) son los más importantes para tener una base solida y seguir construyendo equipo (que es de lo que se trata).

Esto, el objetivo y el trabajo en común, va alineado con la idea de que las tareas, de todo el equipo, no consisten en pasar «responsabilidades» de una persona a otra dentro de un proceso (aquello de procesos VS personas) si se trabaja así = hago x «porque lo demás es responsabilidad de fulanito y yo ya he hecho lo mío», al final nadie tiene responsabilidad sobre el producto final (tal vez el jefe de proyecto lo que sucede en los métodos de trabajo en cascada/tradicionales) sino que todos los miembros del equipo comparten la visión global del estado del proyecto respecto a los objetivos y la percepción de valor por el cliente.

Lo que subyace en esta forma de trabajar esta basado en que el equipo adquiere un compromiso conjunto al elaborar la táctica que van a emplear para conseguir estos objetivos, identificando las tareas, asignándoselas entre ellos y emergiendo entonces un equipo auto-organizado,

Ojo que a esto no se puede llegar realizar visionando 4 diapositivas, es un trabajo a conciencia, que requiere tiempo, esfuerzo y dedicación, y soy realista de nuevo, en ocasiones (en la mayoria) las cosas no son fáciles.

Obviamente nos vamos a encontrar con diversos y variados puntos de vista, también con conflictos (que no tienen porque ser tóxicos o negativos) y en definitiva; con un proceso que no siempre es fácil ni predecible pero que sin el cual es imposible llegar ese punto tan deseado donde podemos afirmar que » tenemos un equipo».

El paso de equipo auto-organizado a auto-gestionado ya se complica un poco más, pero en muchos casos no es necesario si el product owner, jefe/a de proyecto o llámalo X, tiene muy claro que su función es ayudar, incrementar valor, identificar problemas y aportar soluciones, poner el foco, dejar claros los objetivos del negocio/cliente/empresa y no estar buscando responsables, el equipo debe ser el responsable, pero claro, el equipo también debe poder participar en la toma de decisiones para sentir de manera real dicha responsabilidad.

Para concluir con esto; un equipo de desarrollo debería tener muy claro que es lo que se espera de ellos, esto es responsabilidad directa de quien los dirige, sea mediante una gestión únicamente de producto (product owner) o bien del CTO, CEO, CIO, CXX. De que manera, cuando y como,,, a veces esto es un poco áspero de comunicar, y en este punto voy a un tema muy importante: un equipo de desarrollo debe tener un grado de madurez en la capa de negocio muy alto, tanto que no sea necesario explicar que el objetivo final y único de su existencia es proporcionar valor a los clientes.

 

Conflictos, algo normal y sano

Otro asunto que nunca se puede por alto son los conflictos, son habituales, existen, existirán, y pretender que esto no suceda es no ser consecuente y caer en el mundo de los PowerPoint no realistas donde; o bien la gente se desvincula, o se quema, o simplemente aguanta mientras no tenga otra cosa (ojo que eso no tiene que significar que exista un ambiente toxico, pero la productividad y el alto rendimiento juegan en otra liga).

En mi opinión la única diferencia entre un verdadero problema y algo que simplemente sucede es; como se percibe dicho conflicto;  algo que simplemente aporta y es normal, o algo toxico que lo envenena todo.

Los conflictos en un equipo que está trabajando con los mismos objetivos y con responsabilidad mutua son naturales y necesarios dado que sus miembros tienen distintas experiencias, conocimientos, roles y ayudan a obtener la mejor solución posible.

Bajo este planteamiento, es muy importante que cuando una persona discrepe de alguna decisión o sienta que la actitud de otra persona impide que el equipo sea productivo, se sienta con suficiente libertad y confianza como para mostrar su punto de vista a la(s) otra(s) tan pronto como sea posible, para mi es importante hacer esto con humor y buscando el punto de encuentro y no el del desencuentro, la idea es que en vez de hacer hipótesis erróneas por falta de información, fomentar rumorología o dejar los problemas sin resolver hasta aceptarlos como endémicos, se consiga generar un clima de colaboración y simpatía gracias a esos mismo (inevitables por otro lado) conflictos.

Y obviamente el equipo debe ser constructivo con esta critica y no demonizar a nadie, es muy importante que esta comunicación y feedback se realice utilizando el mejor canal posible = cara a cara o por video (para mi; mejor cara a cara), en lugar de utilizar el email, tarjetas, campos de un formulario, etcétera, que además de que pueden exponer a la otra persona al juicio de muchas otras (esta escrito y es consultable) generalmente implica esfuerzos de autojustificación y autodefensa que no aportan nada = desperdicio.

Insisto en la comunicación verbal, porque además de ser más ágil dado que obtiene información de manera más fluida, permite escuchar y entender mejor las razones del otro, evita malas interpretaciones y facilita conocer las emociones de los demás.

En este punto es importante no formular preguntas de manera acusatoria y ni hacer juicios (perogrullada necesaria). El objetivo no es buscar culpables, sino llegar a consensos que permitan aportar más valor al proyecto, ser más productivos y mejorar el proceso de trabajo, esto es obvio, pero a veces se nos olvida, y aunque parezca mentira en muchas ocasiones existe un buen ambiente pero los juicios de valor y las culpabilidades están subyacentes, incluso en reuniones donde el buen rollo es imperante, cuidado con dar por supuestas cosas (por ejemplo junior y senior compartiendo una branch).

Y hasta aquí con esta parte, en definitiva la idea es contar con personas maduras, responsables y con ciertas habilidades sociales y personales, puede parecer sencillo pero cuando se unen presión, cambios, código legacy, diferentes experiencias y puntos de vista, falta de comunicación e información, inseguridades varias de muchos tipos, etcétera, etcétera, nos podemos encontrar con que se cuenta con personas increíbles con esas capacidades (maduras, responsables, con habilidades) pero en el conjunto nada funciona y entonces, lo más básico, que es construir un equipo se viene abajo.

También, y soy consciente de que no es muy popular escribir esto, pero creo que en ocasiones hay perfiles que no saben jugar en equipo y/o como comunicarse, con perfiles así, es imposible construir nada relacionado, ni con agilidad ni con alto rendimiento. son en mi opinión los pilares básicos para poder construir algo.

Como conclusión final: un equipo de desarrollo, en mi opinión, lo más importante (si, incluso por encima de capacidades técnicas) lo que debe poseer son soft-skills y como base mínima e imprescindible la capacidad (y deseo) de trabajar en equipo y comunicarse.

 

 

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada.