Experiencias en un entorno cuasi ágil

srum-or-not-to-scrum

Este año pasado terminó mi andanza en una multinacional en el que trabajaba en un entorno ágil o eso queríamos creer. En mi caso confluyeron varios factores: no participé en el diseño de la metodología, es decir, que cuando yo entré ya estaba implantada; empecé como programador, lo que me permitió verlo desde esta perspectiva; terminé como jefe técnico (Tech leader), lo que me dió otra visión y lo último, no conocía nada de nada sobre agilismo, scrum o afines cuando empecé.

Después de un par de años dentro de la dinámica SCRUM (que era la técnica ágil implantada en mi empresa) y estudiando un poco el tema, me di cuenta de varias cosas:

  • No estábamos haciendo realmente SCRUM.
  • No había compromiso por parte del equipo de dirección.
  • No se hacían esfuerzos por atraer al equipo a la tecnología (se imponía y punto pelota)
  • Siempre se cuestionaba porque no obteníamos los resultados esperados.
  • Las herramientas daban más problemas que solucionar, en mi caso JIRA y AccuRev.

Os contaré un poco más en detalle cada punto y espero que esto ayude en otros proyectos a no cometer los mismos errores o a buscar soluciones a los mismos.

Cuando digo que no hacíamos SCRUM, me refiero al enfoque tradicional del método, por ejemplo, no hacíamos retrospectivas. No se hacían retrospectivas porque no había tiempo y porque no tenían utilidad según los directores (“Si ha salido algo mál es culpa vuestra por no hacerlo el método y sus parámetros han sido establecidos por auténticos expertos”). Como no sé ni cuándo ni cómo ni quién tomó la decisión de implementar SCRUM y sus parámetros, no puedo saber si el error viene de lejos o no, aunque tiene toda la pinta.

Otra cosa que no hacíamos bien era la reunión diaria, cuando era programador, básicamente decíamos qué habíamos resuelto (en código JIRA)  y que íbamos a hacer. Algo como esto “Solved 4356, 4357 and 4358, 5589 is in progress and I hope start 5564 and 5565”, ni que decir tiene que os podéis imaginar mi cara los primeros días que asistí a la reunión. Lo que más eché en falta es la otra parte y que realmente es la importante qué o quién me frena en mi trabajo y qué problemas que no puedo resolver por mi mismo tengo. Esta segunda parte la puse en funcionamiento cuando promocioné a jefe técnico y el cambio fue brutal, no necesitaba la retahíla de números sin sentido si no problema que yo debía solucionar, tomarle el pulso diario al proyecto de forma personal. También he de decir que la reunion diaria era un poco un grupo de excusas por orden pero es algo inevitable, no todo el mundo va al mismo ritmo.  Otra deficiencia, sólo íbamos a la reunion los desarrolladores y el jefe técnico, ni testers, ni BM, ni nadie. Cuando las cosas pintaban mal acudía el jefe de desarrollo pero más que nada a meter miedo en el cuerpo.

El equipo de dirección solo tenía un método de medida, ventas, ni más ni menos. Os digo una cosa no me parece mal, realmente era el único item medible de nuestro trabajo, si se vendía bien o mal y cuanto se vendía. Lo que no estoy de acuerdo de que de toda la cadena involucrada en esa venta el mayor culpable fueran los desarrolladores por no tener las cosas a tiempo. Nunca se pensó igual es el método que no funciona, ¿lo revisamos? ¿igual la comunicación entre negocios (business managers) y desarrollo no es eficiente? ¿igual podemos poner otro enfoque en este proyecto pequeño? ¿Que tal Kanban?. Nada, inclusive me pareció un poco desmotivador que el ratio defectos / funcionalidades no se tenía en cuenta. Si el producto era un desastre o un monstruo de programación y fallo, no pasaba nada mientras se vendiese. El enfrentamiento entre negocio y desarrollo era feroz y continuo.

