La empresa ágil de Alonso Álvarez, Sara Aguilera, Susana Jurado y Miquel Rodríguez

'La empresa ágil' es un libro divulgativo que proporciona una visión de lo que tiene que ver con los modelos ágiles (Agile) pero con un enfoque amplio que supera el nicho de Agile propiamente dicho entendido como modelo de gestión de proyectos para elevarlo a un enfoque empresarial que incluye también el emprendimiento, la innovación y el desarrollo de productos y servicios, alcanzando al final a toda la empresa a nivel de cultura, organización y operación.

Se trata de un planteamiento más en amplitud que en profundidad, donde se recorren todas los frameworks, filosofías y modelos relevantes aunque sin profundizar mucho en la explicación de cada uno de ellos.

El contenido se estructura en catorce capítuls, como sigue:

• '1. ¿Por qué Agile': Un breve capítulo introductorio que intenta justificar la necesidad del enfoque Agile, para lo que explica la visión VUCA del mundo actual, las olas de la innovación y su aceleración y desarrolla el elemento de complejidad de VUCA detallando el modelo de Cynefin de Dave Snowden.


• '2. Principios': Explica los fundamentos de la filosofía Agile. Cuenta el modelo PDCA (Plan, Do, Check, Act) del entorno industrial, las problemáticas específicas de los proyectos de desarrollo software y el modelo waterfall anterior a Agile. Luego explica el manifiesto Agile, tanto sus valores como sus principios. A continuación plantea tres olas en la adopción de agile (equipos ágiles, escalado y empresa ágil) y finaliza explicando en qué consiste Agile, tanto en sus aspectos de mentalidad como de método.


• '3. Lean-Agile': Vuelve sus ojos a Lean, un enfoque procedente de Japón y del mundo industrial pero muy presente en los planteamientos Agile. Habla de la mentalidad ('mindset') y de los principios de Lean y de los tipos de desperdicio que se identifican en Lean.


• '4. Scrum': Explica este framewrok, sin duda el más popular de Agile. Explica sus orígenes y fundamentos y luego desarrolla aspectos esenciales como los roles en Scrum, el proceso o mecánica de Scrum y algunas consideraciones sobre métricas.


• '5. Tableros Kanban': La explicación sobre Kanban se divide en dos capítulos. En este comenta exclusivamente la herramienta de tableros Kanban que ilustra con un sencillo ejemplo.


• '6. El método Kanban': Segundo capítulo dedicado a Kanban que ahora se centra en el método, explicando principios, prácticas, métricas y roles.


• '7. DevOps': Se torna los ojos ahora específicamente al mundo del software y al caso de DevOps, en cierto sentido, un subproducto o hijo del enfoque Agile en proyectos de desarrollo. Se habla de la filosofía DevOps, de la automatización y la entrega continua y de lo que DevOps puede aportar a la empresa ágil.


• '8. Otras prácticas y técnicas': Una panorámica de otros enfoques ágiles, entre los que describen brevemente Scrumban, DSDM (Dynamic Systems Development Mehod), XP (eXtreme Programming) y unas consideraciones sobre las pruebas en entornos ágiles.


• '9. Escalado': Dado que Agile promueve equipos pequeños, compenetrados y co-locados, en este capítulo se examinan planteamientos existentes para implantar la filosofía ágil a gran escala. Se explican marcos como SAFe (Scaled Agile Framework) al que se dedica bastante espacio, Nexus, LeSS (Large Scale Scrum), Scrum@Scale y se finaliza indicando que no es necesario elegir un framework estándar sino que cada empresa debe estudiar sus circunstancias específicas y escalar Agile de la forma más adecuada a su caso.


• '10. No se puede mejorar lo que no se mide': Un capítulo dedicado a la medida y las métricas. Describe las características que deben exhibir y algunas reglas a seguir. Hace una comparativa entre los KPI (Key Performance Indicators) más tradicionales y los OKR (Objectvives and Key Results) más propios de Agile. Y finaliza proponiendo una serie de métricas para la empresa ágil


• '11. Customer Development': Con este capítulo se inicia un cierto cambio de enfoque desde el Agile más nuclear, orientado a proyectos especialmente de desarrollo de software, a una visión más enfocada al emprendimiento, la innovación y el desarrollo de productos y servicios. Y se inicia explicando el Customer Development de Steve Blacnk, en qué consiste, sus etapas, su apoyo en el Business Model Canvas y la filosofía de salir de la oficina (Get Out Of The Building). Se finaliza explicando las catorce reglas de este método.


