En una reciente entrevista efectuada a Don Callahan, Cit’s Head of Operations & Technology, me llamó mucho la atención los siguientes puntos:
The Quarterly: What are the top-of-mind risks for you as you continue Citi’s transition to a digital bank?
Don Callahan: I think the biggest risk for the industry is whether it will be able to move fast enough. Are we going be able to think and execute swiftly? A lot of people talk about being agile. Agility is a lot more than how our developers approach an issue. “Agile” now is a group of subject-matter experts coming together from each walk of life—someone who is a true developer collaborating with someone who is a product manager who knows how to listen to the customer or the client. And then the real test is whether they take that, put it together as an idea, and bring that story to life. In addition, if it is not right, can they move on and come up with the next version fast enough?
The Quarterly: So, give us an example of agility at work.
Don Callahan: An example right now is work that Stephen Bird, CEO of Global Consumer Banking, is leading. We know we have to be mobile first, and we are doing a lot there. In order to be all-in on mobile, we have set up a “lean team” in our Long Island City office, with about 100 people who are operating in a very agile way.
It doesn’t operate like a traditional bank; it is much more like a creative team. They are incorporating feedback, putting up designs on a wall, and testing directly with customers. They are experimenting and coding. I’m seeing the speed, the curiosity, and the execution at levels I’ve never seen before.
Basándonos en la visión de Don Callahan, quiero expresar en estas lineas sobre mi visión del trasfondo de la Agilidad, y los desafíos por venir:
El despegue de la Operatividad:
Sabemos, que es muy común que se intente restringir a la Agilidad a temas operativos, como son la identificación e implementación de prácticas (XP, TDD, etc.), frameworks (SCRUM, Kanban, Lean, etc.), herramientas (JIRA, BitBucket, TFS, etc.) y procesos (Continuous Delivery, DEVOPS, Docker, OpenShift, etc.). Es larga la documentación respecto a estos elementos. Incluso hay quienes hablan de «Metodologías Ágiles» como diversas amalgamas de estos temas.
Sin embargo, y dado nuestra experiencia, entrenamientos, y la visión de líderes como Don Callahan, Masa Maeda (quien nos visitó la semana pasada) y muchos otros a nivel mundial, vemos que el foco NO está en sumar y sumar prácticas, frameworks, herramientas y procesos, sobre todo si es que no se comprende la razón de estas prácticas, frameworks, herramientas y procesos.
Mas bien, estas prácticas, frameworks, herramientas y procesos son importantes, claro, pero son menos importantes que el entender a aquello que quieren resolver o implementar. Lo importante es llegar a la esencia, al trasfondo de la Agilidad. Y una vez ahí, poder construir un camino que permita incorporar, adaptar y (en ocasiones incluso) descartar aquellas prácticas, frameworks, herramientas y procesos, de acuerdo con las características de la organización / área / equipo y el nivel de madurez que se tenga en estos puntos.
¿Y cuál es la «esencia» de la Agilidad?
La interpretación se sintetiza en lo siguiente:
Esencia de la Agilidad:
a) La entrega continua de valor para nuestros usuarios y/o clientes;
b) En un continuo aprendizaje a fin de eliminar los impedimentos;
c) Aceptar y adaptarnos a los cambios;
d) Trabajar codo a codo con el negocio, el cliente y/o los usuarios, y con los demás stakeholders y en un entorno tal que “mejore nuestros días lunes” (*)
(*) El concepto de “mejorar nuestros días lunes”, tiene que ver con un conjunto de situaciones en que se mejora la calidad de vida dentro del horario de oficina. Es el encontrar aquellos elementos motivadores; y que la organización y las personas se organicen entorno a esos elementos.
Es interesante notar que estos elementos no son técnicos, incluso transcienden a lo operativo.
Es decir, es necesario traspasar las brechas que separan los niveles Operacionales, Tácticos y Estratégicos, lo que implica un cambio completo, un «pensar» y «hacer» las cosas, de una manera diferente.
Es importante no enredarse en las etiquetas: estos 4 puntos podrías llamarles como quieras, incluso simplemente «Sentido Común»; y podrían estar ya incluidos de alguna forma en las estructuras y procesos organizaciones. Sin embargo, se puede identificar un claro origen en lo que es el manifiesto ágil, el cual emerge del mundo del desarrollo de software, pero que ha visto traspasada su aplicabilidad a disciplinas muy diversas como la venta en linea de zapatos y la construcción de obras civiles.
En mi punto de vista, es necesario darle adecuada visibilidad y tensión de cambio.
La palabra «Ágil» podría estar de moda, pero no así su Esencia.
Si nos enfocamos en estos 4 puntos de la Esencia de la Agilidad, estamos alineados con Don Callahan, con Masa Maeda y con lo que necesitan las organizaciones modernas, y, es de esperar que con nuestro propio plan de carrera.
¿Y los equipos?
Volviendo a los recovecos de las prácticas, frameworks, herramientas y procesos. Podrían darse muchos casos, pero es interesante notar algunos en los que de alguna forma puedes sentirte involucrado:
a) El que tiene todo pero no entiende nada:
Tu podrías tener la suerte de trabajar en un team donde ya exista la potencialidad de aplicar de estos temas operativos (prácticas, frameworks, herramientas y/o procesos), y puede que tus lideres, tus compañeros, tu negocio, y tu entorno completo, ya se hayan puesto en marcha para aplicarlos de alguna forma.
Todo bien, pero tu no logras entender el «¿por qué?» de todo esto.
Y te quedas con frases como:
- «¡Pero si yo lo hago de la forma tradicional, como me enseñaron en la universidad, y siempre me ha dado resultado!»
- «¿Para qué cambiar si esto ya funciona?»
- «¿Cliente satisfecho? Eso es materia de los de Marketing.
- «¿Negocio satisfecho? Eso es trabajo del Leader o del Management.
- Yo soy un desarrollador de software y me debo dedicar a eso. Y además soy muy bueno en lo que hago: puedo construir cualquier especificación en mucho menos tiempo que el promedio. Soy sobresaliente!!
- «Mi negocio no comprende que mi trabajo es complejo y que no puedo comenzar a desarrollar sin tener un análisis de requisitos completo: menos podría entregarle algo si es que ni el diseño está listo! ¿A caso creen que estamos improvisando acá? ¡Somos ingenieros! tenemos nuestros procesos y los debemos cumplir.»
- «No comprendo donde está la utilidad de aplicar estos cambios, pues nos tomará mucho mas tiempo, y si lo hiciéramos como siempre podría ser mas rápido»
- «¡Esto de la Agilidad es un fraude!»
Sentirás que te quejas y quejas todo el día.
Y lo más extraño es que de apoco, tus compañeros no parecen pensar como tu. Algo les habrá picado?.
– «Y eso no es nada!.. No sé qué bicho le picó a mi jefe que ahora dice que necesito supervisión constante, como si fuera un bebe..»
El problema es que no logras entender que estos cambios, estas nueva prácticas, frameworks, herramientas y procesos, tienen una razón de ser, y NO son un fin por si mismo.
- No trabajamos TDD por que lo dijo el jefe:
- Sino por que es una forma se asegurar que lo que hacemos sea exactamente lo que el negocio quiere. Ni mas ni menos.
- Lo que minimiza el numero de defectos entregados a SIT.
- Lo que nos hace ser más eficientes.
- No trabajamos con XP por que lo diga un libro:
- Sino por que hemos descubierto que es una forma de trabajo creativa, e increíblemente veloz.
- No trabajamos con SCRUM por que esté de moda, o por que «desde arriba» nos lo impusieron:
- Sino por que es un marco de trabajo que ordena el esfuerzo del equipo de desarrollo y testing,
- Nos define cómo interaccionar con el negocio, y el cliente.
- Nos permite centrarnos en lo más valioso para el cliente final o usuario.
- Nos brinda un proceso continuo de feedback y de mejora continua. Nos muestra nuestras debilidades que hasta ahora estaban ocultas.
- Y más aun: vemos cómo nuestro esfuerzo da sus frutos de una forma rápida y constante;
- Nos hace ser más equipo y menos grupo; nos aísla y protege de los vaivenes de los proyectos.
- No trabajamos con Lean por que algún gurú nos diga que nos llevará al nirvana:
- Sino porque nos ayuda a identificar y descartar los impedimentos y por lo tanto ser mas efectivos y eficientes en nuestro trabajo.
- No trabajamos con (o estamos intentando adoptar): JIRA, GIT, TFS o Continuous Delivery, DEVOPS, Docker, OpenShift, por que estén de moda, o por que alguien supo vender estos juguetes a la alta gerencia:
- Sino que porque cada una de estas herramientas y procesos y movimientos constituyen un eslabón en una cadena, que tiene como fin ultimo el entregar valor al cliente y usuario de una forma continua, rápida, segura y de alta calidad
b) El que SI entiende todo pero está amarrado:
Al contrario, tu podrías entender que estos cambios si son necesarios. Sabrás cómo estos cambios beneficiarían a tus clientes, usuarios, y por lo tanto al negocio; y a tu equipo; y a ti mismo.
Pero te has encontrado con una serie de impedimentos:
1) Trabajas con una tecnología legacy:
- Ves cómo los otros equipos de tu organización se van sumando y sumando a este nuevo paradigma pero te ves impedido a incluir las prácticas o frameworks o herramientas, o quizá no puedas implementar esto en su cabalidad: Por ejemplo, tu entorno tecnológico impide que puedas tener Integración Continua, por lo que el proceso de compilación y puesta en ambiente de integración no se puede automatizar.
- Es muy difícil o imposible entregar valor sino hasta cuando un gran sección o modulo de tu aplicación esté completamente desarrollado.
La Esencia de la Agilidad no está en las prácticas, frameworks, herramientas, ni procesos. Por lo que, no es necesario que implementes todas estos elementos operativos, ni siquiera que implementes uno solo en su totalidad, o según los libros.
- Puedes adaptarte, puedes aplicarlos parcialmente, o puedes hacer lo mismo, quizá menos eficientemente, pero de una manera eficaz.
- Si tienes el chip de la Agilidad, entonces, sea como sea que sea tu entorno de trabajo, siempre:
- Intentarás entregar valor en forma continua de valor a tus usuarios y/o clientes;
- Crearás en tu equipo un continuo aprendizaje a fin de eliminar los impedimentos que puedes eliminar según te soporte tu tecnología.
- Aceptarás y te adaptarás los cambios.
- Trabajarás codo a codo con el negocio, el cliente y/o los usuarios, y con los demás stakeholders y en un entorno tal que “mejore nuestros días lunes”.
No te escudarás en la tecnología, pues ahí no está lo importante.
2) Tu y tu equipo están convencidos pero el negocio no lo está:
- Se alejan de ti, o no están dispuestos a tener reuniones mas allá de una cada mes o al inicio del proyecto (para decir lo que quieren).
- O tu negocio es muy critico como para «ponerlo en riesgo» a aplicar algún cambio.
- A pesar de los errores y fracasos en los proyectos el negocio crees que no se puede hacer las cosas en forma diferente
3) Tu y tu equipo están convenidos pero el Management local no lo está:
- Los procesos de la PMO son estrictos, y se deben cumplir a rajatabla.
- No hay capacidad de innovación.
- No es rentable para el Management arriesgarse a que las cosas salgan mal. «¡Porque saldrán mal!»
Siempre comienza de lo pequeño:
- La clave es que si vas a fallar, que falles rápidamente, para aprender y luego intentarlo nuevamente.
- Busca entre tus pares los ingredientes necesarios mínimos para poder hacer un experimento de proyecto ágil de bajo costo.
- Crea el entorno necesario para asegurar que aquellos visionarios, se capaciten, y puedan experimentar de forma controlada. Minimizando el efecto de las fallas, y potenciando el resultado de los éxitos.
- Cualquier éxito, por pequeño que sea, difúndelo.
- Convence con el ejemplo.
Siempre colabora con lo grande:
- Ponte en contacto con la comunidad local para crear lazos y un continuo flujo de conocimiento.
- Consigue un mentor dentro de la gerencia con quien puedas trabajar.
- Consigue un coach externo, para que guíe a la gerencia y luego a la organización.
- Alíneate rápidamente con las decisiones estratégicas relacionadas.
- Potencia a los visionarios creando un movimiento. Que esto no pare!.
¿Y los comités?
Una vez le preguntaron a Steve Jobs, cuantos comités habían en Apple Inc. Y su respuesta fue clara: cero comités.
Pero no todas las organizaciones son Apple Inc. y no hay muchos Steve Jobs, en todas partes (pero de que los hay, los hay).
Entonces, puede que tu organización si necesite de comités, que se reúnan a pensar el cómo adaptar tal o cual idea a cierto entorno concreto.
Si es el caso, este comité debería enfocarse en dos tareas principales:
a) Apoyar en los procesos de onboarding de prácticas, frameworks, herramientas, y procesos.
b) Ayudar a lograr explicar el ¿por qué? de estas prácticas, frameworks, herramientas y procesos.
Sin embargo, existe una tercera tarea, la cual debe estar por sobre las anteriores en importancia:
La principal función del comité, es la de ayudar a que se produzcan los cambios de Mind-Set necesarios para que la Esencia de la Agilidad entre en el ADN de la organización.
En mi firma personal hay 2 lemas que reflejan estos 4 puntos y el cómo se pueden hacer estos cambios:
“¡Hoy mejor que ayer, mañana mejor que hoy!” Kaizen / 改善
“Culture is history. You cannot change history. To change culture you have build/integrate new stories” Peter Bregman
Saludos.
Rodrigo Burgos Noceti 