No lo llames Agile, llámalo Y

Publicado: 2 diciembre, 2012 en Agile, Cultura Corporativa

Niels Pflaeging - Betacodex co-founder

Ayer sábado tuve la suerte de ser invitado por parte de Teresa Oliver de @skok_es y Carlos Iglesias de @runroom a una charla sobre “Cambio y Complejidad Organizacional” a cargo  Niels Pflaeging de @Betacodex.

Antes del evento tan sólo conocia alguna ligera referencia a Niels i Betacodex a través de Teresa y Jaume Jornet, que fueron los que justamente meses atrás me hablaron de la Stoos Network creada a principios de 2012. La cuestión es que cuando supe de la charla de Niels decidí de forma consciente no conocer demasiados detalles de su trabajo y enfoque organizativo. La recomendación de mis compañeros era más que suficiente. Era como ir a ver un estreno en el cine e intentar, durante los dias previos, no ver demasiados traillers y que nadie te explique nada para asegurar la sorpresa.

Era justo lo que conseguí en el caso del workshop de Niels y os aseguro que la satisfacción por todo lo aprendido ha quedado muy por encima de cualquier expectativa imaginable.

Aunque la memoria no es uno de mis fuertes puedo decir que, hasta la fecha, ha sido la mejor, mas apasionante y enriquecedora charla a la que jamás asistí. Esto, sumado al hecho de que todo lo aprendido va a ser directa e inmediatamente aplicable a mi entorno profesional, hace que ciertamente haya recibido un enorme regalo.

La jornada para mí empezó realmente la noche anterior. La celebración del evento en cuestión significaba que mucha gente amiga viajaba a Barcelona por lo que era obligado, y deseado, compartir la velada cenando juntos. por tanto, dicho y hecho, el grupo de Unutopia nos íbamos a cenar con Niels y su pareja. Nos propusimos en un principio no hablar de trabajo ni de agilismo pero… cuando vives con pasión aquello que haces es imposible e innecesario separar lo profesional del resto de facetas de tu vida.

Esa noche tuve el placer de conocer a Niels y compartir con él puntos de vista y enfoques profesionales muy interesantes. Que crack! en unos pocos minutos ya me habia ganado como adepto. Con el grupo compartimos experiencias, dudas, proyectos, ideas y más ideas lo que luego me provocó un placentero insomnio en el que fuí incapaz de desconectar mi cerebro debido a la energia generada y a la necesidad de dejar anotados mis pensamientos (entre los cuales estaba ya el boceto de este post).

El sábado a las 10 de la mañana, tras un par de activadores cafes, los treinta y tantos empezábamos el esperado workshop y, tras una ronda obligada y necesaria de presentaciones y exposición de nuestras expectativas sobre la sesión, entrábamos en materia: “Organizar la Complejidad“.

Niels nos planteó un recorrido a través de 10 puntos clave que marcarian un hilo argumental o linea de pensamiento a la vez que nos aportaria una serie de herramientas para abordar el cambio organizativo que muchos buscamos.

En la introducción nos comentó la existencia de una serie de “empresas locas” las cuales són reconocidas como exitosas siguiendo, lo que me atreveria a llamar, anti-patrones o prácticas (lamentablemente) poco habituales en las que como común denominador teniamos la generación de beneficios como una consecuencia y no tanto como un fin en sí mismo. Justamente estas empresas, como casos de éxito, fueron caso de estudio de la red Beyond Budgeting (1999) entre las cuales estan Handelsbanken, Toyota, Alfi, Goretex, Southwest Airlines y algunas otras. Y es allí, como parte de Beyond Budgeting, donde Niels inicia su camino hacia la evidencia organizativa y erigiendose como valedor del cambio radical como único camino para sanar empresas ahogadas en su propia inoperancia. Su consejo para ello: Es imperativo crear sentido de urgencia!

La historia que Niels nos relata se inicia en el año 1850 con el inicio de la era industrial y la invención del Management de la mano de Frederich Taylor (1911) que junto a sus secuaces McKensei y Gantt (mi querido amigo Gantt) logran implantar un modelo de total división de la organización a nivel funcional pero sobretodo a nivel de gerentes pensantes y operarios ejecutores de ordenes. Este modelo entraba en contraposición con otro modelo vigente hasta ese momento en la era artesanal o manufacturera. Ese modelo no era otro que el modelo Jedi, el tándem Maestro-Aprendiz, cuya fórmula se basaba en la co-producción y su máxima era la de lograr, como maestro, que el aprendiz llegase a convertirse en un maestro mejor que uno mismo, lo cual aseguraba la mejora generacional.

