Mostrando entradas con la etiqueta Agile. Mostrar todas las entradas
Mostrando entradas con la etiqueta Agile. Mostrar todas las entradas

jueves, 21 de noviembre de 2024

Patrones subyacentes metodológicos y analíticos. El uso consciente de las herramientas y modelos

Después de bastante tiempo publicando artículos que, con alguna excepción en forma de reseña de libros, tenían que ver con la inteligencia artificial y/o la robótica, hoy voy a cambiar momentánea y brevemente de tercio para hablar de análisis, metodología y rigor.

Habitualmente veo, incluso en entornos académicos, usos o entendimientos incorrectos de herramientas, metodologías o enfoques de trabajo de naturalezas diversas pero que, de una forma u otra, caen dentro del ámbito de la gestión empresarial.

Me refiero a conceptos o herramientas como un simple DAFO, o un modelo de negocio o enfoques como 'agile' o 'design thning'.

Términos que tienen en común haber hecho fortuna en el mundo empresarial, enseñarse con frecuencia en el ámbito universitario o de posgrado, y estar muy presentes en medios más o menos especializados (en este caso a lo mejor habría que enfatizar lo del 'más o menos'). Y, como ya he comentado en algún otro post y a propósito de algún tema diferente, esa popularidad tiene una doble cara o es un arma de doble filo. Por un lado es bueno, ayuda a que se propague y se aplique, y por otro lado es malo, porque favorece el uso frívolo y descuidado del término, la herramienta o la metodología.

A mi, que valoro el conocimiento y el rigor y que me he preocupado de autoformarme en todos esas herramientas y enfoques que menciono, debo confesar que me enerva un tanto ese constante empleo frívolo, superficial e incluso ignorante de esos  nombres, herramientas y métodos.

Pero ayer vino a mi mente una reflexión algo más positiva, que me pareció interesante y que motiva este post.

El caso es que tuve ocasión de leer un uso, para mí algo 'cogido por los pelos' del término design thinking. Y pensando el porqué de ese uso, se me ocurrió una explicación diferente, y algo más positiva que la pura ignorancia y superficialidad.


Metodologías y patrones


Esa reflexión me lleva a distinguir, en cada enfoque metodológico o herramienta de trabajo, dos niveles.



Por un lado está lo que es la herramienta o metodología propiamente dicha, la que alumbraron sus creadores, generalmente conocidos gurús de la gestión, la que está bien analizada, documentada, explicada y a la que debemos referirnos para un discurso y una práctica rigurosos. A este nivel, y aunque el término quizá resulte algo aburrido y 'viejuno', lo voy a denominar metodología, ya que no se me ocurre un término más atractivo y moderno.

Pero por debajo de la metodología rigurosa, hay una serie de fundamentos, principios básicos o patrones de comportamiento, más difusos quizá, más laxos e indefinidos quizá, pero también más generales y que permiten su aplicación en entornos diferentes de aquellos para los que fue pensada la metodología inicialmente. Éstos serían los patrones subyacentes.

Lo que creo que sucede es que, en muchos casos, las personas no bien formadas, no bien advertidas, pero que 'han oído campanas', se quedan con dos cosas: por un lado, el nombre 'oficial' de la metodología, que en realidad se refiere al nivel superior y, por otro, a los patrones o principios básicos, que son el nivel inferior pero más general.

Y luego aplican los principios básicos, pero dándoles el nombre de la metodología.

Y así, se habla de un DAFO (cuando realmente no es un verdadero DAFO pero sí usa sus principios, sus patrones) o de un design thinking que, realmente, no es un 'design thinking pero que emplea sus principios y patrones.

Por si dicho así suena muy abstracto, lo concreto en cuatro herramientas o enfoques metodológicos muy populares y con frecuencia mal usados.


Análisis estratégico: el DAFO


Metodología


El DAFO es una muy bien conocida herramienta de análisis estratégico. El DAFO, como metodología (nivel superior), se aplica a una empresa u organización y adopta dos visiones: una externa (Amenazas y Oportunidades) en que se mira al mercado y al contexto, y otra interna (Fortalezas y Debilidades) en que se analiza la situación y competencias de la propia organización. Tanto para el análisis interno, como para el externo, se mira tanto lo bueno (Oportunidades y Fortalezas) como lo malo (Amenazas y Debilidades).

