Archivos de la categoría ‘Agile’

Macro Retrospectivas II

Publicado: 15 mayo, 2013 en Agile, Retrospectiva, Runroom

R.I.P.

Tras muchos meses de abstinencia, la semana pasada volvía a mi Dojo, a @Runroom. Es allí donde inicié mi andadura como Agile Coach y es allí donde se me sigue permitiendo experimentar todas las técnicas e ideas que caen en mis manos.

Mi visión personal es que se trata de una relación win-win de grado máximo, sin mayor pago que la gratitud por ambas partes por el absoluto entusiasmo y entrega con el que llevamos a cabo cada sesión.

En esta ocasión tenia intención de regalarles algo nuevo y diferente, una sesión Kinder Sorpresa! Deseaba generar el ambiente propicio para que fluyesen grandes conversaciones. Se trataba de una Retrospectiva Corporativa, Trimestral de las que se agendan cada 4 o 5 meses, por lo que no podía pretender que 30 personas se dedicasen a escribir Pluses y Deltas en postits de colores. Caer en la rutina significaría el fracaso absoluto, o así lo quise pensar.

El Handicap: Sólo disponíamos de 2 horas justo antes de la hora de comer.

Por suerte para mí, en los días previos a esta dinámica habia tenido la suerte de poder asistir a 3 talleres que ampliaron en mucho mis conocimientos y, sobretodo, mi Caja de Herramientas:

– El Taller de Retrospectivas de Teresa Oliver y Ariel Ber.
– El Open Space #Games2Learn organizado por @AgileBCN y facilitado por Ariel Ber y Jaume Jornet.
– El Curso de Agile Coaching de Ariel Ber y Joserra Díaz.

Sí, es justo lo que estais pensando, menuda sobredosis de Ariel! Y fue un verdadero lujo . Todas esas sesiones me dieron montones de ideas que me comprometí a poner en práctica en la mayor brevedad, y la oportunidad me la brindaba la Retrospectiva de @Runroom.

Volviendo a dicha Retrospectiva, la cuestión es que para empezar les planteé la siguiente dinámica: “Quebrar @Runroom antes de Fin de Año”. En grupos de 6-7 personas les pedí que diseñaran la secuencia de acciones con las que lograrían que la organización quebrase y echase el cierre.

Una vez entendido el planteamiento los equipos se pusieron a ello decorando las paredes de la oficina con TimeLines, StoryBoards y Esquemas que visualizaban la tragedia. Tras un par de iteraciones todos creyeron tener listo el plan perfecto. Se pidió a cada grupo que expusiese su asesinato como si de un capitulo de C.S.I. o el juego del Cluedo se tratase.

En este punto se generó cierto debate sobre la probabilidad o imposibilidad de que cierto hecho o acción pudiese llegar a producirse, o si era suficientemente grave como para provocar el fin planteado. Esta parte de la dinámica, aunque consumió más tiempo del previsto consiguió abordar temas muy interesantes.

Cuando los 4 asesinatos habian sido expuestos, no se si porque fue realmente un tema candente o porque de forma unilateral así lo decidí (si así fué, mea culpa) propuse profundizar en el tema de la “Trasparencia a nivel Corporativo”, es decir, ¿Se tiene el adecuado nivel de información sobre la compañia y el negocio para trabajar de la mejor forma posible?

Para ello me hubiese gustado realizar la dinámica del Teatro del Oprimido pero ni el tiempo ni el espacio disponible jugaban a nuestro favor. Por ello opté por una opción más formal. Propuse realizar un FishBowl para continuar el debate y así, en la zona de sofás, 3 de los socios sentados, una butaca vacía y el resto del estudio como espectadores se inició la conversación.

La experiencia, en lo que a mí respecta, no pudo ser más gratificante. Disponíamos apenas de 20 minutos pero trascurridos 45 seguian todos enzarzados en un enriquecedor debate. Los espectadores se iban turnando para ocupar el espacio disponible en el FishBowl para aportar su punto de vista al respecto.

Una vez el tema no dio más de si o tal vez porque era ya mucha el hambre que había, se dio por cerrada la dinámica. Los asistentes dieron su feedback de la sesión con una mezcla de Happiness Door y Juego de la Perfección. de la que, aún pendiente de revisar en detalle, me quedé con un alto grado de satisfacción general.

