• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Organizaciones

5 argumentos en contra de usar Scrum

Durante los últimos meses he observado un cierto encarnizamiento en torno al debate sempiterno de las metodologías ágiles y en especial de Scrum del que he preferido mantenerme a distancia.

Este tipo de debates no es nuevo y creo que cada dos o tres años experimentan un renacimiento a causa de la decepción que muchas personas experimentan con los métodos ágiles.
​
El objetivo del presente artículo hoy es dar contexto a los argumentos en contra de Scrum, en un intento de intentar ayudar a entender qué es y qué no es.

Me he centrado en cinco: La excelencia técnica, el rol del Scrum Master, el intrusismo, la mercantilización de las certificaciones y la muerte de Scrum.

Scrum no promueve la excelencia técnica.

Muy cierto. Ningún equipo de desarrollo de Software que hiciera una basura de producto con clases de mil líneas, acomplamiento extremo, spaghetti code y cuyo concepto de test es “funciona en mi máquina”, tras aplicar Scrum, han conseguido ninguna mejora.
​
Es más, muchos de ellos, debido a la presión inherente al proceso de Scrum, han terminado haciendo cosas incluso peores, fruto de una falta absoluta de orientación a producto y una Definition of Done.
​
Porque puedes coger cualquier cosa en este mundo, y de la forma más amateur del mundo, destrozarla y decir que no promueve lo que tu quieres que promueva.
​
Y eso está bien, porque Scrum no promueve la excelencia técnica. Son las personas que hacen Scrum las que tienen que promover la excelencia técnica. En concreto el Equipo de Desarrollo (Dev Team).

No concibo trabajar en 2020 con un equipo que no entienda cómo escribir buenas Historias de Usuario ayuda a dirigir una arquitectura hexagonal u onion. Tampoco que no entendamos las bondades que aporta reducir los ciclos de feedback a través del uso de herramientas de integración y despliegue continuo como Azure. O del uso de telemetría para identificar quick wins y el impacto que el software que escribimos tiene en el valor que nuestros usuarios perciben.

Azure application insights permite integrar telemetría de la aplicación directamente en Visual Studio

Que Scrum no hable específicamente de excelencia técnica no significa que Scrum excluya la excelencia técnica.

Significa que es un framework ligero, usado en multitud de industrias y sectores en todo el mundo; como tal, es imposible describir todas las opciones que existen para mejorar la excelencia técnica sin caer en el error de intentar hacer el diccionario Larousse del Scrum: Una iniciativa noble, épica pero inútil.

​
El Scrum Master es un rol, no es una persona.

Totalmente cierto. Y todavía no he encontrado quien diga lo contrario. Sin embargo, es habitual que dada la naturaleza física del mundo, el rol del Scrum Master termine realizándolo una persona y no el espíritu santo.

Es más, debido al caos que suele generar un cambio de contexto continuo en caso de que una persona comparta varios roles, muchas de esas personas querrán dedicarle tiempo completo al rol, mientras que otras no.

El tiempo que le dediquen afectará a la efectividad del rol.
​
También afectará a la efectividad del rol la capacidad y el conocimiento que la persona o personas que ejerzan el rol tengan sobre Scrum y sus posibles consecuencias o ramificaciones.

Si su exposición a Scrum está limitada al popular episodio: “Peppa Pig y su familia desarrollan Software usando Scrum” es posible que su capacidad de entendimiento esté limitada por una falta de conocimiento sobre las consecuencias de hacer Scrum.
​
E incluso así, se puede hacer Scrum.

Igual no es un Scrum maravilloso que además cae en los problemas expuestos en el punto anterior pero la naturaleza de Scrum, que es ser libre para ser usado por quien quiera, permite usarlo.

Los Scrum Masters y Product Owners no han programado nunca. Son unos intrusos.

​
​Bingo, otra en la frente. Ahora mismo hay muchas personas ejerciendo el rol de Scrum Master, Product Owner, enseñando Scrum y certificando gente que no tienen ni idea de programar.

Es más, hay organizaciones y partes de organizaciones con cientos y miles de personas que no producen software utilizando Scrum.