Hecho este análisis estratégico, la empresa puede identificar sus opciones estratégicas y elegir, con cierto conocimiento de causa, la mejor

Así concebida es, como digo, una herramienta de análisis estratégico y aplicada a una empresa o una organización

Sin embargo, la veo con frecuencia aplicada a un proyecto concreto, incluso de no mucho alcance, dentro de una organización. Estrictamente hablando, eso es incorrecto


Patrones subyacentes


Los patrones subyacentes al DAFO son esa doble mirada interna y externa, por un lado, y la otra doble mirada: positivo-negativo.

Y así considerado, en realidad, podríamos aplicarlo a otros muchos ámbitos. Por ejemplo, se habla en ciertos entornos, de un DAFO personal, y creo que ahí, si sabemos bien lo que estamos haciendo, podría llegar a tener bastante sentido. Me encaja menos aplicarlo a lo que he dicho más arriba, proyectos, pero, de nuevo, sabiendo lo que se hace, podría llegar a ser admisible.

Probablemente el DAFO sea una de las herramientas más sencillas y flexibles, con unas patrones más claros y que la habilitan con más facilidad que otras a aplicarla fuera de su verdadero entorno que recuerdo, de nuevo, que es el análisis estratégico.


Modelo de negocio: el Business Model Canvas


Metodología


El Business Model Canvas es una herramienta omnipresente en la literatura actual de gestión empresarial y, especialmente, de innovación y emprendimiento. Se trata de una herramienta para describir un modelo de negocio y, con base en esa descripción, poder adoptar posibles decisiones sobre el mismo. Ese es su objeto, aunque parece también muy ligado al emprendimiento y la innovación, precisamente porque, y tal y como definen reputados autores, una startup lo que está buscando es un modelo de negocio rentable y sostenible y, por tanto, necesita describir y analizar ese modelo de negocio y trabajar sobre él.

Pero he visto usar también el Busines Model Canvas para un proyecto, un simple proyecto, ni siquiera especialmente transformador, en una empresa establecida con un modelo de negocio establecido... y que el proyecto no va a modificar. Y eso no es muy correcto.


Patrones subyacentes


El Busines Model Canvas tiene unos patrones menos claros y externalizables que el DAFO, pero podríamos identificar la necesidad de una triple mirada: por un lado hacia el mercado (clientes, proposición de valor, canales y relaciones), por otro hacia la parte operativa (actividades, recursos y socios) y finalmente hacia la económica (flujos de ingresos y estructura de costes).

Y, quizá, podríamos decir que los propios cuadrantes que hay dentro de cada una de esas miradas, nos confecciona una especie de checklist de cosas a tener claras en una organización.

El Business Model Canvas es una herramienta muy popular y muy útil, pero que creo que no se extiende fácilmente fuera de su entorno natural que es el modelo de negocio de una empresa, o de una unidad de negocio dentro de ella o incluso de una línea de productos dentro de ella.

Si lo aplicas a un proyecto, creo que solo podría tener sentido en proyectos más o menos ambiciosos y transformadores y no tanto por el proyecto propiamente ducho sino para saber cómo el modelo de negocio condiciona al proyecto o cómo, caso de ser realmente transformador, el proyecto impacta en el modelo de negocio.


Dirección de proyectos: Agile


Metodología


Quizá uno de los términos más usados, y con frecuencia de manera incorrecta o con una valoración incorrecta, es el de 'agile'. Aunque a los fanáticos del agilismo les repele que se le denomine 'metodología' y prefieren hablar de 'framework', creo que aquí opto denominarla metodología, siguiendo los dos niveles explicados más arriba y, en concreto, del ámbito de la dirección de proyectos. Una metodología surgida en el mundo del desarrollo software, aunque luego ha hecho fortuna yendo más allá y aplicándose a otros muchos tipos de proyectos e impregnando metodologías de innovación y emprendimiento como 'lean startup'.

