Juan Palacio,

más de una década emprendiendo con «agilidad» y

discreción

Hoy nos acompaña Juan Palacio, probablemente, uno de los referentes más reconocidos y respetados por la comunidad ágil en nuestro país. Juan es una persona que ha conseguido un equilibrio perfecto entre lo personal y lo profesional, pese a estar involucrado en múltiples iniciativas y emprendimientos «ágiles» y «no ágiles»:

Juan Palacio, fundador de Scrum Manager y Navegapolis: «no trabaja, disfruta«

Juan es ante todo discreto, nada mediático, pero también es comprometido y cercano. Juan siempre intenta y consigue entregar más de lo que recibe. En este sentido un ejemplo de generosidad. Gran conocedor de la Agilidad, practicante y emprendedor «ágil», y todo un referente en Scrum.

Cristina (CRV): Hola Juan, es un honor tenerte a bordo!

Juan (JP): Gracias Cristina, estoy encantado de estar en tu “casa digital”.

CRV: Pregunta obligada: ¿qué entiendes por Agilidad?, ¿cuál es tu visión?

JP: Entiendo a la Agilidad como la estrategia de gestión adecuada para situaciones en las que no tienes un objetivo definido y estable, sino una visión y una dirección de avance hacia ella. Procesas información de forma continua, y actúas en consecuencia. No estás ejecutando un plan, sino adoptando continuamente la mejor reacción para continuar en la dirección adecuada, con la información que vas procesando.

CRV: ¿Eres más de metodología o de cultura?

JP: Más que “cultura” diría “pericia”, o “talento” como la amalgama de sabiduría, práctica, experiencia y habilidad. Y diría que soy de ambos: Soy de metodología, y soy de talento, pero aplicando cada uno donde se debe.

Si quiero capacidad de respuesta ágil e ingeniosa, soy de talento. Si quiero previsibilidad en la ejecución, soy de metodología.

CRV: En Agilidad, ¿crees más en integrar o en escalar?

JP: Se suele pensar que para llevar la Agilidad a organizaciones de más de media docena de personas, es necesario “escalar la agilidad”. Conseguir que grandes organizaciones trabajen con unas formas que han surgido, y parecen más adecuadas para pequeños equipos.

Aquí hay un punto interesante: lo que todo el mundo entiende por Agilidad tiene dos posibilidades: Una, que podemos llamar agilidad técnica (ortodoxamente se llama ingeniería concurrente) y que se basa en metodología, y no en talento para lograr una entrega de producto o de la prestación del servicio previsible, de forma temprana, iterativa e incremental.

Y otra Agilidad que se basa en el talento, para conseguir además ingenio en el resultado.

Si se trata de agilidad técnica (ingeniería concurrente) creo en escalar esa “agilidad técnica”, para institucionalizar su aplicación en una organización grande. Propuestas como LeSS, SAFe, Spotify framework… pueden servir de modelos en esta línea. agilescaling.org es un punto de información interesante en esta línea.

Si se trabaja con Agilidad, creo que lo que hay que hacer no es escalar la agilidad, sino desescalar la organización; “fractalizarla”. En este aspecto para uno de los mejores modelos para que una organización grande sea ágil es la organización fractal “Fractal Teams” de….Michel Henric-Coll

CRV: Podrías elegir al menos tres de las bondades de la Agilidad?

JP:

CRV: Desde tu punto de vista, ¿cómo aplica la Agilidad a la Innovación? ¿y al Emprendimiento?

JP: A la innovación: La Agilidad aporta la potencia de la comunicación y fertilización de ideas entre los miembros del equipo o de los equipos.

En cuanto al emprendimiento, si se trata de sectores con continuas novedades y productos en evolución, la única estrategia por la que apostaría es la Agilidad, porque hablamos de un terreno en el que continuamente ves (o deberías ver) mejoras posibles de la idea original, y por tanto necesitas una estrategia en la que los cambios sean bienvenidos, y no “incidencias” que amenazan el cumplimiento del plan original.

CRV: ¿Qué lugar ocupa Scrum en Agilidad?

JP: El Scrum técnico: el marco de roles, prácticas y reuniones es un punto de partida. Un conjunto de prácticas para aprender y empezar, pero es el “manual de caligrafía” para aprender a escribir. Si queremos ser calígrafos (metodólogos de scrum) este es el manual de cabecera, pero si queremos ser escritores (profesionales ágiles) no empezaremos a serlo hasta que nos demos cuenta de que lo importante no es la forma, sino el fondo.

El Scrum avanzado o profesional: el concepto original de Scrum. Lo que denominaron “Scrum” por primera vez Nonaka y Takeuchi en 1986 y que se refiere al modo de trabajo de equipos de profesionales brillantes, autoorganizados que abordan el desarrollo de sistemas complejos, y por tanto imprecisos, solapando las fases del desarrollo, y que es el Scrum que haces cuando no sigues metodologías: eso es Agilidad.

