Descubriendo los problemas de equipos ágiles

En esta nueva entrada verás como muchas áreas que parecían no estar relacionadas pueden afectar el funcionamiento de un equipo de alto rendimiento. Cuando la empresa empieza a usar Agile, comienzan a verse ciertos patrones de conducta que hacen que el implementar las metodologías sea un pequeño desafío cada día. La primera cosa a asumir es que esos inconvenientes no se dan como consecuencia del cambio de la forma de trabajo sino que en realidad estuvieron allí desde el principio.

164406_mem immigration thumbnails

Agile hace siempre que las fallas en los procesos queden expuestas y se muestren de forma explicita. El mayor inconveniente es que muchas veces no es fácil detectar donde se encuentra realmente el problema y en muchas ocasiones se tiene la percepción de que está en un lugar, mientras que en la realidad se sitúa en otro. Esto es lo que yo llamo el proceso espejismo y te contaré una historia para que veas como esto se da en muchos ámbitos.

Años atrás me encontraba en Inglaterra trabajando como Scrum Master al frente de 2 equipos de trabajo los cuales usaban tableros visuales Kanban para representar sus flujos de forma explícita y así dejar los procesos visibles para todas las personas. Durante varios ciclos de trabajo nos encontramos con un inconveniente que se repetía una y otra vez y que consistía en que los desarrolladores acusaban al tester de no ser lo suficiéntemente eficiente o rápido a la hora de probar las aplicaciónes.

Kanban


El proceso espejismo
A primera vista parecería ser cierta la aseveración de los desarrolladores, sin embargo, un análisis más en profundidad me demostró que el problema se encontraba en otro sitio… el grupo de desarrolladores tenía una velocidad de finalización de historias de usuario no constante, esto es, una semana podían terminar un par mientras que a la próxima un número muy superior.

nonConstant

Esto daba como resultado que el tester no contaba casi con trabajo para probar la primera semana mientras que la segunda se generaba una cola interminable de requerimientos. Rascando un poco más pude apreciar que habían serios problemas de comunicación y colaboración, cosa que debería ser el punto de discusión en vez de quedarse con la visión simplista del tester ineficiente.

El sistema del reloj de arena
En teoría las empresas y sobre todo los grupos de trabajo deberían funcionar como relojes “Suizos” en cuanto a su coordinación, colaboración, confianza y excelencia técnica para así lograr un resultado óptimo, pero digamos que en muchos casos no es ni siquiera la regla. En el ejemplo anterior te he mostrado como hay una relación estrecha entre muchas áreas que parecen no estar conectadas pero que en definitiva son el centro del asunto.

Es así que hace algún tiempo atrás comencé a idear un sistema rápido para detectar sintomatologías de grupos Agile (pero puede ser usado para otras metodologías) para posteriormente conectarlas y descubrir el origen real del problema, cosa que en ocasiones no es fácil de apreciar directamente.

hourglass-icon

A esta técnica la denominé “El reloj de arena” por su similitud con el funcionamiento del mismo. La idea es sencilla pero muy poderosa, debes dibujar 5 líneas superiores y 6 inferiores, lo que dará un resultado similar a un reloj de arena y de allí su nombre. Cada una de las líneas o ejes representará una característica definida que te explicaré en breve.

hourglassNuevo

Nota: Asumo que tu equipo realiza todas las reuniones obligatorias en Agile (¿Lo haces?)

Obviamente el flujo será siempre hacia abajo; la metáfora te ayudará a la construcción inicial y a comprender su funcionamiento. Ahora indica en la parte superior de cada eje (línea) los conceptos de:

1a. Colaboracion
2a. Excelencia técnica
3a. Honestidad y confianza
4a. Colocación/Comunicación
5a. Disponibilidad del dueño del producto

Te explicaré en breve qué significa cada uno de ellos. Por su parte, en el cuadrante inferior deberás contar con los siguientes 6 textos:

1b. Carencia de conocimiento específico
2b. Presión en el trabajo
3b. Centralización de conocimiento
4b. Multitaréa
5b. Estructura jerárquica
6b. Deuda técnica

Los números fluyen siempre hacia abajo como el reloj de arena y todos ellos con una escala del 0 al 5, comenzando o terminando en el centro. Como puedes apreciar, estos se encuentran con líneas sólidas a excepción de “Deuda técnica”, la que está diferenciada ya que no deberías llenarla (la calcularemos en base a los otros valores).

