Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X
Articles

Escalar ágil [1/2] – Un poco de perspectiva

O cómo pasar de un equipo de 10 personas a uno de 25 en un año, sin morir en el intento

Para Runroom, el 2011 pasará a la Historia como nuestro gran año de consolidación. Caigo en la obviedad al recordar que estamos atravesando probablemente la peor crisis económica de la Era Contemporánea, cosa que hace aún más increíble este crecimiento exponencial.

No estoy escribiendo este post para explicarte las claves de este milagro (nota mental: escribir otro con mis reflexiones sobre este asunto), sino para contarte lo que he aprendido de la experiencia de crecer:

D U E L E ! ! !

Duele un huevo. Y ahora ya sabes por qué llevaba tanto tiempo sin escribir.

De dónde venimos?

Necesito que entiendas nuestra historia particular, aunque quizá ya la conozcas: El año 2003, cuatro ex-compañeros de la universidad decidimos saltar al vacío, cada uno con nuestro ordenador bajo el brazo, con nuestra corta pero intensa experiencia laboral, y con una mano delante y otra detrás.

A pesar de que mágicamente empezamos muy pronto a trabajar para los primeros clientes (varios de ellos todavía siguen con nosotros), enseguida nos dimos cuenta de que no podíamos limitarnos a ser un grupo de programadores y apostamos por incorporar una nueva capa de valor a nuestra oferta de servicios: el diseño.

Rebajando nuestros ya precarios sueldos, como apuesta personal, convenimos apostar por el fichaje de un diseñador al equipo. Aunque el primer intento no resultó lo que esperábamos, aquello nos transformó. Nos dimos cuenta de que tanto valor tenía la mejora de nuestra oferta para los clientes, como lo que aprendimos nosotros de la experiencia.

De modo que empezamos a interesarnos por otras áreas de conocimiento: usabilidad, comunicación, marketing… La experiencia adquirida y la formación que nos fuimos auto-proporcionando nos llevó, poco a poco, pasito a pasito, a tener un equipo multifuncional  de 8-9 personas, lo suficiente para empezar a necesitar…

La llegada de las metodologías ágiles

Con este crecimiento orgánico, la llegada de proyectos más y más ambiciosos no se hizo esperar. Agile nos permitió organizarnos mejor, tener una visión más completa sobre la producción y mejorar técnicamente en la ejecución.

Fue como si, por fin, después de 8 intensos años de movimientos intuitivos, de palpar a tientas el camino a seguir, encendiéramos las luces. De repente, sabíamos donde estábamos y hacia donde teníamos que caminar.

Y lo que en su día fue un grupo de profesionales expertos en ASM (A Salto de Mata), se transformó en un equipo, con roles organizativos más claros, con procesos más definidos, con herramientas de mejora y con ganas de gritarle al mundo “somos la hostia!!”

La ventaja de un equipo, el problema de un equipo.

Hasta ese momento nos habíamos sorprendido a nosotros mismos consiguiendo proyectos importantes y, más aún, logrando la hazaña de llevarlos a buen puerto a base de constancia, intuición, oficio, pit i collons y, qué demonios, modestia a parte, una buena dosis de talento y carisma.

Pero ahora éramos un equipo! Con un Scrum Master, un Product Owner, un panel guapísimo y unas ganas de aprender y mejorar insaciables.

En este escenario, empezaron a llegar multitud de nuevos proyectos y con ellos, la saturación. Se hizo evidente la necesidad de ampliar la plantilla. Necesitábamos ayuda y gradualmente, a medida que los proyectos lo requerían, fuimos incorporando al equipo nuevos programadores, maquetadores, diseñadores, marketeros…

Los 4 socios nos dedicábamos cada vez más a gestionar los proyectos y al negocio, y cada vez menos al desarrollo (muy a mi pesar).

Pero seguimos siendo un solo equipo.

Quizá ahora que conoces nuestra historia y la situación de aquel momento, te resulte más fácil comprender por qué no nos detuvimos a analizar las causas de la saturación y a tomar cartas en el asunto, aunque las pistas eran evidentes:

1. Nuestro Product Owner no daba a basto definiendo Historias de Usuario y los sprints de 3 semanas consistían en sucesivas “cargas de historias nuevas al sprint”, con lo que los burndowns parecían una montaña rusa.

2. El tamaño del Product Backlog (y por tanto la planificación a medio y largo plazo) fue disminuyendo de forma constante hasta desaparecer por completo. Solo teníamos sprint backlogs parciales.

3. Esto supuso indefinición en las funcionalidades a desarrollar, con el consecuente retrabajo y malestar de los miembros del equipo.

4. El panel empezó su propia transformación. Pasó de ser nuestra guía a convertirse en el lugar frente al cual tratábamos de desenmarañar la desorganización resolviendo mini crisis en cada daily.

5. La carga de trabajo del Scrum Master era tal que empezó a descuidar sus funciones de protector del framework y facilitador del equipo.

6. Y la gente de negocio, los cuatro socios, agachamos la cabeza, nos cargamos a la espalda todo este pollo de gestión, e hicimos lo único que supimos hacer en ese momento: encajar, sufrir y trabajar.

Estaba claro que el equipo era demasiado grande para seguir el mismo modelo de trabajo que cuando éramos 8-10, pero no fuimos capaces de reaccionar porque la tormenta era tan salvaje que toda la energía la empleábamos en sobrevivir.

Para que te hagas una idea, todo esto se empezó a cocer a principios de año y fue aumentando exponencialmente hasta diciembre de 2011.

Y, cómo no, todo se rompió

Leave a comment  

name*

email*

website

Submit comment

Carlos Iglesias