CRV: Desde tu experiencia con Scrum,  ¿qué se practica más en las empresas: ScrumBut, WaterScrumFall o Scrum?

JP: Los equipos realmente ágiles no siguen metodologías. Hay opiniones puristas que entienden que si no aplicas el marco de Scrum tal y como está definido, no haces Scrum. Yo entiendo que en ese caso lo que no haces es “scrum técnico”, pero si el equipo logra la autoorganización, el avance y la entrega continua de valor… entonces claro que hace Scrum (Insisto, lo que llamarían Scrum los creadores del término: Nonaka y Takeuchi).

Los equipos de Google (por ejemplo) no siguen una metodología definida y etiquetada (Scrum técnico, Scrumban, Kanban…) pero no hay la menor duda de que son equipos ágiles.

Muchos equipos de “software factories” orientadas a la venta de horas de programación, siguen el marco técnico de scrum… pero su nivel de Agilidad es mínimo.

CRV: El interés en los últimos años por Scrum es un hecho pero su implantación en la empresa cuesta, ¿por qué crees que pasa?, ¿cuáles son los retos a los que se enfrentan las empresas a la hora de adoptar Scrum?

JP: Seguro que cada empresa tiene características propias, y los retos no son iguales, pero sospecho que al adoptar Scrum la mayor parte de los problemas se producen por ignorar dos conceptos: dimensiones y globalidad .

Dimensiones: ¿Se quiere adoptar scrum en su dimensión técnica, o también en la dimensión organizativa? La dimensión técnica viene determinada por las técnicas y prácticas de trabajo empleadas. La dimensión organizativa comprende también los rasgos de personalidad de la organización, que está determinada por el conjunto de principios y valores que inspiran su cultura organizativa.

Normalmente se va directamente a adoptar un marco ágil (Scrum técnico, DSDM, Kanban, SAFe, LeSS…) sin haber analizado antes las características de la organización y sus proyectos, y determinado si lo apropiado, o aconsejable es un marco de ingeniería concurrente (o agilidad técnica), o un ambiente de Agilidad.

Globalidad: La empresa es una realidad sistémica. La adopción de un marco de scrum técnico en el área de producción tiene implicaciones en las relaciones con los clientes, que están gestionadas por el área comercial. Se generarán tensiones y fricción si no se aborda la implantación de forma global.

Las fricciones y tensiones serán de mayor magnitud si la adopción de Scrum no es sólo en la dimensión técnica, sino también en la organizativa, porque necesita la adopción de determinados rasgos en los principios y valores de la cultura de la organización, a nivel global.

CRV: “El problema” se agrava en la gran empresa: ¿cómo ves el futuro de la agilidad en las grandes empresas?, ¿y en la Administración Pública?

JP: La adopción de Scrum es problemática en la gran empresa, pero no tanto por “gran” empresa, como por empresa “estructurada”. La dificultad no es tanto por el tamaño sino por la “estructuración”. Como te decía antes, si una gran empresa quiere adoptar agilidad y piensa en escalar el modelo ágil a su estructura, lo que en realidad ocurre es que no quiere implantar agilidad sino ingeniería concurrente (“agilidad técnica”); y esto en el mejor de los casos, que también puede ser que sólo quiera la etiqueta o apariencia de agilidad, igual que hace una década muchas empresas no querían implantar CMMI, sino la etiqueta de CMMI.

Si una empresa grande quiere adoptar Scrum, más allá de la implantación de prácticas ágiles institucionalizadas y “escaladas” a toda la organización, no se plantea (no se debería plantear) implantar un modelo de agilidad escalado, sino “desestructurar” o mejor dicho “fractalizar” su organización para que tenga una estructura acorde con la cultura acorde con la agilidad. Y en paralelo, por supuesto considerar si la cultura organizativa también es adecuada para que la agilidad pueda florecer.

¿Cómo de fácil es esto en la gran empresa o en la Administración local, central o autonómica en la que estás pensando? ¿Qué deberías gestionar o cambiar?… pues esa es la respuesta 😉

CRV: ¿Qué papel juegan las comunidades “ágiles” en la difusión e implantación de la Agilidad?, ¿son todo lo eficaces que quisieran o pudieran ser? ¿con qué impedimentos se encuentran? ¿qué podrían mejorar en su labor?

JP: La difusión de la agilidad debe mucho a la viralidad que generan las comunidades ágiles. Lo que sí hace falta es criterio, porque en la riada de información hay también desinformación. Para no desorientarse, o caer en seguidor de falacias la única herramienta es el criterio profesional de cada uno.

