Gracias a la Transformación Digital, las empresas han descubierto que tienen que evolucionar su tecnología, su estructura, sus modelos de negocio y su cultura hacia nuevas formas para poder sobrevivir. Debido al Covid, y su impacto, las empresas no les queda otra alternativa: cambiar o morir.
El C-Level (CEOs, CIOs, CTOs… ) son las figuras más responsables dentro de las empresas, y, por tanto, las que juegan un papel relevante dentro de una Transformación Agile. ¡Lo analizamos!
El C-Level se involucra en Agile
Hace tiempo tuvimos una conversación muy interesante con Christian Heredia Naranjo que podéis leer aquí. En la conversación, Christian nos compartía su impresión sobre la implicación del C-Level en la Transformación Agile:
“Conversación real en una de las empresas que trabajé, en un proyecto de banca:
– C-level: Vamos hacer Agile que funciona a entregar más a menudo y a los Clientes les gusta y lo demandan.
+ Genial! a mi me gustaría ser Scrum Master de un equipo Agile.
-Ok pero tiene que estar pa’ final de año.
+ ….
Tres Sprints después:
+ Mira que, viendo la tendencia, los problemas y cambios que han surgido no da tiempo para Diciembre.
– Lo gestionáis internamente. Al cliente ya le dimos esas fechas y esas funcionalidades NO podemos perder el proyecto ni al cliente.
Y así es como un C-level se involucra.
Entonces volvemos. Si, hay que involucrarlos pero ¿cómo? ¿Cómo le dices que un proyecto que alguien en un análisis precipitado, probablemente bajo presión dió unas fechas y se estimó un presupuesto muy lejos de la realidad?
· Seguramente me respondan: Hay que involucrar al Cliente.
¿Cómo? Al final un cliente hace Agile pero el contrato está cerrado por X euros desde el día uno.
· Respuesta: Hay que hacer contratos Agiles. Donde el proveedor y el clientes conozcan que el Budget y/o Scope pueden variar.
¿Cómo? Si ya estaba dentro de ese bucle infernal.
Resultado: Se perdió el cliente y el proyecto.
Conclusiones en C-level: Pa’ qué tenemos un SM?”
¿Por qué abandonamos Scrum?
Una vez, me encontraba trabajando en una consultora, y un equipo estaba desarrollando la web de una gran aseguradora. El contrato era abierto, se negociaron dos años de desarrollo por una cantidad de dinero. Sin embargo, el cliente tenía hitos importantes y bonus personales asociados, lo cual genera mucha presión al equipo. Cuando llegó el primer hito, el equipo descubrió que no iban a alcanzarlo. Mi responsable decidió que debíamos meter refuerzos, renegociar el alcance, echar horas extras y olvidarnos de la calidad. ¡Lo que se hace en todos los proyectos!
Hablando con él de este tema, me hizo una pregunta clave: ¿Qué quieres que haga Javi? Y tenía razón, una vez la expectativa es entrega-en-fecha, no puedes pretender hablarles de “valor” y de inspección adaptación, ¡es demasiado tarde! El problema no está en las decisiones que tomas cuando “todo va mal”, sino en cómo has vendido el desarrollo. Era más fácil prometer una fecha que explicar que lo importante era conseguir una aplicación que realmente funcionara para sus usuarios y cubriera sus necesidades.
En mi caso, no se abandonó Scrum, pero el Equipo de Desarrollo acabó muy tocado. Scrum en un waterfall encubierto, provoca que los cambios nos destrocen, no tenemos un plan que nos permita pararlos o negociarlos. Lo que sí es cierto, es que, este cliente nos dijo muchas veces que Scrum no lo quería, y que no nos empeñamos en ello, que le dierámos fechas para poner sus bonus y garantizar que nos esforzamos.
¿Nosotros tenemos que cambiar?
Este verano estuvimos charlando con un posible cliente sobre una Transformación Agile&Cultural. Tuvimos que quedar un día en el que pudiera todo el comité de dirección, nadie se lo quería perder. Al finalizar nuestra presentación, llegó el turno de preguntas. Una de ellas, parecía obvia, “¿Debemos participar de esto el comité?”. A mí, se me llenaron las lágrimas de ojos, ¡esto es justo lo que necesitamos! Ahora estamos planteando un cambio desde la dirección hasta los equipos.
He estado en varias consultoras, y tardé meses o años en conseguir que la dirección se interesara por Agile. “Nosotros ya sabemos de esto, no lo necesitamos”. Pero la realidad de los equipos es la misma: horas extra, baja calidad para llegar a la fecha, tensión con clientes, y productos que no tienen uso o son rentables.
La mejor manera de que un cambio ocurra es predicando con el ejemplo. Ahora que soy padre, lo tengo claro, si tu les dices que hagan las cosas de una manera y tu no lo haces, les va a costar más entenderlo.
Los adultos no somos diferentes, nos comportamos como se espera de nosotros, y lo que espera suele ser similar a cómo trabajan nuestros “mayores”. Si un jefe no es transparente con su equipo, no debe esperar transparencia recíproca. Cuando permitimos que un compañero critique a otro en una reunión, y no intervenimos, entonces está permitido. Si hacemos un Agile “fake”, dónde nos saltamos todos los principios y valores, y no desarrollamos en torno a la creación de valor, ¿creemos que va a funcionar?
El CEO no entiende de software
Si nos fijamos, las empresas top en tecnología disponen o han dispuesto de programadores a su cargo. Bill Gates en Microsoft, Mark Zuckerberg en Facebook, Steve Jobs en Apple o Jeff Bezos en Amazon. Todas estas empresas disponen de personas que, en algún momento de su vida, han desarrollado software.
Hay empresas, como Inditex, que promueven que sus empleados de tecnología, pasen unos días en una tienda haciendo labores típicas. El objetivo es claro, entender a lo que se dedica su empresa, para dar mejores soluciones.
Sin embargo, esto no es suficiente para que funcione. He visto a varios CEOs de empresas frenar su propio cambio cultural. Por ejemplo, una vez un CEO me dijo “Javi, si siempre hemos dado fechas, ¿por qué ahora no quieren los equipos dar fechas?”. Muchos han vivido un desarrollo software orientado a fechas, no a generación de valor. Hacer mucho, pero no hacer lo correcto. Y cuando estas personas llegan al C-level, se comportan igual que cómo lo han vivido en su “época de desarrollo”. Los modelos de planificación y control, se imponen a un pensamiento diferente. El objetivo no es hacer software, es resolver problemas con el software.
Por tanto, además de entender de software, hay que interiorizar que, o se plantea el desarrollo desde otra óptica, o podremos generar dinero, pero a base mucho esfuerzo. Las consultoras generan mucho dinero, a base de muchísimos momentos desagradables que hacen que el C-Level viva con extremo agotamiento esta profesión.
Cómo actúa el C-Level en una organización Agile
En el texto original del que parte Scrum: the new new product development game se hablaba de que los equipos tuvieran cierta autonomía para trabajar por sí mismos. ¿Cómo garantizan las empresas que sus equipos rinden bien? Cuando tenemos un planteamiento orientado a resultados y generación de valor, necesitamos reuniones de control orientadas a ello. En Scrum esto se refleja en la Sprint Review. La Sprint Review pasa a ser el evento más importante para una empresa que implanta Scrum. En ella, inspeccionamos el impacto de nuestro producto en el mercado: ¿estamos generando dinero? ¿están los accionistas más contentos? ¿el equipo? ¿nuestros customers? ¿cuál es la tendencia?
Estas preguntas son las más importantes que debe hacer una empresa, y por tanto, las más importantes para el C-Level. Lo bueno de que lo tratemos en la Sprint Review, es que unimos a la estrategia (C-Level) con la operativa (Scrum Team) y podemos, como equipo, tomar decisiones: ¡Nos va la vida en ello!
El llevar ante los equipos los números de la empresa, y dejarles decidir, ayuda a que todos estamos alineados. La mayor energía que puede crear un C-Level en la empresa es la sensación de supervivencia. Si todos tenemos claro cómo funciona nuestra empresa, cómo gana dinero, y lo que queremos ser, entonces podremos avanzar más rápido (nos ahorramos explicaciones).
¿Se debe implicar el C-Level en la Transformación Agile?
Si una organización quiere evolucionar hacia algo diferente, todos debemos estar en la misma página. El C-Level debe “soportar” la transformación, implicarse, interesarse y apostar fuerte por ella. Los cambios duelen, nos pasa a todos, y más a las empresas, pero tras el dolor vienen estados de mejora.
Imagina que es verano en Sevilla, y estás en un edificio sin aire acondicionado, hace calor y así no puedes trabajar. En frente tuya, hay otro edificio donde podrías ir a trabajar, tiene aire acondicionado, y un ambiente más favorable para que puedas concentrarte. Sin embargo, para llegar tienes que andar por la calle, vas a pasar todavía más “dolor”. ¡De esto va la transformación!
Y tu C-Level, ¿se involucra?