• '12. Lean Startup': Se aborda el método heredero natural de Customer Development: Lean Startup que supone, en esencia, el mix de Customer Development con Agile y que aunque el nombre sugiere su empleo en startups (como así es), también se usa cada vez más para el desarrollo de productos y servicios en empresas establecidas. Se explican algunos conceptos básicos como el de hipótesis y pivotaje, el producto mínimo viable (MVP) y los experimentos. Se explica el ciclo Lean Startup y se detallan una larga lista de posibles experimentos. Se finaliza hablando de métricas y de algunas herramientas como el lienzo de la proposición de valor o el Lean Canvas.


• '13. Design Thinking': Explica en qué consiste 'Design Thinking', su ciclo y varias herramientas empleadas agrupadas por fases: herramientas para explorar, empatizar y definir, herramientas para idear y herramientas para prototipar y probar. Finaliza razonando sobre cuándo se debería aplicar Design Thinking.


• '15. Gestión de la innovación': Habla de la innovación desde una perspectiva de gestión. Así, se abordan elementos de estrategia, de medición y de financiación. También se habla de la gestión del porfolio de productos y servicios y se explican algunos modelos de innovación. Finalmente, se comenta el concepto de organizaciones ambidiestras en que existen dos enfoques y modelos de gestión diferentes, uno para el negocio tradicional y otro para la innovación.


• '16. Personas y liderazgo': Torna los ojos hacia las personas y analiza, por ejemplo, los perfiles y características que deben tener las personas en las empresas ágiles y se comentan algunas herramientas para el crecimiento de las personas: formación, comunidades de práctica, hackathones, espacios abiertos, etc. También se habla del modelo de liderazgo adecuado para empresas ágiles y del modelo Management 3.0 de Jurgen Appelo, así como el denominado Agile HR, es decir, el traslado de la filosofía agil a los departamentos de recursos humanos.


• '17. Una nueva organización': Empieza hablando de equipos y silos y cómo deben ser los equipos ágiles. Y luego repasa algunos modelos alternativos de organización como son la sociocracia 3.0, la holocracia o las empresas líquidas. Finaliza con algún ejemplo de organización especial como el caso de Spotify, Morning Star o Zappos.


• '18. La empresa ágil: visión de conjunto': Intenta proporcionar una visión global, estudiando los ciclos de generación de valor y, sobre todo, como realizar la transformación hacia una empresa ágil, finalizando con una serie de consejos.


• '19. Agile no funciona': Repasa problemas que pueden surgir en entornos ágiles con posibles motivaciones y soluciones. Los agrupa en problemas a nivel de equipo, a nivel de organización y a nivel de productos y servicios.

'La empresa ágil' es un libro divulgatvo, fácil de leer y atractivamente ilustrado, del que podemos obtener, sobre todo, una visión abarcadora y estructurada de todos los modelos y herramientas propias del agilismo y plantamientos anexos o derivados. Algo así como un manual de referencia donde está todo lo relevante y explicado de una forma sencilla y comprensible aunque, si se quiere profundizar, se deba de acudir a otras fuentes que el libro señala también muy acertadamente.

Muy instructivo.

Alonso Álvarez

(Fuente: Ficha de autor en A un Clic de las TIC)

Alonso Álvarez

Experto en métodos ágiles: Scrum Master, Agile Coach; agilista convencido y entusiasta seguidor de estas innovadoras formas de trabajo. Profesional con casi treinta años de experiencia, desarrollados en su mayoría en Telefónica Investigación y Desarrollo, en campos como Cloud, Internet y Vídeo. Autor de 14 libros de temática técnica, el más reciente “Métodos Ágiles. Scrum, Kanban, Lean”, así como de unos cuantos artículos. Futurista aficionado, amigo del Cine y de pedalear al aire libre.

Puedes saber más del autor visitando su perfil en LinkedIn o seguirle en Twitter donde se identifica como @alalga

Sara Aguilera

(Fuente: Ligera elaboración propia de su perfil en LinkedIn)

Sara AGuilera

Asesora Agile y, anteriormente, líder la unidad global Agile de BBVA, Sara se declara entusiasta del trabajo en equipo, del trabajo bien hecho, de forma colaborativa y transparente.

Desde el 2014, año el que BBVA comenzó a aplicar Agile de forma continua, estuvo dedicada a realizar la transformación del Banco. En los últimos años ha tenido la oportunidad de aplicar ágil no sólo a nivel de equipo, también a nivel de programas y proyectos, en toda la organización. Y no sólo en España, si no también en México, Perú, Argentina, etc

Ha sido creadora de los planes de formación corporativa del BBVA para alinear la metodología. Impulsora del cambio en todas las unidades de BBVA (Finanzas, Riesgos, etc), en los que introducir Agile también tiene múltiples beneficios.

Aplicación de Design Thinking al proceso ágil para sacar los máximos beneficios.