“Deuda técnica (también conocida como deuda de código o diseño) es una metáfora que se refiere a las consecuencias eventuales de la evolución pobre de la arquitectura de software o desarrollo de código. Es en general la parte del requerimiento que normalmente no es su funcionalidad y que debido a ello no se hace y se dilata en el tiempo (ej. optimizar la base de datos), ya sea por apuro en la entrega o por el deseo de finalizar la tarea antes, lo que da como resultado que se ésta se acumule indefinidamente con otras”

Que el número sea más grande indicará que hay mas de ello (o mejor calidad para algunos casos), por ejemplo, honestidad 5 querrá decir que las personas del grupo confian plenamente en ellas mientras 2 que casi no cuentan con este valor. A su vez, el cuadrante inferiore destaca características que a mayor número más negativo será el impacto, por ejemplo, “Carencia de conocimiento” igual a 5 indicará que el equipo realiza tareas de desarrollo o trabaja sobre tecnologías que no conoce. Como regla general, todo aquello que se acerque al medio será siempre positivo, mientras que lo que se aleje tendrá un efecto negativo en el equipo o empresa. Veamos entonces los diferentes valores y una explicación; es importante que comprendas claramente cada eje ya que será la clave para que puedas interpretar correctamente los resultados.

1a. Colaboracion
Indica la colaboración efectiva entre los miembros del equipo. No hay que confundir comunicación con colaboración; algunos equipos son alborotados, hablan mucho, estan llenos de buenas intenciones pero no concretan las tareas ni finalmente colaboran de forma funcional. Para este último caso el valor será 0 mientras que colabora
ción sin barreras o perjuicios será 5.

2a. Excelencia tecnica
La primer pregunta es saber qué estándares de código y diseño se siguen, ellos son fundamentales a la hora de contar con calidad alta de codigo/diseño así como facilitar el mantenimiento y disminuir la deuda técnica. A su vez, mantener los documentos o cualquier otra información necesaria al día tal como la especificación de instalación, plan de contingencia, integración, etc es parte de la excelencia técnica. Si el equipo desconoce la respuesta a ésta pregunta entonces obviamente el valor será 0.

3a. Honestidad y confianza
Honestidad y confianza es algo siempre dificil de medir y detectar directamente, pero puede ser evaluado observando los conflictos del equipo. Alguno de los síntomas para saber si se cuenta con poca honestidad y confianza son estimados no realistas, acuse directo a personas por tareas no finalizadas, errores que se reiteran ciclo a ciclo, problemas de poder, etc. De verse alguno de estos entonces la honestidad brillará por su ausencia. La puedes también evaluar preguntando a los integrantes del equipo que depositen de forma anónima en una bolsa un valor de 0 a 5 indicando el nivel percibido de honestidad y confianza.

4a. Colocación/Comunicación
Quizas sea el elemento más fácil de ver a simple vista pero puede ser tramposo. Cuando todos los miembros del equipo se encuentran en el mismo sitio físico y se comunican efectivamente entonces será 5. Ahora bien, si algunas de las personas están en forma remota, el valor debería ser también el máximo si el grupo puede verse las caras en cualquier momento, ya sea mediante la colocación de cámaras y la posibilidad de comunicacación visual a un clic de distancia.

5a. Disponibilidad del dueño del producto
Un problema que padecen muchos de los equipos es no contar con el propietario del producto en su totalidad. Algunos están disponibles algunos días u horas de la semana y otros, aunque en teoría deberían estar a tiempo completo, se hallan tan ocupados que no tienen tiempo. A su vez, puede estar disponible pero existir problemas jerárquicos o lo que se llama “el arma invisible”, esto es, la intimidación conciente o no que la persona ejerce sobre grupo, como si este estuviese armado.

Veamos ahora los valores del cuadrante inferior, los que tendrán un efecto negativo cuanto mas grande sea su valor.

