Mis experiencias con respecto a equipos auto-administrados

Standard

Muy buen día, hoy les quiero hablar de un tema que desde que empecé en el mundo de SCRUM, me ha causado interés en el mundo del desarrollo de software.

Para empezar, hay que definir qué es un equipo auto-administrado

Un grupo de empleados auto-organizados, semi-autónomos cuyos miembros determinan, planean y administran sus actividades diarias prácticamente sin supervisión.

Referencia

Si bien el término no es exclusivo de SCRUM ni de software, son las áreas en las que lo conocí y sobre las que tengo un poco de experiencia, por lo cual me gustaría compartirles algunos tips, comentarios y recomendaciones sobre este tema.

Lo primero que me gustaría decirles es que este tipo de equipos desde mi punto de vista debieran ser implementados en toda empresa ya que su enfoque es “deja que el experto haga lo que sabe” y ahora les explico por que.

En la mayoría de empresas en las que he participado anteriormente, si eres un desarrollador, normalmente te llegan los requerimientos ya estimados para que simplemente los ejecutes. Sin embargo aunque esto suene como que facilita el trabajo a los desarrolladores, he observado sólo dos casos 1. La estimación está tan sobrada que normalmente el desarrollador termina mucho antes de lo que la tarea indica. 2.- La estimación está tan corta que normalmente le desarrollador termina mucho después.

Personalmente esto siempre me causaba molestia, porque veía una distribución de la carga de trabajo muy des-balanceada, es decir, veía gente que trabajaba 10 horas al día y gente que trabajaba 5. Todo porque la gerencia asignaba el trabajo y parecía no estar muy bien enterada de como se repartía el trabajo, obviamente hay empresas donde la repartición del trabajo se hace mejor, pero cuando la planeación no es echa por el mismo equipo de desarrolladores, es más probable que las estimaciones sean erróneas y ahora les platicaré un ejemplo de a que me refiero.

Supongamos que tu eres un desarrollador experimentado, que ya has llevado a cabo proyectos importantes y que vienes de otra empresa donde trabajabas con gente muy capaz, digamos que tu eras la viva imagen de la capacidad promedio de tu equipo, es decir, si tu hacías algo en 10 horas, es muy probable que a cualquier miembro del equipo le llevase el mismo tiempo. Pero ahora tu llegas a esta nueva empresa con un nuevo proyecto, lo más probable es que hagas una planeación tomando como base tu experiencia en antiguos trabajos/proyectos, digamos pues que tus estimaciones son basadas en tu experiencia, pero a la hora de la ejecución te das cuenta que la mayoría de tu equipo (gente con experiencia) no tiene ni la mitad de la capacidad que tu creías, o por el contrario tienen mucha más capacidad, en cualquiera de los dos casos verías que tus estimaciones son erróneas lo cual seguramente traería algún tipo de problema o descontento dentro de los desarrolladores.

El otro problema es que si para evitar lo mencionado arriba, hablas con algunos desarrolladores y preguntas “oye, ¿cuánto tiempo crees que te lleve hacer X tarea?” y el desarrollador te dice 5 horas, ahora entrevistas a otros 3 y los 4 coinciden en promedio 5 horas, esto puede indicar que esa es la capacidad promedio, PERO, a la hora de la verdad resulta que le preguntaste a los 4 mejores programadores que tenias, y si se planeará de acuerdo a esto, es muy probable que el resto de desarrolladores se sientan frustrados o presionados en exceso por estimaciones “muy exigentes” según su punto de vista, o si por otro lado, eran los peores desarrolladores, los desarrolladores con mejores capacidades se sentiría igualmente frustrados pero por la razón opuesta.

Obviamente lo idea sería evaluar las capacidades de todos los miembros, pero muchas veces esto costaría mucho tiempo/dinero o simplemente en ocasiones resulta poco práctico.

Esta es para mi una de las principales razones para implementar estos equipos, básicamente la idea es la siguiente.

Tu construyes equipos digamos de 8 personas, normalmente vas a observar varias reacciones, por ejemplo, disgusto por estar con algunos miembros, o alegría por estar con otros, esto te ayuda a de una manera rápida identificar líderes, problemáticos, grupos ya existentes, y en ocasiones, niveles de conocimiento. Lo cual te ahorrará tiempo de investigación, ya que si muchos reaccionan de manera negativa a un miembro del equipo, debiera ser algo que atender de manera inmediata.

Pues bien siguiendo con nuestro ejemplo, digamos que ahora, tu no eres el que planea, sino que simplemente creas el equipo, les explicas el proyecto y te conviertes más que nada en un guía y no tanto en un jefe, ya que de cierta manera lo que se busca es que el equipo sea productivo por si mismo. Con esto tenemos ventajas como que se va a aligerar tu carga de planificación y al mismo tiempo, si se hace de manera correcta, lograrás que el equipo se comprometa ya que es este el que hará las estimaciones (obviamente supervisado por ti) y con lo cual en teoría no tendrán excusas para cumplir con las fechas de entrega ya que son ellos los que están diciendo cuando pueden cumplir.

De aquí en adelante es donde yo veo más beneficios por lo siguiente:

1.- Los equipos filtrarán a sus integrantes.