CRV: Para ir terminando, estás involucrado en varias iniciativas relacionadas con la Agilidad, háblanos un poco sobre ellas

JP: Las iniciativas profesionales que voy abordando van surgiendo con el devenir profesional. De 2000 a 2004 estaba a cargo del departamento de programación de iA Soft y aposté por CMMI (entonces CMM-SW) para “escalar” de 4 a 60 programadores. Esa fue una “tesis” de conocimiento, que a través de sus debilidades me mostró su “antítesis”: la agilidad.

En 2005 – 2006 Ken Schwaber empezaba a dar cursos de Scrum en los que simplemente por asistir, y aunque no entendieras muy bien el inglés, te daba un diploma que afirmaba que eras “Scrum Master”. Scrum se enseñaba sin considerar las implicaciones que en la realidad sistémica de la empresa tiene su adopción, y sin considerar tampoco que la clave de Scrum no está en las prácticas, sino en los principios, y que es mejor adaptar las prácticas a la empresa, que la empresa a las prácticas.

Esa fue la razón de la puesta en marcha de Scrum Manager: compartir el conocimiento de Scrum, porque entonces, aquí era desconocido (en 2005 no había ningún sitio en internet que hablara de Scrum en español) y al mismo tiempo, hacerlo con una propuesta alternativa: Que no fuera un “copia-pega” de inglés a español para dar lo mismo sin aportar las mejoras que parecían evidentes:

No era lógico que acudir a un curso presencial y pagar 1.000 libras fuera la única forma de aprender Scrum, y poder acreditarlo en el curriculum.

Con el nombre de Scrum Manager puse en marcha una plataforma moodle donde se pudiera aprender Scrum gratuitamente, y que exigiera aprobar un examen a quien quisiera un documento diciendo que esa persona conocía la teoría de Scrum. Curiosamente a los 2 años la certificación de la Scrum Alliance empezó a exigir un examen, y comenzaron a surgir otras certificaciones de Scrum con examen.

Scrum Manager aportaba también 2 componentes que creo que se debe considerar también quien quiere aprender Scrum: globalidad y flexibilidad. Es decir: que la empresa es un todo global, no se trata de departamentos aislados y sin una cultura corporativa común. Que la adopción de agilidad tiene implicaciones en la relación sistémica de la empresa.

Y flexibilidad: Scrum no es técnica, sino principios. Scrum, Kanban, Scrumban, DSDM, Crystal… no son modelos de agilidad, son modelos de prácticas ágiles. El mayor nivel de fluidez se logra cuando las prácticas se empiezan a adaptar (a través de la evolución por retrospectivas y mejora continua) a la realidad de la organización y del tipo de proyecto en el que se trabaja.

CRV: Ahora si, para finalizar otra pregunta obligada: un balance personal y profesional hasta ahora y ¿cuáles son tus próximos retos?

JP: El balance, tanto personal como profesional tiene que ser positivo, pero más que para mí, para el entorno al que yo llego: Lo más satisfactorio para uno mismo es entregar más de lo que recibes, porque entonces eres realmente positivo para el sistema, y es el mayor activo que puede tener tu balance.

Mi principal y más motivador reto es Safe Creative: el proyecto que fundé hace ya 8 años para poner en marcha un concepto innovador: un registro de propiedad intelectual adecuado para Internet. Es mi auténtica “escuela” de agilidad, que no para de crecer y abrir nuevas posibilidades, donde más que trabajar, disfruto y aprendo todos los días.

El próximo reto (relacionado con la agilidad) es ayudar a las empresas que quieren “agilizarse”. Scrum Manager surgió para ayudar a los profesionales, y de forma similar, pero para las empresas, estamos desarrollando “Scrum Level”, algo que ya se puede empezar a ver en estado de “recién nacido” en scrumlevel.com Ojalá que resulte útil.

CRV: Pues bien, llegado a este punto quisiera agradecerte el tiempo que nos has dedicado a poner en valor la Agilidad y Scrum en particular.

JP: Pues lo mismo, Cristina. Gracias por invitarme a compartir esta charla en tu casa digital, y enhorabuena porque este sitio es un lujo, con un estilo y un nivel profesional que no es frecuente.

Hasta aquí la Master Class en Agilidad y Scrum que nos ha regalado Juan Palacio. Ha sido un privilegio contar con su compañía!

Por último, te dejo su propuesta musical. Disfrútala!:

En los demás, al verlo tan dichoso,
cundió la alarma, se dictaron normas,
«»No vaya a ser que fuera contagioso…»»
tratar de ser feliz de aquella forma.

La conclusión, es clara y contundente,
lo condenaron por su chifladura
a convivir de nuevo con la gente,
vestido de cordura.»                                              Alberto Cortez (Castillos en el aire. «Castillos en el aire», 1980)