Nueva vida: semana 4

Con retraso. Este fin de semana llegaba con las pilas descargadas y encima tenía faena familiar (el cumple de niño1) y que madrugar para ver a Fernando Alonso ganando en una especie de circuito de F1.

Estuve a mitad de semana a punto de escribir algo porque teníamos el segundo paso a producción, no pudo ser y me quedé un poco chafado. No poner en producción no era realmente lo que más me fastidiaba. Hombre, hubiera estado muy bien poder seguir progresando y poniendo software que funciona en producción para que el cliente fuera viendo que las cosas van a mejor y reduciendo la presión sobre las capas de arriba y, consecuentemente, sobre el resto de los implicados/afectados. Pero bueno, visto con perspectiva, tampoco ha estado mal. He pensado en qué cosas hemos estado haciendo mal (especialmente yo, que soy quien está impulsando el proceso de cambio).

Tengo la sensación de que no he hecho bien (e.d. he hecho mal) varias cosas que nos han llevado a no poder controlar la situación y, simplemente, poner en producción lo que había listo. Que hubiera sido lo razonable.

Ya he contado antes que este proyecto es muy chungo, pero eso no quiere decir que sea aceptable caer en fallos típicos como:

  • ceder a las urgencias
  • no ir acabando historias en el orden de prioridad establecido

así que ya sabía cuáles eran las grandes fuerzas contra las que tenía que luchar. Y sin embargo, se me olvidó lo más importante: para lograr el cambio es necesario ser fiel a los principios, que son la verdadera fuerza que contrarresta a las otras. No soy yo la fuerza que logrará el cambio. Eso, además de una pedantería, es una necedad. Hoy he leído un twit que viene muy al pelo:

Si quieres ir rápido ve solo. Si quieres ir lejos ve acompañado.

Se me olvidaron dos cosas fundamentales:

  1. Delegar. El equipo puede hacer muchas, muchas cosas que yo, por muy superhombre que me pueda sentir en un momento dado, no puedo hacer solo. Lo único que estaba consiguiendo al no delegar era desgastarme y perder el foco, es decir, NO hacer bien mi trabajo.
  2. Ritmo sostenible. Estaba haciendo un gran esfuerzo buscando el hacer posibles ciertas tareas. Al final, el cansancio me pudo y cometí errores y descuidé otras tareas más importantes. Se me olvidó que el ritmo sostenible es para todos, no sólo para los demás.

Así que, viendo la inevitabilidad del fracaso en el paso a producción (se nos descontroló el encoding en los ficheros de propiedades con los literales de los mensajes que aparecen en la aplicación, alguna funcionalidad que no estaba del todo bien cerrada y mi propio desenfoque en las tareas necesarias para controlar cuáles eran las funcionalidades que queríamos poner en producción), organicé una reunión para revisar el proceso de paso a producción y la organización interna del equipo.

Así, hemos oficializado la separación del equipo de desarrollo y de soporte a la producción. He delegado las tareas de todo lo relacionado con el soporte a la producción. Ojo, se delegan las tareas, no la responsabilidad. Si algo no se hace como es debido será mi culpa. Pero sé que he delegado eso en la persona más apta para hacerlo. Es lo mejor para todos y, en el fondo, lo único que estamos haciendo es reconocer una organización de las tareas que estaba ocurriendo de facto.

El otro cambio consiste en hacer (o tratar de hacer) entregas en producción todas las semanas. Como diría UncleBob: “¡como lo hacen los verdaderos hombres!”. Aceleramos el ciclo de release para obtener feedback mucho más rápido y, sobre todo, para poder forzar a toda la organización a desembarazarse del “efecto release”. Estoy empujando mucho para que todas las funcionalidades se troceen en cachitos pequeños. Requisitos que dejen de tener títulos generales, de esos que aparecen en el primer nivel del dichoso documento de Análisis Funcional que NADIE-ABSOLUTAMENTE-NADIE se ha leido, por más que se haya pagado por él.

Poco a poco los compañeros se van acercando a los libros que tengo sobre la mesa. El otro día uno de ellos, un viejo programador de COBOL y NATURAL me pidió el “User Stories Applied” de Mike Cohn. Casi me echo a llorar de alegría. Y mañana le llevo el “Implementation Patterns” a otro compañero. Veremos si éste se lo lee. El inglés, ese viejo enemigo… 🙂

