Mi transformación ágil

Me he dado cuenta de que nunca he puesto por escrito cómo fue "mi transformación ágil". Que transformó el proyecto en el que trabajaba pero también a mí misma.
Aquí va la historia.

Año 2015 (o fue en 2016?). Después de más de 2 años en el proyecto, y una bajada de trabajo (y presupuesto) tremenda, solo quedamos 6 personas (más el jefe).

Éramos casi silos independientes. El jefe daba tarea a cada uno de nosotros, y apenas sabíamos lo que hacían los demás. Era como estar en cubículos al estilo americano.

A veces al marcharme a casa, veía como otro compañero se quedaba con algún marrón. Nadie le ayudaba (ni yo) y básicamente era mutuo.

Pero algo estaba cambiando en el cliente para el que trabajábamos. Estaban implantando algo llamado "agilidad" y nuestro responsable del cliente quiso subirse al barco.  Nos explicó que quería implantarlo en nuestro proyecto, y que íbamos a tener una serie de reuniones con un "coach agile" para que nos guiase en el camino.

Y así fue. Primero empezamos conociendo de qué iba eso de la agilidad un poco "por encima" y luego nos hablaron de Scrum y Kanban. La gente del cliente había recibido formación pero nosotros (como empresa externa) estábamos totalmente verdes.

Nos hablaron de las ceremonias, la daily, la retro, la review y la retrospectiva. Y que necesitábamos un Scrum Master. Ahí yo levanté la mano: me presento voluntaria! Ya que la coach había dicho que el jefe no podría hacer ese rol, vi la oportunidad y me lancé.

Nos preguntó qué tipo de tareas hacíamos. ¿Evolutivos o incidencias? Nosotros hacíamos sobre todo evolutivos, aunque también tratábamos las incidencias de producción. Nos propuso tener 2 tableros, uno para los evolutivos y otro para las incidencias.

Tuvimos que definir nuestro tablero para evolutivos (llamémosle tablero Scrum), identificar las columnas que queríamos visualizar, cómo indicar que teníamos algo bloqueado, cómo saber quién estaba tratando ese ticket... (pensad que era todo en físico, no usábamos ninguna herramienta tipo Jira).

El tablero Kanban

Para las incidencias usábamos un tablero kanban básico: to do, doing, done. Y a un lado un contador: ¡Llevamos x días sin incidencias! xD

El tablero Scrum

Tenía unas cuantas columnas. Recuerdo que había una parte para "los Product Owner" para que pudiesen indicar los tickets en los que estaban trabajando. Digamos que ellos tenían su propio "to do, doing, done". Y luego estaban las columnas para lo que estábamos desarrollando en ese sprint.

Desarrollo, tests unitarios, tests de integración, tests de usuario, listo para subir a producción, en producción.

El sprint

Inicialmente definimos que nuestros sprints durarían 3 semanas y con el tiempo pasamos a sprints de 2 semanas. Y no tardamos mucho la verdad.

En el cliente se hacían subidas a producción planificadas cada 2 semanas, así que los sprints de 2 semanas nos permitía alinearnos y subir a producción lo más rápido posible.

Las historias de usuario

En todo ese tiempo no escuché hablar de historias de usuario, pero sí que definimos entre todos qué información debía figurar en los post-it: 

• 

  Mi avatar :-)

  Título resumen para saber de qué iba el evolutivo.
• Horas de trabajo estimadas (no sabíamos lo que eran puntos historia), fecha prevista de subida a producción.
• Tecnología en la que había que desarrollar (podía ser cobol, o una herramienta con código propio que usábamos para la generación de documentos, o javascript para el front).
• Quién estaba con el desarrollo (para esto imprimimos unos avatares para identificar a cada persona del equipo).
  
• Dependencias con otros equipos.
• Quién era el peticionario (hacíamos evolutivos para diferentes departamentos del cliente).

Los bloqueos y las dependencias

Si un ticket estaba bloqueado, le poníamos un punto rojo (una pegatina xd), y si tenía dependencias por resolver, un punto azul.

De las dependencias se encargaba la gente del cliente ya que nosotros no teníamos digamos "autoridad" para reclamar según que cosas a otros departamentos.

Las estimaciones

Nosotros éramos todos de un mismo proveedor, y facturábamos por evolutivo realizado. Cada evolutivo se estimaba en horas siguiendo un ábaco que estaba "validado" por el cliente. Aunque en ocasiones lo usábamos simplemente para que reflejase las horas que nosotros considerábamos que eran necesarias.

Las estimaciones junto con el análisis técnico las solíamos hacer los que conocíamos mejor la aplicación. No significa que no hablásemos entre nosotros, pero teniendo en cuenta que yo era la que menos tiempo llevaba en el proyecto y lleva 3 años, podemos decir que éramos un equipo muy maduro, que conocía muy bien la aplicación, y que no solíamos errar el tiro en las estimaciones.