Es de recibo reconocer que el modelo Tayloriano cumplió con creces sus objetivos en un momento en que los mercados estaban en constante creación y expansión y en los que la competencia era apenas insignificante. Pero eso no quita que el modelo Tayloriano, por ser anti-natura, deba nutrirse de herramientas para asegurar su propia supervivencia: Definición de objetivos, procesos y metodologias, organigramas, presupuestos, etc. Mientras que el modelo Maestro-Aprendiz simplemente se basa en el acuerdo contractual entre ambos.

Nota mental: Tal vez algun@s penseis que el modelo artesanal no escala. Pero justamente ahí puede estar el origen del problema ya que el escalado o crecimiento debe surgir de una necesidad y no de un fin. Y mucho menos ser un objetivo como tal!

A lo largo de la conversación, Niels nos evidencia que los mercados han cambiado a la vez que el tipo de trabajo tienen ahora una gran componente de complejidad, y no tanto de complicación. Los mercados son globales y han llegado a su límite de crecimiento y las tareas son cada vez mas complejas (que no complicadas) por lo que se requieren personas y cerebros para su realización.

de la Era Artesanal a la Era del Conocimiento (@betacodex)

de la Era Artesanal a la Era del Conocimiento (@betacodex)

El principal problema radica en que las organizaciones, habiendo entrado de cabeza en la era del Conocimiento (1970) siguen aplicando patrones y estructuras de la era industrial.

Esas estructuras empresariales Niels las denomina Alpha. Alpha son aquellas orientadas a y por el Management, donde cada parte ocupa una posición claramente identificada i diferenciada y suelen ser representadas como una Pirámide reflejando su jerarquía vertical. En contraposición nos plantea un modelo Beta el cual está reflejado en organizaciones que responden a la teoría de sistemas, dinámicas, adaptativas y organizadas por roles (que no cargos). Esta estructura es representada por Niels como un Melocotón.

Fuera del melocotón/empresa están los Mercados, formados por clientes, proveedores, sociedad, etc. En la carne del melocotón o Periferia están las Células (equipos, no departamentos) encargadas de aportar valor a los Mercados ofreciendo servicios o productos. El hueso o Centro del melocotón, por no tener contacto con los Mercados actúa como un mero proveedor de servicios hacia las cédulas periféricas.

Peach model (@betacodex)

La grandeza de la metáfora es explicitar que dichas células operan en sus propios mercados internos. Todas ellas pueden ser clientes o proveedoras de otras células lo cual genera una competencia natural por los recursos y en consecuencia provoca el nacimiento, crecimiento, división o muerte de cada elemento del sistema que depende del propio sistema y que por él mismo no es nada. Este dinamismo es el que produce la inercia y movimiento real de toda la organización y en ningún caso será un plan orquestado por el Centro o cualquier otra de las partes.

Es debido a dicho dinamismo la razón por la que Niels plantea el modelo “Beta eterno” como el ideal por estar en permanente adaptación en el camino de la mejora continua.

¿Hermoso verdad? Un universo donde la propia gravedad coloca y mueve a cada elemento respecto al resto. Me estaba recordando la brillante metáfora de Los triángulos equiláteros de mi amigo Ariel Ber. Y más todavía cuando Niels comentó las bases para lograr dicho funcionamiento: presión de pares (me gusta más peer-preasure), presión social y, de forma innegociable, sin incentivos!

Sin incentivos. que fácil verdad? Cuantas empresas operan hoy en día sin incentivos? apenas un 1%? El ser humano es estúpido, no es así? y Niels no dejó de recordárnoslo a lo largo de toda la jornada. Y justo ahí entramos a hablar de personas, más concretamente de la Naturaleza Humana y allí volvían a aflorar científicos de antaño con sus teorias de clasificación de especies. Concretamente Douglas McGregor (1960), y sus allegados Marshlow y Herzberg, estudiosos de la conducta en primates y amigos de experimentar sobre el principio de recompensa y castigo.

Ellos dividieron a la raza humana en la Teoría X y la Teoría Y. Al espécimen X no le gusta trabajar y por tanto lo evita y funciona con incentivos o por miedo. El humano Y, por contra, necesita sentirse realizado y disfruta con el trabajo por lo que no requiere de estímulos externos para gestionarse y motivarse. La creatividad de los X, de haberla, es más bien escasa y por contra los Y son altamente creativos, corriendo el riesgo de que sus organizaciones no quieran o simplemente no sepan sacar partido de ella.