E incluso hay personas que utilizan Scrum o partes de Scrum en cosas que no tienen nada que ver con la Tecnología.

Este es precisamente uno de los motivos por los que Scrum es tan popular. Porque no tiene una legión de policías diciéndote lo que no puedes hacer sino que son unas reglas de juego que puedes utilizar para múltiples cosas.
​
Y no sólo hay personas haciendo Scrum en equipos de tecnología que no saben programar. Hay CTOs, CIOs, Development Managers, Arquitectos de Software e incluso programadores que no tienen ni idea de programar.
​
Por un lado, yo nunca contrataría a un Scrum Master para trabajar con un equipo de tecnología que no tiene un conocimiento mínimo de Software. Y si ese es el caso, le invitaría a hacer al menos dos o tres cursos de los miles gratuitos que hay en línea para que aprendiera qué es programar, para qué sirve el control de versiones o por qué una arquitectura monolítica puede superar en beneficios a una de microservicios en equipos pequeños y cross-funcionales.
​
Por otro, los técnicos tendemos a pensar que el valor de nuestro Software reside en el código. Y el ciclo de vida del Software es mucho más que eso. Podemos hacer un código maravilloso y ofrecer cero valor a nadie. En la mayoría de los casos hacen falta personas de producto, de proceso, de operaciones, de administración de sistemas, de marketing, de ventas y de administración para ofrecerle valor a alguien.
​
Los programadores hemos de dejar de estar enamorados del código que escribimos y empezar a enamorarnos del valor que el código que escribimos crea.

​
El mercado de Scrum y las metodologías ágiles se ha mercantilizado. Las certificaciones no valen nada.

Absolutamente cierto. En la fiebre del oro del lejano Oeste quienes tenían ganancia asegurada no eran los buscadores de oro, sino los vendedores de palas.
​
Lo cual no quiere decir que no hubiera buscadores de oro que no se hicieran tremendamente ricos.
​
Hoy en día hay compañías completamente alejadas de estos debates que están usando Scrum para ser tremendamente ágiles: competitivos, adaptativos e innovadores.
​
​Durante una reunión en 2015 a la que asistí en Boston, cuna de Scrum, descubrí que existe un acuerdo total entre las compañías certificadoras para identificar a individuos influenciables y a través de campañas dirigidas de Facebook Ads, anuncios en conferencias ágiles y una campaña orquestada por redes sociales, fabricantes de post-its, rotuladores y el lobby de las jirafas, para certificarlos a todos. Todo se hizo con conocimiento del club Bilderberg y la aprobación del Conde Drácula y Don Pimpón.

A pesar de que alguien haya leído el párrafo anterior y le haya dado un vuelco al corazón – ¡Lo sabía! – es ironía. Lo cual no cambia el hecho de que Scrum se haya mercantilizado.
​
No hay más que crear una sensación de demanda para dirigir un comportamiento.

No es nuevo.

En 1775 se hizo en Francia para fomentar el consumo de la patata, que se veía como un alimento para el ganado.
​
Las compañías, sobre todo en el último lustro, han demandado más profesionales con conocimientos de Agile. Y Agile se ha asociado tradicionalmente a Scrum. Es por ello que han surgido cientos o miles de compañías dedicadas a la fabricación en masa de certificaciones ágiles cuyo marketing es cuestionable o puede llevar a engaño.
​
Y hoy en día, tenemos un maravilloso y variado mercado de limones.

No es algo exclusivo de Agile, es algo inherente a cualquier sector emergente en cualquier industria en cualquier país.

Desde las mascarillas para el COVID a los másteres que no son másteres.
​
Un momento. ¿No soy yo, Jerónimo Palacios, parte de esa mercantilización? Por supuesto que sí, en la medida en que todo el que tiene que ver con las certificaciones cae dentro del mismo saco.