Aunque como metodología, en efecto, agile es 'laxa', los enfoques agile como scrum definen sus roles, sus herramientas, sus ceremonias...

La verdad es que creo que en el caso de 'agile', su mal uso se debe casi siempre a superficialidad y a ignorancia de todos esos detalles, pero de todas formas, creo que exhibe patrones muy claros,  muy útiles y muy exportables más allá de su ámbito natural.


Patrones subyacentes


El patrón más claro, y en el fondo definitorio, es el de el crecimiento iterativo y adaptativo, crecimiento y adaptación tanto en la definición del propio alcance del proyecto como en el desarrollo y entregables del mismo. Y un crecimiento y adaptación que, un poco, se mueven por una especie de ensayo y error, especialmente cuando trasciende el mundo del software y se centran en innovación.

Esa visión adaptativa e iterativa es la que lo convierte en tan útil para salir del mundo de los proyectos de software e ir hacia otro tipo de proyectos. Y, ese movimiento de ensayo y error, lo prepara bien para la innovación, como hemos dicho.


Productos y soluciones: desing thinking


Metodología


Quizá como metodología, el design thinking sea en sí misma la más difusa, a veces más una filosofía que una metodología y la que, de forma natural, tiende más a sus principios y patrones que a un enfoque cerrado.

De todas formas, y aunque muchos de los propios gurús del design thinking parecen derivar y ampliar sus fronteras, su ámbito principal es del diseño de productos y servicios, o soluciones en general, con una visión amplia, que conecta con el cliente y usuario finales, y que también propotipa y prueba, avanzando de forma iterativa.


Patrones subyacentes


Dentro de los patrones del design thinking se encuentran también la iteración y la adaptación, pero quizá refuerza más que agile, elementos como la creatividad, la empatía con y observación del usuario / cliente así como el prototipado

La cercanía al usuario final, la empatía y el prototipado son útiles en muchos problemas complejos o sin roadmap de resolución claro, y eso lleva a posibilidades de uso fuera del ámbito de los productos, servicios y soluciones.


Sobre el conocimiento y el rigor


Hecho el razonamiento anterior y ejemplificado en los casos que con más frecuencia me encuentro, tiendo a adoptar una visión un poco más optimista de cómo son usadas estas herramientas y metodologías.

No digo que no exista desconocimiento y superficialidad, que existen y bastante, y no digo que no exista un cierto 'postureo', que también existe y probablemente bastante, pero al menos me queda la expectativa de que, aunque seguramente bajo un nombre incorrecto, al menos se estén aplicando unos principios y patrones que sí pueden ser correctos y útiles. 

Dicho lo cual, a pesar de todo, reclamo, aunque sé que en vano, la profundización en el conocimiento real de las herramientas y tecnologías y que se usen por su nombre cuando realmente se está aplicando esa herramienta o metodología.

Y defiendo y abogo también, cuando tenga sentido, se apliquen sólo algunos de sus patrones y principios pero, cuando eso suceda, sea mediante una identificación y selección consciente de esos patrones y sin aplicarles un nombre que no les corresponde.

Esa es mi propuesta y ese es mi deseo. La propuesta aquí está. El deseo, creo que ni el genio de la lámpara me lo va a conceder :).


Conclusiones


Por debajo de las herramientas y metodologías más populares de análisis y gestión empresariales, subyacen unos principios y patrones básicos. 

La confluencia, por el lado negativo, de una cierta ignorancia y superficialidad en muchos adoptantes, y en el lado positivo, de unos patrones y principios básicos de utilidad mucho más general, hace que con frecuencia se apliquen  fuera del ámbito que les es propio y con un nombre que sería incorrecto.

Sin embargo, si reforzásemos el conocimiento y consciencia tanto de metodologías como de patrones, podríamos aplicar con mucho provecho los segundos, sin adjudicarles el nombre las primeras. 


viernes, 31 de enero de 2020

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)

lunes, 27 de enero de 2020

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 ÁlvarezSara AguileraSusana 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.

miércoles, 22 de enero de 2020

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 ÁlvarezSara AguileraSusana 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. 

lunes, 20 de enero de 2020

