Sensaciones [Post 1/2 sobre la #CAS2012]

Antes de hacer retrospectiva o siquiera un resumen, me gustaría hablar del feeling.

Me fui de Cáceres con la sensación de haber vivido un evento de esos que se te quedan tatuados para siempre. He de remontarme a mi primer Open Space, el AOS2010 de Barcelona, para recuperar emociones parecidas.

En aquella ocasión, lo he explicado mil veces, sentí que alguien me había pegado una bofetada de hiper-realidad. Una hostia tan fuerte que aún conservo el pitido en los oídos. Síííí amigos… En Barcelona me di cuenta que debíamos cambiar muchas cosas en Runroom, que iba a ser un duro proceso, pero sobretodo que la Comunidad Agile me había iluminado el camino y ya no había retorno.

Como decía Steve Jobs, si hoy miro hacia atrás y conecto los puntos, no puedo evitar que se me erice el vello de todo el cuerpo. Me doy cuenta de que aquel evento me cambió la vida. Muchos de los que allí estuvisteis fuisteis y sois fuente de inspiración. Ahora ya os he logrado digerir y aterrizar a un plano menos mítico, más terrenal, pero os otorgo igualmente el mérito de haberme acompañado, guiado y modelado durante todo este tiempo.

A la vuelta de esta CAS2012, me siento, a partes iguales: agradecido por la inversión de energía y talento que ha hecho tanto la organización como los ponentes, y orgulloso de pertenecer a esta tribu que me ha acogido y me ha elevado, haciéndome crecer y dándome la oportunidad de compartir y recibir.

No sé hacia dónde se conectarán los puntos en el futuro ni si me cambiará la vida de nuevo, como no lo supe en aquel AOS, pero sí tengo claro que la sensación de estar rodeado de personas maravillosas, de gente que está cambiando el mundo delante de mis narices, de la necesidad irrefrenable de admiraros tanto y tanto por ser tan potentes, maduros, generosos, íntegros y comprometidos, eso, ya no me lo quita nadie.

[box icon= info]Continúa en…

Mi análisis [Post 2/2 sobre la #CAS2012]

[/box]

j j j

Escalar ágil [2/2] – El desenlace

[box icon= info]
¡Atención!
Si no has leído la primera parte, puedes encontrarla aquí:
Escalar ágil [1/2] – Un poco de perspectiva
[/box]

Y, cómo no, todo se rompió

En cualquier equipo ajeno al agilismo, solo hubiese hecho falta el propio paso del tiempo para llegar a ese punto que en emprendeduría tradicional se llama “morir de éxito” (a mi me gusta más llamarlo “pillarse los cojones con la tapa del piano”, porque soy un romántico)

En nuestro caso, la implicación, motivación y profesionalidad del equipo fueron la razón de que hiciese falta que se diesen estos 3 factores para detonar la bomba:

  • Se nos juntaron las entregas en paralelo de dos proyectos grandes en febrero.
  • Por motivos personales, nuestro Product Owner tuvo que ausentarse algunas semanas.
  • Para colmo, estábamos trabajando sobre una nueva tecnología que aún no dominábamos y perdimos un tiempo valiosísimo equivocándonos en algunas decisiones técnicas que nos hicieron retroceder y volver a empezar.

De modo que enero fue un mes especialmente duro. Éramos ya 19 personas en el equipo y no cabía nadie más en el estudio. Habíamos previsto cambiar de local pero las obras se retrasaron 2 meses.

Se hacía más que evidente que, a velocidad de crucero no llegaríamos a las fechas de entrega. Hubo sacrificios personales, gente viniendo a programar los fines de semana, saliendo a las tantas…

Y todo esto hizo que nuestro Scrumban se degradase tanto que, sencillamente, dejó de funcionar. Nos saltamos demos, retrospectivas, sprint planning meetings, dailys…

Desde gerencia se entoñaban las tareas directamente al equipo, sin pasar ni medio filtro, con la consecuente pérdida de foco. Todo eran fuegos. Todo era urgente.

Caímos en el error más típico y más grave que se puede cometer: priorizar las horas de producción a las de planificación. Nos saltamos la metodología con pértiga porque “necesitábamos el tiempo” que requerían las liturgias para producir.

Nos traicionamos a nosotros mismos.

El golpe moral

Para mi, ver hecho añicos lo que tanto esfuerzo y energía había costado levantar, fue un mazazo.

Me costó varias semanas de digestión y de llorar en hombros amigos (gracias Jaume Jornet, Alberto Alcaraz, Alberto Alejo, Àlex Puig…) asumir que todo se había roto y que había que volver a empezar de cero.

Mientras tanto, pasó el mes de febrero, hicimos las entregas, y se acercaba la fecha del cambio de local.

Yo quería aprovechar la energía de cambio para tener listo “El Nuevo Modelo”. No tenía ni idea de cómo debía ser, pero tenía claras algunas cosas:

  • Era necesario dividir el grupo en varios equipos.
  • Cada equipo debía tener UN Product Owner, un Scrum Master, su propio panel y sus propias liturgias (daily meetings, retrospectivas, demos, sprint planning meetings, etc).
  • Nadie de “negocio” debería pasarle una sola tarea a ningún miembro de un equipo directamente. Obligatoriamente todas las tareas debían ser priorizadas y filtradas por el Product Owner correspondiente.
  • Y lo más importante de todo: el nuevo modelo debía poder escalar. Debía de ser lo suficientemente flexible como para crecer sin dolor.

De modo que, aprovechando las hermosas paredes de pintura de whiteboard del nuevo estudio, comencé el boceto de lo que, tras numerosas revisiones y cambios, hoy es la nueva organización de Runroom.

Manos a la obra!

Mi primer acercamiento fue hacer equipos “por cliente”… pero me resultó totalmente imposible. En el momento de hacer el primer intento, estábamos trabajando para 17 clientes simultáneamente en más de 20 proyectos (solemos hacer de 2 a 4 proyectos grandes al año y muchos medianos, por la tipología de clientes que tenemos)

Así llegué a la primera conclusión: “No, no, he de hacer equipos equilibrados y balancear proyectos.

Para ello, empecé representando cada una de las personas del equipo en un postit grande en el caso de los que estaban a jornada completa y pequeño en caso de media jornada.

Por otra parte, pinté con una textura diferente cada una de las capacidades de la persona: programación, maquetación, diseño, gestión, marketing y consultoría/negocio.

Intenté, sin fijarme en los nombres, que los equipos quedasen repartidos lo más equitativamente posible respecto a sus capacidades

Gestión de backlogs

La intuición me decía que el diseño de un modelo de equipos escalable pasaba por tener controlado el flujo de llegada a cada uno de los backlogs de equipo. En Runroom, debido a que hacemos muchos proyectos a la vez para muchos clientes simultáneos, somos unos cuantos los que nos ocupamos de la gestión y especificación de los proyectos, y por tanto la entrada de tareas y definición de nuevas funcionalidades depende de varios stakeholders internos.

En este sentido, la masterclass de Xavier Quesada en la Casa de Carlitos y Patricia fue muy reveladora. La idea era tener un backlog de entrada donde la gente de negocio va definiendo necesidades. Un backlog de épicas que de alguna forma se sintetizarán a Historias de Usuario y desde el cual balancear los proyectos a los distintos backlogs de cada equipo…

Algo parecido a esto:

Jugar al Tetris

Y así fue como con estos dos conceptos, nació un primer modelo…

Y un segundo…

Y un tercero…

Y así hasta que llegamos a una solución lo más óptima posible, teniendo en cuenta la herencia de proyectos que teníamos en ese momento.

Hoy y Mañana

A decir verdad, el modelo que finalmente estamos implementando a día de hoy no es ninguno de estos. Ha ido evolucionando con nuevas incorporaciones, y con toda seguridad no dejará de cambiar. Pero el avance ha sido brutal, porque hemos conseguido:

  • Tener dos equipos auto-gestionados.
  • Que cada equipo tenga un Product Owner único, responsable de priorizar el trabajo en curso.
  • Que si en un momento dado necesitamos seguir creciendo, podemos montar un tercer equipo crossfunctional sin que suponga un trauma para el resto de la organización.

Cuando llevábamos 2 semanas trabajando sobre este nuevo modelo, se nos presentó Ángel Medinilla y nos hizo una jam session de esas que te dejan vibrando varias semanas.

Con su particular estilo, llegó en plan sabueso buscando smells y he de reconocer que encontró unos cuantos ^_^

Actualmente, a parte de los 2 equipos de desarrollo de proyectos, hay un tercer casi-equipo de marketing (SEO/SEM/SMM) que da servicio a todos los proyectos. Digo casi-equipo, no porque no valore el trabajo que realizan, que es excelente, sino porque simplemente no están coordinados entre sí (hacen cosas muy distintas), ya que trabajan de forma individual con los Product Owners.

La principal sugerencia de Ángel que desde luego tenemos intención de llevar a cabo lo antes posible, es añadir esas capacidades de SEO/SEM/SMM a cada equipo, de modo que de cara a un futuro no muy lejano, intuyo que acabaremos teniendo 3 equipos, cada uno de ellos con capacidades de diseño, desarrollo, maquetación, y también marketing para buscadores.

Intentaré explicar los avances de ese cambio y aprovecho para darle de nuevo las gracias a Ángel, que es un maldito crack y si aún no lo conoces, ya estás buscando vídeos suyos en YouTube, siguiéndole en Twitter y contratándole para que os haga un agile coaching como mandan los cánones! :D

[box icon= lifesaver]
Cosas que pueden ayudarte si estás en una situación parecida:

  • No es buena idea tener equipos grandes. Si tienes un equipo de 10 (sin contar stakeholders), sepáralo en 2 de 5 lo más equilibrados posible. No es fácil, pero te aseguro que te ahorrará mucho sufrimiento.
  • Centraliza las peticiones de tareas a un supra-Product Owner que tenga la capacidad de negociar prioridades de negocio con los Product Owners de cada equipo.
  • Me ayudó muchísimo trabajar con una whiteboard y post-its para modelar el equipo. En primer lugar por la capacidad de mover y reordenar a la gente y en segundo lugar porque estaba radiando información y por tanto iba recibiendo feedbacks interesantes.

[/box]

j j j

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ó

[box icon= info]Continúa en…

Escalar ágil [2/2] – El desenlace

[/box]

j j j

Mesa redonda en La Salle sobre metodologías ágiles

El mates 14 de Febrero, San Valentín, me invitaron a participar en el Breakfast La Salle sobre metodologías ágiles, para hablar de mis dos amores: agile y Runroom.

Tras una rápida introducción a las metodologías ágiles de 13 minutos de Xavier Albaladejo (Agile-Lean Coach y experto en Gobierno TI de everis), tuve el honor de compartir el panel de debate con Adrian Perreau de Pinninck (Artificial lntelligence Researcher y Project Manager de Intelligent Pharma), Miquel Mora (CIO y socio fundador de yaencontre.com) y Laurentiu Neamtu (coordinador del Postgrado en Métodos Ágiles de La Salle Campus Barcelona).

Espero que os resulte interesante! :)

Mira si soy chulo que voy sin afeitar…

j j j

Cultura corporativa amb folre i manilles

Hay algunas personas, muy poquitas, los elegidos diría yo, que son capaces de cambiar tu percepción de la vida en tan sólo un par de conversaciones. Para mi, Ángel Medinilla es uno de ellos.

Cada vez que hablo con él, cada vez que coincidimos, mi visión de la empresa, del equipo, del negocio, del oficio, evoluciona un pasito más.

En esta ocasión, tuve la suerte de asistir a un par de sesiones sobre Cultura Corporativa que Ángel impartió junto a Álex Barrera, otra bestia parda a quien no tenía el placer de conocer, en el contexto de la Scrumweek que se celebró en Barcelona la semana del 7 al 11 de noviembre.

Unas sesiones inspiradoras, donde la temática central bailó alrededor de los conceptos tribales de The tribal leadership y sus cinco niveles. Compartimos experiencias y situaciones del día a día, identificamos los distintos roles que cada uno de nosotros adoptamos y entendimos cómo articular los mecanismos necesarios para resolver problemas de cohesión y motivación en el equipo.

Podréis imaginarme babeando henchido de orgullo cuando, en una de las diapositivas, apareció la foto de medio equipo de Runroom posando con la camiseta y Álex nos puso de ejemplo de tribu nivel 4, es decir, de equipo ultra motivado, cohesionado, implicado y con valores de equipo. Pude ver orgullo también en las caras del resto de runroomers que asistieron.

La tribu Runroom

El domingo hice 40km con mi familia con el fin de acercarme a presenciar por primera vez un espectáculo que ya es, desde hace un año, Patrimonio de la Humanidad: los “castells“. Asistí pues al intento por parte de los Minyons de Terrassa de repetir la hazaña que mantienen desde 2002 como hito histórico, jamás logrado por nadie más que ellos: cargar y descargar un 3 de 10 amb folre i manilles, que en términos profanos vendría a ser una torre de 10 pisos, con 3 personas por planta, reforzados en los cimientos por grandes piñas humanas formadas por varios cientos de forzudos estratégicamente colocados en tres pisos que quitan el aliento.

Folre i manilles 3 de 10

Es difícil describir lo que se siente al presenciar un 3 de 10. Incluso habiendo visto varias jornadas castelleres por la TV, como es mi caso, no podía imaginarme la profunda emoción que experimenté. Escuchar el murmullo de tensión de la multitud, sentir el calor de la plaza, concentrada y expectante mientras los valientes tiemblan de esfuerzo, los ágiles dosos escalando la torre humana que ya tremola al son de las gralles… Buscar en los ojos de los que me rodeaban el brillo que ya notaba en los míos, y entender que estaba presenciando algo único que quedaría en la memoria de todos los que allí conteníamos el aliento con los ojos clavados en la enxaneta, una niña finita y grácil, que demostró tener la determinación de quien conoce su destino. 

Recordé las palabras de Ángel:

“Un equipo de nivel 4 necesita un Gran Reto, algo que represente una oportunidad única en la vida. Cuando llega ese reto y el equipo acepta el desafío, se produce ese momento de catarsis colectiva, sin importar el éxito o el fracaso. El nivel 5 es un estado transitorio que se da rara vez en la vida.”

Coraje, orgullo, pasión, identidad, solidaridad, sacrificio, humildad, excelencia técnica, superación. Son los valores de equipo que percibí allí, los que me hicieron emocionarme y los que me ponen la piel de gallina mientras escribo estas líneas.

Curiosamente, los mismos valores que compartimos ese grupo de espartanos que hacemos posible un proyecto que aún me sorprende cuando miro atrás y repaso el camino recorrido desde la distancia.

No importó que no lograsen su objetivo. Todos los que estábamos allí hubiésemos dado un brazo por ser parte de ese “fracaso”, por formar parte de esa tribu.

Castells

Os dejo un vídeo del momento histórico en que els Minyons logran cargar y descargar un 3 de 10. No es lo mismo que estar allí, pero mejor que mi ladrillo intentando explicarlo será, digo yo!

j j j