Sin embargo, creo que dado el posicionamiento que hemos tenido, intentando mantener la calidad -y por ende el precio- por encima de la media, centrándonos en hacer de la formación -y no de la certificación- una palanca de transformación en las organizaciones con las que he trabajado y aportando experiencia haciéndolo.
​
Como ser humano es imposible no caer en contradicciones. Estoy seguro de que he formado personas que utilizan Scrum como un báculo con el que golpear a otros. Personas que han terminado formando parte de equipos de Software como Scrum Masters sin saber de tecnología.

Siempre he creído que lo importante de mi trabajo es explicar las cosas, la importancia que tiene la tecnología y las personas en torno al valor que creamos, pero siempre lo he hecho desde la perspectiva de Scrum.
​
Además, no es ningún secreto que puedes ir a Scrum.org y pasar la certificación PSM sin necesidad de asistir a nuestra clase ni a la de ningún Professional Scrum Trainer. Es más, con un poco de google fu puedes buscar archivos con cientos de preguntas por la red que te ayudarán a pasar la certificación sin saber siquiera cuantas preguntas está obligado a responder el Team todos los días al Scrum Manager.
​
Y eso hace que la certificación no valga nada. Porque la certificación certifica -¡Sorpresa!- que en un momento dado has pasado un examen de conocimiento básico sobre Scrum. Lo que vale es el conocimiento, ideas, habilidades y capacidades de la persona que ostenta esa certificación de ejercer ese rol en una organización.


Scrum ha muerto.

Toda la razón. Llevo viendo morir a Scrum y Agile desde que empecé a aplicar técnicas de desarrollo ágil y XP en 2007, cuando me subí al carro de Ruby on Rails. Hay pocas cosas tan viejas en el desarrollo de Software moderno como Scrum, que ya tiene 25 años.
​
Dentro de unos años Scrum no existirá. Y con ello habrá desaparecido la mercantilización, la falta de excelencia técnica y el rol del Scrum Master.

Ojalá el motivo de la desaparición de Scrum tiene como motivo que las organizaciones que desarrollan productos complejos han entendido que todas las cosas que promueve Scrum, incluyendo la agilidad de negocio, forman parte de su ADN, y por tanto no tienen que recurrir a ningún framework, método, certificación o bala de plata para mantenerse competitivas.

La increíble teoría de la latencia de las decisiones

Ahora que la parte dura de la pandemia del COVID-19 ha pasado y se han producido desconfinamientos, es probable que en algún momento desees volver a cenar a un restaurante con tu pareja, tu familia o un amigo.

Durante este tiempo en casa has tenido la oportunidad de revisar los mejores restaurantes de la ciudad y has hecho una lista ordenada por puntuación, reseñas y tipo de comida.

En el centro de la ciudad, Ángela está disponiendo todo para poder recibir a nuevos comensales cumpliendo con todas las medidas de seguridad.

Su equipo está muy contento de volver al trabajo y han preparado todo para hacer que todo esté perfecto.

Están muy emocionados. Las neveras están llenas. Todo está listo.

El día señalado nos dirigimos al restaurante. Tomamos asiento y revisamos la carta, que es un poco reducida. Elegimos nuestro plato y pedimos una botella de vino mientras esperamos.

En cocina, el equipo es uno de los mejores de la ciudad. Son capaces de preparar los 14 platos de la carta en tiempo record y han practicado durante la última semana para asegurar que todo está perfecto.

Sin embargo, para asegurar que el servicio cumple con todos los requerimientos sanitarios, cada comanda debe de ir primero a la mesa de Ángela, que se encarga de revisar las peticiones de los clientes una a una y decidir que platos se prepararan y quien se encargará de hacerlos.

Durante la primera hora las cosas funcionan. Un poco lentas, pero funcionan.

Sin embargo, cuando los clientes ya completan un tercio del aforo del local, las notas empiezan a acumularse en la mesa de Ángela mientras ésta tiene que acudir a cocina constantemente a revisar quien está disponible y cual es el siguiente plato que puede entrar en función de los requerimientos que hay que cumplir.

La primera noche es un desastre.

La segunda también.

Durante la tercera el equipo consigue mantener el servicio a duras penas. Los clientes dejan malas reseñas en Internet y empieza a correrse la voz.