'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 ÁlvarezSara AguileraSusana 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'.

miércoles, 15 de enero de 2020

No, Agile no significa ir más rápido


Con frecuencia, los nombres que se escogen para las tecnologías, y en ocasiones también para las disciplinas de gestión, son engañosos. A veces, ya sea por ignorancia o, creo más bien, con intenciones de naturaleza comercial, se eligen nombres que llaman a engaño y que hacen creer lo que no es.

Y eso ocurre con Agile, una, ¿cómo la llamaríamos? filosofía o disciplina de gestión de proyectos que se encuentra absolutamente de moda, aunque sus orígenes se remonten a muchos años atrás. Se trata de una filosofía que, simplificando un poco, se aplica en proyectos con requisitos poco claros o que se mueven en un entorno de incertidumbre (típicamente, proyectos de innovación o emprendimiento, y muchos proyectos de desarrollo software) y que se basa en construir el resultado mediante iteraciones cortas que producen resultados tangibles, por ejemplo, una nueva versión de software utilizable.

Pero  ¿qué sugiere el nombre de Agile? Pues, claro, agilidad, es decir, rapidez

Y así, de nuevo puede que en algunos casos por ignorancia y en otros intencionadamente, se ha asimilado agilidad o agilismo a rapidez y muchos gestores han implantado agile (o "cosas" que pretenden serlo) sólo en búsqueda de esa tierra prometida de la rapidez.


Agile significa adaptación


Pues va a ser que no: agile no significa ir más rápido. Agile, lo que significa, es ser adaptativo

Y esa capacidad de adaptación, eso sí, nos puede hacer avanzar más rápído en algunos casos.

¿Qué quiere decir esto? 

Pues que, dado que nos movemos en entornos de incertidumbre y de requisitos poco claros y cambiantes, renunciamos a definir clara y completamente el alcance al inicio del proyecto y renunciamos también a hacer una planificación de tareas, tiempos y recursos para toda la vida del proyecto. En lugar de eso, vamos avanzando en ciclos cortos (lo que Scrum denomina sprints), generando incrementalmente versiones del entregable final (un software, un producto, un modelo de negocio...). Y con base en lo que vemos y el entorno, deducimos cuáles son los nuevos requisitos y hacemos un nuevo incremento corto adaptado a esa realidad.


¿Es Agile más rápido?


¿Y eso es más rápido?

Pues no exactamente, o no necesariamente. Sólo en los contextos adecuados. 

De heco, y aunque no lo voy a detallar en este post (invito al lector a razonarlo), en un proyecto con requisitos claros y entorno estable (lo que desde hace un tiempo el Project Management Institute denomina proyectos predictivos) creo es más eficiente e incluso más rápida la gestión de proyectos tradicional.

Lo que ocurre, eso sí, es que cada vez son menos frecuentes esos proyectos predictivos. Y en entornos de incertidumbre y requisitos poco claros, Agile si que tiene las armas para ir más rápido. ¿Por qué? Pues porque las inevitables equivocaciones que se producen en un entorno de incertidumbre, se corrigen de forma muy costosa y lenta en un proyecto gestionado de forma tradicional, mientras que tienen un impacto menor, mucho menor, en Agile dado que como mucho nos equivocamos en un pequeño incremento. Así que esos errores inevitables se corrigen rápido y el proyecto en su conjunto, termina antes.

Además, Agile produce una "ilusión de rapidez" por aquello de que produce resultados tangibles en iteraciones cortas. Y por eso, el cliente, o la dirección o el mercado, ven resultados pronto y los observan crecer a buena velocidad. Estrictamente hablando, eso no es ir exactamente más rápido, el final se puede alcanzar en el mismo plazo, sino hacer visible los resultados antes. Pero esa estrategia de producir resultados en pequeños incrementos, aparte de ser pieza muy importante del mecanismo de adaptación, genera esa sensación, no realmente cierta pero sí útil y atractiva, de rapidez y agilidad.


Conclusión


Este es mi convencimiento y algo que suelo destacar en las ocasiones en que explico Agile a mis alumnos o clientes.

