En los despachos del C-Suite, las palabras Transformación Digital son, probablemente, de las más repetidas en las conversaciones acerca de la estrategia y el futuro de la compañía.
Vivimos en la era más disruptiva de la Historia de la humanidad desde el punto de vista de la tecnología. No solo por la profundidad e impacto en nuestras vidas de las distintas disrupciones tecnológicas que van apareciendo, sino también por la alta frecuencia y velocidad con la que aparecen.
Los modelos de negocio se están transformando. La tecnología no sólo inventa nuevos modelos, sino que está dando la vuelta literalmente a sectores muy tradicionales… y tan solo está enseñando la patita.
En este escenario, uno de los mayores retos de nuestras compañías es ser capaces de adaptarse al Cambio, en mayúscula. Agile, viene a satisfacer esa necesidad de adaptación.
Entorno complejo
Agile viene del mundo del software.
El concepto nace de la voluntad de 17 personalidades de ese mundillo que, el 17 de febrero de hace 17 años (2001), tienen a bien pasar un fin de semana en una estación de esquí de Salt Lake City (Utah) con la intención de reflexionar acerca de las mejores formas de desarrollar software… y de ahí nace el famoso Agile Manifesto.
Las metodologías predictivas difícilmente funcionan en entornos de incertidumbre como los que solemos encontrar en el software. La famosa matriz de Ralph Stacey plantea dos ejes: acuerdo respecto a los requerimientos en las coordenadas, y el grado de la incertidumbre respecto a la tecnología.
Desgraciadamente, en los proyectos digitales, solemos movernos en un entorno complejo.
Los diagramas de Gantt se han hecho famosos por ser poco menos que un brindis al sol.
Pero Gantt es tan solo un reflejo de la metodología de trabajo que impera todavía en la mayoría de organizaciones a la hora de afrontar un proyecto de software:
El Modelo en Cascada
Y a su vez, esta metodología es tan solo un reflejo del modelo organizativo (estructura formal) que impera en nuestras empresas.
Como se ha discutido largo y tendido, dicho modelo se basa en una herencia directa del modelo conceptualizado por Frederick Taylor en su famoso libro «The Principles of Scientific Management».
El taylorismo, aboga por una jerarquización verticalizada de la toma de decisión.
Esto tuvo mucho sentido en un momento de la historia donde la inmensa mayoría de la población era analfabeta… y en un contexto industrial, donde la capa inferior era la mano de obra, dirigida por un management cualificado.
¿Sigue teniendo vigencia el planteamiento en el contexto en el que hoy nos encontramos, donde la gran mayoría somos trabajadores cognitivos, altamente cualificados? Probablemente, si escalásemos esta pregunta al global de la población activa, la respuesta sería totalmente contraria a la realidad que tozudamente domina la mayoría de contextos laborales.
El «mundo real».
Pero para comprender en profundidad el porqué del modelo en cascada, debemos además tener en cuenta que las organizaciones no solo están fragmentadas en estratos horizontales de middle-management, sino también en los Silos Funcionales a los que tantas hemos hecho ya referencia en este podcast:
Por tanto, ¿cómo llevar a cabo un proyecto digital en una organización fragmentada en silos funcionales?
Pues solo hay una manera: en cascada, donde secuencialmente el proyecto va pasando por todas las áreas, acumulando herencia de decisiones no informadas. Es decir, sin feedback real del cliente final, porque éste no recibe valor hasta que finaliza todo el proceso.
Desgraciadamente, esto provoca una delegación de responsabilidad debida a que el foco deja de ser entrega de valor al cliente final, al usuario, y se centra en acabar el trabajo de mi departamento o área para pasárselo al siguiente departamento.
Y la adaptación al cambio ya tal…
Entonces ¿qué es Agile?
No se puede hablar de Transformación Digital si no somos capaces de adaptar el software que nos va a dar ventaja competitiva en el mercado, de forma constante, iterativa incremental, incorporando feedback, aprendiendo, siendo soporte para eficiencia, pero también para la innovación, para la disrupción.
«Sin tecnología, no hay disrupción. Sin Agile, no hay tecnología capaz de adaptarse a los cambios constantes y cada vez más virulentos y exigentes del mercado.» #EnElMundoReal🎙 #Agile Clic para tuitearNo soy capaz de resumir Agile en un solo episodio, pero sí voy a intentar sintetizar 4 conceptos que considero de gran relevancia:
1. Entrega temprana y frecuente
Todas las metodologías ágiles están enfocadas a la entrega de valor, entendiendo valor como software funcionando. De hecho, como reza el 7º principio: «El software funcionando es la medida principal de progreso».
En siguientes episodios hablaremos de desarrollo iterativo-incremental.
2. Cross-funcionalidad
Romper los silos funcionales es la única opción. Tener un objetivo común: la entrega de software con valor. Y combinar las distintas disciplinas para entregarlo de forma frecuente.
Y colaborar, colaborar, y colaborar. Los responsables de negocio y los desarrolladores trabajan juntos de forma cotidiana durante todo el proyecto. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
«Los silos funcionales son el verdadero cáncer invisible en nuestras organizaciones.» #EnElMundoReal🎙 #Agile Clic para tuitear3. Individuos motivados
En mi opinión, uno de los retos más difíciles de conseguir… y donde pincha la mayoría de organizaciones que intentan ser ágiles.
En el audio hago referencia al libro de Daniel Pink, «La sorprendente verdad sobre qué nos motiva»
Os invito echarle un ojillo a este vídeo resumen:
Dan desarrolla su teoría alrededor de los siguientes tres pilares:
- Maestría → Por qué aprendemos instrumento en tiempo libre? Por qué acudimos a meetups profesionales after-hours? Sencillamente, nos hace felices ser conscientes de nuestro propio desarrollo, llegar a ser buenos en algo. Por eso es tan importante tener una cultura que subraye la excelencia, el aprendizaje, el crecimiento profesional y personal.
- Autonomía → En una organización jerárquica dirigida por push & reporting, no hay espacio para la auto-gestión. Agile propone equipos auto-gestionados.
- Propósito → Más allá de la rentabilidad, más allá del objetivo económico. Necesitamos sentir que lo que hacemos tiene sentido. Y en mi opinión, Customer Experience es clave. En la entrevista a Antonio López de Decathlon, reflexionábamos precisamente acerca de la importancia del propósito.
4. Mejora contínua
Plan, Do, Check, Act: el ciclo de Deming. Donde respectivamente, establecemos una estrategia, la ejecutamos, evaluamos las acciones, y estandarizamos lo que ha funcionado.
Kaizen (改善) es una palabra de origen japonés compuesta por dos vocablos: kai (改) que significa «cambio», y zen (善) que quiere decir «beneficioso».
Si algún día tengo un barco, le pondré de nombre Kaizen.
En el episodio hago referencia a esta charla de José E. Rodríguez Huerta y Bea Martín Valcárcel, en la CAS de Bilbao en 2013:
Actualización 16/05/2018:
Gracias a un simpático hilo arrancado por Teresa Oliver…
Hace años mi trabajo consistía en convencer a la gente para que lo intentara. Hoy me encuentro pidiendo por favor que dejen de hacerlo
— Teresa Oliver (@tolivern) 15 de mayo de 2018
…llegué por casualidad a esta magnífica charla de Allen Holub titulada «The death of Agile».
No dejes de verla!
Lecturas recomendadas por los oyentes
¿Te gustaría recomendar un libro relacionado con el episodio a la comunidad de oyentes del podcast? Déjame un comentario en esta misma página o en cualquier otro canal, y lo añadiré. ¡Gracias por colaborar!
 «The Age of Agile» (recomendado por José Manuel Beas)Jose lo describe así: Creo que todos tratamos de resumir Agile en 3 o 4 puntos que sean fáciles de recordar. Tú lo has hecho muy bien con tus «entrega frecuente y temprana de valor a los clientes», «cross-funcionalidad o multidisciplinariedad», «individuos motivados» y «kaizen o mejora continua». Denning no lo resume muy lejos de ti con sus tres leyes: «Ley del Equipo Pequeño», «Ley del Cliente» y «Ley de la Red». Tranquilos, no haré spoiler. 😉 |