Ángela toma una decisión.

A partir de la seiguiente semana contrata un equipos de compliance que se encargará de proporcionar capacidad a la toma de decisiones. Sin embargo, el resultado es incluso peor.

El nuevo equipo de compliance decide que el problema es la necesidad de tiempo para la toma de decisiones.

Así que a partir de ahora los clientes tendrán que avisar con al menos 24 horas de antelación de lo que desean comer para que el equipo tenga la oportunidad de organizar la comida.

Problema resuelto.

¿Problema resuelto?

Este problema es un problema clásico donde la toma de decisiones afecta a la agilidad de negocio, a pesar de tener una capacidad tecnológica y un equipo altamente preparado.

En el informe CHAOS de 2018, un referente en la estadística de gestión de proyectos, Standish Group introdujo la teoría de latencia de las decisiones para explicar por qué aparentemente organizaciones preparadas para enfrentar problemas de negocio de forma ágil tenían altos niveles de fracaso y de rotación de personal.

La latencia de las decisiones es un factor decisivo para valorar la agilidad de una organización”

La teoría propone que esos niveles de fracaso están más relacionados con la latencia -espera- que se produce entre las decisiones que con la capacidad de la organización de hacer frente a los problemas.

En una simulación avanzada, Patrick Steyart, creador de Okaloa FlowLab, explica como lidiar con este tipo de latencias usando Upstream Kanban y también en el libro Essential Upstream Kanban (Descarga gratuita tras introducir datos).

En 2017 también publiqué un artículo sobre el uso de Upstream Kanban para tratar este problema.

La latencia de las decisiones -también ironizada como parálisis por análisis- es un factor decisivo para valorar la agilidad de una organización.

En el caso de Scrum, se resuelve teniendo vectores de responsabilidad única, tales como el Product Owner para las decisiones de negocio, que sólamente por existir pueden agilizar un dominio de negocio o un producto, produciendo un retorno de inversión mucho mayor que su coste.

También el tener un equipo de desarollo que pueda tener una cierta independencia en la toma de decisiones técnicas o una librería de diseño para la creación de la experiencia de usuario son inversiones fundamentales para permitir que se pueda crear valor hacia el cliente.

Es precisamente cuando se trata de tomar acciones que cambian la latencia de las decisiones cuando las organizaciones presentan más resistencia a estos cambios. En general, reducir el número de decisiones puede llevar a que determinados roles y funciones queden totalmente obsoletos.

Por ejemplo, abordar decisiones en entornos de complejidad usando Cynefin puede destripar de autoridad a un manager cuya función es precisamente el controlar las decisiones que se toman.

Cuando un Scrum Master es empoderado para acceder a la organización y provocar cambios que afectan -y por tanto suboptimizan- al resto de la organización, pueden ser vistos como una amenaza. Sin embargo, reducir o incluso eliminar totalmente determinados estratos de decisión ayuda a reducir costes y mejorar la entrega.

Y esto no sólamente aplica a la creación y gestión de productos. Una organización que permite a sus empleados comprar cosas necesarias para su trabajo de un coste no superior a 150€ puede reducir eliminar la mayor parte de los sistemas de control y aprobación de gasto. Esto es lo que en Lean se conoce como waste.

Los estados por los que debe pasar una decisión pueden visualizarse y gestionarse utilizando Kanban.

Aquellos que somos fans de chefs Alberto Chicote o Gordon Ramsey podemos visualizar el impacto sistémico que tiene en un restaurante que el propietario decida meterse hasta la cocina a tomar decisiones que no le corresponden.

Esta analogía sería válida para comparar al equipo de compliance de Ángela con los gerentes intermedios de cualquier organización.

¿Significa eso que las personas deben operar con absoluta libertad y desprecio hacia las normas de la organización en un entorno de anarquía?
​
En absoluto.
​
Precisamente es en estos entornos donde tener una serie de reglas en torno a metas concretas de negocio las que nos permiten alcanzar nuevas cotas de competitividad y agilidad.
​
*Standish group ha creado un Free Membership donde se puede tener acceso gratuito a los reportes hasta 2015, aquí el link.

