En el post anterior (lo puedes leer aquí) estuve hablando un poco sobre lo que era la deuda técnica, los tipos de deuda técnica y algunas ideas sobre como gestionarla. En esta ocasión mi querido amigo lector, estaré planteando el costo oculto de la deuda técnica.
Pero ¿que son los costos ocultos? los costos ocultos, son los costos que están ahí afectando el costo del productos o servicio y que no se ven (a simple vista). Algunos ejemplos son materia prima desechada por errores en el proceso o desplazamientos innecesarios de materiales entre el almacén y la planta. A nivel de desarrollo de software, la deuda técnica es un factor de generación de costos ocultos, los cuales se pueden volver exponenciales si la deuda técnica no es identificada, o no se le da el valor que esta tiene y sobre todo, si no se paga con el rigor que requiere cualquier deuda generada. Dentro de los costos ocultos que genera la deuda técnica (seguro tu podrás identificar muchos mas) te quiero plantear los siguientes:
El costo del Valor Negativo
La deuda técnica es un valor negativo. Sí, mi querido amigo lector, lo has leído bien, ‘Valor negativo’. Un valor negativo puede ser en términos de tiempos de inactividad del sistema o una mala interfaz de usuario que afecta la satisfacción del cliente, mal rendimiento del sistema, etc. Estos ejemplos afectan la experiencia del cliente y crean un valor negativo.
Otro gran ejemplo de esto puede ser características no utilizadas en el Producto. Estas características consumen tiempo y dinero para ser desarrolladas, probadas, implementadas y documentadas. Además, los desarrolladores tienen que seguir manteniendo estas características que también reducen su productividad.
El Costo de disminución del ritmode entregas
Con la generación y acumulación de deuda técnica, será cada vez más difícil trabajar en nuevas características. En general, el impacto de la deuda técnica no es lineal, es exponencial. Esto significa que los equipos que generan mas deuda técnica, pasaran más tiempo arreglando el impacto de dicha deuda y a su vez, disminuirán el ritmo entrega de nuevas funcionalidades.
Ahora, si se afectan la cantidad de nuevas funcionalidades que un equipo puede entregar, derivará que haya menos funcionalidades para que las partes interesadas inspeccionen y validen los supuestos de valor.
El Costo en la motivación de los desarrolladores
La deuda técnica acumulada ralentiza el progreso de las distintas entregas de valor, lo cual puede llegar a crear una presión innecesaria por parte de los stakeholders hacia el equipo de desarrollo. Esta presión puede llegar a ser aún mayor, si en la organización se tiene una obsesión con la velocidad de los equipos. Es decir que hay mas énfasis en controlar la cantidad de puntos de historia que hace un equipo sprint tras sprint, que en colocar énfasis en los resultados del equipo. Esto sin duda, puede ser muy frustrante para los equipos ya que incluso, se comienza a cuestionar su productividad, su efectividad y hasta si el conjunto de habilidades que tienen son las idóneas para desarrollar la solución.
Conclusión
La deuda técnica tiene un costo oculto que puede afectar la entrega de valor, el empirismo y también la moral del equipo. Por lo que como toda deuda, cuanto mas rápido se pague, sera mejor.
Y para finalizar un punto que no se puede perder de vista, es que la deuda técnica puede llegar aumentar el costo final de la solución.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
La metáfora de la deuda técnica nace de una frase originalmente acuñada por el desarrollador de software, Ward Cunningham[1], para explicar a los “no técnicos” la necesidad de «refactorizar». Como las metáforas son inherentemente abstractas, la verdadera definición de deuda técnica depende de la interpretación. Por lo que, a lo largo de los años, varias personas han desarrollado sus propias definiciones personales a lo largo de los años. Lo que ha llevado por ejemplo a malas interpretaciones que existen en muchas organizaciones, al confundir la deuda técnica con el Carry-Overs (La deuda técnica no incluye ignorar o retrasar cosas como funcionalidades, que intencionalmente no se construyeron).
Una de las expresiones mas utilizadas para estas es: “La deuda técnica es el coste y los intereses que se deben pagar por hacer mal las cosas”, es decir que provocaran afectaciones a futuro en la solución que se está desarrollando.
La mayoría de los autores coinciden en que la principal causa de la deuda técnica es la presión en fechas y planes. Sin embargo, con el tiempo, el término deuda técnica se ha perfeccionado y ampliado. Por ejemplo. el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon señala que la deuda técnica «conceptualiza la compensación entre el beneficio a corto plazo de la entrega rápida y el valor a largo plazo». Otra perspectiva proviene del analista de la industria, Gartner, que define la deuda técnica como la desviación de una aplicación de cualquier requisito no funcional.
Otro par aportes importantes fueron presentados por Steve McConnell con su taxonomía y Martin Fowler con sus cuatro cuadrantes. La pequeña taxonomía de McConnell, habla de que:
No hay deuda técnica, si… Hay retrasos, recortes, etc., que no requieren el pago de intereses. No todo el trabajo incompleto es deuda.
Si hay deuda técnica… puede ser (I) Deuda incurrida involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrida intencionalmente.
Dándole una vuelta más al término, la figura de abajo muestra cuatro tipos de posibles mejoras o tareas a realizar en el futuro para aumentar el valor del producto software, como pueden ser ampliar funcionalidades (que es en lo que suelen fijarse las empresas), o invertir en arquitectura, invertir reducir los defectos o la deuda técnica, que es invisible y tiene un efecto negativo.
Existen 3 tipos de deuda técnica que son:
Deuda técnica planificada: este tipo de deuda técnica ocurre cuando la organización toma una decisión informada de generar alguna deuda técnica con el pleno conocimiento de las consecuencias (riesgos y costos). En el caso de la deuda técnica planificada, es fundamental ser lo más preciso posible en términos de definir los compromisos que la organización pretende hacer. Un ejemplo podría ser: “Para cumplir con la nueva fecha límite de lanzamiento de noviembre, hemos decidido renunciar a las pruebas de la unidad de escritura en las últimas tres semanas del proyecto. Escribiremos estas pruebas después del lanzamiento «.
Debido a que estas decisiones pueden acumularse rápidamente con el tiempo, es imperativo mantener un registro de ellas. Al hacerlo, aumentará la probabilidad de que la deuda técnica se aborde y se pague más rápido. De lo contrario, se olvidará rápidamente, lo que podría costarle mucho tiempo a la organización a largo plazo.
Deuda técnica no intencional: se refiere a la deuda técnica no planificada que surge debido a malas prácticas. Por ejemplo, un enfoque de diseño que termina conteniendo muchos errores. Este tipo de deuda técnica a veces ocurre como resultado directo de una comunicación deficiente dentro de la organización o cuando los objetivos de Desarrollo y Operaciones están desalineados.
Deuda técnica inevitable: esto ocurre debido a cambios en el negocio y al progreso de la tecnología a lo largo del tiempo que presentan mejores soluciones. Por lo general, surge cuando se solicitan cambios en el alcance a mitad del proyecto, lo que resulta en un costo inmediato, como agregar una nueva característica a un diseño existente para respaldar mejor la entrega móvil. En resumen, la deuda técnica se crea cuando los nuevos requisitos comerciales hacen obsoleto el antiguo código.
Siempre evitar acumular deuda técnica
Si bien la deuda financiera es fácil de rastrear, la deuda técnica no es inherentemente una métrica. Con algunos ajustes, la teoría de la deuda técnica se puede traducir a ciertas métricas, como el tiempo de comercialización frente al tiempo que trabaja horas extras para pagar intereses. También puede aparecer como una menor productividad de un equipo, que también es difícil de medir.
Los expertos recomiendan hacer un seguimiento de su deuda técnica para evitar que sea demasiado difícil de manejar. Como las deudas pueden sobrevivir a múltiples ciclos de desarrollo, su seguimiento es esencial. Así es cómo:
Comience una lista de deudas técnicas. (Esto incluye todas las instancias donde los desarrolladores saben que el código no es tan limpio como debería o debe ser para el desarrollo futuro).
Listar y agrupar tareas diferidas en unidades viables.
Tenga en cuenta las consecuencias de ignorar cada unidad.
Mantenga la lista visible.
Informe a los equipos que confían en los lanzamientos de entrega, como marketing, ventas, etc., que está trabajando en deudas técnicas, para que cada nuevo lanzamiento no pueda incluir solo nuevas características.
Programe un horario regular y frecuente para pagar la deuda técnica.
Algunas ideas de como Gestionar la Deuda Técnica
Evaluación:
Al identificar la deuda técnica, es posible que haya encontrado algunas señales clave. Por ejemplo, las clasificaciones de rendimiento de su producto podrían estar disminuyendo o sus desarrolladores pueden tardar mucho más en iterar. ¿Pero cómo mides esto? ¿Cuál es el verdadero costo de la deuda técnica?
Una forma de llegar a esta medida es observar la cantidad de días que los desarrolladores necesitarían dedicar a reducir la deuda técnica realizando actividades como refactorizar o reemplazar la aplicación. Esto proporcionará un excelente análisis de costo / beneficio. Además de proporcionar una actualización del estado actual, también es importante generar estimaciones de cómo espera que la deuda técnica cambie con el tiempo.
Comunicación
Uno de los pasos más importantes a tomar en la gestión de la deuda técnica es reconocer que existe en primer lugar y compartir ese descubrimiento con las partes interesadas clave. Por lo tanto debería buscar identificarse siempre el verdadero costo de la deuda técnica, hacerlo visible, comunicarlo a todos. y explicar la importancia de pagar la deuda técnica más temprano que tarde.
Implementación
Hay tres opciones a considerar en términos de gestión de la deuda técnica.
Renunciar al requisito por completo. En otras palabras, la organización decide vivir con el sistema tal como es y ya no considera que el requisito sea necesario. Si no puede renunciar al requisito, deberá refactorizar o reemplazar la aplicación.
Refactorizar la aplicación. Esta opción tiene como objetivo reducir la complejidad, eliminar duplicados y mejorar la estructura del código. La refactorización es la única forma de mejorar la estructura interna de un código sin cambiar el comportamiento del programa.
Reemplazar la aplicación. Si bien esto introducirá una nueva deuda técnica, la idea es abordarla rápidamente y minimizarla lo más posible.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Dada la declaración de emergencia de salud pública de importancia internacional, declarada por la organización mundial de la salud, por el brote que se viene presentando a nivel mundial del coronavirus, quise realizar este post, para recordar algunos de los enemigos de la adaptabilidad organizacional, que al igual que los virus, afectan el sistema organizacional como un todo, en pro de no permitir que la organización alcance los objetivos trazados y/o obtener el nivel de adaptación al ritmo requerido según las exigencias del mercado.
Quisiera empezar este post entonces, con la siguiente frase de Charles Darwin: “No es la más fuerte de las especies la que sobrevive, tampoco es la más inteligente la que sobrevive. Por el contrario, es aquella que se adapta mejor al cambio”. Y empiezo con esta frase, por una razón mi querido amigo lector. La cual, es el hecho por el cual, actualmente se habla mucho de agilidad a nivel organizacional, dada la necesidad que existe en las organizaciones de mejorar su capacidad de responder a un entorno que cambia rápidamente. Motivo por el cual se crea en las organizaciones una especie de necesidad de supervivencia, que lleva a las organizaciones a buscar cada vez más, nuevas formas de hacerlo.
Teniendo presente esto, vemos que en las organizaciones tienen una fuerte motivación para hacer de la adaptabilidad uno de sus objetivos más importantes. Sin embargo, el desafío que presentan, es precisamente, el convertirse (o permanecer) en una organización adaptablemente exitosa. Sin duda todo un desafío que requiere un ambiente fértil dentro de la organización (su cultura) para hacerlo realidad.
Mi querido amigo,en este post quiero tocar esos enemigos de esa adaptabilidad interna. Los cuales, al igual que los virus, debe ser y encontrar la manera de neutralizarlos y así allanar la forma de alcanzar la adaptabilidad externa como organización. Veamos entonces cuales he identificado:
«En una organización de ‘comando y control’, surge el miedo entre los empleados. Esto lleva a los empleados a dudar de tomar la iniciativa o la responsabilidad ellos mismos y mata la confianza dentro de la organización.»
Los dictadores usan tácticas de miedo para motivar a las personas y así mantener a las personas divididas. Y cuando las personas se dividen, buscan «orientación» y apoyo. Desde ese punto de vista, es comprensible que equilibrar una cantidad «saludable» de miedo y dependencia en una organización siga siendo un modelo de gestión popular. Ahora bien, en tiempos de incertidumbre y confusión, las personas recurren a los métodos «conocidos» y «probados». Ahora, si miramos como es un proceso de habilitación agile en una organización, notaremos que este puede ser uno de los períodos más inciertos y confusos que pueden vivir las personas y más si el cambio no es bien gestionado.
Imagínate (por ejemplo) lo que puede pensar y sentir un jefe, cuando le decimos que «Comenzaremos a trabajar con equipos autoorganizados. Que tomaremos decisiones de forma autogestionada y lo más cerca posible del cliente. Que, además, vamos a buscar eliminar los silos y a los intermediarios que no aportan valor al producto final.»
Éste (en una acción natural de autoconservación), se pude convertir en alguien que buscará frenar el cambio. Liderando así, con la táctica del miedo y matando cualquier posibilidad de innovación, generando como consecuencia un ejército de ‘sí-hombres’.
¿Ahora cómo podemos eliminar este virus de la organización?, estos 4 tips te darán una luz.
Crear lazos de confianza en roles y no en cargos.
Crear transparencia. Es decir, invertir en transparencia mutua, ser abiertos sobre los desafíos que se avecinan y fomentar el trabajo colaborativo para buscar constantemente mejorar las cosas.
Limitar las reglas en los procesos. Es importante eliminar las reglas en los procesos que no agregan valor, para permitir que se genere el nivel deseado de confianza como cultura.
Gestionar el sistema, no a las personas.
«Las estrategias de pensamiento defensivo, las ideas obsoletas y la satisfacción crean un sesgo a favor del status quo.»
Sobre este tema, hay una teoría interesante sobre la aversión a la pérdida. Esta noción proviene del campo de la psicología. Y en resumen, establece que las personas tienen el doble de motivación para evitar pérdidas, que para obtener el mismo beneficio.
Vemos lo mismo en los procesos de habilitación agile donde, por ejemplo, en lugar de tomar la decisión de embarcarse en una aventura, en la cual iremos experimentando y descubriendo que es lo que mejor se ajusta al contexto de la organización, presentamos un marco de trabajo puntual. En este tipo de situaciones, siempre habrá personas que prefieren quedarse haciendo las cosas como siempre lo han hecho. Estas personas a menudo actúan como si cooperaran, pero mientras tanto intentan frustrar el proceso de cambio tanto como pueden.
¿Ahora cómo podemos eliminar este virus de la organización?, estos 3 tips te darán una luz.
Tener una visión clara. Hacer que la estrategia y objetivos de la organización, sean claros para todos será clave. Mostrar a todos cómo pueden alinear su trabajo con la estrategia de cambio, permitirá que existan colaboradores involucrados y empoderados.
No centrarse solo en la planificación sino también en la implementación. La idea es dedicar más tiempo en la traducción de los planes, en acciones específicas. Además de un plan, asegurarse de invertir también en personas que puedan guiar a su organización en ese proceso, será clave. Tener un enfoque gradual que deje en claro dónde están las prioridades y descubrir paso a paso, cómo implementarlas.
Dedicarles tiempo a las personas. La idea es explicar a los colaboradores lo que se espera de ellos, dedicar tiempo y atención al esfuerzo que lleva a las personas aceptar el cambio será clave. Escuchar atentamente sus objeciones y hacer algo concreto con ellas permitirá que se empoderen de lo que sucede en la organización.
«Las cadenas de hábitos son demasiado ligeras para sentirse hasta que son demasiado pesadas para romperse.» – Warren Buffet –
El sesgo de decisión se centra más en el comportamiento para evitar tomar decisiones y mantener el status quo, debido al efecto de la aversión a la pérdida. En este punto mi querido amigo lector, miremos más de cerca el peligro de la rutina. Es claro que, la tendencia a seguir la rutina es enorme, “si nos funcionó ayer, para que cambiarlo, ya que nos sentimos cómodos para seguir haciéndolo”. Expresan mucho en las organizaciones. Algo que debemos tener presente es, que el dolor de la rutina debería ser peor que el dolor del cambio, para que una habilitación agile sea inevitable.
Ahora, como las organizaciones están formadas por personas (entre otras cosas), serán las personas las que tienen que hacer los ajustes. Por lo tanto, son las mismas personas de la organización, las que realmente tienen que querer romper con los «hábitos» para hacer posible la adaptabilidad.
¿Ahora cómo podemos eliminar este virus de la organización?, estos 2 tips te darán una luz.
Involucrar al equipo. la idea es que los colaboradores participen en la toma de decisiones y en la definición de las actividades de mejora apropiadas para sus niveles en la organización. (herramientas como los Okr, son de gran ayuda para ese punto)
Crear embajadores. Esto no solo les ayudará a mejorar más pronto, sino que también ayudará a convencer otros, a que se involucren y empoderen del proceso de cambio.
«Si la responsabilidad de tomar decisiones se concentra en un nivel superior centralizado, solo se necesitan unas pocas personas para eliminar cualquier cambio y transformación.»
Dada la necesidad de respuesta al cambio, de adaptación y de flexibilización, cada vez más rápida en las organizaciones, se requiere por parte de estas una especie de “emprendimiento en los niveles inferiores”, como lo han denominado algunos líderes de pensamiento en negocios, liderazgo y cambio. Sin duda, esto hace que la descentralización sea un paso lógico que deben dar las organizaciones. Sin embargo, para muchas de ellas (especialmente grandes), es difícil poner esto en práctica. La necesidad de hacer este cambio, se expresa verbalmente y hasta en presentaciones, pero en la práctica los colaboradores sienten que nada cambia.
En las organizaciones centralizadas, la organización de un proceso de habilitación ágil, a menudo se integra en un equipo de proyecto con nombres imaginativos como «Proyecto Phoenix», «XX más Ágil» o un nombre más genérico como «La nueva forma de trabajar». Sin embargo, los miembros de estos equipos centralizados, a menudo son elegidos de las capas de gerentes intermedios, asistidos por empleados para procesar y compartir los resultados de las reuniones. Pero rara vez están conformados por verdaderos agentes de cambio. Este tipo de equipos de proyectos centralizados a menudo se comportan, como el sol en el universo organizacional, con respecto a todas las demás áreas de la organización y cambian las iniciativas que lo rodean como planetas, dependiendo de la gravedad del equipo central para hacer las cosas.
Si todas las decisiones con respecto a la habilitación agile en una organización, son tomadas por un organismo central, se creara mas resistencia al cambio. Por el contrario, si en la toma de decisiones son consultadas y apoyadas en las necesidades de cada contexto dentro de la organización, se generaran equipos más empoderados y exitosos en los diferentes niveles.
¿Ahora cómo podemos eliminar este virus de la organización?, estos 3 tips te darán una luz.
Realizar experimentos y mostrar los resultados. Es decir, agentes de cambio capaces de mostrar resultados medibles para ganar más confianza y tracción.
Buscar una iniciativa de mejora clara, sólida y definida en la que pueda lograr conjuntamente mejoras medibles.
Definir claramente el alcance y establecer acuerdos claros sobre los resultados esperados.
Ser transparente sobre los éxitos y fracasos, mostrando lo que ha ajustado y por qué, sobre la base de datos.
«Los sistemas empresariales altamente optimizados son excelentes para la eficiencia, pero mortales para la adaptabilidad. Como resultado, los activos, habilidades y procesos comerciales se vuelven más especializados y el cambio solo puede tener lugar a pequeña escala.»
Al estar históricamente tan arraigado en nuestra vida y organizaciones, la creencia en la existencia de la eficiencia. Hace que en las organizaciones, se materialice la idea de hacer constantemente el trabajo de una forma cada vez más eficiente. Eliminar el desperdicio por lo tanto parecería un objetivo razonable.
Ahora bien, un enfoque excesivo en la eficiencia puede producir efectos negativos hacia la adaptabilidad. Cuando la eficiencia mejora, se tiende a crear un mayor grado de especialización en el camino. Esto crea varias islas aisladas en un gran océano corporativo conocidas como silos. Debido a su enfoque interno, dichos silos pierden flexibilidad y con el tiempo, desarrollan un lenguaje propio que alguien de otro silo no comprende. ¿la consecuencia? Cuando tienen que trabajar juntos, se necesita un ejército de traductores para traducir toda la comunicación mutua y unos coach para guiar la comprensión mutua.
El enfoque en la eficiencia y la especialización que fue tan valioso y exitoso en la época de la revolución industrial se está volviendo obsoleto. Hoy en día, las organizaciones más exitosas son aquellas que tienen comunicación y colaboración en su ADN. Los que todavía se están enfocando en aumentar la eficiencia, la especialización y con esa inflexibilidad, tienen cada vez más problemas para sobrevivir.
¿Ahora cómo podemos eliminar este virus de la organización?, este Tip te dará una luz.
Pasar de la eficiencia a la efectividad. La eficiencia se trata de hacer más cosas en un determinado período de tiempo o de hacer menos trabajo para hacer lo mismo. La eficacia es sobre conseguir las correctas cosas. En otras palabras, progresar no se trata solo de ser productivo. Se trata de ser productivo en las cosas correctas. Los equipos agiles en su conjunto, con sus puntos de vista individual, contribuyen a que se hagan las cosas correctas y con eso el cambio de eficiencia a efectividad.
«Los límites departamentales rígidos, los silos funcionales y los reinos políticos aseguran que la organización no pueda adaptarse rápidamente a los cambios que afectan los activos y habilidades existentes.»
Si bien es cierto, que hoy en día las luchas al interior de las organizaciones no son tan sangrientas como lo fueron en la época romana. Si es cierto que existe en muchas organizaciones rivalidad entre las diferentes áreas, en donde a cada una le interesan sus propios objetivos, por encima de los objetivos organizacionales.
Estos silos a menudo consisten en un grupo de personas que tienen todos los mismos tipos de conocimiento. Y como siempre ha funcionado así y ha tenido éxito, ahora también debería ofrecer los resultados esperados (pensamiento de muchas organizaciones y/o líderes de estas). Una de las cualidades de los silos es que son por lo general cerrados, es decir especializados. Lo que les crea una incapacidad para adaptarse a las circunstancias actuales, lo cual podría ser un amenaza para que se conviertan en las modernas falanges macedonias.
En la historia, existieron los contubernium (era la unidad mínima del ejército romano, formada por ocho soldados de infantería). Los contubernium Marcharon, lucharon, trabajaron y acamparon juntos. En el campo pudieron auto-organizarse. Y dado que estaban compuestos de personas que tenían que administrar sus intereses y los del imperio, (en opinión de un colega, fue el primer equipo scrum). Aunque no todos los equipos fueron igualmente buenos en cada tarea debido a las diferentes habilidades que tenían los participantes, sí formaron una organización bastante adaptativa que se unió bajo la misma dirección y visión al mismo objetivo. ¡Sobrevivir y ganar!
¿Ahora cómo podemos eliminar este virus de la organización?, este Tip te dará una luz.
Fomentar la auto-organizacion y la auto-gestion, sera la clave.
«Déficit de habilidades: cuando las personas no tienen las habilidades, la capacitación y el entrenamiento son actividades clave, para hacer la transición exitosa de ser ágil a ser ágil .»
En este punto, siempre he notado que se cree en el interior de las organizaciones, que el problema es la falta de conocimiento de sus colaboradores. Por lo que se cree, que el problema no está tanto en la explicación y los ejemplos, sino en el grado en que ellos lleguen a dominar las diferentes técnicas y/o herramientas. Sin embargo, en muchos casos el problema ha radicado en la falta de conocimiento o habilidades de los consultores que son contratados para liderar los procesos de cambio. lo cual termina impactando en mayor medida el resultado esperado.
Ahora bien, para que los colaboradores dominen las diferentes técnicas y herramientas. Primero deben aprender de profesionales experimentados sobre cómo implementarlos. Luego se busca que aprendan en la práctica haciéndolo juntos varias veces y solo cuando se sientan lo suficientemente seguros como para hacerlo solos, estarán listos para avanzar. Aquí será clave la transparencia y la profesionalidad de estos profesionales (los consultores), dado que su objetivo principal, no debe ser permanecer en el tiempo, sino por el contrario, debería ser ayudar a que su cliente alcance sus objetivos, pero sin crear dependencias de ellos para avanzar. Estos (los profesionales experimentados), a su vez deberán gestionar el cambio que esto implica.
¿Ahora cómo podemos eliminar este virus de la organización?, estos Tips te dará una luz.
Gestionar el conocimiento de los colaboradores.
Seleccionar consultores, con experiencia real, casos de éxitos comprobados y sobre todo con un plan claro que muestre por un lado los objetivos a alcanzar y su respectiva fecha esperada de salida.
«El transbordador espacial a menudo se usaba como un ejemplo de por qué no se debería intentar hacer algo reutilizable. Pero un experimento fallido no invalida el objetivo mayor. Si ese fuera el caso, nunca hubiéramos tenido la bombilla.» – Elon Musk sobre el cohete reutilizable Space-X.
Mi querido amigo lector, Si has leído el libro Elon Musk, estarás de acuerdo conmigo, en que él (Elon Musk) ha puesto la experimentación en el corazón de su organización. Desde el comienzo del proceso de desarrollo, Tesla y Space X prueban continuamente diferentes ángulos para lograr los mejores resultados. En este sentido, el ‘truco’ (por así decirlo), es comenzar con experimentos pequeños y construir a partir de ellos. Es lógico que dentro de las grandes empresas establecidas se cree un entorno controlable, en el que a veces es difícil ir más allá de lo habitual, sobre todo por el nivel de jerarquía que estas presentan. Sin embargo, el contar en estos mismos ambientes con las redes que propone la agilidad, hace que existan espacios controlados en los que se puede experimentar y así obtener grandes resultados.
Sin embargo, para poder experimentar, se necesita espacio y confianza para poder «fallar». Esto requiere la mentalidad ágil mencionada anteriormente dentro de la organización. El fracaso es esencial e ineludible durante este proceso incremental e iterativo. Ahora, este fracaso debe ser consciente.
Ahora, si miramos el Framework Scrum (por ejemplo) ofrece una gran estructura para organizar la experimentación dentro de las organizaciones de una manera segura y valiosa. Si vemos la guía de scrum, por ejemplo, esta nos dice que: “Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de retroalimentación. Las entregas incrementales del producto «Terminado» aseguran que siempre esté disponible una versión potencialmente útil del producto en funcionamiento”. Las palabras claves que allí se encuentran son: incremental, iterativo y retroalimentación. Claves para obtener la mayor información posible sobre el camino que estamos recorriendo.
Esto en un contexto de adaptabilidad organizacional es clave; ya que permite a la organización a través de sus equipos, identificar si va por el camino correcto, con respecto a un producto, un proyecto o los objetivos trazados.
«Las organizaciones sin un propósito compartido convincente y un objetivo claro compartido tienen problemas para alinearse en un camino natural hacia la adaptación.»
Para tocar este punto mi querido amigo lector quiero tomar como referencia a Simon Sinek (y su teoría del círculo de oro) que dice:
“Los líderes inspiradores piensan, hacen y se comunican de adentro hacia afuera. De esta manera, inspiran a otros a hacer algo por sí mismos en lugar de manipularlo.” Sinek muestra esto en el Círculo Dorado:
QUÉ: casi todas las organizaciones saben QUÉ hacen, qué productos y servicios proporcionan y también lo comunican. Indican claramente «esto es lo que hacemos». Es la propuesta: qué productos entregamos a quién.
CÓMO: Algunas organizaciones y líderes saben CÓMO lo hacen. Cuáles son sus valores fundamentales y sus competencias básicas. Cuál es su valor agregado, su punto de venta único.
POR QUÉ: Pocas personas u organizaciones pueden indicar POR QUÉ hacen LO QUE hacen. Cuál es su GRAN POR QUÉ en realidad es.
Y luego no se trata de obtener ganancias o ganar dinero. Eso es un resultado. El por qué, se trata de la meta, la razón, su creencia y su valor agregado. Tu propósito, tu derecho a existir.
Tomo esto como base, para indicarte mi querido amigo, que sin un propósito claro del porque se hacen las cosas a nivel organizacional, cuesta mucho, no solo propiciar un cambio, sino también adaptarse a un entorno o contexto nuevo para la organización. Sin una brújula que indique hacia donde se va como organización, resultará más complicado identificar lo que hay que cambiar y el camino que hay que transitar.
¿Ahora cómo podemos eliminar este virus de la organización?, Estos 2 Tips te dará una luz.
1. Asegurándose de que el propósito de la organización esté totalmente traducido internamente. No solo necesitamos tener un atractivo «Por qué» hacia los clientes para que quieran pertenecer a nosotros. También internamente este «Por qué» debería proporcionar claridad y dirección en el trabajo que hacemos.
2. Durante una planificación de cada Sprint/ciclo de trabajo, asegurarse de tener un objetivo fuerte. Definir un objetivo de sprint/ciclo de trabajo claro, ayuda enormemente a enfocarse más y a organizarse mejor en el equipo. Los objetivos de Sprint/ciclo de trabajo son una especie de mini traducciones del propósito de la organización para el corto / mediano plazo.
«Con el auge de la agilidad, la dualidad se viene haciendo presente cada vez más en las organizaciones. comprender en que consiste y la forma en que debe de ser gestionada, será clave para adaptarse.»
Quise dejar este punto para el final con un solo propósito, que analizáramos por unos segundos este fenómeno que se viene presentando en las organizaciones. Actualmente con el auge de la agilidad a nivel organizacional, muchos colegas fomentan como punto de solución a los problemas de agilidad, la eliminación de las jerarquías en las organizaciones, lo cual esta demostrado que no solucionará los problemas de estas, dado que en las organizaciones exitosas o que son consideradas realmente adaptables (para no decirles agiles), son aquellas que han encontrado la forma de gestión idónea basada en la sana convivencia de estos dos mundos que unidos forman el sistema organizacional.
Por un lado, las redes imprimen dinamismo, creatividad, innovación, colaboración, flujos de valor etc. Por el otro la jerarquía proporciona planificación (visión, propósito), presupuestación, organización etc. El gran dilema se presenta en la identificación de los puntos de unión de ambas partes, así como los lazos que deben ser creados para que los dos ecosistemas no solo convivan, sino que se complementen en un solo propósito que es permitir que la organización se adapte con mayor facilidad a los diferentes contextos en los que se va a enfrentar a lo largo del tiempo.
La clave entonces se encuentra en que ambas estructuras deben encontrase “conectadas”, para así hacer posible el aprendizaje organizativo y que la información fluya entre ambos sistemas (de manera natural) “derribando” los límites entre áreas y niveles jerárquicos. Es decir que el objetivo final es la consecución de una empresa eficiente, pero con su visión puesta en el largo plazo.
Sin duda mi querido amigo todo un desafío, el eliminar estos virus que afectan la adaptabilidad organizacional. Sin embargo poder identificarlos, así como los factores que hacen que emerjan, pero sobre todo tener clara la estrategia de gestión del cambio, será la clave para erradicarlos de las organizaciones.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
DoD (Definition of Done), una responsabilidad que no es solo del equipo de Desarrollo
Hace unos días estuve con mi familia observando la carrera de la Formula E (toda una experiencia recomendada, por cierto) y, en el lugar en el que estábamos, nos encontramos con un amigo desarrollador que trabaja en una importante organización del sector bancario en este hermoso país en el que me encuentro actualmente. Después de varias conversaciones sobre la carrera automovilística que estábamos presenciando, se me dio por preguntarle como iban las cosas en su lugar de trabajo y si se había repetido una situación como la que vivieron en dicha organización meses atrás, y de la que habíamos conversado en otro espacio.
Para ponerte un poco en contexto mi querido amigo lector, en aquella ocasión, nuestra conversación fue por un problema que se había presentado luego de un paso a producción que realizo el equipo en el que mi amigo se encontraba (ya fue reasignando a otro equipo). En ese entonces (según me comentó), no solo el equipo en el que él estaba, sino toda la organización, estaba en pánico. Dado que tres días antes, el equipo implementó una nueva funcionalidad en la aplicación de dicha organización, la cual apuntaba a fortalecer un servicio critico que presta la organización. Los primeros días (según el análisis de seguimiento sobre la funcionalidad) mostraban que al parecer la nueva funcionalidad fue bien recibida. Incluso mejor de lo esperado (según me comentaba).
Sin embargo, al tercer día surgió la noticia de que la aplicación tenía una violación de seguridad, la cual fue detectada en la nueva funcionalidad implementada. Datos personales e información de los producto de los clientes estaban expuestos a cualquier persona. Sin duda una mala noticia para el producto, pero también malo para la organización (si se hacía pública), la cual podía recibir una fuerte multa por este tipo de violaciones de datos y sin mencionar, el daño a la reputación que sufriría la organización.
Según me comentaba mi amigo, al detectar esto (como es normal) se realizó una reunión de crisis, con el equipo completo, junto con el Director de Tecnología, el Product Manager, un representante de seguridad y otras personas (me indicó que nunca había visto), presenciaron dicha reunión, en la cual el Director de Tecnología preguntó:
«¿Cómo puede ser que no hayamos previsto esta violación de datos?»
Un compañero de mi amigo, integrante del equipo de Desarrollo dijo: «No sabíamos que debíamos tener esto en cuenta».
Sorprendido, el Director de Tecnología respondió: “Somos una institución financiera. Tener presente este tipo de cosas, debe estar en nuestro ADN”
Entonces el Scrum Master manifestó: Tenemos un definición of Done (DoD) que indica que “Un producto solo debe ser liberado cuando se cumple el DoD” y somos muy estrictos en esto. Sin embargo, sobre lo que esta presentando el problema, no tenemos nada en él.
A lo que una persona del área de seguridad dijo: «¿Cómo es posible que esto (lo que se debió controlar), no esté en Definition of Done (DoD)? Estas reglas de protección de datos son vitales «.
En ese momento de la conversación con mi amigo, le manifesté la siguiente pregunta: ¿Quién o quienes definieron el contenido del Definition of Done?, a lo que me indico que el equipo de desarrollo y el PO. Acto seguido le indique que quizás el problema, tenga que ver con el hecho de que el Definition of Done (DoD), es creado solo por el equipo de Desarrollo incluso con la ayuda del PO. Lo cual en su momento no me entendió, pero luego de manifestarle mis argumentos al respecto (los cuales te expongo mi querido amigo lector en este post), llegamos a un buen acuerdo.
Este mi querido amigo lector, no es el único caso que conozco. Ya que, en los últimos años, he podido conocer casos similares, en donde por una incorrecta definición del Definition of Done, organizaciones completas han tenido problemas similares. Por lo cual, te planteo entonces mi punto de vista.
El Definición of Done (DoD), NO es una responsabilidad única del equipo de desarrollo y del PO. De hecho, si revisamos por ejemplo la guía de Scrum, vemos que hay un fragmento vital, que a menudo es pasado por alto por coaches, scrum master y hasta desarrolladores, el cual dice:
“Si la definición de “Terminado/hecho” (DoD) para un incremento es parte de las convenciones, estándares o guías de la organización, al menos todos los Equipos Scrum deben seguirla. Si “Terminado/hecho” (DoD) para un incremento no es una convención de la organización, el Equipo de Desarrollo del Equipo Scrum debe definir una definición de “Terminado/hecho” apropiada para el producto.”
Los equipos de desarrollo pueden ampliar la definición de «Terminado/hecho» (DoD), agregando elementos adicionales en la parte superior de la convención. Pero comienza con la convención de organización, según lo indica la guía:
«El Equipo Scrum planifica formas de aumentar la calidad del producto mejorando los procesos de trabajo o adaptando la definición de «Terminado/hecho» (DoD), si corresponde y no está en conflicto con los estándares del producto u organización».
Es decir, mi querido amigo lector, que el Definition of Done, debe ser algo organizacional en el que participen los diferentes actores que hacen parte (ya sea de forma directa o indirecta) de los proyectos que lleva la organización, para así tener una visión mas global.
Algo que veo muy a menudo, es que los equipos de desarrollo crean su propio Definition of Done (DoD) y lo ajustan incluso a sus propios intereses o a su silo. Es decir, algunos ni siquiera consideran en el Definition of Done a los QA y peor aún, rara vez hay una alineación entre los diferentes equipos que puede llegar a tener un proyecto más grande, un Art (Agile release Train – Concepto de SAFe, una tribu, o un Squad. Algo que sin duda puede llegar a ser considerado un anti-patrón.
Es importante que la organización avance, ayudando a los equipos con un Definition of Done sólido y global. Este DoD puede incluir todo tipo de reglas y regulaciones de la organización, como los problemas de cumplimiento mencionados en la historia de lo que le paso a mi amigo.
Estoy seguro de que alguien podría decir, “Pero en agile buscamos formar equipos autoorganizados». Lo cual es verdad. Sin embargo, hay una limitación a lo que un equipo puede decidir hacer. No pueden ignorar las convenciones, reglas o restricciones organizacionales o incluso de negocio. Y estas deben incorporarse en el Definition of Done de los equipos. Por lo tanto, un equipo de desarrollo no puede dejar de lado estas cosas solo por el hecho de considerarse «autoorganizado».
Por lo tanto, mi querido amigo lector, mi invitación es que, como organización, se definan Definition of Done adecuados, globales y que sirvan de base para que los equipos de desarrollo los complementen según su contexto. Dado que, un Definition of Done (DoD) incompleto o una desalineación en los DoD de los Equipos Scrum, puede resultar en grandes problemas para la organización y/o sus clientes. Ahora bien, incluso en el día a día, es importante que todos comprendan lo mismo, cuando un incremento de producto está «Listo/terminado/hecho». Esta transparencia es vital para un entorno Complejo.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Referencias:
Scrum Guide 2019
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Hace poco tuve la oportunidad de participar como consultor en un espacio en donde su buscaba definir la mejor forma (desde el punto de vista “metodológico” -Palabras del cliente), para abordar un proyecto cuya complejidad era evidente y que además contará con ciertas particularidades propias del negocio, que hacen que fuese indispensable determinar la mejor forma de abordar el proyecto.
Como siempre, cae a este tipo de espacio la pregunta: ¿lo abordamos con agile o con waterfall? (en un futuro post abordaré esta pregunta), sin duda mi querido amigo lector ya entenderás el porqué de la invitación que me realizaron a participar de dicho espacio.
Luego de determinar que efectivamente seria bajo agile que seria abordado el proyecto, llega a la mesa una nueva pregunta con la que me he topado en diferentes espacios con diferentes tipos de perfiles organizacionales y es ¿Cuál es el tamaño correcto o idóneo del Sprint para obtener mejores resultados?, de la respuesta que di a esa consulta nació este post, por lo que comparto un poco contigo mi querido amigo lector lo respondido.
Para empezar mi respuesta tome como referencia uno de los principios del manifiesto ágil que dice: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”. Esto está completamente en línea con el Mindset agile y particularmente con Scrum (En el proyecto en mención, cabe mencionar que existirán varios equipos y que no todos trabajaran bajo scrum). Después de todo, El Mindset agile y el framework Scrum, nos invita a trabajar bajo iteraciones que demoran entre una semana y un mes. Y la idea es que al final de cada iteración, se entregue un incremento de producto “Terminado”.
Para muchos, estas iteraciones no son lo suficientemente cortas. Modern Agile, por ejemplo, dice que un par de semanas no es suficiente. Manifiesta que se debe «entregar valor continuamente». Entonces vino sobre la mesa la siguiente pregunta: ¿Cómo encaja esto, con el objetivo del proyecto y la forma de trabajo con la que lo abordaremos?
Para continuar mi argumentación y así llegar a la respuesta deseada, pase entonces a explicar porque utilizamos marcos de trabajo agiles, para resolver problemas adaptativos complejos, explicaba como por ejemplo Scrum es » Un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente» (tome como base la definición oficial de la guía de scrum).
Hice énfasis, en dos palabras claves que son: Complejo y adaptativo. Dado que, en un entorno complejo (como el que se debe abordar en este tipo de proyectos), debe poder adaptarse a nuevas ideas. Y lo mejor es poder adaptarse tan pronto como sea posible. A veces, el feedback, se puede dar en pequeños complementos para el producto. Esto permitirá tener ciclos cortos de retroalimentación o feedback, por parte del cliente. Por lo que, particularmente en Scrum esto resultaría en tener Sprints cortos.
Ahora, también plantee que veo un riesgo en este enfoque. Al centrarse en la entrega de pequeños incrementos, existe la posibilidad de que no se considere la imagen general. Es decir que los equipos (participantes del proyecto), terminanen cayendo en el problema de convertirse en una fábrica de características (centrarse en una entrega rápida en lugar de un resultado valioso – Este problema ya lo toue antes en un anterior post).
Les explicaba que, los ciclos de retroalimentación cortos requieren dedicación y enfoque, extrayendo lecciones del incremento y adaptándose cada vez. Por lo que los invite a Imaginarse el hecho de tener que hacer esto todos los días. Es un trabajo duro respondieron.
Continúe manifestándoles que también hay entornos de productos en los que se necesita más tiempo para entenderlo y comprenderlo lo suficiente como para tomar decisiones informadas. Por lo tanto, en este tipo de entornos no se logra el éxito, dividiendo los elementos en pedazos más pequeños, porque no habrá nada significativo para cortar en algún momento. Contrariamente a la creencia popular, no hay nada de malo en tener grandes porciones de trabajo. Siempre que los elementos sean lo más simples posible (aquí les hice referencia a otro principio del manifiesto ágil, “el arte de maximizar el trabajo no realizado”. Por lo que conclui esta primera parte con una frase popular que dice: «En entornos complejos, lo que sucederá es desconocido».
Les indique además que, hay otra perspectiva a considerar y es que de tener Sprints más cortos significaría más revisiones de Sprint, lo que significa a su vez, más oportunidades para inspeccionar y adaptarse junto con las partes interesadas.
Como conclusión les manifesté que, por el tipo y objetivo del proyecto, tenían motivos suficientes, para necesitar feedback de los usuarios lo más rápido posible. Sin embargo, lo que realmente es posible depende del entorno del producto. Algunos entornos permiten dar pequeños pasos y recibir feedback casi continuamente. Otros entornos tienen características diferentes que requieren más excavación y experimentación para crear un incremento.
Entonces, como conclusión, explicaba que, para determinar el tamaño idóneo del sprint requerido para cada proyecto, se debe verificar las características del entorno del producto, del proyecto y del equipo. Por lo tanto, no hay una respuesta única que sirva como “bala de plata”, para todo tipo de proyecto. Esta es la razón por la cual Scrum (por ejemplo), da la bienvenida a los experimentos al probar algo, inspeccionar cuál es el impacto y luego adaptarse en función de nuevas ideas.
Por lo cual mi recomendación fue que no basaran su decisión final del tamaño del sprint en suposiciones. Como, por ejemplo, Sprints más cortos siempre son mejores. Les indicaba que lo mejor era que basaran dicha decisión en lo que aprendieran de la experimentación y el análisis realizado.
Con lo cual para grata sorpresa, el día de hoy mi querido amigo lector me comentaron que decidieron hacer los dos primeros sprint del proyecto a modo de experimentación con un tiempo de 2 semanas, e iban a analizar cómo les iba para determinar si debían aumentar o disminuir el número de semanas del sprint, con el que iban a desarrollar el resto del proyecto.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Post Producto de una buena conversación sobre Design Thinking, lean Startup y Agile, y como pueden ayudar a una organización a alcanzar sus objetivos
Hace poco conversaba (de manera informal), con un ejecutivo de una importante organización perteneciente al sector bancario (con quien he podido establecer una buena amistad), sobre cómo mantener el foco en la creación de valor para el cliente, sin caer en el gran problema que sufren muchas organizaciones de centrarse en las practicas, siguiendo así, procesos que en muchos casos, no son modificados en pro de ser mas agiles, sino que por el contrario, a los procesos ya robustos de las organizaciones, les introducen “practicas” que terminan siendo mas de nombre que de resultado en sí.
Veíamos de paso como en las diferentes áreas de la organizaciones, dichas “practicas”, terminan creando a su vez, más silos en la organización, dado que se ven también como fases independientes no complementarias y el espíritu del trabajo colaborativo termina diluyéndose a lo largo del proceso de “generación de valor”.
De nuestra conversación me llamo mucho la atención el hecho, que hay 3 cosas de las que mas se hablan en las organizaciones en la actualidad (esto lo expreso por experiencia propia y por experiencias expresadas por mi querido amigo de conversación) y son: Agile, Design Thinking y Lean Startup. En algunas quizás por desconocimiento de su verdadera aplicación terminan generando el problema plantado, mi querido amigo lector en el párrafo anterior.
En medio de nuestra conversación, vino a mi mente la siguiente imagen que vi hace poco más de 1 año:
Imagen con la cual le explicaba a mi querido amigo, que: Agile, Design Thinking y Lean Startup, son tan necesarias como complementarias para la generación de valor. Le explicaba igualmente que en muchas organizaciones en las que he podido acompañar, siempre encuentro las mismas inquietudes entre los altos ejecutivos. Y son:
¿Cuál es la diferencia que existe entre ellas?
¿Cuál debería usar?
MI querido amigo lector, estas inquietudes solo muestran la superficie del problema y no abordan la razón por la cual las organizaciones recurren a estos conceptos en primer lugar. Mas que buscar la diferencia (algo totalmente valido, desde el desconocimiento de lo que es cada una), lo que verdaderamente deberíamos preguntarnos en las organizaciones es:
¿Qué tienen en común?
¿Cómo pueden ayudar a la organización a alcanzar los objetivos trazados?
Le explicaba igualmente a mi querido amigo, que los tres conceptos se centran en la creación de valor para el cliente a través de procesos iterativos y, por lo tanto, contribuyen a aumentar el enfoque en el cliente y la adaptabilidad organizacional. Y si bien lo hacen de diferentes maneras, los resultados de los enfoques son complementarios.
Cuando miramos el proceso de creación de valor en sí mismo, debemos pensarlo como un flujo continuo: descubrir el valor, validar el valor y entregar el valor. Cada concepto cumple un propósito diferente en este flujo: Con Design Thinking, definimos un resultado que queremos lograr. Con Lean Startup, determinamos qué camino (entre los distintos caminos que puedan llegar a existir), podría ser el mejor para alcanzar el resultado deseado. Y con Agile optimizamos el viaje, mediante la habilitación del Mindset, a lo largo de ese camino para finalmente alcanzar el resultado deseado.
Es importante tener en cuenta que hay un valor limitado en delinear dónde termina Design Thinking y comienza Lean Startup, o dónde termina Lean Startup y comienza Agile. El énfasis en conciliar los pasos individuales y trazar límites solo distrae de la comprensión de los motivos y por qué estos conceptos podrían ayudar. Sin mencionar que crear nuevos silos y no permite que florezca el trabajo colaborativo.
De igual forma le explicaba a mi amigo, que ninguno de los conceptos es una «bala de plata» en sí mismo. Dado que ninguno de los conceptos individuales abordaría todos los problemas relacionados con la capacidad de adaptación y generación de valor centrada en el cliente. Si bien Agile busca precisamente eso, como filosofía requiere de la aplicación de ciertas prácticas y cambios para lograr su cometido. Por lo tanto, la verdadera magia sucede, cuando se logra incorporar los tres conceptos en toda la organización para cambiar la forma en que se aborda todo. Es decir, se requiere de la habilitación del Mindset y la implementación de las practicas para lograr la magia.
Como le seguía explicando a mi amigo: El hilo conductor de todos estos conceptos es su enfoque en la generación de valor al cliente a través de un proceso de aprendizaje iterativo. Sin embargo, este enfoque se logra de diferentes maneras, que son complementarias entre sí:
Como punto de partida tenemos en Design Thinking, todo lo relacionado con el Value Discovery, mediante el cual intentamos descubrir el valor que se puede crear para las partes interesadas. Y el proceso iterativo se utiliza para reducir la multitud de opciones a un resultado objetivo específico.
Por otro lado, con Lean startup, tenemos todo lo relacionado con la validación de valor. Dado que, ya existe una idea sobre cuál podría ser el valora generar, tendríamos como objetivo validarlo. Además, podría haber múltiples formas diferentes de entregar un valor específico a las partes interesadas, por lo que el proceso iterativo confirmaría cuál de ellas funciona mejor.
Finalmente, Agile se utiliza para ayudar a la organización a escalar la entrega a lo largo del camino elegido, mientras se mantiene eficiente y flexible para responder a los cambios y la nueva información descubierta durante el proceso.
Como le explique a mi amigo, un buen resumen podría ser:
Con Design Thinking definimos un resultado que queremos lograr. Es decir, cuál es el valor específico que queremos ofrecer a nuestros clientes y/o partes interesadas. Con Lean startup determinamos qué camino podría ser el mejor para alcanzar el resultado deseado. Ósea, cuál es la mejor manera de entregar ese valor. Y con Agile, damos los pasos a lo largo de ese camino, llegando finalmente al resultado. Es decir, nos permite identificar, cómo podemos ofrecer el valor al cliente a nivel organizacional de la manera más efectiva y eficientemente posible
Por lo tanto, en nuestra conversación llegamos a la conclusión, de que no hay necesidad de elegir entre cual concepto aplicar. Dado que cualquier organización que decida embarcarse en un camino para aumentar su capacidad de generar valor, tendrá que incorporar aspectos de los tres, es decir habilitar la agilidad e implementar las practicas, para ver resultados significativos.
Mi querido lector, espero que este pequeño resumen de tan amena conversación haya sido de tu agrado, tanto como lo fue para mí.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Contenido Premium: 11 errores que se deben evitar al querer implementar DevOps
Habilitar la agilidad en una organización sin duda requiere cambios en todos los niveles organizacionales. Algunos mas complejos que otros, pero al final es una espiral de cambios constante, para adaptarse al nuevo contexto y/o a las nuevas necesidades.
Desde hace varios años, los equipos de negocios y desarrollo han visto un cambio de los enfoques tradicionales de desarrollo de software, al tener que pasar del desarrollo en cascada al desarrollo iterativo, de ágil a nivel de equipos ha escalado ágil hasta llegar a Enterprise Business Agility.
Pero cambiar el enfoque de una organización desde la definición de temas estratégicos, pasando por la identificación de necesidades de los clientes, la gestión del portafolio y el desarrollo de iniciativas hasta llegar a la entrega está lejos de ser sencillo. Cada bloque del proceso presenta diferentes tipos de retos que deben ser abordados a lo largo de todo el ciclo de la mejor manera posible.
Es decir que, para tener una visión completa de la agilidad empresarial, es necesario equilibrar el Valor (construir lo correcto), la Calidad (construir correctamente y el Flujo (construir a la velocidad adecuada). Para este último, significa optimizar el flujo de entrega de valor balanceando el grado en que la organización optimiza el uso de recursos y optimiza el flujo de entrega de valor al cliente.
Es en este punto en donde entra DevOps. Para unos una cultura, para otros una metodología, para otros algo creado sin necesidad, dado que la agilidad como tal engloba el concepto de unir de manera colaborativa y con el único fin de generar valor, el trabajo de las diferentes áreas de la organización.
Implementar DevOps en una organización se convierte en un desafío cultural y tecnológico, lo cual significa que es obligatorio para cualquier organización tomarse en serio el proceso, tener líderes a la cabeza del proceso, que lo entiendan y puedan trabajar con diferentes tipos de roles de manera interfuncional, será sin duda una de las claves principales del éxito de la implementación. Por lo tanto, si hay una visión clara y los objetivos están bien definidos desde el principio, entonces el resto de la organización se alineará. Por el contrario, si esto no existe, es casi seguro que la implementación va a fallar.
A continuación, veamos los 11 principales errores que se deben evitar entonces al querer implementar DevOps:
Partir con la idea que DevOps es una cultura. No, DevOps no es en sí una cultura, pero sí requiere de una fuerte evolución cultural y organizativa para su implementación. Un evolución cultural hacia la colaboración, la comunicación, y en último término la completa integración entre las áreas de desarrollo y sistemas. Lo cual requiere una buena gestión del cambio.
Pero según lo anterior, entonces que podemos decir que es DevOps: DevOps es una metodología de desarrollo software, y una evolución cultural no es en sí misma una forma de desarrollar software. Esta evolución cultural es tan complicada de conseguir en algunas organizaciones, que muchas personas la identifican directamente con implementar DevOps.
Creer que DevOps es un Rol o cargo nuevo. Este es otro error común, ya que se tiende a confundir DevOps con modelos que algunas startups se ven abocadas a adoptar en sus inicios, en los que todos los miembros del equipo técnico saben de desarrollo, de operaciones, de bases de datos… etc. DevOps no consiste en aumentar la responsabilidad de los desarrolladores haciendo que lleven varios sombreros (en particular dos, el de desarrollo y el de operaciones), sino en sustituir esos dos sombreros por uno solo, un nuevo sombrero de DevOps.
Según Rob Steward, vicepresidente de desarrollo de producto de Progress Software, “una buena práctica de DevOps liberará a los desarrolladores de ciertas tareas, para que se centren en hacer lo que mejor saben hacer: escribir software. Dado que DevOps elimina el trabajo y las preocupaciones de la puesta en producción del software una vez que está escrito”.
Si esto es así, ¿qué es un ingeniero DevOps?, ¿Por qué se buscan en el mercado (y cada vez con mayor demanda) perfiles con habilidades específicas para montar equipos DevOps? La respuesta es sencilla. Para un desarrollador pasar a un modelo DevOps resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas habilidades. Estas habilidades, según una investigación de Puppet Labs, son: scripting, reingeniería de procesos, experiencia con herramientas específicas y una serie de soft skills necesarios para lograr las interacciones que se requieren dentro del proceso. Por lo que un perfil de este tipo, no es fácil de encontrar.
Así que no, DevOps no es una profesión, y estrictamente no existen ni perfiles DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con capacidades específicas para integrarse en equipos DevOps”.
No considerar a las personas y a los recurso en el proceso de implementación. Si no se tiene suficiente conocimiento sobre las cargas de trabajo de los equipos y sus capacidades para realizar tareas, lo mejor es no obligarlos a adoptar DevOps. Lo más recomendable siempre será, cuantificar primero la carga de trabajo de cada una de las personas de los equipos y de los equipos en general. Los siguientes pasos serán entonces, diseñar indicadores clave de rendimiento (KPI) y garantizar que estén bien controlados. Acto seguido, analizar y comprender el rendimiento de todos, para así utilizar la información obtenida para organizar mejor las cargas de trabajo
Ver a DevOps solo como un proceso de automatización. Si bien en DevOps, es importante automatizar la mayor parte del proceso (si la mayor parte, no todo), tanto como sea posible. DevOps va más allá, Matthew Skelton (cofundador de Skelton Thatcher) dijo: “si se crea un enfoque DevOps, que involucra a un único equipo encargado de la automatización, se perderá el sentido, ya que concentrarse solo en la automatización le proporcionara solo un poco de efectividad adicional en TI”. otro experto en DevOps, Stephen Thair (Cofundador de DevOps Guys) explica: “DevOps no es solo una cosa de TI. Ya que, si la organización está centrada solo en la automatización, DevOps le ofrecerá un software mejorado. Pero no solucionará los problemas de cuellos de botella que tenga el flujo de desarrollo de soluciones en la organización”.
Otro punto interesante para tener en cuenta es: Armar un equipo o célula en TI enfocado en DevOps, hará que se establezca un nuevo silo en el flujo.
Querer implementar DevOps con personas sin experiencia. Actualmente muchas empresas están dando el paso hacia la implementación de DevOps. Sin embargo, en muchos casos con pocos o ningún ingeniero con experiencia real en la implementación de DevOps. Como resultado, terminan entregando trabajos de baja calidad. Aquí hay que tener algo presente, pasar de un proceso de desarrollo de soluciones sin DevOps a uno con DevOps es una idea brillante, pero solo si como organización se está bien preparado y se cuenta con ingenieros con experiencia. Ya que el nivel de habilidades y conocimientos que se requieren es extremadamente alto.
Sobreponer la velocidad sobre la calidad. Muchas organizaciones se enfocan en fabricar un producto rápido, en lugar de enfocarse en la calidad. (aquí una opinión muy personal: agilidad sin calidad, no es agilidad y la agilidad si debe brindar velocidad a la hora de generar valor, pero con calidad). Las tareas de DevOps deben lograrse manteniendo altos estándares. Por otro lado, no puede comprometer la velocidad con la calidad. En el mundo de hoy, la competencia se ha vuelto tan dura y permanecer relevante es un desafío. Es por eso por lo que muchas organizaciones se apresuran a aceptar proyectos de DevOps y terminarlos en el menor tiempo posible. Como resultado, la calidad del trabajo es pobre. La velocidad y la calidad deben funcionar de la mano.
Avanzar hacia nuevas tecnologías sin terminar de madurar las anteriores. El problema en muchas organizaciones es que comienzan a usar nuevas tecnologías antes de que terminen de investigar y/o madurar las anteriores. Además, en muchos casos vemos como usan tecnologías que aún están en modo beta, solo porque los competidores están haciendo lo mismo. (el mismo caso sucede con la agilidad, la cual en muchos casos llega a las organizaciones, más por el hecho que en la competencia se está “trabajando bajo agile”, que por el hecho de existir conciencia que se debe habilitar en la organización) . Antes de comenzar a usar estas tecnologías, las organizaciones deben tomarse el tiempo necesario para realizar una investigación seria y exhaustiva de dichas tecnologías, con el objetivo de determinar si estas son las que realmente requiere o se adaptan a la organización o si, por el contrario, es la organización quien debe adaptarse a ellas. Esto con el fin de gestionar dicho cambio responsablemente. Hay que tener en cuenta también que la tecnología cambia día a día y se están introduciendo complementos para actualizar las tecnologías antiguas. Sin embargo, lo recomendable siempre será, no tengas prisa por actualizar cuando se trata de tecnología. Lo mejor siempre será, tomarse el tiempo para aprender todo en cada etapa, y luego avanzar al siguiente paso cuando se esté listo.
Tener un ¿por qué? muy pobre para querer implementar DevOps. Al igual que al hablar de agilidad en una organización, es muy importante tener un ¿por qué?, muy solido a la hora de hablar de DevOps. Dado que DevOps es una excelente manera de acelerar la formar en que TI puede asegurarse que cumple con las demandas de la empresa. Sin embargo, al querer implementar DevOps, este debe enfocarse en respaldar las necesidades de la organización. Tener claro el ¿por qué?, siempre ayuda a determinar la estrategia adecuada. Y una estrategia adecuada, ayudara a alentar a las partes interesadas a determinar el presupuesto, los recursos y los cambios que se necesitan.
No incluir a las personas de auditoria o de PMO. Muchas organizaciones consideran que DevOps es un tema exclusivo de TI, quizás porque en su acrónimo habla de Desarrollo y operaciones. Sin embargo, DevOps es una combinación de muchas partes interesadas. Ya que este es un proceso continuo de automatización y desarrollo de software que puede dar lugar a muchas áreas grises en temas de auditoria, cumplimiento de estándares de seguridad y/o normativos. Por lo cual es de suma importancia contar con personal de auditoria o de la PMO que entienda los procesos, evalué los controles e identifique los riesgos (esto no es un trabajo solo de este grupo de personas, debe ser de todas las personas que participan. Sin embargo, por su neutralidad, están llamados a brindar una mirada externa que aporta mucho valor). Es decir, la organización debe crear un sistema de pensamiento inclusivo, que haga que la implementación de DevOps no sea algo solo de TI, sino por el contrario que sea de contexto organizacional.
Determinar un plan de implementación prescriptivo y ser rígido con dicho plan. Al igual que en la agilidad, es más importante “responder al cambio sobre seguir el plan” sin que el plan no sea importante. Y he aquí en donde muchas organizaciones fallan en su implementación de DevOps. La rigidez con que se busca abordar DevOps en la organización termina creando puntos ciegos (como los que se presentan en una habilitación agile) que no permiten ver la situación real. Por eso es importante localizar el liderazgo adecuado dentro de la organización para dicho fin, es decir lideres que estén al servicio de la implementación de DevOps, no al contrario. Por otro lado, se debe gestionar el cambio de paradigma en la organización sobre como abordar las fallas o errores. Es decir, si en la compañía se castiga el error, las personas serán reacias a mostrarse abiertas a los cambios que requiere la implementación de DevOps. Fomentar la experimentación será clave en el proceso.
Sobre vender DevOps en la organización. DevOps no es una bala de plata que va a solucionar todos los problemas de cuello de botella que existen en la organización y/o las ineficiencias que existan en TI y/o en el proceso de desarrollo de soluciones. Aquí es crucial entender por parte de la organización, que entre mejor estén hechas las cosas antes del despliegue, mejores resultados se obtendrán. Otro punto importante es adoptar un enfoque que vaya proyecto por proyecto y no uno completo o Big Bang. Siempre es recomendable comenzar por proyectos valiosos, pero no de misión crítica. De esa manera la organización puede ver los beneficios claros de las practicas de DevOps, así de los posibles errores que se estén cometiendo, sin que sus procesos críticos se vean afectados. Así con el paso del tiempo y cuando el tema vaya madurando en la organización, se va llevando a procesos más críticos.
Como puedes ver mi querido amigo lector, son muchos los errores que se pueden cometer al querer implementar DevOps en una organización. Aquí solo mencioné los más comunes, sin llegar mencionar los técnicos, que representan otros desafíos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