Otro problema era la planificación semanal, no teníamos tiempo reservado para hacerla en condiciones (me refiero el equipo) al final el jefe técnico hablaba con negocio de las prioridades (otro tema para hacer un post) y repartia el trabajo deprisa entre desarrolladores y estos hacías las subtareas de duración diaria, luego se revisaba y se escribía un documento larguísimo con compromisos, explicaciones, JIRA asociados, etc. etc. que se firmaba por mucha gente y se presentaba en la reunión semanal de jefes técnico al jefe de desarrollo. Yo creo que nunca hemos cumplido ese documento, era irreal, nunca se tenía en cuenta el entorno cambiante, los bugs, lo cambios de personal. etc.

Lo de las herramientas era todo una historia, para mi no fue complicado entender el objetivo de las mismas aunque no había programado nunca en un entorno ágil, JIRA es muy potente con las vistas y demás y como jefe técnico tuve que trabajar mucho más intensamente con él, para definir planificaciones y asignaciones. JIRA es sencillo en su inicio, pero yo me encontré con: todo el mundo ponía JIRA en los proyectos, los BM (bussines managers). los PM (Producto Managers), los testers, los jefes de desarrollo, los arquitectos, algunos usuario internos, los jefes técnicos, etc. Inmanejable, en cuanto alguien decía que no se le respondía en tiempo o que hacía 4 semanas que había pedido no se qué cambio o nueva funcionalidad, se le decía “para hacerlo más rápido pon tú el JIRA” y hala, otro usuario más poniendo JIRAs. Había tareas repetidas, duplicadas, cerradas y reabiertas, en el producto comercial y todavía abiertas. Luego cuando los greenhopers no cuadraban cambiábamos los periodos o sacábamos tareas y listo, todo graficamente bonito.

La integración entre accurev y JIRA una muerte, AccuRev solo daba problemas a la hora de mantener el código, además teníamos otro repositorio con SVN para poder hacer las cosas rápido (construir el producto duraba entre 5-6h siempre y cuando todas las dependencias estuvieran preparadas) con lo que el trabajo duplicado y las inconsistencias estaban a la orden del día, nos pasábamos más tiempo peleando con JIRA y con AccuRev qué desarrollando código.

Ah, y por su puesto no habéis oído nada de TDD, CI porque no se hacía nada de eso. Los testers aconsejaban que tuviésemos test unitarios para alguna partes, pero con cuidado porque a veces su entorno de test se rompía con muchos test unitarios.

Ahora mis aportaciones que han funcionado mucho mejor de lo que yo esperaba.

