Los equipos y estructuras autoorganizadas son claves para un desarrollo ágil y, por lo tanto, para activar los beneficios de la business agility en nuestra empresa. Uno de los problemas con los que se encuentra la autoorganización es que la idea tiene una barrera de entrada fuerte. Generalmente, en las empresas de corte más tradicional genera rechazo inmediato, urticaria y escepticismo. En este artículo voy a compartir qué me ha funcionado para convencer y para poner en marcha equipos autoorganizados.
[Leer más…] acerca de La autoorganización en las empresasBlog
Product Owner, improvisación o adaptación
La agilidad no ha parado de extenderse en los última década e incluso las organizaciones que miraban con recelo todo este movimiento están dando sus primeros pasos y viendo cómo pueden sumarse, aumentando así su competitividad. ¿Cómo está conviviendo en estas compañías mentalidades tan diferentes? ¿Cómo están respondiendo los Product Owners a las necesidades?(Extra: ¿qué es la transformación digital?)
Emma es una project manager en una gran compañía. Una telco internacional que solo en España cuenta con más de 10.000 trabajadores entre internos y externos. Ella trabaja en la parte que en su empresa llaman legacy. En otras muchas esta parte de la compañía la llaman waterfall o tradicional. Trabajan como siempre lo han hecho y ahora tienen que convivir con una parte “agile” (el uso de las comillas no es una casualidad) que ha surgido en la compañía y ha empezado a trabajar de otra manera.
Para gestionar la parte que le toca en toda esta gran maquinaria, Emma necesita cuadrar dependencias, esfuerzos y fechas. Cuando interactúa con equipos que están en la party legacy de la empresa, se entienden. Todos hablan el mismo idioma. Pero cuando se dirige a las nuevas estructuras ágiles y sus Product Owners recibe un: “No tenemos fecha concreta. Nosotros trabajamos en agile, así que no tenemos fechas”. Emma está frustrada y, con razón, duda sobre la operatividad – e incluso la profesionalidad – de los equipos ágiles.
La planificación (continua) es clave
Existe un falso mito alrededor de la agilidad y la planificación. Analicemos por encima Scrum, por ejemplo:
- El Product Backlog contiene el futuro del producto. Debe estar ordenado, refinado, estimado y con él es sencillo conocer cuáles serán los siguientes pasos.
- En la Sprint Planning se crea un plan para alcanzar nuestro Sprint Goal durante el Sprint.
- La Daily Scrum es un evento para crear un plan de las siguientes 24h, una vez inspeccionado como va el plan del Sprint.
- La Sprint Review es un evento de negocio que pertenece al Product Owner dónde se analiza la situación actual del producto, del mercado, obtendremos feedback de los Stakeholders y re-planificamos el futuro de nuestro producto y lo plasmamos en el Product Backlog.
- La Sprint Retrospective es una oportunidad para el Scrum Team de planificar acciones de mejora en el Definition of Done, procesos, herramientas o personas.
Como podemos comprobar existe una planificación continua. La clave del éxito de la agilidad en entornos complejos no reside en la falta de planificación. Reside en darle más importancia a la planificación en sí misma, a las conversaciones, a la transparencia que subyace tras cada planificación, que al plan en sí mismo y estar dispuesto a actualizar el plan con cada nuevo descubrimiento que nos pueda aportar una ventaja competitiva. (Extra: Cómo Scrum nos ayuda a alcanzar la agilidad de negocio)
Planificando tendré oportunidad de adaptación
Tener una planificación es básico para poder desarrollar un producto o un servicio de forma profesional. El tipo de respuestas que se ven en desarrollos “ágiles” como el que le daban a Emma “Es que trabajamos en agile y no sabemos cuándo vamos a tener nada” demuestra que no es un desarrollo agile en absoluto y falta product ownership. Es un desarrollo donde se está improvisando. Improvisar y adaptar no es lo mismo. Inspeccionar y adaptar es la clave de la agilidad y eso solo puede ocurrir cuando tengo un plan, y soy capaz de modificar mi plan según las necesidades del mercado.
Una respuesta a Emma en un entorno ágil podría ser: “Emma, con lo que sabemos hoy y con los datos históricos que tenemos, creemos que estará este día X. Cada dos viernes es nuestra Sprint Review y damos transparencia sobre la situación que tenemos y siguientes pasos. Pásate si estás interesada. Además, en este lugar está nuestro Product Backlog y release plan actualizado”. Bastante diferente, ¿no crees?
La falta de Product Ownership
Según mi experiencia el gran mal que azota a las empresas es la falta de liderazgo del producto. Muchas llamadas comienzan con “es que no sale el trabajo”, “es que los equipos no están comprometidos”, “es que no se hacen las cosas bien”.
Cuando escarbas descubres que no existe nada relacionado con la gestión del producto (métricas de valor, releases maps, estrategia y visión de producto alineada con estrategia y visión de compañía) o gestión de la demanda. Esto hace que todo el mundo corra, pero en círculos. Todos están exhaustos, muchas horas trabajadas, mucha presión y nada de valor generado. ¿Os suena esta sensación que todos hemos tenido?
En muchos casos puedes ver un Agile Coach que corre a trabajar para que el equipo esté unido, tengan dinámicas divertidas y buena comunicación. En mi experiencia puedo decir que me he cruzado con equipos con más necesidad de tener una gestión de producto bien aterrizada, profesionalizada y bien ejecutada que con necesidad de mejorar sus interacciones sociales. Eso es algo que se alcanza cuando el equipo (incluyendo al Product Owner) se relacionan alrededor de un objetivo claro y ponen todo su conocimiento y esfuerzo al servicio del beneficio de sus clientes y, por tanto, del revenue para la empresa.
El empoderamiento del Product Owner
Un Product Owner de una gran aseguradora se quejaba de que no tenía ningún tipo de poder de decisión sobre el producto, que le gustaría poder tomar más decisiones y tener más responsabilidad. Yo le pregunté que dónde podría ver sus diferentes horizontes de planificación, sus futuras entregas a los clientes y como esperaba que esas entregas impactaran en las métricas de negocio. “No tengo nada de eso” fue la respuesta.
Para crear productos de alto valor el Product Owner debe estar empoderado. Y aquí hay un contrato de dos partes. La empresa, claro está, debe darles capacidad de maniobra y libertad. Pero no hay que olvidar que el Product Owner debe ganarse la confianza. Tener al menos una visión de producto, un roadmap, un release map y qué métricas vamos a tomar para ver si el valor del producto es el esperado, eso es básico. Sentarse a pedir más responsabilidad con todo este plan bajo el brazo suele ser más sencillo.
Conclusion
El Product Ownership brilla por su ausencia en el desarrollo ágil de productos. Esto nos lleva a falta de planificación e improvisación que suele terminar en desastre. Este “Product Management Vacuum” ocasionado, en muchas ocasiones, por tener Product Managers (o Product Owners) más enfocados en gestión de personas, en planes de proyecto y en cumplir hitos que en tener una visión, generar valor y validar que, con los usuarios reales, que esto está ocurriendo.
El foco de un Product Owner debe estar en las tres V: Visión, Valor y Validación. Una vez que tengamos esto, podemos empezar a trabajar en un desarrollo ágil de producto que permita alcanzar agilidad empresarial a toda la organización.
Si quieres saber más sobre Product Ownership:
- Los 10 mejores libros para Product Owners
- Nuestra academia online: Vídeos grabados y exámenes. Organizáte como quieras.
- Nuestros cursos virtuales: Para facilitar la formación en tiempo de COVID estamos dando nuestros cursos en formato remoto.
- Path de Scrum.org para Product Owners: Conjunto de recursos muy recomendable para todos los perfiles: Scrum Masters, Agile Coaches, Product Owners o jefes de proyecto
Transformación digital: Foundations Model
La explosión del agilismo de los últimos años se debe, en gran medida, a los procesos de transformación que han arrancado en organizaciones de todo tipo en la última década. Pero, ¿todos tenemos claro qué se busca y qué piezas la componen?
En Diciembre de 2019 Jero y yo visitamos a un posible cliente que quería transformarse. Este cliente es una empresa internacional, grande y potente. Para poder dejarla en el anonimato, no puedo decir a qué se dedica, porque reina en su sector de una manera abrumadora desde hace años.
Nos llamaron por que una empresa nueva, pequeña, a la que no prestaban mucha atención, estaba empezando a robarles cuota de mercado. En los últimos 6 meses, esta pequeña startup, había sido capaz de poner en el mercado un producto disruptivo, aprender del comportamiento de sus usuarios, tirar el producto a la basura y rehacer uno nuevo con otro nombre que incorporaba todo lo aprendido. Este nuevo producto estaba funcionando muy bien y robándole clientes.
En esos 6 meses, los directivos de la empresa que nos llamó, aún no habían sido capaces de juntarse y ver cómo podrían competir. ¿Os suena esta historia?
Esto me recordó al Chaos Report 2018. Si no conoces el Chaos Report, es un reporte anual generado por Standish Group. Tienen una base de datos con miles de proyectos y siguen su evolución. Proyectos de todo tipo: grandes, pequeños, medianos, ágiles, no ágiles, en diferentes localizaciones. Hacen seguimiento de estos proyectos y luego nos proporcionan los factores de éxito. Nos mastican datos como el porcentaje de éxito de los proyectos ágiles y los no ágiles, o cómo influyen en el éxito del proyecto las soft skills o las hard skills del equipo. Son informes realmente interesantes y, si no recuerdo mal, tienen un precio alrededor de los 300$.
El informe de 2018 comenzaba con la “Teoría de la latencia en la toma de decisiones” (decision latency theory) donde argumentaban que el factor que más influía en el éxito de proyectos (o productos) era la capacidad que existía en la organización a la hora de tomar decisiones respecto de este producto.
El agilismo nació para poder hacer frente a la creación de productos complejos a través de la inspección y adaptación. Evidentemente, si tu tiempo de respuesta a un suceso inesperado es muy alto, tu capacidad de adaptación es bajísima. Por ello Agile se basa en equipos auto-organizados, en roles de negocio empoderados que pueden tomar decisiones, en desarrolladores que tienen control de todo el flujo del software, desde la creación hasta el deployment.
¿Es todo agilidad?
Cuando surgió el término transformación digital era para hacer referencia a todos esos cambios que empresas grandes y tradicionales estaban realizando para poder competir con las nuevas empresas nativas digitales.
Empresas que aún tienen sótanos llenos de archivadores con datos en papel, intentando subir su nivel de competitividad para luchar con empresas que surgieron directamente con lago de datos, tecnologías big data, data scientists y arquitecturas escalables en la nube.
La digitalización de la humanidad cambió por completo el paradigma empresarial. Antes, el pez grande se comía (o compraba) al pez chico. Ahora, el pez rápido se come al pez lento. Esta transformación es profunda, difícil y engloba tecnología, negocio, cultura, perfiles, management, métricas, productividades o gestión de presupuestos.
¿Qué es transformarse?
Cuando desde una organización nos decían “nos queremos transformar, queremos que nos ayudéis” desembocaba en una conversación larga sobre qué era lo que querían, que significaba para ellos la transformación, que esperaban, qué métricas buscaban mejorar, qué iniciativas habían pensado y qué era en lo que podíamos ayudarles y en qué no.
Recuerdo una empresa que visitamos en 2018 por primera vez. Querían empezar su proceso de transformación implantando Scrum directamente. Su tiempo de entrega mínimo era de 5 meses. Tenían mucha deuda técnica, un stack tecnológico muy primitivo y técnicos que no habían tenido tiempo para innovar ni ponerse al día con nuevas prácticas. Les aconsejamos que primero pusieran el foco en bajar ese tiempo de entrega y les pusimos en contacto con un partner nuestro especializado en crear flujos de integración continua bajo tecnología de Microsoft, que es lo que ellos usaban. Y una vez hecho, podríamos seguir trabajando.
Transformación Digital: Foundation Model
Para poder tener todas estas conversaciones sobre transformación necesitábamos un entendimiento común sobre qué es la transformación digital y qué partes la componen. Desarrollamos un modelo basado en nuestra experiencia. A mi me gusta llamarlo “Foundation Model” porque habla sobre los pilares de una transformación digital
Como nosotros entendemos la transformación digital, ésta tiene tres pilares y una base que sustenta todo:
- Transformación de negocio: Ahora tenemos mucha información sobre los hábitos de nuestros usuarios y ellos quieren productos personalizados e inmediatos. Hay que buscar modelos de negocio que exploten esta nueva relación.
- Transformación tecnológica: Entender todos los datos que tenemos y ser capaces de tener ciclos de entrega reducidos requiere de DevOps, big data, nube…
- Agile: Al incluir nuevos modelos de negocio y nuevas tecnologías hemos introducido una gran incertidumbre dentro de nuestra organización. Tener procesos ligeros basados en equipos de trabajo con alta capacidad de respuesta y foco en entregar alto valor a nuestros usuarios es clave.
- Cultura: Por mucho que cambiemos nuestras tecnologías o nuestros procesos, si los comportamientos dentro de la empresa sigue buscando crear reinos de taifas, nadie comprometido con los resultados de la empresa o un sistema que sigue alejando a los que crean los productos del usuario final, nada se sustentará.
Hemos creado un paper donde explicamos este modelo de transformación digital de forma más extensa y cómo lo usamos con nuestros clientes. Puedes descargártelo de forma totalmente gratuita aquí.
Conclusión
Este modelo surge simplemente para facilitarnos las conversaciones con nuestros clientes. Su intención es crear un entendimiento común sobre qué es una transformación digital, qué partes tiene, qué necesitan ellos, qué podemos ofrecerle nosotros y qué no.
Es totalmente abierto y está en construcción. Siéntete libre de usarlo si crees que te puede servir, o de modificarlo y ampliarlo si así te es más útil.
Me encantaría que me dieras feedback. ¿Qué opinas? Puedes dejarme un comentario en este post o tirarme un tweet.
Scrum y la Business Agility
Muchas veces se tienen dudas como “Y en Scrum se puede…”, “¿y puedo hacer…?”, “¿y se puede…?”. Parece que Scrum es como un conjuro mágico en el que si solo cambias algunas cositas podría seguir funcionando. Y si en vez de ancas de rana pongo ojos de sapo, ¿funcionará? Scrum está lejos de ser una fórmula mágica que soluciona todos nuestros males. Veamos cómo la Business Agility o Agilidad Empresarial puede ayudarnos con estas cuestiones
¿Qué es la Agilidad Empresarial o Business Agility?
El problema real que encierra esta pregunta es que estamos asumiendo que Scrum es un fin. “¿Se puede hacer esto o lo otro y sigue siendo Scrum?”. Cuando a nadie le debería importar si es Scrum o no.
El día que un CEO toma la decisión de reservar una buena parte del presupuesto de los siguientes años para comenzar una transformación, no está buscando que los equipos estén haciendo Scrum, Kanban, Product Owners empoderados o equipos auto-organizados.
Nuestro CEO está buscando la supervivencia de su empresa ganando competitividad e intentando poder luchar de tú a tú algún día con las nativas digitales. Busca alcanzar la Agilidad Empresarial o “Business Agility”:
- Capacidad de poner en valor rápidamente nuestro desarrollo (fast revenue)
- Alta gestión de riesgos
- Poder aprovechar las oportunidades de mercado
Scrum es una herramienta para activar Business Agility en las organizaciones. Lo hace creando al menos un incremento terminado, potencialmente usable, un incremento Done en cada Sprint. De esto va Scrum. No es un fin, es un medio.
Scrum no va de daily, retrospectivas bailando o similares. Va de entregar valor. Scrum nos proporciona elementos: artefactos, eventos y roles, que nos brindan una alta capacidad de inspección, adaptación y transparencia. Los pilares del empirismo. Son las armas que necesitamos para crear incrementos de alto valor y maximizar nuestra capacidad de generar ingresos.
¿Como nos habilita el Incremento “Done” la Agilidad empresarial?
Fast revenue
Los desarrollos de productos se siguen enfocando a proyecto. Primero obtenemos todos los requisitos, creamos un plan para los siguientes meses (o años) y, al final del todo, me voy al mercado a intentar monetizar.
Con el enfoque iterativo incremental que nos propone Scrum y teniendo incrementos terminados, integrados y listos para usarse en cada Sprint, podré ir buscando una version de mi producto que me permita llegar al mercado e ir generando beneficios.
Un ejemplo es el lanzamiento de Amazon Prime Videos. Con poco catalogo, sin soporte para Chromecast o sin aplicaciones nativas para tablets y teléfonos comenzó a poner en valor su nuevo producto lo antes posible.
Alta gestión de riesgos
Podemos hablar de tres grandes riesgos y la manera que tiene Scrum de gestionarlos es resolverlos.
- Riesgo de mercado: ¿Estoy creando lo que mis usuarios realmente necesitan? Scrum va de crear un incremento y conseguir feedback real para adaptar mis siguientes pasos si es necesario.
- Riesgo financiero: ¿Esto cuánto me va a costar? Por mucha documentación y planes que hagamos ya sabemos que siempre habrá variables que no conozcamos. E incluso las variables que conocemos tienen baja predictibilidad. La única manera de conocer el coste es realmente empezar a hacerlo y luego intentar obtener predictibilidad basada en datos históricos.
- Riesgo técnico: ¿Mi idea se puede realizar con las tecnologías que actualmente estoy usando? Una vez más, la única manera de saberlo es empezar a hacerlo e ir obteniendo una nueva versión de mi producto Sprint a Sprint.
Capacidad de aprovechar oportunidades del mercado
Si tienes previsto un desarrollo de más de un año y una oportunidad de mercado llega cuando estás en el sexto mes de trabajo con todo abierto, nada integrado, en definitiva, nada terminado. O Incluso si simplemente has estado documentado lo que vas a hacer los siguientes meses, sumarte a esta nueva ola conlleva muchísimo esfuerzo. Tanto que generalmente se decide dejar pasar o esperar a terminar todo el desarrollo disminuyendo drásticamente tu capacidad de competir.
Conclusion
Una vez que tenemos claro qué Scrum es un medio para hacer crecer Business Agility en nuestra organización, será fácil respondernos a preguntas “¿en Scrum se puede…?”. Simplemente debemos pensar si al introducir un cambio estoy aumentando o disminuyendo mi Agilidad Empresarial.
¿En Scrum se puede tener dos sprints de desarrollo y luego otro de hardening?
Cuando terminen los sprints de desarrollo:
- Si viene una oportunidad de mercado…
- ¿Podré sumarme a ella? No.
- ¿Alguien me puede asegurar cuándo podré hacerlo? No. Nadie puede asegurar que el hardening vaya a tomar solo un sprint o dos.
- ¿Puedo poner en el mercado lo que tengo al final del Sprint de desarrollo? No. Adiós al fast revenue.
- ¿Estamos tomando decisiones del futuro de nuestro producto basándonos en feedback real? No. No lo hemos podido poner en producción por lo que no tenemos ninguna métrica de negocio real. Al no estar nada terminado no tenemos transparencia de la situación del producto, esto nos llevará a discusiones sin fundamento con los Stakeholders en la Sprint Review eliminando nuestra capacidad de adaptación al mercado.
¿En Scrum se puede hacer la Daily Scrum 2 veces por semana?
La Daily Scrum nos permite inspeccionar el avance de nuestro Sprint para alcanzar la Sprint Goal con nuestro Incremento. El Sprint Goal puede representar una hipótesis sobre nuestro producto que negocio quiere comprobar si realmente es lo que quieren los usuarios y si nos va a otorgar el beneficio esperado. Por ejemplo, que mis usuarios van a querer pagar con Paypal.
La Daily Scrum es una manera de maximizar las posibilidades de que el equipo de desarrollo tenga terminado todo el trabajo relacionado con la Sprint Goal a final del Sprint. Eliminando algunas daily,
¿estoy ayudando a mi Agilidad Empresarial o poniéndola en riesgo?
El estado de Agile en 2020
Hace más de 10 años estuve trabajando en un proyecto financiado con fondos europeos llamado Tratamiento 2.0. El objetivo era definir un marco para la obtención de información para la toma de decisiones médicas y la verificación automatizada de estas decisiones.
Me llevó unas cinco semanas definir ese marco teórico utilizando una metodología desarrollada por la Universidad de Amsterdam y hacerla cumplir con lo que se buscaba, que era una especie de UML para las decisiones médicas.
Ese proyecto se enmarcaba dentro de lo que posteriormente sería Horizonte 2020, un programa de la Unión Europea para el desarrollo de actividades de investigación científico-técnicas. Lamentablemente, mi trabajo nunca llegó a usarse.
Por aquel entonces 2020 era una quimera. Un puerto gris. Algo que quedaba lejano en el tiempo. Y sin embargo, hemos llegado.
La transformación del sector
Durante estos últimos años, el sector de la tecnología en España ha cambiado radicalmente.
Aunque quizás parezca lejano, hasta bien entrado el 2016 seguía existiendo un techo de cristal para las carreras técnicas (Programadores, Arquitectos de Software) que requería pasar a un puesto de gestión para poder ver incrementado tu salario.
En 2013 me mudé a Londres y apliqué a 20 ofertas para desarrollador un Lunes por la noche. Al día siguiente tenía 15 llamadas perdidas y mensajes en el buzón de voz. Contrastaba con la sequía de interés por parte de las empresas en España. En las consultoras andaluzas, el sueldo era de 850€ netos.
Fue una de las primeras cosas que me sorprendió cuando me fui de España en los peores años de la crisis.
Por otro lado, encontrar compañeros de 50 años que arrastraban una carrera técnica sin intención de cambiar, porque sus expectativas estaban más que satisfechas.
Al principio se me hizo extraño. Nunca había trabajado en equipos técnicos con gente que estaba más cerca de la jubilación que del comienzo de su carrera profesional. Fue interesante descubrir como la madurez personal puede aportar mucho más que los conocimientos técnicos a los proyectos de Software.
Durante ese tiempo tuve la oportunidad de conocer en profundidad proyectos como el del Government Digital Services del gobierno británico, en el que introdujimos principios DevOps para garantizar la calidad de la arquitectura, la testeabilidad y reducir los ciclos de vida del desarrollo y la producción. Hablé de ello en la Conferencia Agile Spain de 2014.
El concepto de transformación digital también llegó tarde a España. Trabajando en la transformación digital de CapOne UK en 2014, vine unos días a España y descubrí a través de una búsqueda rápida en Google que nadie hablaba del tema. Fue BBVA en 2015 la que se embarcó en un proyecto de transformación que todavía dura.
En 2017, los recruiters invadieron el mercado después de haber pasado por Centroeuropa. Se destapó el pastel. A pesar del esfuerzo de muchas empresas para mantener unos salarios contenidos, se hizo patente que no había tanto talento técnico como demanda.
Durante esta década han surgido multitud de pequeñas compañías que se han especializado en el apoyo a determinados aspecto del proceso de transformación. También las grandes se han lanzado con los dos pies a intentar llevarse un trozo del pastel.
Los casos de éxito y de fracaso
Hay pocos casos de éxito a gran escala pero multitud de ellos a pequeña escala. De hecho, hay muchas startups y pequeñas compañías que no existirían de no llevar la Agilidad de Negocio en su ADN.
El motivo para que las grandes todavía no puedan presumir de casos de éxito rotundo es sencillo. La cultura de una compañía de décadas y decenas de miles de empleados no se puede cambiar en uno, dos o cinco años. Probablemente requiere jubilar a una generación de personas para dejar paso a las nuevas ideas.
Muchas personas siguen viendo Agile como algo perteneciente a tecnología. Y a tecnología como algo separado del negocio. Incluso peor: Abrazan Agile como un fin en si mismo cuando en realidad es un medio para conseguir un fin. Organizaciones más competitivas, innovadoras y aptas para sobrevivir.
Por supuesto, el crecimiento de la demanda de Scrum Masters, Product Owners y Agile Coaches no ha hecho sino atraer personas externas al sector que han buscado la mejor manera de incorporarse a puestos bien pagados en compañías que se preocupan de sus empleados. Tardará un tiempo y llevará una criba, pero muchos de ellos han llegado para quedarse.
Tal y como dice un buen amigo y conocida figura del desarrollo de Software: “¿Y cual es el problema? Yo empecé a hacer Software en el 2000 tras pasar un curso de tres semanas en una desaparecida consultora después de suspender las oposiciones a profesor de filosofía”
Conforme arrancamos 2020, Agile no es una palabra desconocida para la mayoría de las organizaciones. Quizás no todos entienden de la misma manera lo que es, pero ya no es desconocido.
Agile no es un puerto gris. Es un puerto que hace tiempo superamos.
Ahora el trabajo es más difícil, ya que supone ir alineando, descubriendo y acompañando organizaciones en descubrir como usar esa amalgama de cosas inconexas para obtener un resultado tangible en su cuenta de resultados.
Hace cuatro años publiqué un artículo en LinkedIn que tuvo cierto éxito: 9 Easy Mistakes to Avoid during your Agile Journey. Uno de los puntos a evitar era “No despedir gente“, en el que hacía una clasificación rápida del tipo de reacciones que la gente tiene ante estos procesos de cambio: Aceptarlas, Irse o lucharlas desde una falsa aparicencia de aceptación.
El problema son los terceros. Tienen una evidente falta de Skin in the game, cuidan mucho su exposición pública, no ponen su nombre junto a lo que dicen y utilizan a otros para sus fines publicitarios.
En el libro Skin in the Game, Nassim Nicholas Taleb explora las asimetrías cotidianas en las que no nos fijamos en lo que la gente dice, sino en como se están arriesgando para defender desde El Mundo Real™ esas ideas.
Los falsos ídolos
No quiero terminar de escribir este artículo sin hablar de las certificaciones: los falsos ídolos.
Al parecer, existe una creencia generalizada en el mercado Agile que las certificaciones son una especie de sistema mágico que te habilita para hacer cualquier tipo de transformación mágicamente.
No lo son.
Las validaciones profesionales existen desde hace muchos siglos como complemento a una experiencia profesional que es insustituible. Habitualmente son una manera de establecer un reto claro en el objetivo es mejorar el conocimiento para luego llevarlo a una realidad. Proporcionan una base que permite comparar, aprender y descartar en función de una variable más. No la única.
Aquí hay dos falacias a explorar.
La primera es que hay grandes profesionales que no ostentan ninguna certificación. Sin embargo, no ostentarla no te hace por defecto un gran profesional.
La segunda es que sirven como muñeco de paja para golpear con el argumento de que sólo sirven para obtener un título y que la formación en torno a ellas es solamente una preparación -un peaje- para ganar más, aunque no tengas ni idea.
Es un problema de calidad de la fruta que compramos.
Hace un tiempo escribí sobre la teoría del mercado de los limones, una metáfora para ilustrar el problema que supone poner a competir un producto de buena calidad con uno de mala calidad. La solución en este entorno es disminuir la asimetría de la información -que el consumidor esté mejor informado- para hacer evidente la diferencia de calidad de los productos existentes en el mercado.
Estas falacias son fácilmente rebatibles.
Agile como moda
Para aquellos que piensen que esto es una moda, les recomiendo que hagan una comparativa de búsqueda entre Agile y Televisión 3D, para descubrir qué es una moda y qué es un movimiento que poco a poco está transformando el mundo.
Agile en 2020 está más vivo que nunca.
Hay muchos retos por delante: Profesionalizar cada vez más el sector, conseguir que los programadores dejen de estar enamorados de su código y empiecen a enamorarse del valor que su código crea y convencer a muchos responsables de toma de decisiones que las bolas mágicas están pasadas de moda.
Por supuesto hay quien seguirá vendiendo Scrum o Kanban como la solución mágica a los problemas de las organizaciones, pero no lo son. Aportan la estructura necesaria para poder afrontar esos problemas, pero no los resuelven.
Esto significa contar con gente técnicamente preparada y darles el espacio que necesitan para poder empezar a aportar, eliminando capas de gestión que están ahí para dar una falsa apariencia de control sobre el Caos.