Y finalmente. El viernes tuvimos nuestra segunda retrospectiva. Estuvo menos bien que la primera, fundamentalmente porque no la facilité bien. Perdí el foco varias veces y no conseguí que la gente participara con la frescura que lo hizo en la primera. Debo prepararlas un poco mejor. La retrospectiva es clave para tomarle el pulso al proyecto desde el punto de vista del equipo. Aun así salió bastante bien y el equipo sacó temas muy interesantes:

  • Queremos un protocolo para gestionar bien las peticiones que nos llegan desde el exterior. Normalmente al equipo se le interrumpía muchísimo con peticiones por correo, por teléfono, físicamente, y todas urgentísimas. Evitar esto es algo que les preocupa muchísimo. Afortunada o desgraciadamente los que pueden hacernos de PO (dueño de producto) están muy lejos y se está usando Mantis para tratar de organizar la comunicación con ellos. Así que el equipo ha reclamado un flujo de trabajo bien definido para esto.
  • Algunos miembros del equipo nos hemos incorporado hace bien poco, por lo que no tenemos NI IDEA de qué va la aplicación y ni siquiera el negocio que trata de resolver la aplicación. Por eso hemos reclamado una formación específica en ambos terrenos.
  • Las reuniones diarias se siguen alargando demasiado. Hemos identificado que hay un miembro del equipo (concretamente yo) que alarga mucho sus intervenciones y que a veces nos descentramos y no nos dedicamos exclusivamente a responder a “las tres preguntas” (hombre, a veces hay que comentar un poco, para que fluya la información, pero a veces nos pasamos…). Hemos decidido que un voluntario, ¡Bravo Víctor!, tomará el rol de moderador. Bueno, será el martes porque hoy lunes se nos olvidó a todos. 🙂

Hubo dos cosas que me llamó la atención en esta última retrospectiva:

  • la primera es que nadie (ni yo mismo) nombró el hecho de que había sido un fracaso no poder poner en producción (bueno, sí, fue llamativa la frase “no pasamos a producción pero no hubo gritos como otras veces”). Yo diría que eso es bueno, pero no sé…
  • y la segunda es que a mi pregunta de si el nuevo proceso les gustaba o les resultaba molesto alguien contestó: “nos sentimos mejor aprovechados” y “nos sentimos más equipo”.

¡Subidón!

  • Rafa

    El conseguir manejar correctamente las interrupciones creo que es el punto mas complejo de tener un equipo agil. El entorno suele estar malacostumbrado a que sus deseos sean resueltos inmediatamente aunque no sean urgentes. Hay que conseguir que todo el mundo reme en la misma direccion para llegar a buen puerto.

    • jmbeas

      Tienes toda, toda, toda la razón. Pero también están las interrupciones propias, las que nos hacemos a nosotros mismos, no sólo haciendo más de una cosa a la vez, sino físicamente interrumpiendo nuestra actividad, fundamentalmente por falta de planificación (a nivel de tareas personales). Hablaría de la técnica del pomodoro, pero no estoy siendo un gran ejemplo: me está costando horrores aplicar la técnica. 🙁

  • Pingback: Tweets that mention Se hace camino al andar… » Blog Archive » Nueva vida: semana 4 -- Topsy.com()

  • Y si haces “pomodoros generales sincronizados” como hace Xavi Gost en BeCode? el día que estuve allí con ellos me encantó la idea, todo el mundo estaba enfocado en los mismos periodos de tiempo y luego se hacía una breve reunión por si a alguien le había surgido algo en ese tiempo o necesita de algo para el próximo, pero sin ser una interrupción, puedes retrasar el comienzo del pomodoro pero todos tienen que empezar juntos 🙂

    • jmbeas

      Es una buena idea, Kini, pero me temo que el entorno no es aún el adecuado para una dinámica tan disciplinada. De los tres grandes temas en los que trabajo: ritmo sostenible, autoexigencia y autodisciplina, creo que la autodisciplina llega siempre la última. (Dependiendo de la personalidad del equipo, el ritmo sostenible viene impuesto para conseguir la autoexigencia, o viene como objetivo que le das al equipo que ya es autoexigente)