Y me alegra ver que, aunque no sé si lo explicarían de la misma forma que yo, unas autoridades en el mundo de Agile, como son los autores del libro  'La empresa ágil' : Alonso ÁlvarezSara AguileraSusana Jurado y Míquel Rodríguez, van en una línea, al menos parecida, cuando indican:

tendemos a usar "ágil" como sinónimo de "rápido", pero en realidad también tiene una connotación de "flexible" y "adaptable".


Así que, recordemos, debemos usar Agile en entornos de incertidumbre y requisitos poco claros por muchas razones, incluido que nos pueden permitir terminar antes por gestionar mejor los cambios de alcance y requisitos. Pero no, Agile no significa realmente ir más rápido, Agile, lo que significa es ser adaptativo. La rapidez, en todo caso, se nos dará por añadidura.

lunes, 13 de enero de 2020

Estructurando la complejidad de los problemas: el framework Cynefin


Sea cierto o no, sea sólo una opinión o una realidad, tenemos la percepción de que los problemas a que nos enfrentamos hoy en día son crecientemente complejos. Hablamos de que los entornos actuales se caracteriza por ser VUCA (Volatile, Uncertain, Complex, Ambiguous), es decir, nos movemos en entornos volátiles, inciertos, ambiguos... y complejos.

La complejidad del entorno en que nos movemos dificulta la toma de decisiones, pero éstas al final deben de ser tomadas así que, de alguna forma tenemos que estructurar esa complejidad y lidiar con ella.

Leyendo 'La empresa ágil' de Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez, descubro la existencia de un framework que intenta de alguna forma estructurar, clasificar si se quiere, la complejidad de los problemas. No es que, por sí mismo ayude directamente a la decisión, pero sí puede aportar un marco conceptual para que el decisor conozca en qué entorno se mueve.

Estoy hablando de Cynefin, un framework propuesto hace ya veinte años, en 1999, por Dave Snowden, entonces en IBM Global Services. Cynefin es, si se quiere, simplemente un nombre artístico, un término que proviene del galés y que significa "hábitat". Lo que propone este framework son cinco áreas o cinco tipos de problemas que nos podemos encontrar.


Son éstos:
  • Simples: Se trata de problemas en que existen relaciones causa-efecto estables, claras, sencillas y conocidas. En este tipo de problemas se pueden aplicar recetas y mejores prácticas. Es la situación más sencilla pero Snowden advierte a los líderes frente a la tentación de clasificar en este bloque problemas que realmente no deberían estar en él, mediante simplificaciones artificiales o poco realistas.

  • Complicados: En este caso existen también relaciones causa-efecto, pero éstas no son obvias ni conocidas sino es mediante la aplicación de conocimiento experto o un análisis profundo. la decisión debería precedida de ese análisis o conocimiento y la solución adecuada puede no ser única.

  • Complejos: En este caso, aunque existen relaciones causa-efecto, éstas sólo pueden conocerse en retrospectiva. La forma de actuar normalmente es por prueba y error, ensayando alternativas y viendo como funcionan.

  • Caóticos: No está claro que existan relaciones causa-efecto. La única forma posible de conducirse es actuar, ver cómo es la respuesta y responder en función de lo que encontramos.

  • Desordenados: en realidad se trata de una situación de indeterminación en que no tenemos claro a cuál de los anteriores dominios pertenece el problema en cuestión.

En general, los problemas, conforme avanza el conocimiento pueden resituarse siguiendo la dirección de las agujas del reloj, pasando de caóticos, a complejos y luego a complicados y finalmente simples.

Los autores de 'La enpresa ágil' nos indican que Agile es una forma de abordar la complejidad y, en efecto, parece que la filosofía Agile de actuación de forma adaptativa y en ciclos cortos, encaja bastante bien en los dominios complejos (e incluso complicados) de Cynefin.

En fin. tal y como lo veo, Cynefin no nos va a solucionar directamente ningún problema, pero a lo mejor sí nos orienta sobre la forma de abordar esa solución y la metodología a grandes rasgos a emplear.

viernes, 22 de noviembre de 2019

La guía Agile de PMI y Agile Alliance