Cierto es que algunos se quejaron: “No hemos hecho una Retrospectiva”. Bueno, acepto las críticas ya que muchos traían sus Pluses y Deltas ya preparados, pero sinceramente debo discrepar ya que tal vez esta había sido la primera vez que lograban aflorar abiertamente temas tan delicados y profundos como los abordados. Además de disponer ahora de un inventario de acciones que debían evitar a toda costa si querían que @Runroom siguiese creciendo.

Debo decir que la dinámica fue agotadora y que esa noche dormí del tirón como hacia tiempo que no lograba. Ahora sólo queda editar el video de la sesión para que sirva de recordatorio, de anécdota o de acta de la reunión.

Muchas Gracies @Runroom, repetiremos en Septiembre!

Festen

Anuncios

Reclutando pasión

Publicado: 2 mayo, 2013 en Agile, Cultura Corporativa

Patch Adams

¿Por qué os cuento esto? Pues por que me vino a la memoria parte de mi oscuro pasado oscuro, el cual no se remonta únicamente a mis 12 años trabajando para una consultora. Corría el año 1994 cuando trabajaba como comercial de una empresa de representación de productos alimentarios cuando me ofrecieron trabajar para Häagen-Dazs como refuerzo de su campaña de invierno.

Justamente Häagen-Dazs fue innovador en su sector al romper la barrera estacional que hasta entonces tenían los helados, reservados per sé a la época veraniega y al público infantil, pero eso ya es otra historia…

El hecho es que para mi primera y única entrevista la directora comercial en persona me citó en dicho establecimiento. Ningún intermediario y ninguna fría sala de reuniones. Una vez hechas las presentaciones y sin entrar en demasiado detalle en experiencia ni curriculum le pidió a uno de los encargados que nos trajese una bola de helado de cada sabor.

Yo no podía estar más descolocado, trajeado y encorbatado frente a una bandeja repleta de tarrinas de helado. Más de 15! No sabia que pretendía esa mujer, lo único que tenia claro es que el hecho de haber memorizado mi para entonces escueto curriculum no me serviría de nada.

–       Te apetece probar nuestros helados?

–       Claro!

–       Cual te gusta mas?

–       El de nueces de Macadamia, sin duda.

–       Prueba este – me dijo acercándome una tarrina de chocolate – y dime que te parece.

Mierda! Precisamente el chocolate no me gusta demasiado pero al probarlo estaba increíble. Sólo recuerdo que se me escapó un “Joder, que bueno!” y la miré medio disculpándome por el palabro.

–       ¿Por qué?

–       ¿Por qué?

–       Si, me gustaría que me explicaras por qué te ha gustado.

–       No se, supongo que no me esperaba este sabor.

La conversación continuó un buen rato y probé todos y cada uno de los sabores comentando con ella mis impresiones y preferencias. Al acabar yo me lo había pasado genial pero todavía no sabia muy bien que tipo de prueba era esa.

–       Gracias por tu tiempo Marc. Por mi parte ya lo tengo claro. Tienes alguna pregunta?

–       Bueno, supongo que me gustaría saber si encajo en el perfil que buscáis y también me ha sorprendido mucho el tipo de entrevista que me ha hecho.

Me sonrió y me dijo:

–       Es fácil, simplemente buscamos personas a quien les apasionen los helados.

Yo no pude más que sonreir y despedirme de ella esperando que me llamasen para confirmar que trabajaría con ellos, y así fue.

En ese momento se que pensé que esa reunión había sido algo absurdo que me serviría como anécdota cuando estuviese con mis amigos. Ahora en la distancia no puedo menos que ver la gran inteligencia de esa directora que buscaba crear un equipo creado por personas apasionadas.

Y tú, ¿a qué tipo de personas necesitas sumar a tus equipos?

Zappos Recruiting

Me gustan los JuegOS, en Serio!

Publicado: 28 abril, 2013 en Agile, Open Space

Ficha técnica:

Evento: #Games2Learn

Lugar: #eGarage cedido por @Esade

Organiza: Carlos Iglesias y @AgileBCN