| ¡Déjanos tu propia recomendación en los comentarios de la página! |
¿Qué te ha parecido el episodio de hoy?
Como siempre, mil gracias por escuchar. De verdad, quiero saber qué piensas, qué te ha parecido, así que me encantaría que me dejes tu feedback, tus dudas, bien a través de los comentarios en esta página, o mejor aún a través de un comentario en iTunes, iVoox o la plataforma que utilices, acompañado de unas estrellitas… para mi es súper importante porque es lo que me va a permitir ganar visibilidad para ampliar aún más esta gran conversación que espero mantener con todos vosotros, oyentes.
Un fuerte abrazo y os espero en el mundo real.
Envíame tus preguntas
Envíame tus preguntas en un mensaje de voz y las responderé en el propio podcast!
No te pierdas ni un programa!
Suscríbete en iTunes Suscríbete en iVoox
Únete a la comunidad en Facebook.
Contáctame por Twitter.
Conéctame en LinkedIn
Buenísimo!
Es mi primer potcast y me ha encantado…
Es como si me lo explicaras a mi a solas…
Felicidades!
Xavi Servole
Merci Xavi! 🙂
Desde mi punto de vista, para montar un equipo agile hay un factor muy importante, la confianza. Sin confianza desde capas superiores hacia el equipo no va a funcionar.
Por cierto estaba a punto de enlazar el video de youtube sobre la motivación y me he encontrado con que ya lo habías puesto en las notas, lo vi hace años y es muy recomendable.
Mil gracias Ezequiel.
100% de acuerdo en cuanto a la confianza. Es un tema complejo, porque ni se le puede exigir a un equipo pasar de 0 a 100 en autonomía, ni a un manager lo propio en confianza… Ahora bien, está claro que lo segundo es la base para conseguir lo primero.
Un abrazo!