La 'Agile practice guide' es fruto de un trabajo conjunto entre PMI (Project Management Institute) y la Agile Alliance para hacer confluir, de alguna manera, la visión más tradicional y amplia del PMI con la muy específica de Agile y crear una guía práctica para éste segundo caso.

La guía, que es de una extensión media-corta, se estructura en siete capítulos:

  • '1- Introduction' comienza hablando de los enfoques predictivo y agile y luego presenta la guía con una explicación de los capítulos que la componen.

  • '2- Introduction to agile' habla brevemente de los proyectos de alta incertidumbre (donde encuentra su territorio natural el enfoque agile). Luego explica el manifiesto agile y la actitud que supone. Habla brevemente de Lean y Kanban y finaliza con unas consideraciones sobre la incertidumbre y la complejidad en los proyectos.

  • '3- Life cycle selection' Explica cuatro ciclos de vida (predictivo, iterativo, incremental y agile) y cuándo resultan adecuados. También habla de modelos mixtos.

  • '4- Implementing agile: creating an agile environment' habla de cómo poner en marcha una iniciativa agile. Nos habla fundamentalemente de las personas: del equipo y los roles.

  • '5- Implementing agile: delivering an agile environment' adopta un enfoque algo más metodológico y así, por ejemplo, introduce una serie de buenas prácticas agile: retrospectivas, preparación y refinamiento del backlog, reuniones diarias y demostraciones y revisiones. También habla de cómo resolver algunas problemáticas y del seguimiento y medida de proyectos en el enfoque agile.

  • '6- Organizational considerations for project agility' comenta aspectos diversos y algo heterogéneos como gestión del cambio, cultura organizacional, contratos, oficina de proyectos, coordinación interequipos o estructura organizativa.

  • '7- A call to action' Un breve cierre que anima a seguir en contacto con las comunidades agile y de dirección de proyectos.
A los capítulos propiamente dichos se une una larga serie de anexos:
  • 'A1 PMBOK Mapping Explica brevemente cómo aplica al caso agile cada una de las áreas de conocimiento del PMBOK

  • 'A2 Agile Manifesto Mapping estabece una correspondencia entre los valores del manifiesto agile y lo descrito en la guía

  • 'A3 Overview of agile an lean framewors hace un repaso express por los diferentes frameworks agile, tocando Scrum, eXtreme Programming, Kanban, Crystal, Scrumban, Feature-Driven-Development (FDD), Dynamic Systems Development Method (DSDM) y Agile Unified Process. Además comenta alguna idea para escalar estos frameworks a equipos grandes o multiequipos.

  • 'X1 Contributors and reviewers simplemente, listado de organizaciones y personas que han participado

  • 'X2 Attributes that influence tailoring una guía de alto nivel para la personalización de agile

  • 'X3 Agile suitability filter tools propone un modelo para evaluar lo apropiado de usar un enfoque agile
La 'Agile practice guide' es, creo, un librito oportuno que aporta una visión preliminar del mundo agile y cómo encaja con la visión de dirección de proyectos más tradicional. Es una guía correcta, que no brillante, y que sirve muy bien como introducción aunque probablemente precise de un estudio más detallado, tanto del framework agile de nuestra elección, como de la propia doctrina de dirección de proyectos contenida en el PMBOK.

Ficha técnica:
AÑO: 2017 
ISBN: 978-1628251999
PAGINAS: 210


martes, 20 de noviembre de 2018

Mi Actividad: Hablando de Agile y Automatización Robótica de Procesos en el marco del Programa Ejecutivo de Transformación Digital de EOI en Santander


El pasado viernes 16 de Noviembre tuve el placer de impartir una doble sesión dentro del marco del Programa Ejecutivo de Transformación Digital que imparte la Escuela de Organización Industrial en Santander.

Y hablé de dos temas que enfocan de forma diferente la necesidad de responder con agilidad ante los cambios continuos y acelerados que plantea la revolución digital.

Por un lado, una visión más de gestión, hablando de la gestión de proyectos con filosofía Agile. Repasamos los antecedentes, el porqué del surgimiento de Agile, los principios del manifiesto Agile y las principales características de Scrum, para acabar con alguna visión intermedia como la TI Bimodal.