Facilita: Ariel Ber y Jaume Jornet

Este pasado viernes no hubo forma de dormir. En gran parte por la ilusión que me hacia poder asistir al día siguiente a este encuentro monográfico sobre #SeriousGames en el que compartiría una jornada muy especial y montones de experiencias con viejos y nuevos amigos.

En parte ese insomnio también venia provocado por que me había exigido preparar algunas dinámicas y juegos para la ocasión, pero quería huir de mis propios convencionalismos trayendo algo nuevo para la ocasión. Aunque le estuve dando vueltas hasta el último momento no lo conseguí.

Llegué temprano y ayudé con los últimos preparativos para acondicionar la sala. Pedazo de espacio es el #eGarage. Enorme sala polivalente que nos permitió adaptarlo completamente y crear 4 zonas de “trabajo” diferentes en las que los más de 80 asistentes pudimos participar en multitud de juegos durante toda la jornada.

A primera hora, ya que se trataba de un Open Space, se dieron las pocas instrucciones básicas y se generó un panel de propuestas que se ubicaron en cada uno de los slots y salas disponibles. Y acto seguido empezaron las sesiones.

Creación de productos y metáforas mediante los sets de LEGO SeriousPlay, aprendiendo a usar el Business Model Canvas para salvar princesas, Sesiones de Dungeons&Dragons para ScrumMasters, introducción a las técnicas de Agile Lateral Thinking, Destrucción de productos para equipos de Marqueting, subir a alfombras voladoras para equipos, creación de juegos, Marcianitos y 3 en raya humanos, Prototipado rápido con Arduino, Triangulación de sistemas complejos, magistrales lecciones prácticas del mundo Casteller, introducción al Teatro del oprimido, Figth Jam, juegos Win-Win, y mucho más.

Los bloques de mañana y tarde se cerraron son sendas rondas en las que cada grupo compartió con el resto lo más significativo de las sesiones a las que habían asistido.

No es mi intención explicar el contenido de las sesiones ya que creo que ningún resumen haría justicia a lo allí vivido. Con esto aprovecho para invitaros a asistir al próximo evento ya sea en aquí en Barcelona o en el internacional #Play4Agile.

Al cierre Ariel nos retó, como ya es costumbre en él, pidiéndonos que asumiésemos el reto de poner en práctica algo de lo aprendido durante la jornada y para asegurar el éxito nos hizo elegir un compañero que, a modo de Pepito Grillo, debería asegurar que cumplíamos tal promesa. En mi caso me marqué el objetivo de realizar al menos una sesión del Teatro del Oprimido antes de Julio.

Al final tuve que despedirme de todos con lo que supuse que era la última dinámica a medio construir. Un Castell que se erguía perfectamente guiado por las instrucciones del Gran Josep @GripauBlau_cdt. Para mi y para muchos de mis compañeros de comunidad no hay mejor metáfora de los principios y valores ágiles que la creación de un Castell.

Gracias a todos los asistentes, a Ariel y Jaume por facilitar, a Carlos por organizar y a ESADE por cedernos el espacio.

¿Repetimos?

Mi amiga Incertidumbre

Publicado: 24 abril, 2013 en Agile, Cultura Corporativa

change ahead 2

Damas y Caballeros, dejemos de una vez de hacernos trampas al solitario! No hay pitonisa ni consultor que pueda asegurar como ni cuando vamos a lograr un objetivo a largo plazo. Y esta inseguridad crecerá exponencialmente cuanto mayor sea la complejidad de dicho proyecto.

Proyecto! Que gran palabra. Mi padre siempre me preguntaba como podía ser que trabajase realizando proyectos si para él, viniendo del mundo comercial de la industria química, un proyecto era una fase previa a la ejecución, era un Plan! Una Estrategia! Un I+D!

Yo durante muchos años le intenté explicar mis procesos de trabajo y como el transcurrir de las diferentes fases acababan entregando, en mayor o menor medida, el producto esperado. Yo creía en mis propias explicaciones, que menos! Ciego pero Coherente. Proyectos diseñados para seguir con tiralíneas mis preciosos diagramas de Gantt que sincronizaban a la perfección miles de horas y decenas de profesionales. Que vergüenza!

