Scrum
Anoche cuando me senté a escribir tenía un propósito claro y sencillo:
Mis compañeros de marketing me habían pedido que escribiese un texto para celebrar que acabamos de acreditarnos como centro de formación oficial de Kanban University.
Escribir esto es algo muy sencillo y agradable: Convertirnos en partner de la Kanban University es algo importante, una acreditación que apenas tienen cinco organizaciones en España, y que reafirma nuestros esfuerzos por ser un referente en el sector de la formación IT.
Hasta ese punto todo iba según lo previsto y escribía rápido. Pero mis compañeros de marketing, en su ánimo de facilitar mi trabajo, me habían escrito unas preguntas que me sugerían responder con el texto. “¿Por qué Kanban? ¿Por qué ahora?”.
Son dos preguntas que hasta me atrevería a calificar de inocentes. Es evidente que aportaría valor al texto si explicaba los motivos de nuestra apuesta, y también les ayudaría a enfocar la campaña de comunicación si les daba un argumento de por qué era acertado hacerlo en este momento. “¿Por qué Kanban? ¿Por qué ahora?”.Me repetía estas dos preguntas una y otra vez, así que paré de escribir lo que me habían pedido, y empecé a pensar en la respuesta a ambas cuestiones: “¿Por qué Kanban? ¿Por qué ahora?”. Por mi cabeza pasaban muchos argumentos para contestarlas: buenas razones técnicas, estupendas estrategias comerciales… pero cuando me decidí a escribir lo primero que teclearon mis manos fue un: “Por que no me siento a gusto con mi trabajo”. Y ahí supe que la noche sería larga.
En apenas un par de meses cumpliré 15 años en Tecnofor y en esta andadura hemos organizado miles de cursos, de las más variadas tecnologías y metodologías de gestión IT. En nuestros inicios lo que primaba era la formación técnica, después fueron las metodologías tradicionales, y en tiempos más recientes, Agile. O para ser más preciso, Scrum. Nuestro sector, imagino que como tantos otros, no evoluciona de forma lineal sino al impulso de las modas.
He de reconocer que personalmente me encanta Scrum. Supongo que debido a un cúmulo de factores, pero diría que fundamentalmente es por ser un framework que ayuda a gestionar la incertidumbre en la construcción de productos. Y la última parte es clave: Construcción de productos. Scrum es útil si vas a desarrollar productos complejos. No es ningún secreto, ni es un enfoque innovador y disruptivo por mi parte: Es la primera frase de la guía de Scrum. La cuestión es que cuando miro mi entorno no veo productos por ningún lado. Parece evidente que España no es un país industrial, y tampoco tenemos aún una gran industria de producto digital, al menos no una que justifique por si misma un hype del tamaño que Scrum tiene hoy en el sector de la formación. ¿En qué trabajan quienes están formándose en Scrum? ¿Para que lo utilizan?
La mayor parte de la informática de nuestro país se dedica a dar soporte a las operaciones de las empresas de las que dependen directamente, bien sea de forma interna o en modo outsourcing.
Estos sistemas de información tienen arquitecturas y tecnologías muy diversas pero, salvo casos muy puntuales, no pueden ser considerados productos. Son el resultado de un proyecto inicial de gran esfuerzo, seguido de un mantenimiento y una evolución basada en proyectos. Proyectos que usualmente son atendidos por equipos armados ad-hoc, que la mayor parte de las veces simultanean tareas de varios proyectos, y que a menudo afectan a varios de estos sistemas a la vez.
Aunque torturando los conceptos estos pueden llegar a parecerse a cualquier paradigma, sobre todo si es uno en el que uno cree, no resulta razonable hablar de una existencia amplia de productos tecnológicos en nuestro país. Tanto es así que lo habitual es que en las organizaciones sea complicado gestionar el rol de Product Owner… porque no hay producto por ningún lado. En este contexto, siendo de lejos la formación de Scrum la más solicitada del paradigma Agile ¿Por qué entonces no causa insatisfacción al alumno que no trabaja en un entorno de producto? ¿Por qué no genera por tanto decepción ni tan siquiera en equipos de infraestructura y explotación, o aquellos que trabajan en un entorno de servicios y operaciones, más alejado aún del concepto de desarrollo de producto?
De nuevo, supongo que la respuesta a la pregunta anterior se debe a una multitud de factores, pero es una realidad. En Tecnofor llevamos años realizando formación Scrum, y analizando de forma objetiva las opiniones de nuestros alumnos y clientes podemos decir que demuestran su satisfacción. Mi teoría personal es que los principios y valores Agile que se presentan al inicio de cada curso de Scrum son universales y aplicables a cualquier contexto, tanto si trabajas en producto como si no lo haces. El framework de trabajo quizás no sea aplicable a tu día a día, pero quien no ha soñado con un trabajo basado en principios como Compromiso, Coraje, Foco, Apertura y Respeto. También puede que alumnos que no trabajan en un entorno de producto y experimentan una gran dificultad por adaptar su día a día a un framework como Scrum no estén achacando estas grandes complicaciones a la falta de encaje con la naturaleza real de su actividad, sino al esfuerzo que un cambio de principios y valores exige en una organización. O quizás sea nuestra predilección humana por las recetas completas, por los métodos que nos ofrecen una respuesta para cada pregunta, como hace Scrum.
Es evidente que en el sector estamos viviendo una disfuncionalidad que lleva a que una parte importante de los alumnos que realizan una formación de Scrum puedan aprovechar solo parcialmente lo aprendido, y que, en su ánimo de adoptar un nuevo marco de principios y valores, estén intentando aplicar también un framework para el desarrollo de producto en actividades donde objetivamente no aplica. Si la empresa tiene problemáticas a las que Scrum no se adapta, como la gestión de servicios o de portfolio, forzar a la organización o a Scrum genera un desgaste de energía que no puede aprovecharse después para el propio propósito de la empresa. Obviamente no pretendo juzgar a nadie por ello, pues yo mismo caí en el error hace años y no tuve reparo en reconocer públicamente mi fracaso. Pero, ¿Qué responsabilidad tiene una empresa de servicios como la nuestra en esta situación disfuncional?
Nuestros clientes nos demandan una formación y nosotros respondemos proporcionándoles un servicio cuidado, con el que están contentos y satisfechos. ¿Qué motivo podría haber para que “no me sienta a gusto con mi trabajo”?
La razón es que siento que no estamos haciendo lo suficiente a la hora de asesorarles, que les estamos fallando a la hora de hacerles cuestionarse su elección y ofrecerles otras alternativas. Nos hemos limitado a darle a los clientes lo que nos pedían, quizás por miedo a que se sientan contrariados y dejen de contratarnos, quizás por confundir nuestro rol de una empresa de servicios con una equidistante a las opciones.
Es cierto que no todos los clientes desean este asesoramiento y así nos lo hacen saber, y otros se auto-prescriben una formación que nosotros simplemente ejecutamos. Y es igualmente cierto que debemos respetar y respetamos las decisiones del cliente, que en definitiva es el responsable último de sus consecuencias y quien suele tener una mejor idea de los objetivos de su organización. Pero nada de eso debe ser una excusa suficiente. Si alguien me pide un tostador mi obligación como proveedor es darle el mejor tostador posible, con las mejores características técnicas y con el mejor servicio, pero si en algún momento intuyo que su intención es usarlo para asar un pollo, no puedo obviar esa situación. ¿Realmente estamos haciendo todo lo posible para evitarlo?
Si lo estuviésemos haciendo el porcentaje de clientes que deciden apostar por Scrum tendería a parecerse más al de empresas que hacen una gestión de productos. Seguro que habría un porcentaje algo mayor, dado que existen muchos clientes que se aproximan a nuevas formas de trabajo solo para conocerlas y evaluar si estas pueden resultarles de valor. Y otros muchos que seguirían renunciando a nuestro consejo o utilizando otras fuentes de asesoramiento. Pero ello no puede hacernos obviar nuestra responsabilidad, que debe ir mucho más allá de entregar lo que se nos demanda. Debemos hacer nuestro mejor esfuerzo para validar con el cliente que aquello que nos solicita va a resultarle útil.
¿Por qué Kanban? El motivo consciente: Es un metodo Agile que encaja perfectamente con nuestra estrategia comercial de evolución para los clientes que llevan años apostando por ITIL y gestión de servicios, así como con los proyectos Jira, pues ambos se basan en una gestión de flujos. Además es más sencillo de adoptar: Propone empezar desde tu forma de trabajo actual, con tus roles actuales, con eventos flexibles, y tu decides evolucionarlo desde ahí.
Supongo que el motivo subconsciente es que necesito sentir que disponemos de una alternativa completa y consistente para ofrecer a los clientes otra opción para adoptar principios Agile, aún cuando no se dediquen a desarrollar productos.
¿Por qué ahora? Por que ha llegado el momento de asumir nuestra responsabilidad en las decisiones de nuestros clientes, por que es el momento de abandonar la equidistancia y posicionarnos, y por que nuestro mínimo no puede limitarse a satisfacer al cliente.
El riesgo de posicionarnos es que probablemente perdamos clientes a los que no les guste nuestro enfoque, pero el riesgo de no hacerlo es dejar de sentirnos orgullosos de nuestro propio trabajo.
Pablo Grueso. 28 de junio de 2020