Por otro lado, y en la segunda parte, adoptamos un cariz más tecnológico y con filosofía low-code, para hablar de RPA (Robotic Process Automation), revisando primero lo que es un proceso de negocio y las diferentes tecnologías que se emplean en su digitalización, para luego abordar la definición de RPA, las funcionalidades más habituales, su relación con la inteligencia artificial y aspectos relacionados con los proyectos de puesta en marcha o el centro de excelencia RPA, sin olvidar alguna breve demostración con la herramienta UiPath.

Cuatro horas intensas, con mucho diálogo y que espero que hayan sido tan provechosas para los alumnos como interesantes han resultado para mi.


martes, 10 de julio de 2018

Mi actividad: Módulo de Innovación en Programa de Transformación a la Cultura Digital para CESCE


Hace unos días se produjo el cierre del Programa de Transformación a la Cultura Digital que, dirigido a los profesionales de la aseguradora CESCE se impartió por parte de la Escuela de Organización Industrial.

En ese programa, fui el encargado del módulo titulado 'La digitalización como palanca para la innovación'. Dicho módulo, impartido a dos grupos diferentes, consistió en una sesión de cuatro horas en donde repasamos los conceptos y relación entre creatividad, investigación e innovación además de entender conceptos fundamentales del poder transformador de lo digital. Luego nos adentramos en el terreno de la creatividad y los juegos con alguna dinámica muy entretenida para a continuación repasar los diferentes modelos de innovación, con especial foco en el Desarrollo de Clientes y Lean Startup.

Dejamos un espacio para repasar cómo se está innovando en el sector asegurador y finalizamos hablando de las técnicas de gestión adaptativas hablando de Agile y DevOps.

Unas sesiones que espero que para los alumnos hayan sido instructivas y entretenidas y que a mi me ha servido para descubrir la fuerte cultura innovadora de CESCE.

viernes, 11 de mayo de 2018

Una comparativa de Agile, Lean Startup y Design Thinking a cargo de Jeff Gothelf

'Lean vs Agile vs Design Thinking' es un libro cortito, apenas 46 páginas, que intenta clarificar la relación que existe entre estas tres popularísimas filosofías relacionadas con la innovación: lean startup, agile y design thinking. El punto de partida del autor es que a pesar de sus similitudes, son utilizadas por unidades diferentes de una misma empresa, produciendo, por un lado, confusión y, por otro, evitando en ocasiones que se den los frutos que de ellas se espera.

La estructura del libro es muy sencilla, constando de los siguientes capítulos:
  • 'Introduction'
  • 'Agile'
  • 'Lean Startup'
  • 'Design Thinking'
  • 'So, which process is right'
Es decir, tras una cortísima introducción, describe brevemente cada una de las filosofías en liza y luego plantea unas conclusiones.

En esencia, el mensaje es que Agile ayuda a entregar resultados de una forma regular, Lean Startup a determinar en qué debemos enfocarnos y Design Thinking a que aquello en que trabajamos realmente tenga valor y, además, identifica diez buenas prácticas comunes a las tres. Al final del libro relativiza un tanto el trabajo teórico y nos recuerda que al cliente, en el fondo, lo que le importan son nuestros productos y servicios y no cómo llegamos a ellos.

Es importante advertir que el autor se enfoca mucho a los proyectos de desarrollo software, cuna de agile, pero que esto puede sesgar sus opiniones.

Aunque creo que el autor no logra del todo dar una visión absolutamente coherente e integrada de las tres disciplinas, lo cierto es que es un libro muy pedagógico, ameno y que 'aporta sus cosas'.

Jeff Gothelf

(Fuente: Traducción y ligera elaboración propia de su perfil en Rosenfeld Media)

Jeff Gothelf
Jeff Gothelf es evangelista Lean en Neo, expandiendo la palabra de la gran colaboración de equipos, innovación de producto y decisión basada en evidencias.