La cuestión es que si hablamos de comportamiento es obvio que estamos rodeados de gente X e Y. Pero y si hablamos de naturaleza humana? en este caso, y me costó verlo, McGregor nos engañó. No existe ningún ser humano X. La conclusión es que dependiendo del contexto observamos mayor o menor densidad de comportamientos X o Y por tanto, de forma bastante obvia, las empresas Beta hacen foco en el Entorno para lograr comportamientos Y pero las empresas Alpha hacen foco directamente en el comportamiento de sus empleados lo cual no puede crear más que resistencia contra el cambio planteado. Esa resistencia se percibe como desmotivación, falta de implicación, etc y son estos síntomas los que el patrón de Taylor intento controlar entrando en un círculo vicioso.

Llegado a este punto eran las 2 de la tarde y paramos a comer y el grupo nos desplazamos a un restaurante cercano amigos de @runroom. Allí degustamos tapas variadas y vino para acompañar una más que interesante conversaciones. Por cierto, menudas exquisiteces nos sirvieron en el restaurante l’Atmosphere.

Por mi parte, aunque la sesión continuó hasta pasadas las 5 de la tarde, dejaré aquí este relato y sólo añadiré, a modo de resumen, una pequeña selección de recomendaciones de enorme relevancia para mí y que seguro que en Twitter están dando la vuelta al mundo junto al hashtag #betacodex:

– No planifiques. Céntrate en estar preparado para abordar los retos que se presenten.
– El crecimiento y el beneficio económico son una consecuencia del buen hacer, no un fin en si mismas.
– Haz foco en principios, no en reglas.
– La cultura corporativa es un efecto, no una causa.
– El 95% de los problemas son provocados por el sistema, no por las personas.
– La transformación nunca concluye. Es un camino sin fin!
– Ponle CO-JO-NES!

Esas fueron algunas de mis lecciones aprendidas. Cuales fueron las tuyas?

Niels-Lecciones aprendidas

Insisto que no dejo aquí el post por falta de ganas ya que os aseguro que seguiré escribiendo para completar el resto de notas que tomé durante la sesión. La única razón es… dejaros con las ganas! Si habéis llegado a leer hasta este punto no tengo duda que el tema os interesa y estoy seguro que tenéis un cambio entre manos por lo que os aseguro que la mejor opción es conectarse a betacodex.com y empezar a devorar todos los papers y presentaciones que allí ha publicado Niels y su equipo. Lo siguiente será esperar a que Niels regrese a España para asistir a su workshop ya que os aseguro que el precio que cuesta es realmente insignificante dado que el ROI es enorme e inmediato.

Ahora no puedo menos que intentar, en la medida de mis posibilidades, devolver este regalo a la comunidad. Por tanto espero estar preparado en breve para compartir todo lo aprendido.

Thousands of Thanks Niels for this inspirational and revealing workshop (see you soon)

Anuncios

Era mi primera CAS, igual que fue mi primer AOS hacia pocos meses. Debo reconocer que el feedback inicial no era demasiado esperanzador ya que muchos desde diferentes puntos coincidían en que la mayoría de charlas eran de empresarios hablando de “sus libros”. La verdad fué que una vez allí asistí a pocas de esas pero a las que asistí fueron una autentica pasada, llenas de planteamientos inteligentes y coherentes para con sus propias organizaciones, negocios y clientes.

Todavía sin ibuprofeno, me adentré en la sala Malinche para escuchar la keynote de Masa K. Maeda, la cual debo reconocer que cuanto menos no logró inspirarme, aunque eso no perturbaría mi ánimo totalmente predispuesto a disfrutar y aprender al máximo durante los dos días que se . Debo decir que dos días después tuve el placer de reencontrarme con Masa en Madrid, donde realizó una charla de clausura de la LeanCamp Madrid que fué magistral y enormemente inspiradora. Yo mismo le reconocí a Masa que me hubiese encantado tener esa charla en Cáceres.

Twit LeanCamp Madrid

Para mi primera charla del Jueves me reservé “Una historia de Agilismo” de la mano de, quien resultó ser el CEO de Biko, Diego Cenzano explicando su visión de su propia empresa y exponiendo con total claridad los 10 impedimentos para lograr los objetivos de cualquier empresa. Era imposible no observar, en cada uno de los puntos expuestos, a gran parte de la audiencia asistiendo en silencio como acto de reconocimiento explícito de que diego estaba dando en el clavo.

En esa charla tuve mi primer orgasmo que llegó con la propuesta de Diego, hecha realidad en Biko, acerca de la Cuenta de Resultados Bottom-Up. Equipos autónomos, conocedores de sus costes y con capacidad para definir su propia tarifa en base a su velocidad. OMG! WTF! Demasiado bonito para ser cierto… el único problema, tal como luego me reconoció Diego, era la imperiosa necesidad de reforzar la imagen del “Equipo Biko” que prevaleciese sobre la independencia de cada uno de sus equipos (Ups! he dicho independencia?) pero ya estaban haciendo foco en esa linea.