Cursos que te pueden interesar…

Professional Scrum Product Owner Advanced

Professional Agile Leadership

Transformación digital: Foundations Model

La explosión del agilismo de los últimos años se debe, en gran medida, a los procesos de transformación que han arrancado en organizaciones de todo tipo en la última década. Pero, ¿todos tenemos claro qué se busca y qué piezas la componen?

En Diciembre de 2019 Jero y yo visitamos a un posible cliente que quería transformarse. Este cliente es una empresa internacional, grande y potente. Para poder dejarla en el anonimato, no puedo decir a qué se dedica, porque reina en su sector de una manera abrumadora desde hace años.

Nos llamaron por que una empresa nueva, pequeña, a la que no prestaban mucha atención, estaba empezando a robarles cuota de mercado. En los últimos 6 meses, esta pequeña startup, había sido capaz de poner en el mercado un producto disruptivo, aprender del comportamiento de sus usuarios, tirar el producto a la basura y rehacer uno nuevo con otro nombre que incorporaba todo lo aprendido. Este nuevo producto estaba funcionando muy bien y robándole clientes.

En esos 6 meses, los directivos de la empresa que nos llamó, aún no habían sido capaces de juntarse y ver cómo podrían competir. ¿Os suena esta historia?

Esto me recordó al Chaos Report 2018. Si no conoces el Chaos Report, es un reporte anual generado por Standish Group. Tienen una base de datos con miles de proyectos y siguen su evolución. Proyectos de todo tipo: grandes, pequeños, medianos, ágiles, no ágiles, en diferentes localizaciones. Hacen seguimiento de estos proyectos y luego nos proporcionan los factores de éxito. Nos mastican datos como el porcentaje de éxito de los proyectos ágiles y los no ágiles, o cómo influyen en el éxito del proyecto las soft skills o las hard skills del equipo. Son informes realmente interesantes y, si no recuerdo mal, tienen un precio alrededor de los 300$.

El informe de 2018 comenzaba con la “Teoría de la latencia en la toma de decisiones” (decision latency theory) donde argumentaban que el factor que más influía en el éxito de proyectos (o productos) era la capacidad que existía en la organización a la hora de tomar decisiones respecto de este producto.

El agilismo nació para poder hacer frente a la creación de productos complejos a través de la inspección y adaptación. Evidentemente, si tu tiempo de respuesta a un suceso inesperado es muy alto, tu capacidad de adaptación es bajísima. Por ello Agile se basa en equipos auto-organizados, en roles de negocio empoderados que pueden tomar decisiones, en desarrolladores que tienen control de todo el flujo del software, desde la creación hasta el deployment. 

¿Es todo agilidad?

Cuando surgió el término transformación digital era para hacer referencia a todos esos cambios que empresas grandes y tradicionales estaban realizando para poder competir con las nuevas empresas nativas digitales. 

Empresas que aún tienen sótanos llenos de archivadores con datos en papel, intentando subir su nivel de competitividad para luchar con empresas que surgieron directamente con lago de datos, tecnologías big data, data scientists y arquitecturas escalables en la nube.

La digitalización de la humanidad cambió por completo el paradigma empresarial. Antes, el pez grande se comía (o compraba) al pez chico. Ahora, el pez rápido se come al pez lento. Esta transformación es profunda, difícil y engloba tecnología, negocio, cultura, perfiles, management, métricas, productividades o gestión de presupuestos.

¿Qué es transformarse?

Cuando desde una organización nos decían “nos queremos transformar, queremos que nos ayudéis” desembocaba en una conversación larga sobre qué era lo que querían, que significaba para ellos la transformación, que esperaban, qué métricas buscaban mejorar, qué iniciativas habían pensado y qué era en lo que podíamos ayudarles y en qué no.