Sara es licenciada en informática por la Universidad Politécnica de Madrid y ha tenido las certificaciones PMI / ACP y SAFe Program Consultant.

Puedes saber más sobre él visitando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @SaraAguilera_)

Susana Jurado

(Fuente: Ficha de autor en la solapa del libro 'La empresa ágil)

Susana Jurado

Susana Jurado es Ingeniera de Telecomunicación y Executive MBA por la IE Business School. Gran parte de su carrera profesional se ha centrado en la innovación, y durante los últimos años, en los campos de la estrategia, metodologías y gestión de la innovación.

Es una apasionada y evangelizadora de la metodología Lean Startup y Customer Development desde 2012. Es coautora del libro 'La empresa ágil' y autora o coautora de varios white papers y un caso de estudio para la Harvard Business Review sobre la aplicación de Lean Startup y el intraemprendimiento en grandes organizaciones. También ha sido ponente en diversas conferencias internacionales.

Puedes saber más de la autora visitando su perfil en LinkedIn o seguirla en Twitter donde se identifica como @sjapru

Miquel Rodríguez

(Fuente: Ligera elaboración propia sobre la ficha de autor en la solapa del libro 'La empresa ágil)

Míquel Rodríguez

Míquel Rodríguez ha dedicado más de veinte años de su vida profesional a capacitar personas y organizaciones para crear mejores productos y servicios. Considera que la formación es su 'ikigai', y en ella mezcla profesión, pasión, misión y vocación. Ha impartido más de 10.000 horas de formación en diferentes y empresas y universidades tanto en Europa como en Estados Unidos. Después de su paso por varias consultoras tecnológicas en la era de las .com y de trabajar como freelance durante ocho años, se incorporó al equipo de Netmind como director de consultoría y agilidad para liderar servicios de valor añadido y transformación organizacional.

Actualmente colabora con todo tipo de organizaciones , desde grandes corporaciones a startups, para impulsar mejoras organizacionales y transformaciones ágiles. Colaborador habitual en el Knowledge Center de Netmind con artículos y vídeos.

Miquel tiene un grado en Computer Engineering por la Universidad Autónoma de Barcelona en 1997, un Máster en gestión de TI por la Universidad Ramon Llull en 2003, un Executive MBA también por la Universidad Ramon LLull en 2007 y un Programa Ejecutivo en ESADE sobre Design Thinking y Business Innovation. Además tiene la certificación SPC 4.0 - SAFe Program Consultant. Es co-autor del libro 'La empresa ágil'.

Puedes saber más sobre él visitando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @miquelrodriguez)

Ficha técnica:

TITULO: La empresa ágil

AUTOR: Alonso Álvarez, Sara Aguilera, Susana Jurado y Miquel Rodríguez

EDITORIAL: Anaya Multimedia

AÑO: 2019 

ISBN: 978-8441541917
PAGINAS: 392

Artículos de este blog relacionados

• Una receta sencilla sobre la delegación de decisiones
• Métricas y comportamiento
• 'Postureo' ágil
• No, Agile no significa ir más rápido
• Estructurando la complejidad de los problemas: el framework Cynefin

El sentimiento de propiedad de la transformación

Cuando una empresa, especialmente una gran empresa, acomete una transformación de negocio, sea ésta transformación una transformación digital o de otro tipo, es práctica frecuente recurrir a los servicios profesionales de terceros, normalmente consultoras estratégicas o tecnológicas.

Y esta forma de actuar tiene su lógica. 

Recurrir a servicios de terceros tiene la ventaja de importar conocimiento especializado del que, probablemente, carezcas en tu empresa. Además, los consultores externos pueden aportar una cierta dosis de objetividad y, finalmente, una dedicación que quizá el equipo de plantilla no pueda conseguir.

Sin embargo, dejar en exceso en manos de terceros el pilotaje de una transformación también tiene peligros, serios peligros.

Por una parte, si la consultora no logra (a lo mejor ni siquiera lo intenta) transferir a tu empresa el conocimiento especializado o los nuevos procesos, métodos o prácticas creados , ese conocimiento, y con él la transformación realmente, desaparece con la consultora. Y tu empresa se queda igual que antes del proyecto, "compuesta y sin transformación".

Un poco a este peligro es al que se refieren Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez en su libro 'La empresa ágil' cuando, hablando evidentemente en este caso de una transformación a Agile, e intentando valorar los pros y contras de adoptar un equipo interno o externo para esa labor, nos dicen:

Desconfía de quien te ofrezca una transformación "llave en mano", que proporcione las personas y roles y que luego deje la empresa sin haber garantizado la continuidad.

Pero yo quisiera destacar, no sólo el aspecto más relacionado con el conocimiento y los métodos, sino otro que tiene que ver con la gestión del cambio y el sentimiento de propiedad.

Si el peso de la transformación recae sobre los hombros de una consultora, no es ya sólo que los empleados de tu empresa no aprendan bien los resultados de esa transformación, sean estos herramientas, procesos o lo que sea, es que tampoco se involucrarán, tampoco los sentirán como algo propio. Se verá la transformación como "el proyecto de otros", como algo ajeno, puede que incluso como algo de lo que desconfiar, a lo que ignorar, temer o combatir.

Y esa es, sin duda, la peor de las recetas para triunfar en una transformación.

La transformación, digital o como sea, debe tener sentido estratégico, debe de ser beneficiosa en términos de posición competitiva, de experiencia de cliente o de eficiencia, pero, para que triunfe, además de esos valores objetivos, debe generar ilusión, motivación y complicidad, debe ser ser sentida como propia y como valiosa por toda la organización.

Y entonces sí que será imparable.

La Biblia de Ethereum con Andreas Antonopoulos y Gavin Wood

'Mastering Ethereum' se puede considerar en el momento en que escribo esto (Diciembre de 2019) como 'la Biblia' de Ethereum, no sólo por lo que el libro aporta en sí mismo, que es mucho, sino también por la autoridad de los dos autores.

Se trata de un libro que, aunque muy ordenado y muy bien explicado, presupone, en el fondo, unos conocimientos teóricos y prácticos bastante sólidos sobre tecnología software.

El libro, tras incluir un glosario inicial de términos, se estructura en catorce capítulos:

• '1. What is Ethereum?: ' Define lo que es Ethereum, lo compara con Bitcoin, hace una breve singladura histórica y luego explica algunos conceptos relevantes como 'Turing completeness' o las aplicaciones descentralizadas (DApps).


• '2. Ethereum Basics: ' Explica la 'moneda' de Ethereum, el ether y el wei, proporciona algunos criterios sencillos para elegir un wallet y, usando MetaTask, desarrolla un ejemplo sencillo que incluye cosas como la creación de un Wallet o el envío de divisas (ether). También explica la división entre las EOA ('Externally Owned Accounts) y los Contratos y muestra un ejemplo sencillo de creación de un contrato e interacción con él.


• '3. Ethereum Clients: ' Comienza definiendo lo que es un cliente Ethereum, luego explica algunos aspectos del funcionamiento de las redes P2P blockchain y las opciones para elegir una red u otra (incluyendo las de prueba). También ejemplifica el uso de Clientes con el caso concreto de Geth (Go-Ethereum).


• '4. Chriptography: ' Un capítulo importante y complejo en que se explican conceptos de criptografía desde su base, antes incluso de blockchain y Ethereum. Se nos cuenta qué son las claves y qué una dirección Ethereum, se explican con brillantez los sistemas de PKI, el cálculo de los hashes, y aspectos de protocolo y codificación.


• '5. Wallets: ' Explica el concpeto de wallet, los tipos deterministas y no deterministas y algunas buenas prácticas.


• '6. Transactions: ' Se explica lo que es una transacción y su estructura, poniendo especial cuidado en dejar claro lo que es el Nonce. Luego explica el concepto, funcionamiento y motivaciones del 'gas' que se consume en las transacciones. También se desarrollan otras ideas importantes como la transacción especial para crear contratos, la firma digital o la propagación de transacciones


• '7. Smart Contracts and Solidity: ' Se explica lo que es un smart contract y su ciclo de vida. Luego se hace una introducción a los lenguajes de alto nivel para la definición de smart contracts en Ethereum. A continuación se concentra en el lenguaje Solidity, del cual es creador Gavin Wood, uno de los autores del libro, y con base en ese lenguaje se desarrolla un ejemplo bastante completo de creación y uso de un smart contract.


• '8. Smart Contracts and Vyper: ' Un capítulo corto en que se usa otro lenguaje de alto nivel diferente: Vyper.


• '9. Smart Contracts Security: ' Un capítulo largo y complejo pero muy interesante en que, aparte de proporcionar algunas buenas prácticas, se estudia, con base en casos reales, patrones y anti-patrones de uso de smart contracts en relación con la seguridad.


• '10. Tokens: ' Se explica el importante, pero al tiempo algo etéreo concepto de token, los tipos habituales y cómo se usan. También se comentan con cierto detalle los estándares existentes en relación con los tokens y criterios sobre por qué y cuándo usarlos.


• '11. Oracles: ' Se explica qué son los oráculos (Oracles) y por qué se necesitan y se comentan también algunos patrones de diseño y aspectos específicos como la autenticación de datos, los oracles de sólo computación y los oracles descentralizados.


• '12. Decentralized Applications (DApps): ' Explica el concepto de las aplicaciones descentralizadas, cómo éstas van mucho más allá que los contratos inteligentes (que sólo descentralizan la lógica de control y funciones de pago) y ejemplifica los conceptos desarrollando un ejemplo de DApp.


• '13. The Ethereum Virtual Machine: ' Un capítulo bastante tecnológico en que se explica el concepto de máquina virtual para luego contar diferentes aspectos de la máquina virtual Etehreum, como su juego de instrucciones o la gestión del estado. También en este caso dedica amplio espacio a ejemplificar los conceptos con un ejemplo concreto con un contrato inteligente.


• '14. Consensus: 'Explica el concepto de consenso, por qué es necesario y los dos grandes tipos de algoritmos de consenso: Proof of Work (PoW) y Proof of Stake () y se explica que de cara al futuro, Ethereum apuesta por PoS pero que actualmente usa PoW y, en concreto, el algoritmo Casper del cual se explica alguna idea adicional.

Antes de finalizar, el libro ofrece hasta seis anexos con la historia de los 'forks'(ramificaciones), estándares, uso de gas estimado en cada una de las operaciones de la máquina virtual, herramientas, un tutorial de la librería web3.js y, finalmente, un listado de enlaces.

'Mastering Ethereum' es un magnífico libro, basado en un enorme conocimiento teórico y práctico, muy cuidadoso y riguroso en las definiciones y conceptos, muy bien estructurado, bien explicado (aunque, personalmente, echo de menos más gráficos que simplifiquen la comprensión) y con abundantes ejemplos de código y herramientas. Eso si, a pesar de todos esos méritos, no es un libro sencillo de leer, salvo para desarrolladores especializados, pero no creo que sea culpa de los autores sino de que las ideas que cuenta son, en sí mismas, complicadas. Hacer el libro más sencillo, creo, sería con el coste de explicar menos y con menos rigor.

En resumen, un libro excelente, pero para especialistas o para valientes.

Andreas M. Antonopoulos

(Fuente: Wikipedia)

Andreas M. Antonopoulos

Andreas M. Antonopoulos (nacido en 1972) es un defensor del bitcoin griego-británico.​Es presentador en el podcast "Let's Talk Bitcoin"​y profesor en el programa de maestría de Moneda digital de la Universidad de Nicosia.

Antonopoulos obtuvo el grado en Ciencias de la Computación, Comunicación de Datos y Computación Distribuida de la University College de Londres. Dio servicios de consultoría a diversas empresas en torno a temas de código abierto y redes abiertas en 1990.

Es autor de más de doscientos artículos publicados en forma impresa y distribuidos en todo el mundo.

Como socio de Nemertes Research, Antonopoulos investigó la seguridad informática, afirmando que la mayor amenaza para la seguridad informática no eran los hackers experimentados, sino los sistemas demasiado complejos que resultaban de un cambio rápido en los negocios.

En 2012 Antonopoulos se enamoró de bitcoin. Eventualmente abandonó su trabajo como consultor independiente y comenzó a hablar en conferencias sobre bitcoins, empezó a realizar consultoría en torno a Bitcoin para nuevas empresas, así como a escribir artículos en torno a bitcoin sin remuneración económica.

De acuerdo a su podcast, Antonopoulos es consultor en varias startups relacionadas con bitcoin. Se desempeñó como jefe del comité contra la pobreza de la Fundación Bitcoin hasta 2014, cuando renunció citando la falta de transparencia de la fundación como razón de su renuncia.

En marzo de 2016, Antonopoulos lanzó la primera edición del libro Mastering Bitcoin, en versión impresa y en línea.

Puedes saber más del autor visitando su perfil en LinkedIn o seguirle en Twitter donde se identifica como @aantonop

Gavin Wood

(Fuente: Traducción y ligera elaboración propia de Wikipedia)

Gavin Wood

Gavin Jame Wood nació en Abril de 1980 y es un programador británico que es co-fundador y antiguo CTO de Ethereum.

En Agosto de 2014 propuso Solidity, un lenguaje de programación orientado a contratos para escribir 'smart contracts'. Es el fundador y antiguo CTO y presidente de Parity Technologies que liberó la Parity Bitcoin technology stack. También fue el autor del artículo Polkadot.

Cursó sus primeros estudios en la Lancaster Royal Grammar School, se graduó en la Universidad de York con un Máster en Ingeniería de Sistemas de Computadora e Ingeniería de Software en 2002 y completó su doctorado en Ciencia de los Computadores en la Universidad de York en 2005 con una tesis titulada "Content-based visualisation to aid common navigation of musical audio". La tesis condujo directamente a Moonbar, un visualizador estático de música usado en varias importantes aplicaciones de música del escritorio Linux.

Puedes saber más sobre él visitando su página oficial o siguiéndole en Twitter donde se identifica como @gavofyork)

Ficha técnica:

TITULO: Mastering Ethereum

AUTOR: Andreas M. Antonopoulos y Gavin Wood

EDITORIAL: O'Reilly

AÑO: 2018 

ISBN: 978-1491971949
PAGINAS: 385

Artículos de este blog relacionados

• Blockchain como una gigantesca máquina virtual
• Los ocho componentes de una blockchain pública y los ocho componentes de Ethereum

Una receta sencilla sobre la delegación de decisiones

Lejos quedan ya, al menos en teoría, los tiempos en que predominaba el estilo de liderazgo cohercitivo, aquel del 'ordeno y mando' en que el líder, o mejor, el jefe, tomaba todas las decisiones.

Los modernos modelos organizativos y de liderazgo buscan organizaciones más planas y mayor autonomía de las personas y equipos, mayor delegación de funciones y decisiones.

Hay buenas razones para ello.

Por un lado es mucho más eficiente. Centrar todas las decisiones en una persona supone, hablando en términos de proceso, un clarísimo cuello de botella y un punto único de fallo, dos elementos a evitar en cualquier actividad empresarial con una lógica aseptica y de pura eficiencia.

En el otro extremo, el más humano, la delegación supone un mayor aprovechamiento de todo el talento y el conocimiento existente en la organización y que es imposible que el líder atesore por sí mismo.

Finalmente, la participación en las decisiones por parte de una capa amplia de empleados, supone un elemento de involucración y motivación.

Sin embargo, intuitivamente, parece que existen decisiones que por su calado o por su dificultad deben ser tomadas en las altas instancias de una empresa.

¿Cómo saber cuando delegar y cuándo escalar una decisión?

Creo que, en general, depende un poco del caso y del sentido común pero quería recoger una receta sencilla que se menciona en el libro 'La empresa ágil' de Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez. En él encontramos esta cita:

Debe delegarse o dejarse en manos de quien ejecuta la acción cuando es muy frecuente, hay poco tiempo para tomarla o requiere acción local y escalar (o subir a una instancia superior) cuando es poco frecuente, tiene un muy alto impacto o requiere una visión global o de largo alcance.

Agile es una filosofía de trabajo que, en efecto, pone mucho foco en el equipo y en la autonomía de los equipos para autogestionarse. Se trata, pues, de una filosofía de trabajo que promueve una delegación casi diría que masiva.  

Y la receta que se propone parece puro sentido común: delegar decisiones frecuentes, locales o rápidas. 

Buen criterio.

Colaboración: "Robots en la oficina" en Invertia

La semana pasada se publicó en 'Empresa Digital', mi columna de opinión en el portal financiero Invertia, mi artículo "Robots en la oficina".

En él, de una forma que espero sencilla, describo las características de los robots que pueblan cada vez más el software de escritorio y que automatizan procesos administrativos, de prestación de servicios o, si se quiere, de oficina.

Hablo fundamentalmente de RPA (Robotic Process Automation) y de bots conversacionales. 

Si quieres acceder al artículo original, lo puedes encontrar siguiendo este enlace.

Métricas y comportamiento

A estas alturas ya es de reconocimiento general que para gestionar un negocio casi cualquier actividad de forma eficiente y práctica, es necesario medir de alguna forma esa actividad y sus resultados, hacer un seguimiento de esas medidas y una actuación caso de que las medidas nos indiquen que el negocio o la actividad no discurre por la senda que deseamos.

Aunque quizá con menos nivel de implantación del que cabría suponer, y sobre todo con menor nivel de automatización del posible y deseable, sí parece que en general las empresas, especialmente las de cierto tamaño, disponen se una serie de medidas e indicadores de negocio que podemos esperar hayan recogido en los llamados KPI (Key Performance Indicator) y, quizá, hayan articulado el conjunto de los indicadores principales en un Cuadro de Mando. Esos indicadores serán en general cantidades numéricas y medibles, si es posible de forma automatizada.

¿Para qué queremos las métricas?

Diría que las medidas e indicadores tienen dos misiones fundamentales:

• Foto de situación: es decir, presentar de una forma relativamente sencilla, manejable, rápida y objetiva, cual es la situación de nuestra actividad, de nuestro negocio en un momento dado y su evolución en el tiempo.


• Orientar el comportamiento y la acción: es decir, dar pistas de hacia dónde debemos orientar la acción tanto directiva como de todos los empleados de la compañía.

Para la segunda misión, es decir, para orientar el comportamiento, aparte de la pura medida, del indicador, se hace necesario, o al menos esa es la práctica habitual, el establecimiento de unos objetivos, es decir, de unos valores a alcanzar en esa medidas o indicadores.  

Hasta aquí todo parece perfecto, correcto, casi inapelable.

Problemas con las métricas

Pero lo cierto es que la práctica demuestra que con mucha frecuencia, una aplicación estricta de estas ideas conduce a comportamientos indeseables. ¿Por qué? Porque en el fondo, una indicador mide un fenómeno subyacente y el comportamiento y objetivo que queremos orientar es el subyacente. SIn embargo, una excesiva presión en el indicador hace que el número, el indicador, que en realidad es algo superficial, se convierta en el verdadero objetivo, en lugar de el comportamiento subyacente.

En esa línea se encuentran Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez cuando en su libro  'La empresa ágil'. y hablando de métricas en relación con la filosofía Agile, afirman:

puede ocurrir que la métrica se convierta en el objetivo y no el comportamiento que queremos promover.

Si eso suena muy abstracto, esperemos aclararlo con dos ejemplos. 

En el caso de un centro de atención al cliente, en general, y por motivos de eficiencia y escala, consideraremos deseable que la atención sea lo más rápida posible. Y eso es correcto. Pero si por ello establecemos un KPI que sea el tiempo medio de la atención y ponemos mucha presión en conseguir un objetivo exigente, los operadores tenderán a cerrar la conversación casi inmediatamente y ante problemas complejos del cliente, tenderán a desbordar a otras unidades, o a cerrar en falso la atención sin realmente entender o resolver el problema. En este caso, ese objetivo de atención rápida debería verse compensado, y con mayor peso, por otro objetivo relacionado con la calidad de la atención y la efectividad de la respuesta. El comportamiento subyacente es la buena y rápida atención, pero la presión en el indicador de tiempos ha hecho que los operadores y sus coordinadores sólo se fijen en cerrar las llamadas (y tickets asociados) de la forma más rápida posible con independencia de la atención propiamente dicha.

En el caso de una fuerza de ventas, es práctica común establecer unos objetivos de ventas anuales. El comportamiento subyacente deseado es vender cuanto más mejor, evidentemente. Sin embargo, la medida de las ventas por periodos anuales y el establecimiento de objetivos y recompensas en periodos anuales, puede llevar a comportamientos no deseados. Así, por ejemplo, si un vendedor se encuentra a mediados de Diciembre con sus objetivos anuales de ventas ya cumplidos y le surge una oportunidad con un nuevo cliente ¿qué hará? Pues no sería extraño que intentarse 'estirar la goma' de forma que el contrato con ese nuevo cliente se firmase ya en Enero del año siguiente, es decir, en un nuevo periodo anual y así empezar a aportar al cumplimiento del año siguiente. Al fin y al cabo, este año ya ha cumplido el objetivo. ¿Es ese el comportamiento deseado por la empresa? Sin duda, no. La empresa quiere vender cuanto más mejor y cuanto antes...pero el indicador y sobre todo el objetivo promueve un comportamiento inadecuado.

En busca de soluciones. Los OKR

No tienen fácil solución este tipo de problemáticas. Diría que hay que poner el máximo cuidado en el diseño de los indicadores para que modelen realmente lo que queremos medir y conseguir. Diría, además, que hay que prever que unos indicadores compensen efectos unilaterales de otros (como en el caso del call center, la medida de la calidad de la atención compensaría el foco en cerrar rápidamente la interacción). Pero, sobre todo, creo que es necesario aplicar por parte de los gestores mucho sentido común a la hora de valorar y sobre todo recompensar  a los empleados con base en indicadores y cumplimiento de objetivos.

En el ámbito Agile, los autores mencionados, nos hablan de la nueva tendencia en el uso de los OKR (Objectives and Key Results) que, en el fondo, son tan indicadores como los KPI pero la diferencia, según la entiendo, cae más en el ámbito de su gestión y filosofía subyacente. Así, según nos explican, y al igual que los KPIs, los OKR son medibles, ambiciosos y simples, pero, sin embargo, no van a acompañados de un valor objetivo, sino que lo que se mide son crecimientos en el sentido adecuado (no hasta un valor concreto). La idea es poner el foco en el comportamiento subyacente, y no tanto en alcanzar un valor numérico concreto.

Mis conclusiones

Personalmente, apostaría por medir, medir mucho (por cierto, de forma automatizada) y tener al día todas las medidas relevante para tener un conocimiento cierto y objetivo de cómo va el negocio. Pero, sin embargo, relajaría, y mucho, la presión sobre objetivos y sobre todo, evitaría que las evaluaciones y recompensas se basasen en ellos, o al menos exclusiva y matemáticamente en ellos. 

Y no porque en teoría no sea correcto, objetivo e interesante la medición, el seguimiento de objetivos y evaluación de desempeño. Sino porque, en la práctica, es muy difícil, casi imposible, conseguir unos indicadores y unos objetivos tan bien definidos y medidos, tan perfectos, que reflejen exactamente la realidad, que promuevan exactamente los comportamientos que deseamos sin ninguna desviación y que aporten una valoración absolutamente fiel del desempeño de los profesionales. 

Así que, y quizá por desgracia, debamos aplicar el sentido común y algunos criterios también cualitativos a la hora de evaluar desempeños. 

'Postureo' ágil

La moda es un arma de doble filo.

Y no me refiero a la moda que afecta a nuestro modo de vestir, a las canciones que escuchamos o la forma en que nos peinamos. Me refiero a la moda que afecta a tecnologías y metodologías en el mundo de los negocios.

Una moda que hace que una cierta tecnología o disciplina empiece a aparecer de forma abundante, incansable, casi cansina, en artículos, white papers, eventos profesionales, posts y tuits. Una moda que, en el ámbito de la tecnología, la podemos contemplar hoy en día, por ejemplo, en todo lo que rodea a la inteligencia artificial o a blockchain.

Y una moda que en el ámbito de las metodologías o disciplinas de gestión la podemos encontrar, por ejemplo, en el entorno ágil (Agile).

La moda tiene su parte positiva. Hace que esa tecnología o disciplina sea conocida por el gran público (aunque probablemente no entendida), aumenta su visibilidad y posibilidades comerciales y, quizá mas interesante, aumenta su capacidad de atraer inversiones y talento.

Sin embargo, existe otra cara de la moneda. La moda hace que la tecnología o disciplina se explique mal, se la deforme, por ignorancia o interés, con frecuencia alejándola de su verdadero significado, estado y capacidad actuales. Peor aún, la moda puede hacer que se adopte una tecnología o una disciplina sin saber muy bien por qué y si tiene sentido, sólo porque es lo que se supone que hay que hacer, lo que dicen los expertos, lo que se dice que todo el mundo hace... aunque no se sepa muy bien ni por qué ni para qué.

Y eso lleva a consecuencias, la menor de las cuales puede ser la decepción, y la mayor pérdidas económicas y quizá competitivas o de empleo.

Es tan frecuente el fenómeno que, por ejemplo, en el ámbito tecnológico, esa dinámica ha sido caracterizada por Gartner en su famoso 'Hype cycle' con su también famosa 'cresta de las expectativas infladas' y su famoso 'valle de la desilusión'.

En el ámbito de las metodologías o disciplinas de gestión, está de moda, a pesar de su ya avanzada edad, la filosofía Agile. Y, claro, como está de moda, todas las empresas que quieren 'fardar' de modernas e innovadoras, adoptan o dicen adoptar ese enfoque Agile. Y adoptar Agile está muy bien si se ha entendido el porqué surge, qué tipo de problemáticas aborda, cuándo es interesante y cómo se implementa correctamente.

Lo peligroso es adoptar Agile porque está de moda, o porque, erróneamente, su nombre nos hace pensar que es una disciplina que nos hace ir rápido. Lo peligroso es adoptar Agile sin conocimiento ni rigor, como un mero 'postureo'.

Aunque no usando esta palabra coloquial, en esa línea va la advertencia que Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez lanzan en su libro  'La empresa ágil'. cuando hablando de Scrum, el framework Agile más popular, nos dicen:

El principal riesgo de Scrum es que se convierta en un modo de dar un "barniz ágil" a una actividad predictiva o tradicional, consiguiendo lo peor de ambos mundos.

Y no es advertencia baladí. Sucede, vaya que si sucede...

En mi libro 'La Carrera Digital' apuesto decididamente por el conocimiento y el método y bajo el paraguas de estos atributos abordo, respectivamente, la parte de tecnología y la de gestión que caracterizan a la transformación digital. El conocimiento de la tecnología, de sus fundamentos y de lo que puede aportar a nuestro negocio. Y el método para la aplicación seria de disciplinas de gestión especialmente en el ámbito del análisis estratégico y la dirección de proyectos. Y conocimiento y método los agrupo a su vez bajo la idea fuerza del rigor. 

Un rigor que resulta imprescindible para aplicar adecuadamente la tecnología y gestionarla como conviene. Un rigor que es el contrapeso de la moda. Un rigor que sirve para seleccionar con criterio las mejores opciones tecnológicas y a gestionar con fundamento su implantación. Un rigor que, en fin, nos pone a salvo del 'postureo'.