Nunca llegué a estimar en story points en ese equipo.

La capacidad

La calculábamos en horas teniendo en cuenta cuántos días íbamos a trabajar ese sprint, y de ahí restábamos las horas de ceremonias. Cada uno se preocupaba de conocer su capacidad antes de ir al sprint planning, y lo solíamos compartir en un excel para que tuviésemos la info de todo el equipo en un mismo sitio.

Para las incidencias, cada sprint, o cada 2 sprint, se ocupaba una persona. En caso de que no hubiese incidencias, trabajaría en algún ticket de evolutivos. Lo quisimos hacer rotativo porque encargarse de la producción siempre es agobiante. No era justo que siempre estuviese el mismo...

La autoorganización

Esto fue lo que más nos cambió. Como decía, trabajábamos cada uno en nuestro cubículo y eso no era compatible con la agilidad. Ahora los PO (el cliente) iba a presentarnos lo que querían realizar de cara al próximo sprint, y nosotros, el equipo, decidiríamos cuánto podíamos hacer y quién haría qué.

Ya nadie nos asignaría una tarea, la cogeríamos nosotros.

Esto al jefe no le gustó nada. La agilidad le quitaba totalmente el control sobre las personas. Vio un peligro ahí y empezó a revolverse: no quería aceptar la agilidad.

Lamentablemente para él, el hecho de que se opusiese a la agilidad hizo que nos uniésemos más como grupo: todos veíamos ventajas en pasar a trabajar así y, aprovechando que la petición venía del cliente, no íbamos a quedarnos callados.

Como yo había sido voluntaria para ser Scrum Master, me tocó lidiar con esta situación.

Reunión a 4 bandas (mi jefe, el cliente, la coach agile y yo como Scrum Master)

Antes de esta reunión me había reunido con el equipo para saber qué querían hacer: peleábamos por la agilidad o no? El resultado fue un sí rotundo. Queremos ser ágiles!

El hecho de vernos reunidos sin él, mosqueó mucho al jefe.

Al llegar a la reunión sabía que me iba a tocar enfrentarme a él. Y así fue.

No sé muy bien cómo pero acabamos hablando de nuestra situación como equipo, a lo que respondí que ahora mismo no éramos un equipo, tan solo individuos cada uno trabajando en sus cosas. Pero en agilidad, tendríamos un compromiso compartido, el compromiso del equipo, y trabajaríamos juntos para alcanzarlo. Además de que desde que habíamos empezado a "transformarnos" la gente estaba más animada.

Recuerdo que la coach me preguntó algo como "pero algo habrá que os empuje a levantaros cada día para venir a trabajar". A lo que respondí: claro que sí, cobrar a final de mes.

Aquí mi jefe estalló en llamas. En su cabeza, éramos todos súper amigos y nos llevábamos genial, y nos encantaba nuestro trabajo y nos apoyábamos unos a otros. Vivía en un mundo paralelo de fantasía!

Sabía que aquella reunión me traería consecuencias. Pero cuando vives con una carta de dimisión en el cajón a la que solo le falta la fecha en la que causarás baja... poco te importa.

La magia de la agilidad

Desde que empezamos a adquirir compromisos como equipo, la vida mejoró para todos. Cuando a uno le iba muy bien, se ponía a ayudar al otro que no le iba tan bien, para cumplir con el sprint goal.

La gente dejó de quedarse después de la hora. Si el cliente quería añadir una tarea "urgente" debía quitar otra equivalente.

Solamente por eso, habían valido la pena las broncas con el jefe.

Las habilidades en T

Lo comenté por encima en "El camino hacia el dominio II: un equipo con 11 delanteros". Yo era de cobol y sólo hacía tareas de cobol. Pero al llegar la agilidad me lo replanteé. Aceptaría aprender a trabajar con la herramienta chunga de los documentos si pasábamos a agilidad. Pero no me afectó solo a mí.

A raíz de poder elegir nuestras propias tareas, otras personas empezaron a pedir tareas de cobol para poder aprender. También pasó a nivel funcional: la gente empezó a pedir tareas de áreas que no conocían para aumentar su conocimiento de la aplicación.

¡Todo de forma natural!

Conclusión:

La auto organización, hizo que las personas del equipo se interesasen en adquirir habilidades en T.

La auto organización, hizo que las disfunciones de nuestro equipo empezasen a desaparecer.

La auto organización, hizo que las personas volviesen a estar motivadas.

¿He dicho ya que la clave fue la auto organización? :-P

No fue fácil, no fue rápido, pero marcó un antes y un después. Y por eso siempre seré del #teamAgile :-)

#thisistheway