1b. Carencia de conocimiento técnico
En algunas ocasiones los equipos carecen del conocimiento técnico necesario de fondo para resolver una tarea del ciclo. Este no radica en no saber como implementar una funcionalidad sino que en desconocer las características de la herramienta por no haberla utilizado anteriormente o tener serias dificultades. En general cuando esto pasa suelen hacerse sugerencias sobre la forma de resolver el problema basado en un supuesto funcionamiento de la herramienta, lo que obviamente aumenta la incertidumbre y riesgo y hace que los estimados estén más lejos de la realidad. Cualquier carencia de conocimiento técnico importante del equipo tenderá a acercar la evaluación al número 5.

2b. Presión en el trabajo
Si existen fechas impuestas de finalización así como otro tipo de presiones externas altas combinadas con las de carácter psicológico (miedo a ser despedido, trabajo de fines de semana,etc) en conjunto con reales (fecha de entrega fija debido a un cambio de legislatura o convenio con el cliente, etc), entonces se decantará hacia el número 5.

3b. Centralización de conocimiento
Imagínate que se requiere en cada ciclo 4 características particulares tales como comocimiento de base de datos, prueba, desarrollo y diseño de interfáz gráfica. Si alguno de estos se centra en una sola persona que se hace indispensable entonces el valor será 5. Para el caso que el equipo no sea totalmente funcional (diferente del concepto de todos pueden hacer casi todo) entonces subirá también.

4b. Multitarea
Si los miembros del equipo realizan multitarea de proyectos, esto es, se dedican a más de uno, el valor tenderá a subir. Te diría que si las personas están adjudicadas activamente a 3 o más proyectos a la vez el número debería ser 5.

5b. Estructura jerárquica
Si se cuenta con estructura jerárquica estricta y poco flexible dentro o fuera del equipo que influya activamente en las decisiones de los miembros del grupo entonces el valor será 5. Si de lo contrario, el equipo se auto-gestiona y decide como llevar adelante las tareas, se acercará al cero.

6b. Deuda técnica
Finalmente la deuda técnica no deberás marcarla ya que se te dará estimada como un resultado de los valores ingresados anteriormente. Recuerda que ella representa todas aquellas tareas que por apuro, presión o vagancia se dejan para mas tarde (sin afectar el funcionamiento del requerimiento), lo que hace una acumulación interminables de cosas que parecen prescindibles pero que se deberían llevar adelante en breve (también historias de usuario no funcionales).

Analizando los valores
Una vez recopilada la información y marcados todos los puntos en cada uno de los ejes tendrás una primera aproximación visual al estado del equipo. Como te indiqué anteriormente, los distintos ejes están inter-relacionados por lo que la deficiencia de uno de ellos afectará sin lugar a duda a los otros.

hourglassConDeudatecnica
Nota: La deuda técnica aproximada debería darse como resultado de la media de los valores del eje inferior. Mayor número, más será la acumulación de la deuda técnica. En este caso la deuda técnica será posiblemente alta (4).

El cuadrante de inferior tiene evidentemente un peso significativo ya que influeye de forma negativa a los resultados de la parte superior. Por ejemplo, un equipo que realiza multitaréa constantemente (5) no podrá tener una excelencia técnica de 5, y para el caso que ello pase es una falsa percepción que debería ser ajustada a la baja. Basado en mi experiencia asumiré que el cuadrante inferior influye hasta en un 80% los valores de la parte superior, esto es, una media de 5 abajo supondrá una pérdida de 80% del valor arriba.
Calculemos entonces la media del cuadrante inferior en base a la imagen y veamos que porcentaje debería ser ajustado.

Media de los ejes inferiores:
(4+5+3+5+4) / 5 = 4.2

(80*resultado) / Valor Maximo = % detrimento

(80*4.2) / 5 = 67.2% de detrimento

Este caso nos ha dado que el eje superior deberá ajustarse a la baja, aquí será un 67% del valor indicado originalmente como resultado de las fuerzas que negativas sobre el funcionamiento del equipo. Esto te servirá para poder identificar claramente la diferencia entre la percepción y realidad funcional. Esta última se dará como resultado efectivo de tomar en cuenta varios de los factores mas importantes que afectan a las personas y su trabajo en equipo.

hourglassfinal

El sistema del reloj de arena podría ser empleado casi sin cambios para otras áreas de la empresa. Adicionalmente te sirve para que puedas pensar sobre las diferentes fuerzas que afectan a los grupos de trabajo, que
quizá no hayas tomado en cuenta anteriormente.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Leave a Reply