Pero ¿alguien alguna vez se ha preguntado si su empresa está preparada para trabajar con la metodología Agile?
Como pasa siempre, algo se pone de moda y el directivo de turno se viene arriba (o lo que es peor: para no parecer que se queda atrás) y decide montarse en el carro de la modernidad.
Lo hemos visto cientos de veces:
- Transformación digital
- Bigdata
- Blockchain
- Datawarehouse (antes del bigdata)
- Cloud
- o hay que estar en Twitter!!, o miles de fans en Facebook!! , o vamos a montar una sucursal en SecondLive (¿recuerdas qué era SecondLive?)
Como buenos humanos, no aprendemos. Pero como los errores los cometen otros, parece que no importa.
Pero cuando dolor y sufrimiento nos podríamos ahorrar si se pensaran un poco las cosas antes. Cuando digo “pensar” me refiero a entender y meditar qué implican las decisiones y sobre todo para qué. Descubriríamos que muchas de estas iniciativa son “Tecnología de Demostración” para buscar el efecto “WoW”. Pero cuidado con implantar una metodología que no es apropiada.
La metodología Agile será nuestra salvación
Los gurús nos han prometido que la metodología Agile va a ser nuestra salvación, que con ella vamos:
- ser ágiles
- rápidos
- vamos a gastar lo justo
- vamos acercarnos al cliente a unos niveles antes desconocidos.
- y vamos a lograr hacer productos 100% adaptados a las necesidades.
¿quién no quiere esta maravilla? Yo el primero. Todos mis problemas como gestor de proyectos software se van a acabar.
Preguntas básicas antes de comenzar con Agile
Pero me pregunto yo:
- ¿necesitamos ser ágiles? A ver si vamos a ser un transatlántico y lo que necesitamos es un GPS para navegar con precisión y rentabilidad, en vez de pegar volantazos como una lacha motora (que te recuerdo que no tiene mucha autonomía)
- ¿hacemos productos? Si nos dedicamos a vender casas o ser auditores de cuentas, sinceramente no veo que haga falta ser muy ágil. Sí que puede ser interesante el estar abierto a otras ideas de negocio, y ser permeables a la innovación.
- ¿tenemos realmente una interacción con el cliente? Todos tenemos uno o muchos clientes, eso es innegable. Pero si no tienes sensibilidad a darle gusto al cliente, va a dar igual qué “metodología” usemos. Las operadoras de telecomunicaciones, durante muchos años han obviado a los clientes debido a que sus crecimientos eran tan altos y los clientes se veían obligados a comprarlos que daba igual cómo los trataras que iban a volver. Pero cuando el mundo ha cambiado, estas organizaciones no han cambiado a la misma velocidad, y se han encontrado con cifras record de reclamaciones y clientes enfurecidos. Pero lo que es peor: son incapaces de hacer virar su modelo de negocio hacia algo sostenible, diferenciador y apreciado por sus clientes.
- ¿estamos preparados para ser ágiles?
La pregunta más importante es: ¿estamos preparados para ser ágiles?
“¡por supuesto que somos agiles! ¿Por qué tipo de organización nos ha tomado?”
(futuro ex-) Director General
En mi experiencia, y no gracias a ningún manual, he comprobado que para que Agile/Scrum funcione se deben dar al menos la siguientes premisas:
¿Está mi empresa preparada para Agile? Tolerancia al Fallo
- La organización ¿está acostumbrada a la “Mejora Continua” o “busca la perfección a la primera”? Vamos a entrar un proceso iterativo, y de aproximaciones, por tanto, nada saldrá bien a la primera…. debemos entenderlo.
- Como consecuencia de lo anterior: ¿nuestra organización gestiona bien el fallo o la no-optimización? Esto es vital, si la organización penaliza los fallos o las soluciones intermedias o no suficientemente depuradas, vamos a tener un problema insalvable. Hay organizaciones, sobre todo aquellas que vienen de entornos muy regulados y poco tecnológicos, donde se juega un juego perverso: la búsqueda del fallo.
- ¿por qué se busca el fallo? En este tipo de organizaciones el “fallo” (real o no) se usa como una pelota en un partido de ping-pong. Por cada pequeño fallo, se anota en un “marcador”. Si tienes más fallos que tu competencia (tus compañeros), estas muerto (despedido o degradado). El mecanismo tiene cierta lógica: solo los empleados que comenten menos fallos serán los más aptos para progresar y dirigir. Pero cuando se usa el fallo como arma, se entran en dinámicas de: falta de decisión (si decides te equivocas, y si te equivocas “punto negativo”). Así que nadie toma decisiones, los jefes deben hacer micro-gestión, lo cual les absorbe muchísimo tiempo, y no pueden pensar en la estrategia sino son totalmente tácticos. Finalmente la detención a la mejora y la innovación se propaga por toda la empresa. Eso sí, sin fallos.
- ¿cómo se da el “gusto por el fallo” y por qué es un buen caldo de cultivo? En entornos muy regulados, hay normas para todo, lo cual marca un marco de trabajo muy estricto y relativamente poco proclive a la innovación.
- ¿cómo romper la dinámica? Diferenciar entre optimización o mejora continua, fallo y negligencia.
- Todo se puede optimizar a través de la mejora continua. Es decir, hay cosas que no se hacen bien. Pero eso no quiere decir que se hagan mal, sino que se pueden hacer mejor.
- Fallo, error o incidencia: es algo que claramente no funciona, que entorpece y que se debe arreglar. Pero hay fallos y fallos. ¿cómo dimensionamos la importancia de un fallo? Yo procuro hacerlo basándome en el impacto en el cliente (o accionista) y en la marcha del negocio. Así tenemos que un fallo es crítico cuando impide una operación de negocio y/o impacta en el incremento de valor para el accionista. Todo lo demás no impide funcionar la empresa, así que es susceptible de ser mejorado.
- Negligencia: esta es la clave. Si por negligencia se ha cometido un fallo o un proceso no es óptimo, ese punto sí que debe ser “castigado”, a parte de ser corregido. La negligencia oculta falta de interés, falta de compromiso y falta de profesionalidad.
¿Está mi empresa preparada para Agile? Cultura Corporativa
- ¿es una empresa jerarquizada? El que una gran empresa tenga una gran estructura es inevitable, pero la jerarquía se puede aplicar de una forma dura o blanda. ¿los jefes son infalibles? ¿se parece más al ejercito que a un equipo de futbol? Si la empresa es altamente jerarquizada no dejará libertad de movimientos a los equipos “ágiles” todo deberá pasar por decenas de aprobaciones, y luego para dar explicaciones, por decenas de comités.
- ¿es una empresa colaborativa? ¿Los departamentos colaboran libremente? ¿se suelen formar equipos de trabajos de varios departamentos? ¿los proyectos son solo de un departamento? ¿de dos? o ¿de más de dos? Si la organización es capaz de sacar un proyecto en el que intervengan 3 o más departamentos vamos bien. Se de muestra que no hace falta un “jefe” común sino que los equipos se autogestionan, y no solo por afinidad (cuando un proyecto es de solo 2 departamentos).
- ¿está la dirección comprometida (y lo entiende)? Me hace mucha gracia cuando la dirección manda hacer una cosa, pero luego se olvida y pide otra. En este caso, nos encontramos muy habitualmente que la dirección equivoca “ágil” con “rápido”, incluso la implantación de una metodología y cambio cultural “ágil” debe ser también “rápido”. Por la desgracia no termina ahí: si la dirección sigue pidiendo los indicadores habituales de “proyecto cerrado”, “presupuesto”, “incidencias”… va a ser un foco de frustación.
- ¿hay rotación en la empresa? Si después de todo, tenemos autonomía, equipos autogestionados, la dirección alineada y los usuarios asumen que va a ser un proceso iterativo… pero los miembros del equipo entran y salen a las pocas semanas, estamos muertos. Desgraciadamente en el mundo IT, y sobre todo en puestos de desarrollo de software la rotación es muy alta gracias a la demanda de este tipo de puestos. Pero para nuestro objetivo es mortal ya que la “autonomía” antes reclamada se basa en que el conocimiento y knowhow reside en una persona. Si tenemos rotación deberemos establecer procedimientos de documentación y formación mucho más severos que restarán agilidad al modelo.