Recuerdo una empresa que visitamos en 2018 por primera vez. Querían empezar su proceso de transformación implantando Scrum directamente. Su tiempo de entrega mínimo era de 5 meses. Tenían mucha deuda técnica, un stack tecnológico muy primitivo y técnicos que no habían tenido tiempo para innovar ni ponerse al día con nuevas prácticas. Les aconsejamos que primero pusieran el foco en bajar ese tiempo de entrega y les pusimos en contacto con un partner nuestro especializado en crear flujos de integración continua bajo tecnología de Microsoft, que es lo que ellos usaban. Y una vez hecho, podríamos seguir trabajando.

Transformación Digital: Foundation Model

Para poder tener todas estas conversaciones sobre transformación necesitábamos un entendimiento común sobre qué es la transformación digital y qué partes la componen. Desarrollamos un modelo basado en nuestra experiencia. A mi me gusta llamarlo “Foundation Model” porque habla sobre los pilares de una transformación digital

Como nosotros entendemos la transformación digital, ésta tiene tres pilares y una base que sustenta todo:

  • Transformación de negocio: Ahora tenemos mucha información sobre los hábitos de nuestros usuarios y ellos quieren productos personalizados e inmediatos. Hay que buscar modelos de negocio que exploten esta nueva relación.
  • Transformación tecnológica: Entender todos los datos que tenemos y ser capaces de tener ciclos de entrega reducidos requiere de DevOps, big data, nube…
  • Agile: Al incluir nuevos modelos de negocio y nuevas tecnologías hemos introducido una gran incertidumbre dentro de nuestra organización. Tener procesos ligeros basados en equipos de trabajo con alta capacidad de respuesta y foco en entregar alto valor a nuestros usuarios es clave.
  • Cultura: Por mucho que cambiemos nuestras tecnologías o nuestros procesos, si los comportamientos dentro de la empresa sigue buscando crear reinos de taifas, nadie comprometido con los resultados de la empresa o un sistema que sigue alejando a los que crean los productos del usuario final, nada se sustentará.

Hemos creado un paper donde explicamos este modelo de transformación digital de forma más extensa y cómo lo usamos con nuestros clientes. Puedes descargártelo de forma totalmente gratuita aquí.

Conclusión

Este modelo surge simplemente para facilitarnos las conversaciones con nuestros clientes. Su intención es crear un entendimiento común sobre qué es una transformación digital, qué partes tiene, qué necesitan ellos, qué podemos ofrecerle nosotros y qué no.

Es totalmente abierto y está en construcción. Siéntete libre de usarlo si crees que te puede servir, o de modificarlo y ampliarlo si así te es más útil. 

Me encantaría que me dieras feedback. ¿Qué opinas? Puedes dejarme un comentario en este post o tirarme un tweet.

Kanban y la transformación digital

Hoy me gustaría compartir con vosotros un error que cometí hace tiempo y que a día de hoy sigue siendo uno de lo que más me encuentro a la hora usar el método Kanban como palanca de transformación en las organizaciones.

Hace pocos días mi compañero Jero nos contó qué es la transformación digital en un post altamente recomendable. Otra de las consecuencias de todo lo que explica Jero en ese post es que en las grandes organizaciones todo empezó a gestionarse con Silos Técnicos. Es muy tentador pensar que así está todo muy bien ordenadito. Front por un lado, backend por otro, middleware y los gestores de infraestructuras por otro. De hecho, puedo externalizar todo cómodamente y controlar la productividad de mis proveedores con puntos función, número de historias de usuario, o cualquier otra métrica de actividad (y no de valor). 

Como ninguno de estos silos es capaz de producir valor al usuario final por sí mismo debemos crear una entidad que aglutine el trabajo de todas estas islas tecnológicas y lo entregue al usuario final. Y así surge la figura del Proyecto. Cuando alguien tiene una idea de negocio solicita a todos los silos el impacto que tienen en el proyecto y una estimación de en qué release podrán tener lista su parte. Tras un mes de reuniones se les comunica si realmente ese proyecto ha sido aprobado en el comité y en qué release esperan liberarlo.

Kanban como solución

Esta forma de trabajar genera miles de dependencias y bloqueos, además de un “Time to market” que, por experiencia personal, supera ampliamente el año. Esta claro que hay que hacer algo. Las organizaciones se suman al carro de la transformación digital y comienzan a apostar por métodos Ágiles.