Lamenté no asistir a otros orgasmos colectivos, como las charlas de Uriarte y Guillermo Montoya de Deiser, que Twitter se encargó de evidenciar a través del hashtag de la conferencia. Al menos con la de Guillermo tuve la suerte de asistir a la Beta de su charla en Barcelona hacia la primavera pasada. Y confio que algún dia Jorge nos regale una repetición de la jugada, ya que si no me equivoco su charla no fue grabada (Lo dejo como punto de mejora para la CAS bilbaína de 2013).

Entre horas, aparte de los obligados cafés y las más que interesantes charlas de pasillo, asistí a alguna que otra charla corta y debo reconocer que me quedé muy insatisfecho. Los apenas 10 minutos de Ariel Ber abordando las “Comunidades de prácticas” y otros tantos minutos de Jorge Uriarte sobre el “Sesgo de Confirmación” fueron, lo mire como lo mire, un coitus interruptus. Grandes ponentes con grandes temas entre manos que debían ser reducidos a la mínima expresión presas del autoritario reloj. Me hubiese gustaria poder alargar esas charlas al menos media hora más para que no se quedasen únicamente en meras píldoras. Aún así, como digo, fueron unos minutos brillantes y la valentía de Ariel al utilizar el formato Pecha Kucha por la exigencia que le supone al ponente.

Después de una mañana intensa llegaba la hora de comer y la organización había optado por un tapeo de pié que propició un buen networking y conversaciones regadas con buen vino y acompañadas por viandas típicas, entre las que destacaron el buen jamón y las tortas del Casar.

Por la tarde opté por sacrificar el resto de sesiones para adentrarme de lleno en el taller sobre “Aprender y explicar Agile ágilmente” a cargo de Ariel Ber. La verdad es que soy ultra #fan de Ariel, pero siempre es un placer asistir a una de sus sesiones. El taller se inició con algunas dinámicas de toma de contacto con el objetivo de conocer a la audiencia que tenía ante él. Luego, tomando el rol de Product Owner algo estereotipado, nos hizo construir un Barco iterativo incremental. Para mí la dinámica más potente fue la de los Triángulos Equiláteros cuya finalidad fue evidenciarnos a todos las dependencias implícitas en un sistema complejo.

Tras un reducido descanso retomamos el taller realizando una charla-debate en el que abordamos temas más concretos acerca de la aplicación de Agile en nuestros proyectos. Para ello utilizamos la dinámica FishBowl lo cual, propiciando la participación de todos los asistentes, enriqueció enormemente la conversación.

Y así acabo el primer dia de la Conferencia, aunque no del todo…

La organización nos había preparado dos eventos nocturnos. Primero realizamos una visita guiada a la Ciudad Histórica de Cáceres. Sólo os digo que fue una experiencia muy interesante y… no os explico nada más! Si queréis saber detalles tendréis que ir a Cáceres 😉

Luego nos habían reservado durante unas horas un restaurante del centro donde volvimos a degustar tapas y vinos de la comarca, momento en el que retomaron conversaciones mas que interesantes y conociendo con ellas, por vez primera, a gente increíble, aunque a esas horas los vinos ya habían hecho efecto 😉

La noche acabó temprano, tras unos últimos Gintonics, ya que a la mañana siguiente debíamos retomar la Conferencia. O sea que cuando aún no eran las 5 de la madrugada y tras acompañar al último grupo a su hotel, fuimos en busca del merecido, aunque corto, descanso.

 

Mañana más.

de Barcelona a Cáceres

Desde el primer momento supe que este año asistiría a la CAS, sin excusas, la Conferencia anual de Agile Spain la prueba es que me hice con una de las primeras entradas “Early Bird” e intenté colaborar (pobremente) en la organización del evento, aunque debo reconocer que llegarme hasta Cáceres no me hacia especial ilusión. Que se me había perdido en Cáceres? No podían haber escogido una ciudad peor comunicada?

A esos problemas logísticos se le sumaba la necesidad de ir en avión y buscando la opción más económica la propuesta era ir de Barcelona a Sevilla con Ryanair para luego tomar un coche de alquiler hasta Cáceres. Como buen catalán me preocupaban los gastos pero la opción de Ryanair se me hacia cuanto menos desagradable.