Por mi cuenta he ido trabajando todas esas áreas, dentro y fuera de la empresa. Me formé en TDD y agilismo porque era mi obligación ética, por suerte hay mucha información de calidad en la red (no me cansaré de recomendar el libro de Carlos Blé Diseño Ágil con TDD). Eso te da tranquilidad, primero porque entiendes qué haces y porqué lo haces y puedes aportar de forma mucho más efectiva.

  1. Mejor comunicación negocio – desarrollo (business – development) por suerte mi BM era un chaval joven que quería mejorar y con la mente abierta. Lo introduje dentro de las reuniones diarias para que escuchase de primera mano problemas y soluciones y supiera qué decir a usuario y jefes sobre el proyecto. Esto es básico para que los desarrolladores aprendamos el lenguaje del negocio y los de negocio confíen en nosotros, ser una piña.
  2. Mejores reuniones diarias. En mi reunión nada de números, de eso ya me encargaría yo como jefe técnico. Problemas, soluciones y preguntas. Es increíble la sinergia que se puede dar en personas afines, unos desarrolladores ayudaban a otros, los BM echaban una mano, si se generaba una discusión la paraba y la planificaba para más adelante, hay que mantener la reunión lo más corta posible. Es importante que los programadores hablen entre ellos, es inevitable que hay programadores más experimentados y capacitados y otros menos, pero creo que el jefe técnico tiene que ser el interfaz entre ellos. Los programadores estrellas son reacios a ayudar y muy dados a esperar crédito, hay que darles ambas cosas, no pasa nada, el objetivo es equipo.
  3. Mancharse las manos. El enfoque “Ahora soy jefe técnico, no puedo programar lo mio es de alto nivel, yo mando” chorradas, hay que ponerse al lado de tu equipo y escribir código, ya sea más o menos. Establece tus prioridades entre planificación y gestión y codificación, que los tuyo sepan que sabes de qué hablas cuando das consejos. Que sigas aprendiendo de tu equipo, que no te importe cagarla y quedar el ridículo al codificar, no pasa nada, aprende y hazte cercano a tu equipo. Siéntate con el BM y que te explique su trabajo y su lenguaje del negocio, las peculiaridades, los usuarios clave, etc. Habla con tu jefe de desarrollo, pregúntale, cuestiónale, puedes aprender mucho del negocio a alto nivel, que te ayudará en tu día a día.
  4. Mayor transmisión entre desarrolladores, por desgracia la rotación de personal y de proyectos era alta, lo cual no ayudaba mucho a tener un equipo constante y cohesionado. Establecí unos documentos de “primeros días” dandole al nuevo integrante un margen de una semana para familiarizarse con herramientas y técnicas, esto no fue muy bien, era muy complicado y dependía de la persona. Igual otro enfoque como pair programming o asignar un mentor hubiera sido mejor, no lo sé.
  5. Sugerir bibliografía y eventos, el 90% de los desarrolladores no se actualizaba de forma periódica, es decir, no leia o seguía blog o comunidades afines a su campo de trabajo. Cuando necesitaban una librería la usaban y aprendían pero no intentaba mejorar de forma continua. Yo una vez a la semana les mandaba un correo con lecturas o eventos que me parecían interesantes para el proyecto o los individuos.
  6. Reducir al máximo las duplicidades en JIRA. Eliminé muchos usuarios que podían poner JIRAS y dependiendo de su perfil me lo asigné a mi o a nuestro BM. eso era cargarnos con mucho trabajo pero era la única forma de controlar un poco el tema, a veces fue bien, a veces no, hubo gente que se negó a quitarse sus privilegios de mandar sobre los desarrolladores y la jerarquía manda en estas empresas.
  7. Automatizar en lo posible la construcción de ejecutables, Se intentó definir una política de entregables consistente y automatizable, pero no salió muy bien, las fechas de los entregables oficiales estaban marcadas hasta el 2020 y eran inamovibles, además mi experiencia con integración o construcción continua eran nulos o muy básicos y no pude hacerlo de forma eficiente, unos cuantos scripts ANT que creo que cuando yo me fui tirarían a la basura porque no eran intuitivos ni fáciles de mantener.
  8. Premiar a los buenos desarrolladores y ayudar a los más lentos. Esto es una cuestión delicada, no todo el mundo es igual, y hay que intentar que todo el mundo se sienta bien y respetado en el equipo. Hay programadores que hacen el doble que otros pero esos otros tiene un conocimiento esencial del sistema. A los dos hay que tenerlos contento para que colaboren y no se quemen. Es la tarea más compleja de un jefe técnico.

En esta experiencia en una multinacional he aprendido muchas cosas, algunas que no me gustaría repetir, otrás que sí y otras que me gustaría haber mejorado e intento formarme todos los días para la próxima vez hacerlo mejor. Lo que sí he aprendido es que el valor humano es imprescindible para cualquier proyecto, un entorno sano y no viciado, sea ágil o caótico es un ambiento donde trabaja a gusto, cada persona es mundo y el trabajo de los jefes hacer equipos de trabajo y no grupos de desarrollo.

Para otro post mis reflexiones sobre el outsourcing que también teníamos en nuestro proyecto.

Anuncios

Un comentario en “Experiencias en un entorno cuasi ágil

  1. Antonio, felicidades, me parece una entrada realmente interesante y trabajada. El problema no es tanto Scrum, ni otras herramientas ágiles sino las enormes disfuncionalidades que se dan en muchas empresas. Más que Scrum lo que necesita es gente equilibrada.

    Un saludo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s