Uno de los métodos Ágiles más conocidos es Kanban y a las oficinas de Transformación les suele encajar cuando hablamos de un silo tecnológico que da servicio al resto de la compañía.

Pero pensemos por un momento el ciclo de los proyectos. Separaremos en dos alturas cuando hay alguien trabajando en el proyecto y cuando está esperando a que alguien realice otro trabajo:

ciclo vida visión sistémica Kanban

 

Este es el escenario en el mejor de los casos. Generalmente las releases tienen una fecha a la que algunos silos llegarán con el trabajo terminado y otros no. Lo que nos va dejando proyectos incompletos dentro de nuestro sistema durante meses y meses. Esto hace competir a las grandes en la carrera de la innovación entregando al usuario ideas que tuvieron hace más de 12 meses.

 

Obteniendo beneficio limitado de Kanban

Cuando se empieza a trabajar con Kanban en muchas organizaciones se piensa que el problema está en los equipos. Que no sacan el trabajo suficiente  y se pone el foco en mejorar esos pequeños picos de actividad que vemos en la imagen anterior en vez de en los periodos de espera. Trabajar en tratar de mejorar esa eficiencia de recurso en vez de la eficiencia de flujo de todo el proceso nos hace desperdiciar mucho dinero y tiempo obteniendo pocos beneficios.

Si comenzamos a trabajar con Kanban solamente a nivel de silos seguramente habremos ganado en visualización de nuestro trabajo, gestionaremos mejor los riesgos y hasta podremos aumentar nuestra tasa de entrega. Pero lamentablemente esto apenas impactará en el time to market global, en que el número de bloqueos baje o en que generemos más valor. En definitiva, nuestro impacto en aumentar beneficios en la empresa será prácticamente nulo.

 

¿Cómo podemos lidiar con esto?

Un buen Agile Coach debe buscar la visión sistémica y ayudar a la organización a entregar más y más valor al usuario. Agile es un medio para maximizar revenue, gestionar riesgos y aprovechar oportunidad de mercado. Pero Agile no es un fin en sí mismo. Hay que tener cuidado de caer en la trampa de tener una lista de checks de si los equipos tienen tableros o no, si hacen dailies o no, si hacen retrospectivas o no, y quedarnos ahí. Cuidado con la vanidad de las métricas de actividad. (Aquí te dejo el enlace a nuestro Kanban Metric Layout por si te interesa)

Soluciones hay muchas y depende del contexto. Te puede ayudar:

  • Que la organización sepa hablar de “flujo” a todos los niveles. Y entiendan cómo funciona.
  • Tener métricas orientadas a flujo: Lead time, throughput, tiempo medio de bloqueo, etc.. en los equipos, y a nivel programa o portfolio.
  • Poner el foco en eficiencia de flujo en vez de en eficiencia de recurso.

Entendiendo el concepto de flujo, visión sistémica y usando correctamente el método Kanban se puede obtener un alto impacto en un tiempo reducido. Si quieres saber más:

  • Aquí puedes ver nuestra guía Kanban.
  • Aquí más posts sobre Kanban.

 

Beneficios de Management 3.0

¿Qué beneficios esperas obtener si empiezas a adoptar Management 3.0? ¿Quieres introducirlo porque está de moda – Management 2.0 – o lo haces porque realmente entiendes por qué surge, qué es y cuáles son sus principios guía?

Antes de profundizar en las prácticas que hay detrás de esta manera de ver a la organización con una perspectiva sistémica, es relevante que conozcas algunos de los posibles beneficios que puedes conseguir con su uso.

Platón y su caverna

Recientemente mi compañero Jero hizo uso en nuestra newsletter de la alegoría de la caverna de Platón. También voy a aprovechar este recurso, ya que cuando leí su entrada, me vinieron multitud de pensamientos representados por este mito.