Con esta fijación en la cabeza me propuse barajar tantos planes B como pudiera plantearme. Y se me acabó ocurriendo la idea de aprovechar el viaje alquilando una autocaravana, opción que también nos ahorraba el alojamiento. Y así nació la propuesta de hacer el primer #MOSCAS, acrónimo de “Motorhome Open Space to Conferencia Agile Spain”. Es decir, no sería interesante celebrar un Open Space en ruta tratando las inquietudes profesionales y sociales de los pasajeros asistentes? Total, la estimación optimista de 10 horas de conducción daban para ello y mucho más. Y de regreso tendríamos el mismo tiempo para continuar la experiencia.

Así fue que lo propuse a la comunidad de Agile Barcelona y en nada ya tenia a Bea, Ignasi y Carlos interesados por acompañarme en la aventura. En nada habíamos confirmado la existencia de un aparcamiento de autocaravanas full-equip y gratuito en Cáceres a apenas mil metros del centro de conferencias lo cual hacia aún mejor la propuesta.

Ya me veia reservando la parte trasera del vehículo para ubicar el tablón con los slots. Una “Happiness Door” colocada en el interior de la puerta trasera de la caravana. A la altura de Vilafranca ya habríamos expuesto los temas que querríamos tratar y los estaríamos priorizando mediante “Dot Voting“. En el camino de regreso podríamos haber enfocado el Open Space a compartir, debatir y profundizar las charlas a las que hubiésemos asistido.

Al final, lamentablemente, el alquiler de semejante vehículo tenia asociado límite de kilometraje por lo que la intención de recorrer más de 2.000 kilómetros incrementaba el presupuesto a cotas incoherentes, por lo que retomamos el plan original de viajar con RyanAir.

Tras no pocos zarandeos entre nubes llegamos a Sevilla y ya pasadas las 11 de la noche de la noche llegamos a Cáceres justo para aprovechar las últimas horas de los hosteleros del lugar para degustar exquisiteces locales acompañada de una buena charla político-independentista acompañados por el dueño del restaurante. Todo estaba siendo idílico hasta que se nos ocurrió aceptar la invitación para degustar un tremendo orujo blanco, que pasaron a ser tres más un gintonic, lo cual hizo que la noche se acortase en exceso y el madrugón para asistir a la keynote de Masa K. Maeda resultase tremendamente doloroso.

Luego el día se despejó gracias a un generoso ibuprofeno y pudimos disfrutar de un Jueves repleto de buenas charlas y esperados reencuentros…

Retrospectiva Runroom

La semana pasada estuve facilitando una retrospectiva global en @Runroom, una empresa amiga con la que colaboro puntualmente. Se trataba de su Retrospectiva trimestral. En ella reunimos a todos los equipos de trabajo con la idea de aflorar conjuntamente Pluses y Deltas a nivel corporativo, más que de cada equipo en particular. Es clave recalcar, y digno de mención, que en la sesión estaban presentes todos los miembros de la empresa: Desarrolladores, Directivos, expertos en Marketing, Responsables de Equipo, Responsables de Producto, Diseñadores, todos.

El grupo en cuestión superaba las 30 personas.

Mi visión de la dinámica fue muy positiva ya que todos los presentes compartieron sus inquietudes y valoraciones acerca de la situación de la empresa con total transparencia y, aunque afloraron puntos de tensión, se respetó totalmente la “Prime Directive“.

En esa ocasión opté por realizar la dinámica manteniendo una única secuencia de trabajo con las 30 y tantas personas juntas lo cual provocó que tras 2 horas no habíamos logrado abordar la identificación de acciones para los puntos más prioritarios #Fail

La opción que descarté era la que sin duda realizaré a partir de ahora. La idea tenia como base haber separado los asistentes en grupos pequeños (5 de 6 por ejemplo) y que cada uno de ellos realizase su propia mini-Retro obteniendo así lo que consideraban sus 4-5 puntos más relevantes.

Luego eso puntos se hubiesen expuesto en conjunto y priorizado para abordar entonces, de nuevo en pequeños grupos (distintos a los anteriores), las propuestas de acciones para resolver los puntos más prioritarios.

GameStorming sequence

Esta segunda dinámica se asemeja mucho a las propuestas de GameStorming con sus fases de 1) Apertura 2) Navegación 3) Foco que de forma iterativa van llegando al objetivo trazado.

Lesson Learned: Las retrospectivas globales deben programarse con una duración mínima de 4 horas.

Wish List: Puestos a pedir, disponer de una jornada completa sería perfecto y celebrarla en un entorno externo al lugar de trabajo habitual sería todavía mejor.

Agradezco a @Runroom el hecho de permitirme formar parte de su equipo y poder así ver y participar de primera mano de su constante evolución.

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.