Esto es básicamente que cuando se trabaja en equipo es muy probable que nadie quiera tener compañeros que no trabajen o que no completen el trabajo ya que, uno de los temas en estos equipos, es que el equipo y no los individuos se vuelven los responsables, es decir, si un integrante no cumple sus tareas, el equipo es el que no cumple. De tal suerte que, si el equipo tiene un integrante que constantemente los hace quedar mal, el mismo equipo debiera hablar con el integrante para lograr que este se ajuste o en su defecto provocar su salida, sirviendo así como un filtro automático en los equipos.

2.- Ubicación de capacidades.

Complementando un poco lo anterior, otra utilidad es que es lógico que a la gente productiva, le gusta trabajar con gente productiva y que a la gente le gusta trabajar con gente de una capacidad similar, es decir, a ningún programador le gusta hacer X actividad en 1 hora y que otros miembros la hagan en 3 horas, ya que esto al final se traduce en que una sola persona hará la mayoría del trabajo. es aquí cuando podemos aprovechar para ver que integrantes del equipo son los más productivos y cuales los menos productivos permitiéndonos con esto, mover a las personas a equipos donde embonen mejor.

3.- Mejora en estimaciones.

La experiencia me ha enseñado que entre más tiempo pasa un equipo trabajando en conjunto, mejor van siendo sus estimaciones, ya que todos empiezan a conocer el ritmo de trabajo de los demás y al mismo tiempo se van tomando confianza, propiciando que se cuestionen entre ellos sus estimaciones haciendo comentarios y observaciones hasta que se llegue a un consenso sobre la estimación y con el tiempo terminan por mejorar su exactitud.

4.- Creación de equipos equilibrados.

Como comentamos anterior mente, la idea es crear grupos que se filtren de manera automática, con lo cual el resultado deberá ser tener equipos donde sus integrantes tengan capacidades similares, una ventaja de esto es que en caso de querer capacitar a los miembros, ya tendrás la certeza de que todos cuentan con un nivel similar, evitando así que haya desperdicio cuando se invierta en estas capacitaciones.

5.- Menor frustración.

Otro objetivo de tener estos equipos es que, sea el equipo el más preocupado por tener un ambiente ideal de trabajo, buscando al final, tener compañeros, con capacidades similares, con productividad similar, inclusive con un ambiente divertido, todo esto también busca provocar que al tener un equipo con todas estas características y que además manejan tiempos similares, es muy probable que los equipos se frustren menos.

Algunos tips:

Pues bueno, creo que con estos 5 puntos se entiende la idea general que quiero transmitir sobre los beneficios de los equipos auto-administrados, ahora les daré unos tips que he visto que funcionan al momento de implementarlos.

1.- Delegar poder no sólo responsabilidad.

Muchas veces he visto que cuando no se les da el poder de decisión de manera explicita a los miembros del equipo o si no se les da de ninguna manera, es muy difícil que los equipos funcionen como se busca, recordemos lo siguiente, el objetivo de que contratemos expertos es porque ellos son los que saben, es decir, si contratas un diseñador, al que le tienes que decir como diseñar, pues no tiene mucha lógica, es aquí donde entra el darles poder a los equipos para que tomen decisiones sobre los temas que dominan, obviamente siempre es necesaria la supervisión, pero, al mismo tiempo, si no estamos dispuestos a conceder estos poderes, mejor reflexionemos dos veces el implementar este tipo de equipos.

2.- Confiar en los demás.

Un punto muy importante es estar preparado para confiar en que las personas hagan su trabajo, si no puedes confiar en otros, difícilmente se podrá implementar esta estrategia.

3.- Paciencia.

Otro punto clave es que esto es una estrategia a largo plazo, si bien vamos a tener algunos resultados rápidos, los beneficios reales vienen a mediano y largo plazo, es decir, en SCRUM normalmente se trabaja por periodos de 2 semanas a 1 mes por SPRINT, y obviamente cada sprint las estimaciones y los resultados van mejorando, la cooperación al interior de los equipos se va mejorando, dale tiempo a esta estrategia y verás grandes beneficios.

4.- Guía a los equipos.

Si bien, lo que se busca es que los equipos se vuelvan independientes, siempre es necesario guiarlos durante el proceso, y tratar de ser más un mentor, que un jefe.

5.- Seguimiento.

Además de guiar, es importante darle seguimiento a los equipos, ya que puede que haya integrantes que con el tiempo se vuelven menos aptos para cierto equipo, ya sea porque sus capacidades crecen o más rápido o más lento que los demás, y es importante detectar esto para hacer los ajustes necesarios. Así mismo sirve para identificar líderes y candidatos a puestos más altos dentro de la organización.

Pues bueno, este tema es muy extenso, y espero más adelante hacer una especie de guía más formal que les sea de utilidad para llevar a cabo una implementación, sin embargo me gustaría que se queden con la idea de implementar esta estrategia que me parece genial y que estos tips les sirvan durante este divertido viaje que les causará enojos y satisfacciones.

Bueno, eso será todo por ahora, espero y les sea de utilidad estos comentarios y como siempre, cualquier comentario o crítica para mejorar es agradecido y bienvenido. Saludos.

 

Leave a Reply

Your email address will not be published. Required fields are marked *