Si te detienes a observar a las organizaciones que te rodean, estoy convencido de que verás que muchas de ellas están atadas al mundo de lo sensible, viven dentro de la caverna. Ven sombras y defienden su realidad o la realidad que les han hecho ver. Las cosas son como son y no se pueden cambiar, o peor aún, se pueden cambiar pero adaptemos el cambio a nuestra realidad, en lugar de adaptarnos nosotros al cambio. No es algo que introduzca yo, entre otros, ya lo dijo Charles Darwin en su día:

No es el más fuerte de las especies el que sobrevive, tampoco es el más inteligente el que sobrevive. Es aquel que es más adaptable al cambio.

Algo que posteriormente reafirmó Stephen Hawking, quien además de creer que este siglo sería el siglo de la complejidad, nos deleitó con esta frase:

La inteligencia es la habilidad para adaptarse al cambio.

En mi caso puedo garantizarte que he vivido dentro de la caverna durante bastantes años. Después empecé a caminar poco, viendo las sombras con perspectiva, pudiendo salir finalmente de la cueva. A día de hoy, aunque no me gustaría terminar como Sócrates, me siento en la obligación moral de volver a las “cavernas” y ayudar a otros entender que hay otro mundo además del sensible, que también existe el mundo de lo inteligible.

Para iniciar el camino anterior, me gustaría contarte algunos de los beneficios que puedes obtener a través de Management 3.0.

Beneficios

Son muchos los beneficios que puedes obtener al adoptar Management 3.0. Aunque lo intentase, estoy seguro que no sería capaz de describirte todos ellos, por un lado porque mi conocimiento y alcance no es ilimitado y por otro lado porque algunos son una consecuencia directa y otros indirecta que depende del contexto.

Por ello voy a describirte algunos de los que vivimos nosotros mismos, tanto en nuestra organización como en aquellas a las que acompañamos, de tal forma que tengas información de primera mano basada en nuestra experiencia.

  • Trabajadores más felices. Entendiendo por felicidad la suma del nivel de motivación e involucración.
  • Reducción de la tasa de rotación. Incrementando la retención de talento principalmente como consecuencia de establecer un modelo cultural que apuesta por las personas como principal activo de las organizaciones.
  • Aumento de la capacidad de captación de talento. Exactamente por lo mismo que en el punto anterior, esta capacidad se ve favorecida aportando ventaja competitiva a las organizaciones y sus equipos.
  • Autoorganización efectiva. Favoreciendo la madurez e independencia de los equipos evitando que la autoorganización lleve a cualquier sitio por medio de la definición de responsabilidades claras, objetivos compartidos y límites establecidos y explícitos.
  • Equipos efectivos. Permiten alcanzar niveles de alto rendimiento asentando los pilares de la motivación intrínseca, la autoorganización, la colaboración efectiva, los valores y el profesionalismo (ética, principios y prácticas de excelencia).
  • Organizaciones antifrágiles. Creando una Learning Organization pudiendo aprender continuamente de las situaciones más inesperadas.
  • Confianza y tranquilidad. Mejorando ambos puntos tanto por parte de nuestros Stakeholders (usuarios finales entre ellos) como de nuestros empleados, a través del empirismo y la entrega de valor.
  • Mayor agilidad de negocio. Maximizando el Retorno de Inversión, mejorando la Gestión de Riesgos y siendo más oportunistas en lo que respecta a la situación actual del mercado.

Si te interesa que profundice sobre alguno de los beneficios anteriores y que te indique al menos una técnica que te acerca al mismo, por favor, escribe un comentario en el artículo e introduciré tu petición en el flujo de publicación de próximos artículos.

¿Y ahora qué?

En muchas ocasiones salir de la caverna es un proceso complejo y complicado. Te doy la enhorabuena si te estás planteando hacerlo o si ya estás en ello. Si no es así, te animo a hacerlo. En cualquier caso, si quieres que te acompañemos paso a paso, para nosotros será un verdadero placer que hablemos sobre cómo recorrer el camino juntos, y que no se quede ahí, sino que seamos capaces de ver juntos la luz del Sol de la que tanto se enamoraron Sócrates y Platón.

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad