Archivos para julio, 2012

Así empezó todo

Publicado: 15 julio, 2012 en Agile

Desde las trincheras

Muchos son los profesionales y empresas que empiezan a mostrar su interés por las metodologías Ágiles en nuestro país. También son muchos los que hace ya años que están aplicando esta filosofía de trabajo pero debemos reconocer que en España, por regla general, tendemos a ver y aplicar por primera vez nuevas prácticas y tecnologías cuando en el resto de países ya llevan décadas demostrando casos de éxito, sobretodo en Norte de Europa y Estados Unidos.

Pero nunca es tarde si la dicha es buena.

En mi caso tampoco soy una excepción. Con más de 18 años en el sector tecnológico , la gran mayoría de los cuales centrados en servicios de consultoría y gestión de proyectos informáticos. Y lamentablemente, o por fortuna, muchos de dichos proyectos fracasaron. Fracasaron en muchas ocasiones como proyecto y muchas tantas veces como producto. Todo depende de quien resulta afectado por la mala praxis.

El hecho es que hace unos 4 años tuve la necesidad de cambiar las prácticas, las acciones y las decisiones que me rodeaban y empecé a ponerlo en práctica con un cadáver. Un proyecto tocado de muerte con decenas de miles de horas consumidas (que no invertidas), un cliente a punto de denunciar por daños y perjuicios, un equipo desmotivado al borde del abandono y un producto… inexistente!

En ese momento se me encomienda una jocosa misión: “Te asignamos el proyecto para que lo acabes en 2.000 horas. Punto”.

Tras unas jornadas dedicado a revisar documentación de análisis, alguna pantalla CRUD ya desarrollada, a hablar con el equipo y con los anteriores responsables para tener visión de viabilidad y plazos. Todos me decían: “Yo lo estimé en más de 7.000 horas, pero (a los jefes) no les cuadraba”.

En ese momento, en la primera reunión de cambio de responsable de proyecto, se me pone delante un cliente con odio en su mirada y lo que me pedía el cuerpo era decirle: “Te hemos engañado. Aquí no hay nada que hacer”. En lugar de tirar la toalla le propuse algo absurdo. Le propuse abandonar toda la documentación generada y empezar de cero.

Le propuse reunirnos cada Lunes durante toda la mañana. Él me explicaría la funcionalidad más Core. Aquella sin la cual el producto no tenía razón de ser. Y el objetivo era, habiendo entendido su requerimiento, empezar a trabajar en su diseño y desarrollo para tenerlo listo el Lunes siguiente. El cliente lo aceptó y allí empezamos a ser Ágiles sin saberlo. El pacto con el cliente es que él podría cortar el proyecto cuando quisiera y volver a amenazarnos con llevarnos a juicio si lo que hacíamos no le convencía. Así empezamos nuestros Sprints semanales y nuestro Contrato Ágil al uso.

El gran error que cometí fue que a esas reuniones de toma de requerimientos empecé a ir yo sólo con el cliente, y luego hacía un informe a modo de acta de la reunión que luego explicaba al equipo técnico para que procedieran a su desarrollo. Lo resolví raudo y al segundo mes el equipo ya asistía conmigo a dichas reuniones. Con el tiempo conocí el concepto de Sprint Planning y me alegró comprobar que es justo lo que veníamos haciendo. El cliente (Product Owner) nos explicaba las funcionalidad más prioritarias, el equipo exponía sus dudas y riesgos y cuando estimabamos que ya teniamos suficiente carga de trabajo dábamos por acabada la reunión.

Cada lunes, antes de tomar más requerimientos, le presentábamos al cliente las funcionalidades implementadas. Nada de esquemas ni documentos de análisis sino una versión nueva de la aplicación instalada en nuestro servidor interno de preproducción. Tras casi una hora de “jugar” con la aplicación se confirmaba si cubría la necesario o si debíamos modificar o añadir algo más. Y así resultó que estábamos haciendo Demo Reviews. Evidentemente las necesidades de mejora surgidas en la Demo se añadían a la lista de tareas a implementar y se decidía si debían tratarse de forma inmediata o si se posponían a futuras iteraciones de trabajo.

Y así, poco a poco, semana tras semana, se fue entregando valor y se fue ganando al cliente. Aun así, la decisión realmente Ágil hubiese sido hacerle ver al cliente que él no necesitaba dicha aplicación ya que era evidente para todos que era algo inalcanzable, y que ya existían en el mercado plataformas similares. Pero esa valentía y sinceridad me ha costado 40 años adquirirla.

Justo ahora, con muchos sprints a mis espaldas, no tengo duda de cuales son las prácticas que pueden originar la rápida mejora de un equipo de trabajo, y que justamente es lo que nunca llegamos a implementar en ese proyecto:

  • Visual Management: Antes que cualquier otra actividad o acción de mejora, es mejor explicitar tu proceso actual. Hazlo ocupando una pared para favorecer la transparencia y la participación de todos los implicados.
  • Retrospectivas: Encuentra periódicamente el momento para compartir con el equipo, o la organización, la visión de cada uno de los miembros. El objetivo es realimentar el proceso para lograr entre todos su mejora. La clave del éxito de las sesiones de retrospectiva es que las personas se comprometan con las acciones de mejora que surjan de ellas.
  • Métricas: Si se quiere mejorar se debe mejorar sobre algo concreto, y ese algo debe ser la clave del Valor que se está generando (no sirven “Horas consumidas”). Y sobre ese algo concreto se deberá tener una medición de la situación actual y una estimación de la situación objetivo. Y ese objetivo debería tener una componente temporal para explicitar el orden de magnitud de l esfuerzo necesario para cumplirlo. Es decir, no sirve decir “Comer menos” si se pretende iniciar una dieta para bajar peso. En cambio: “Pasar de 81 a 75 kilos antes de fin de año” es medible y su resultado cuantificable.

Y sobretodo y  ante todo, no nos olvidemos que se trata de personas trabajando con personas y para personas. Aunque este slogan prefiero obviarlo.

Por ahora nada más!

Os animo a todos a agilizar vuestros equipos y organizaciones. De hacerlo así la mejora de vuestro proceso no tardará en llegar.

Anuncios