Ahora en la distancia veo esas prácticas tan absurdas como haber planificado el tiempo y valorado el coste del proyecto frente a una bola de cristal rodeado de velas o inciensos. Las probabilidades de acierto siempre son extremadamente bajas.

Para quien quiera más datos les recomiendo ojear las estadísticas del informe Chaos donde se muestran las alarmantes cifras de productos no usados y de proyectos que fueron cancelados o se desviaron en algunas de sus dimensiones: Coste, Tiempo, Alcance o  Calidad.

% Project Success

Damas y Caballeros, nuestra vida y nuestra sociedad son sistemas altamente complejos. Y esa complejidad nos lleva a la imposibilidad de predecir como se van a comportar dichos sistemas. La solución es de sentido común, no nos queda otra opción que convivir con la Incertidumbre. Eso sí, pongamos todos nuestros sentidos y esfuerzo en hacer que cada día vayamos disipando las nieblas del camino que estamos recorriendo.

Una vez entendamos el escenario en el que nos encontramos, la recomendación es simple: Estar preparados para cambiar de rumbo cuando la situación así lo requiera. Deberemos adaptarnos a los cambios antes que seguir un plan.

Eso no quita que debamos tener un Plan, pero no tanto para seguirlo sino para que nos sirva de referencia. Ya lo decía Sun Tzu hace 2.500 años: “Ningún plan sobrevive al contacto con el enemigo”. Por eso, ya a finales de la era industrial, Edward Deming nos regaló su ciclo de Mejora Continua que se origina con la definición de un plan, que luego será ejecutado, mediremos los resultados obtenidos, y aplicaremos los ajustes necesarios que serán las bases de nuestro nuevo plan. Y el ciclo no deberá dejar de rodar.

Ese plan nos deberá proporcionar la visión holística y los objetivos necesarios para asegurar que todos remamos en la misma dirección. Sobre dicho plan nosotros deberemos medir los indicadores que nos mostrarán si estamos logrando o no dichos objetivos.

La medición constante es una practica fundamental en todo proyecto. Medir, medir y seguir midiendo. Pero recordemos el principio de incertidumbre de Heisenberg en el que, en su definición más amplia lejos de la física cuántica que lo originó, nos dice que el acto mismo de observar cambia lo que se está observando.

¿y esto que significa? Pues que tan importante como medir el proceso que pretendes mejorar es utilizar métricas coherentes y alineadas a ese objetivo. ¿Quien no ha vivido la mala praxis de un equipo comercial vendiendo proyectos bajo coste porque su objetivo de ventas estaba orientado a volumen de facturación?

– “Es que si cierro 50 mil euros más llego a objetivos.” – Me dijo el pobre comercial que con esa acción se embolsaba un 30% de variable sobre su sueldo base (que no era para nada bajo, pero eso ya es otra historia).

Damas y Caballeros,  ya sabemos que abandonar nuestra zona de confort implica coraje y asumir riesgos, pero también sabemos que definir un plan detallado que contemple todas las variables en juego es un acto que otorga una falsa seguridad y nos hace creer que mantenemos el control.

Control! Otro gran concepto. El control no existe como tal, es una ilusión, y más todavía cuando introducimos personas en la ecuación.

(Complejidad * Incertidumbre)Personas ≠ Control

¿Qué opciones tenemos? Mi recomendación es entender y ser fiel a los principios Lean y Agile. Implicar a todo el equipo en fases tempranas del proyecto. Trabajar en ciclos muy cortos de trabajo entregando producto para recibir feedback real del mercado. Focalizarse en aquellas tareas que aporten mayor valor y tengan un mínimo coste. Crear un entorno que promueva la autonomía y la maestría. El equipo trabajará de forma conjunta y con alto grado de comunicación con el cliente. Revisar el proceso de trabajo periódicamente para realizar mejoras dentro del siguiente ciclo. Aprender de cada paso que deis…  y seguiremos para Bingo!

Ciclo Lean Startup

Ciclo Lean Startup

¿Os encaja? Yo os digo que SÍ pero mi primera respuesta siempre será un gran DEPENDE…

Tengan cuidado ahí fuera!

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)

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.