Es conferenciante y líder de pensamiento acerca del futuro del diseño de la experiencia de usuario, enseñando frecuentemente o pronunciando charlas acerca de construir culturas que promuevan el trabajo en equipo y la innovación. Jeff es apasionado de avanzar en los principios que subyacen en el núcleo de Neo, y lo hace a menudo a escala global.

Antes de unirse a Neo, Jeff dirigió los equipos de diseña de experiencia de usuario en The Ladders y Web Trends. Anteriormente, había trabajado con y dirigido pequeños equipos de diseñadores software en AOL. Es autor, junto con Josh Seiden de 'Lean UX: Applying Lean Principles to Improve User Experience'

Puedes conocer más del autor siguiéndole en Twitter donde se identifica como @jboogie.

Ficha técnica:

AUTOR: Jeff Gothelf
EDITORIAL: Sense & Respond
AÑO: 2017
ISBN: 978-0999476918
PAGINAS: 46

Artículos de este blog relacionados

miércoles, 9 de mayo de 2018

Diez prácticas para unificar Agile, Lean Startup y Design Thinking


Al final de su breve libro 'Lean vs Agile vs Design Thinking' en que el autor describe, precisamente, Agile, Lean Startup y Design Thinking, Jeff Gothelf se hace la pregunta lógica: ¿Y qué proceso es mejor?

Y, como cabe esperar, la respuesta no es ni blanco ni negro porque, aunque con filosofías y motivaciones muy similares, en el fondo cada método pone el foco en cosas algo diferentes. A cambio, el autor hace algo casi mejor: extrae, en una práctica inteligente de eclecticismo, diez prácticas que de alguna forma reúnen lo mejor de uno o varios de los métodos.

Estas son las diez prácticas:

  • Trabaja en ciclos cortos: En este caso, realmente hay unanimidad entre las tres filosofías, por lo que el autor sólo reafirma la bondad de trabajar en ciclos cortos, digamos un sprint de scrum o un ciclo de construir-medir-aprender de Lean Startup.

  • Mantén retrospectivas regulares: En este caso para adoptar esta práctica propia de agile pero que no contradice en nada a Lean Startup ni Design Thinking.

  • Pon al cliente en el centro de todo: de nuevo, una práctica compartida por las tres filosofías aunque quizá con más énfasis en Design Thnking y Lean Startup.

  • Sal y mira: es decir, el famoso 'Get Out Of the Building' de Steve Blank. La idea es que no vas a aprender nada del mercado, tu cliente o tu usuario en un laboratorio o en la oficina, así que: sal y habla directamente con ellos.

  • Equilibra el descubrimiento de producto con la entrega de trabajo, probando sólo las hipótesis de alto riesgo: es una forma, quizá de rebajar un poco el ansia de comprobación de hipótesis, especialmente de Lean Startup, centrándose sólo en las que suponen un mayor riesgo en caso de equivocación.

  • Haz menos investigación, pero más a menudo: de nuevo, es un cierto ejercicio de realismo y sentido común. Se trata de invertir menos tiempo y recursos en las investigaciones con usuario y, a cambio, realizarlas con mayor frecuencia.

  • Trabaja (y entrena) como un único equipo equilibrado: en este caso hay unanimidad, tanto Lean como Agile como Design Thinking son muy de trabajar en equipo.

  • Transparencia radical: casi autoexplicativo, se trata de aplicar transparencia a la hora de la comunicación, de explicar las nuevas prácticas, de medir el éxito...

  • Revisa tu estructura de incentivos (y criterios de gestión del desempeño): quizá, en opinión del autor, la mejor forma de conseguir que los equipos elijan, de entre todas las opciones, las más productivas.

  • Haz del trabajo de descubrimiento de producto un ciudadano de primera clase de tu backlog: las tres filosofías ponen énfasis en el aprendizaje pero no son del todo claras y uniformes a la hora de reflejar el avance en el descubrimiento de producto, así que el autor aboga por visibilizar ese avance, junto con el de la entrega de tareas.

Como se ve, hay un poco de todo: prácticas que son unánimes, prácticas propias sólo de alguna de las filosofías y alguna aportación propia del autor.

Pero, en conjunto, lo que sí hay es mucho sentido común...