Liderazgo Ágil

 “Un líder es como un agricultor, que no cultiva sus cultivos tirando de ellos, sino que crea el ambiente perfecto para que los cultivos crezcan y prosperen.”

Un líder ágil lidera a sus equipos de una forma totalmente diferente al management tradicional.

De acuerdo con el Center for Agile Leadership https://centerforagileleadership.com

“Las prácticas tradicionales de liderazgo son obsoletas e ineficaces en el lugar de trabajo actual. La investigación ha demostrado que más del 70% de los trabajadores en América están activamente desconectados y que los gerentes son la principal causa de insatisfacción laboral.”

Es Critico

En los tiempos actuales, impulsadas por la transformación digital, son cada vez más las organizaciones que buscan ser más ágiles en una forma de sobrevivir y prosperar en los entornos cambiantes actuales.

Y así como esa famosa frase que dice “una organización es tan ágil como sus líderes”, el liderazgo se vuelve un factor crítico de éxito en el proceso de transformación. Y particularmente el liderazgo senior necesita desarrollar mentalidades y capacidades sustancialmente diferentes.

Hay tres cambios fundamentales de mentalidad reactiva a creativa que Mckinsey en su artículo https://www.mckinsey.com/business-functions/organization/our-insights/leading-agile-transformation-the-new-capabilities-leaders-need-to-build-21st-century-organizations define como críticos para fomentar la cultura de innovación, colaboración y creación de valor en el corazón de las organizaciones ágiles:

  • De la certeza al descubrimiento: fomento de la innovación. En una mentalidad reactiva de certeza se trata de jugar para no perder, tener el control y replicar el pasado. Hoy en día, los líderes deben cambiar a una mentalidad creativa de descubrimiento, que consiste en jugar para ganar, buscar diversidad de pensamiento, fomentar la colisión creativa, aceptar el riesgo y experimentar.
  • De la autoridad a la asociación: fomento de la colaboración. El diseño tradicional de la organización tiende a jerarquías aisladas basadas en una mentalidad reactiva de autoridad. La relación entre líderes y equipos es de superior a subordinado. Diseñadas para la colaboración, las organizaciones ágiles emplean redes de equipos autónomos. Esto requiere una mentalidad creativa subyacente de asociación, de administrar mediante un acuerdo basado en la libertad, la confianza y la responsabilidad.
  • De la escasez a la abundancia: fomento de la creación de valor. En mercados estables, las compañías maximizan sus acciones a expensas de otros. Este enfoque de ganar-perder refleja una mentalidad reactiva de escasez, basada en el supuesto de oportunidades y recursos limitados. Sin embargo, los mercados de hoy evolucionan continua y rápidamente. Para entregar resultados, los líderes deben ver los mercados con una mentalidad creativa de abundancia, que reconoce los recursos ilimitados y el potencial disponible para sus organizaciones y permite centrarse en el cliente, el espíritu empresarial, la inclusión y la creación.

Responsabilidades de un Líder Ágil

Los líderes ágiles lideran a sus equipos de una manera totalmente nueva. Lideran porque crean precisamente el entorno que los equipos necesitan para crecer y mejorar. Dentro de este entorno, los equipos optimizan los procesos ellos mismos, aumentan su propia eficacia y eficiencia, y toman todo tipo de decisiones a diario. Eso hace que estos equipos se autogestionen. Organizan su propio trabajo y tienen todas las habilidades para hacerlo. Estos equipos ágiles son ágiles en sí mismos porque pueden responder rápidamente a las nuevas tecnologías, las amenazas de los competidores y las expectativas siempre cambiantes de sus clientes. No tienen que esperar la aprobación oficial, las decisiones de gestión o los cambios estratégicos descendentes. Debido a que tienen un ciclo de retroalimentación corto con sus clientes y usuarios, pueden experimentar continuamente con nuevas ideas, mejorar sus productos y servicios y alinearse con otros equipos autogestionados. El líder ágil es el arquitecto de este entorno.

Hoy en día existen una serie de herramientas, modelos, frameworks que buscan dar lineamientos, guía o solución a la aplicación de este tipo de liderazgo, entre ellos:

Evidence Based Management


Puedes leer mas https://www.scrum.org/resources/evidence-based-management, pronto haré una entrada sobre este tema.

Strategic Doing


Aprende mas sobre esto https://strategicdoing.net/

The GRIP Framework


Aprende mas https://www.agileacademy.nl/en/agile-leadership/  de esto también hare una entrada próximamente.

Este y otros temas son desarrollados y llevados a la practica en mi Workshop de liderazgo ágil https://fabianthinking.com/agile-leadership/

Te Invito a Aprender y Leer

Web

https://www.scrum.org/resources/blog/5-agile-leadership-tips-creating-mature-scrum-teams

Libros

Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th.

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

¿Cómo entregan Valor los equipos Ágiles?

Muchas veces nos llenamos la boca respecto de generar valor o dar valor al cliente, pero ¿es lo que realmente hacemos?

En Scrum al final de cada sprint se espera un incremento de producto, lo que es “Software Funcionando”, ¿es esto realmente valor?

Lamentablemente lo de software funcionando o funcionalidades o características se ha tomado literal y muchas organizaciones luchan y corren por llenar sus productos y canales de funcionalidades cuando muchas de estas tienen poco valor para el cliente/usuario.

¿Entonces que es el valor?

En general hablamos de 3 tipos de indicadores para dejar claro donde esta el valor, estos son Impact, Outcome y Output.

  • OutPut: Son los funcionalidades o proyectos que ponemos en manos de los clientes/usuarios tanto internos como externos.
  • OutCome: Son mas métricas que indican cambios (para mejor) en los comportamientos de los clientes/usuarios. Temas relacionados a alguna tarea o actividad que realice el usuario que se vea influenciada por un OutPut.
  • Impact: Son las métricas de impacto en el negocio, son de mediano y largo plazo, temas como Rentabilidad, Ingresos, Costos. Y estas son modificadas o impactadas en el tiempo por los OutCome.

¡No entendí nada!

Vamos a dar ejemplos

  1. ¿Quieres reducir los costos? Entonces ideas una funcionalidad o proyecto que hará que los usuarios se demoren menos tiempo en realizar una tarea x, al tomar menos tiempo el costo por tarea se reduce y se acumulara una reducción de costos en el mediano y largo plazo. El output en este caso es el proyecto o funcionalidad, el outcome es la reducción de tiempo para el usuario y el impact es la reducción de costos.
  2. ¿Quieres vender más? Entonces ideas una funcionalidad que registra la historia de compra de tus clientes y sus artículos visitados, para enviarles promociones posteriormente en base a esa información ¿Cuál es el outcome? Que se provoque un cambio de comportamiento de los clientes en que visiten más el sitio al recibir ofertas de interés y aumente la probabilidad de compra ¿Cuál es el output? La famosa funcionalidad de historia y promociones.
  3. ¿Quiere reducir costos? En general las transacciones online son más económicas para la compañía que las transacciones offline entonces se crea un proyecto para digitalizar las 3 transacciones mas importantes en el canal web, El OutCome sería el cambio de comportamiento de los clientes que en ves de ir a la sucursal usen el canal web y el Impact en el mediano y largo plazo es el ahorro dado que las transacciones online son más económicas.

¿Cuál es el Problema entonces?

El problema es que las organizaciones están midiendo mal el éxito de sus iniciativas, están pegadas en el OutPut, en la cosa, en la entrega, en la funcionalidad.

Entonces tienen indicadores y metas asociadas a:

  • Números de pasos a producción.
  • 10 nuevas funcionalidades al año.
  • Digitalizar 30 transacciones en el año.
  • Número de Proyectos termínanos.
  • Etc.

Cuando las organizaciones se enfocan en el OutPut como métrica de éxito, solo gastan más, se sobrellenan de proyectos o iniciativas, sobrecargan sus recursos y en general logran menos.

Las organizaciones y equipos necesitan enfocarse en OutComes, resultados, allí esta el valor y es lo que tiene impacto en las métricas de salud del negocio.

¿Cuál sería un buen objetivo entonces?

Cuando a un equipo le pones como meta 10 funcionalidades pre-establecidas semestralmente, mermas la innovación, destruyes el aprendizaje y limitas el feedback del cliente/usuario.

En cambio, cuando la meta es un OutCome, por ejemplo, aumentar las transacciones on line de los clientes en un 10%. Entonces das pie para la innovación, investigación y conexión con el cliente, porque entonces el equipo tendrá que explorar cuales OutPuts Provocan ese OutCome.

En el OutCome está el Valor y se puede Medir desde que es puesto en manos del cliente el OutPut.

Para terminar, enfocarse en OutPuts muchas veces destruye valor mas que el que genera. Cuando un equipo corre por lograr la meta de 10 funcionalidades en un plazo determinado, puede sacrificar experiencia y calidad, lo que provocara un OutCome negativo en el cliente.

Si para un cliente la experiencia de compra o transacción online es demoroso, complicada, enredada no se producida el OutCome deseado, será todo lo contrario y abandonará la experiencia online o buscará esa experiencia en otro.

No nos olvidemos del cliente Interno, el talento de la organización, cuando pones en sus manos herramientas engorrosas y complicadas para hacer su trabajo, el OutCome también será negativo y probablemente busquen la forma de hacer su trabajo sin usar la herramienta o dándole un mal uso a la herramienta para saltarse pasos, validaciones, etc.

Para reflexionar…

Pregúntate ¿cuántas funcionalidades tiene tu lavadora, cuantas usas y te agregan valor?

¿Cuántas funcionalidades tiene tu microondas, cuantas usas y te agregan valor?

¿Cuántas funcionalidades tiene Excel, cuantas usas y te agregan valor?

Todos estos temas son tratados en mis Workshops de Scrum in Action https://fabianthinking.com/scrum-in-action/ y Product Ownership in Action https://fabianthinking.com/product-ownership-in-action/

5 Errores de un Scrum Master y ¿Que hacer con ellos?

Hay muchos errores, mal entendidos, formas de pensar opuestas, etc. que hacen muy difícil que una organización entienda la agilidad y mas aun que desarrollen la agilidad empresarial.

Típicamente este camino inicia con un equipo Scrum en TI y es allí a donde quiero enfocar este Post, 5 errores que cometen los Scrum Máster que están iniciando (y que no son ni practicas ni artefactos)

1° No entender su Rol

Suponiendo que entienden correctamente Scrum en teoría (principios, valores, artefactos, eventos), muchos Scrum Master creen que su rol es ese, que el equipo Scrum ejecute correctamente los eventos y artefactos de Scrum y en algún minuto vivan sus valores y principios, pues lo anterior no, ese no es su rol, más bien es un objetivo dentro de un rol que es mucho más grande y complejo.

¿Cuál es el rol del Scrum Máster entonces? El rol tiene 3 pilares fundamentales:

  • Con el Product Owner: Ayudarlo, a comprender el pensamiento ágil y los principios tras el desarrollo ágil de productos, a moverlo del pensamiento de proyectos y ponerlo en un enfoque producto. Que entienda la incertidumbre y aprenda a generar hipótesis y experimentos y validarlos recibiendo feedback del cliente.
  • Con el Equipo: Que abracen el pensamiento ágil, la mejora continua, la auto-organización, la generación de valor y la responsabilidad que ello conlleva.
  • Con la Organización: Que la organización entienda el trade-off de usar Scrum (que debe cambiar para obtener sus beneficios) y que los stakeholder alrededor de este equipo, entiendan que es un equipo que trabaja diferente y por tanto sus formas de interacción son otras.

Lo anterior se resume a que los Scrum Master son agentes de cambio, tanto para la gestión de la iniciativa, como para la gestión del equipo, como para la organización.

El resto de los errores vienen derivados de este primero.

2° No desarrollar al equipo

Muchos Scrum Master han sido jefe de proyectos o incluso desarrolladores, pero no tienen experiencia en el desarrollo de equipos, en generar la autoorganización y la responsabilidad. Y se quedan detenidos y estancados en decirle al equipo lo que tienen que hacer al mismo tiempo que toman responsabilidad por los objetivos (entregables) del equipo. Y si, esto puede ser al principio cuando el equipo No es Equipo y la organización tampoco sabe interactuar o entiende muy bien cómo trabaja un equipo ágil, pero no es algo que debería perpetuarse, eso es un error.

Una buena referencia de cómo moverse de decirle al equipo lo que debe hacer a delegarle totalmente es el liderazgo Situacional https://www.situational.com

No esta demás que un Scrum Master debe saber como se desarrolla un equipo y entrenar sus capacidades de Teaching, Facilitación, Mentoring y Coaching.

Libro Recomendado!

3° No acompañar al Product Owner

Quizás en un inicio el tiempo del Scrum Master se vea absorbido en el pilar del desarrollo del equipo, Primero en que sea un equipo, Segundo en que se autoorganicen y abrasen la mejora continua y el pensamiento ágil. Y justamente parte de ese pensamiento ágil va de la mano del trabajo del Product Owner, en que la generación de valor, la estrategia, la gestión del Producto sea ágil. Lamentablemente muchos Scrum Master jamás toman esa bandera y el Product Owner no deja de navegar solo y sin guía ese camino. Perpetuándose una gestión de alcance tradicional con un desarrollo ágil.

¿Cómo puede el Scrum Master acompañar y desarrollar al Product Owner? Pues primero, entendiendo muy bien el Rol del Product Owner y armándose de los conceptos y herramientas que un Product Owner necesita.

Libros Recomendados!

4° No perseguir el cambio en tu organización

Un Scrum Master es un agente de cambio, por tanto, debe buscar provocar cambios en su organización para que esta se mueva a una gestión mas ágil, a un proceso mas lean desde que nace una iniciativa hasta que esta llega a manos del cliente. Ahora no es fácil, no es de la noche a la mañana ni desde el primer momento, en mi experiencia debe haber recorrido el camino del desarrollo del equipo, y comenzar a caminar mas con el Product Owner para comenzar a generar cambios en la organización.

5° Certificarse y Fin

Esta claro que ser Scrum Master es complejo, y que todo lo que un Scrum Master debería saber (además de Scrum), temas como:

  • Desarrollo de equipos, personas. Liderazgo ágil.
  • Gestión ágil de productos o Lean Product Development.
  • Lean Startup.
  • Facilitación y Técnicas de Facilitación.
  • Mentoring y Coaching.
  • Gestión del cambio.
  • Pensamiento Sistémico, Sistemas Complejos Adaptativos, Etc, etc.

No es algo que se pueda aprender en un curso de Certificación de 2 días, pero lamentablemente esto no queda Tan Claro en esos cursos y quienes van, al obtener la certificación de Scrum Master, sienten que han cumplido dejando de aprender.

Certificarse de Scrum Master es solo el primer escalón de un largo camino.

Los 5 puntos acá descritos, son algo que veo recurrentemente en Scrum Masters, mas en aquellos dentro de organizaciones tradicionales, sin referentes, aislados y por estas mismas razones, el Scrum Master no logra el impacto, defraudándose él y la organización del tema “agile”.

También son una de las razones por las cuales arme el Workshop de Scrum in Action, justamente para mostrar el largo camino y transmitir mas experiencia practica a los Scrum Master que están iniciando. https://fabianthinking.com/scrum-in-action/

Gestionando el Riesgo en un Equipo Ágil

En contextos complejos el riesgo siempre está presente, entendiendo el riesgo como “La posibilidad de ser expuesto a una circunstancia adversa o no deseada”.

Y este hay muchos tipos de riesgos o formas de clasificar el riesgo en proyectos o iniciativas y esas clasificaciones son:

  • Riesgo Financiero: Asociado mas al presupuesto o inversión en una iniciativa y su ROI esperado. ¿alcanzara el presupuesto? ¿se pagará?
  • Riesgo del Negocio: Asociado a si las características o funcionalidades de un producto tendrán el resultado esperado ¿Sera usado? ¿proveerá el beneficio esperado? ¿resuelve el problema?
  • Riesgo Técnico: Asociado a la construcción del producto o iniciativa ¿se puede construir? ¿cumplirá las expectativas técnicas?

Al final todo el riesgo de una u otra manera tendrá una consecuencia en lo Financiero y es de allí la importancia de identificarlo y gestionarlo.

En este Post hablare de como gestionar el Riesgo Técnico y del Rol del Scrum Máster en esto, del riesgo del negocio hablare en un futuro Post.

¡Manos a la obra!

El riesgo técnico lo podemos sub-dividir en 3 conceptos más simples y aterrizados:

  • Puramente Técnico: Es el riesgo respecto del diseño de la solución y su arquitectura, por ejemplo, temas de performance, de seguridad. Temas que tienen posibilidades de fallar en ese ámbito, pero que el equipo tiene el poder de gestionarlos completamente (ya desarrollare esta idea)
  • Dependencias Externas: Este riesgo aparece cuando el proyecto, producto o iniciativa que esta trabajando un equipo, tiene dependencias de terceros, ya sean otros equipos dentro de la organización o proveedores, donde cualquier fallo en calidad y tiempo afectara al proyecto, producto o iniciativa.
  • Del Proceso: Este es el riesgo del día a día que afectara los objetivos del Sprint, por ejemplo, que se caiga un ambiente, que te borren los datos de QA, que se enferme o retire un miembro del equipo, etc.

¿Cómo Gestionamos cada uno de estos?

Primero entendamos por Gestionar el Riesgo actividades de identificación, análisis, plan de acción, monitoreo y control.

Identificación y análisis

Una buena técnica para identificar y analizar el riesgo es armar una matriz de impacto y probabilidad, esta en vez de ser un Excel guardado en alguna carpeta de la iniciativa, debe ser un artefacto de gestión visual y vivo.

El cual puede ser co-creado por el Scrum Team y los principales Stakeholders y de la misma manera debe ser un ciclo de revisión y actualización como cualquier artefacto ágil.

¿Por qué no te digo exactamente cual es el ciclo de revisión y de actualización de este artefacto?

Porque estamos en contextos complejos, no hay balas de plata, es un proceso empírico, debes experimentar un ciclo de revisión y actualización y quizás revisar en las retrospectivas si es el correcto. ¿Debería revisarlo en las Review?  Pues experimenta y recibe feedback de los stakeholders.

Plan de Acción Monitoreo y Control

Una técnica buena y ligera para generar planes de acción respecto de los riesgos es ROAM:

  • Resolved: Todos están de acuerdo en el riesgo ya no es más un riesgo, ya sea porque llego nueva información al equipo, se ejecutó el plan de mitigación.
  • Owned:  Alguien del equipo o stakeholder toma el riesgo para sí y se hará cargo de generan un plan de acción o mitigación.
  • Accepted: Es poco lo que se puede hacer respecto del riesgo en el equipo y fuera de él, por tanto, se acepta que sucederá y se debe pensar en que se hará cuando suceda.
  • Mitigated: Se genera un plan para mitigar el impacto del riesgo.

Ejemplos:

Si hablamos de un riesgo “Puramente Técnico” ( recuerden la subclasificación que hice mas arriba) por ejemplo, un tema de performance o de seguridad, este podría ser Owned por el equipo y planear hacer una prueba de concepto (POC) o un Spike, que se agregue al producto backlog para así dejar el Riesgo es Resolved o Mitigated.

Si hablamos de dependencias externas, un stakeholder podría hacer Owned de ese riesgo y hacer las gestiones para monitorearlo constantemente e informar al equipo o mitigarlo.

Si hablamos de algo que es del proceso, por ejemplo, que se caiga un ambiente, el equipo podría hacer Owned de ese riesgo y generar un plan de crear algún ambiente temporal que se use cuando el ambiente oficial se caiga de esta forma Mitigated el riesgo. Lo mismo puede pasar si alguien se enferma o se va del equipo, preparando un plan de generar conocimientos cross-funcionales en el equipo para que la falta de un miembro sea mitigada.

Para lo anterior crea un tablero del ciclo de vida del riesgo y podrías dividirlo entre los que tienen pocas posibilidades de ocurrencia por tanto debes accionar cuando el riesgo es Gatillado u Ocurre.

Y un tablero para riesgos con alta probabilidad y por tanto tu plan de mitigación debes ejecutarlo sí o sí.

¿Qué es clave?

  • Hacer los riesgos visibles.
  • Gestionarlos constantemente.
  • Involucrar al equipo y los stakeholders.
  • Comunicar y accionar.

Entender que el enfoque agil no le quita complejidad a los proyectos o iniciativas, si no mas bien nos permite navegar o avanzar mejor en esa complejidad, administrando más efectivamente el riesgo y no con prácticas necesariamente explicitas como las que describe este Post sino más bien implícitas, por ejemplo:

  • El riesgo técnico se maneja mejor retrasando decisiones técnicas, realizando pruebas de concepto o Spikes para disminuir esa incertidumbre y las probabilidades de riesgo. En el enfoque tradicional las mismas decisiones técnicas se toman al inicio con mucha incertidumbre.
  • En el riesgo de negocio se generan MVPs para validar la idea, se obtiene feedback temprano del cliente para corregir el rumbo y medir si efectivamente la solución tiene el outcome deseado, incluso a nivel de features es recomendable hacer MVPs. En el enfoque tradicional no obtienes feedback del cliente hasta el final, hasta que todo esta concluido y ya es tarde para corregir el rumbo.

Un Error común como Scrum Master es pensar que la gestión de riesgos depende de ti como Jefe de Proyectos, y que debes resolver todo, cuando realmente lo que debes hacer es facilitar su identificación y gestión, empoderar al equipo en la gestión de riesgos e involucrar a los Stakeholders para que entiendan los riesgos y se hagan parte de la solución.

Este y otros temas son parte de mi Workshop Scrum in Action https://fabianthinking.com/scrum-in-action/

La importancia del tiempo de mejora en el Desarrollo de Equipos

Este tema no es menor, es de vital importancia en cualquier equipo de trabajo, tenga o no el apellido “ágil”.

¿Qué tan común es esta caricatura en las organizaciones?

Lean Kanban y Scrum explícitamente incorporan practicas de mejora continua, y es que estas prácticas son vitales para el desarrollo de equipos de trabajo de alto rendimiento. Lamentablemente muchos Managers o Lideres o Products Owners no dan espacio para la mejora continua, por la urgencia del día a día, tal como grafica la caricatura.

Recomiendo leer esta entrada de mi Blog https://fabianthinking.com/2019/09/11/el-problema-de-la-productividad-en-la-era-del-conocimiento/

Comúnmente y como práctica común de lideres y managers, el performance de un equipo (su rendimiento) se mejora bajo constante presión. Tal como muestra la siguiente gráfica:

 Y es que efectivamente al presionar a un equipo a dar mas (Pressure Point), se puede lograr que un equipo rinda o mejora su performance y esto puede resultar más de una vez. Esto genera una ilusión de buen liderazgo o gestión ya que en efecto da resultado, lamentablemente no es una práctica sostenible. Cuando un equipo es presionando constantemente sin espacio para la mejora, irremediablemente llegara a un punto de quiebre o agotamiento en el cual el equipo bajara su rendimiento por múltiples razones como:

  • Falla en la calidad del trabajo por la presión excesiva.
  • Agotamiento de miembros de equipo, licencias, estrés, etc.
  • Abandono de miembros que ya no soportan el ritmo de trabajo.

¿Cuál es la forma correcta entonces?

Dando espacio para la mejora, sin excepciones.

Al dar espacio para la mejora (Development Time) el equipo bajara su performance ya que no ocupara ese tiempo para ejecutar el trabajo, al contrario, lo ocupara para Desarrollar Nuevas Capacidades, este tiempo lo ocupara en actividades como:

  • Entrenamientos en nuevas tecnologías o herramientas o métodos que les permitan hacer mejor su trabajo.
  • Investigación y análisis.
  • Implementación de mejoras a sus procesos.
  • Desarrollo de Cross-Funcionalidad.
  • Team Building.

Lo importante es que al finalizar el Development Time, el equipo habrá adquirido nuevas capacidades que le permitirán alcanzar un nuevo nivel de Performance, esto de una forma sostenible sin alcanzar un punto de quiebre o agotamiento.

Manager, Lideres, Product Owners, Scrum Masters den espacio siempre a la mejora del equipo.

Este y otros temas orientados al desarrollo de equipos son tratados en mi workshop de Scrum in Action https://fabianthinking.com/scrum-in-action/

Saludos!

El Problema de la Productividad en la era del Conocimiento

Hace mucho tiempo que quería hablar de esto, y es que es uno de los principales males a todo nivel en la organización, tanto a nivel de Portfolios, Programas, Áreas, Gerentes, Lideres y equipos.

¿Qué es la Productividad?

Si vamos a la definición más pura https://economipedia.com/definiciones/productividad.html nos encontramos con lo siguiente:

La productividad es una medida económica que calcula cuántos bienes y servicios se han producido por cada factor utilizado (trabajador, capital, tiempo, costes, etc) durante un periodo determinado.

El objetivo de la productividad es medir la eficiencia de producción por cada factor o recurso utilizado, entendiendo por eficiencia el hecho de obtener el mejor o máximo rendimiento utilizando un mínimo de recursos. Es decir, cuantos menos recursos sean necesarios para producir una misma cantidad, mayor será la productividad y por tanto, mayor será la eficiencia.”

La productividad siempre se ha visto como un objetivo a seguir y un gran indicador de que tan bien lo esta haciendo una persona, un equipo, un área, etc.

Bueno justamente este es uno de los conceptos que en la era del conocimiento y trabajo creativo debemos desaprender para ser realmente más Productivos.

El concepto de productividad viene de las economías industriales basadas en la producción en masa de bienes y ¿esto que implica?, básicamente que el concepto se desarrolló cuando:

  • Economías estables, menos ambiguas y cambiantes, con foco en el desarrollo de productos.
  • Procesos estables, predecibles y repetibles.
  • El trabajador de una cadena de producción sabe exactamente qué tiene que hacer, en qué orden, en qué momento y con qué herramienta.
  • La Relación entre carga de trabajo y tiempo disponible es proporcional.
  • Número mínimo de sorpresas en el proceso, se sabe con poco margen de error, cuanto se debía producir al día o al mes, por trabajador, por línea productiva, por planta.

Sin embargo, hoy, donde la gran mayoría de las empresas son de servicios y experiencias, donde el trabajo es mas creativo y requiere conocimientos mas específicos. De hecho, Peter Drucker, en su obra Management Challenges for the 21st Century, afirmo que: «La productividad del trabajador del conocimiento es el mayor de los desafíos del siglo XXI. En los países desarrollados, es el primer requisito para su supervivencia. De ninguna otra forma pueden esperar mantenerse y mucho menos mantener su liderazgo y sus estándares de vida».

Pues bien, el trabajo de la era del conocimiento es muy diferente del trabajo de la productividad tradicional, y esto es porque:

  • Por primera vez en la historia de la humanidad, el trabajo deja de ser evidente, es decir, no siempre está claro qué es lo que hay que hacer. (se requiere mucho más análisis).
  • La primera consecuencia de que el trabajo no sea evidente es que, para poder hacerlo, primero hay que definirlo. Entender esto es clave, porque definir el trabajo es a su vez un trabajo. Es un trabajo adicional y exclusivo del trabajo del conocimiento.
  • Adicionalmente el hecho de que el trabajo no sea evidente lo vuelve automáticamente no predecible.
  • Tampoco es evidente cuándo puede darse por finalizado el trabajo. los criterios que definen el «cuándo está hecho» no son siempre únicos sino fruto de una decisión basada en el conocimiento, la experiencia y las expectativas.
  • El contexto del trabajo No es estable, hay urgencias no previstas, reuniones no planeadas, sistemas que fallan, dependencias, cambio de prioridades, etc.
  • Y lo más importante, consecuencia de todo lo anterior, hay mucho mas trabajo por hacer que tiempo para hacerlo.

Quiero detenerme en ese ultimo punto, en el pasado un trabajador de una planta de producción, que sabia muy bien cuantas unidades de X debería producir al día o al mes, alcanzado ese numero sabia que su trabajo ya estaba listo, cualquier extra era aumento de productividad. Tu como trabajador del conocimiento cuantas veces al terminar tu día puede decir ¿termine mi trabajo?, de hecho, probablemente te des cuenta que nunca termina, que nunca esta listo, que tu trabajo se acumula y acumula y siempre hay más.

Fíjense en lo que digo, en el trabajo del conocimiento siempre habrá cosas que hacer y esto nos lleva a la realidad de que no podemos hacer todo.

¿Entonces como es la productividad en la era del conocimiento?

En este nuevo tipo de trabajo, se es más productivo y eficaz cuando se “hace lo que hay que hacer”, entendiendo que “lo que hay que hacer” es aquello que nos acerca más a nuestros objetivos, y dejar de hacer o sacrificar aquellas cosas que no. ¡Y esto es a todo nivel!

¿Cuál es el equipo ágil más productivo y eficaz?

¿El que produce más funcionalidades de software como loco o el que produce las funcionalidades clave que hacer que el producto cumpla sus objetivos?

¿Cuál es la organización más productiva y eficaz?

¿La que tiene 100 iniciativas en su portfolio y de ellas el 20% están atrasadas del año anterior y tiene a su talento distribuido porcentualmente en 3 o 5 proyectos o aquella que sabe priorizar y tiene en su portfolio activas solo aquellas iniciativas mas importantes y que realmente lo acercan a sus objetivos estratégicos, mejorando así el foco y distribución de su talento?

“start less, doing more”

Referencias

Deuda Técnica ¿Qué es y cómo gestionarla?

La Deuda Técnica es un tema recurrente en los equipos agiles que desarrollan software o productos digitales, y también es recurrente el no entender realmente lo que es y no gestionarla.

¿Entonces que es?

Es un concepto en el desarrollo de software que refleja el costo implícito del trabajo adicional causado por elegir una solución fácil (o que no cumple con todo técnicamente) en lugar de utilizar un mejor enfoque que tomaría más tiempo. La deuda técnica se puede comparar con la deuda monetaria, ya que, si la deuda técnica no se paga, puede acumular ‘intereses’, lo que dificulta la implementación de cambios más adelante o incluso problemas. La deuda técnica no abordada aumenta la entropía del software.

La deuda técnica no es necesariamente algo malo, lo malo es no entenderla y no gestionarla.

He visto a muchos equipos llamar deuda técnica al trabajo pendiente, historias o PBI que no alcanzaron a terminando durante el Sprint, eso es trabajo pendiente no deuda técnica.

La deuda técnica es Técnica, es decir no es visible para el usuario/cliente hasta que esta nos cobra, algunos ejemplos:

  • Desarrollar un portal o funcionalidad que soporte una recurrencia de 10 transacciones, pero se sabe que en el futuro deberá soportar 500. Entonces un equipo podría decidir caer en deuda técnica y entregar la funcionalidad operativa, sabiendo que solo soporta una recurrencia de 10 pero que deberán mejorarla a 500, ¿Qué pasa si no pago esta deuda técnica? Pues cuando mas usuarios comiencen a usar la funcionalidad la experiencia será terrible y sufrirán errores, caídas, etc.
  • Desarrollar un App, con una estructura de código, módulos, archivos deficientes. Quizás por presiones de negocio, tiempo se hace sin un diseño correcto técnicamente y se libera funcionalmente. Deuda técnica acá es corregir la estructura y diseño internos del código (patrones), ¿Qué pasa si no pago? La App probablemente seguirá creciendo con la misma mala estructura, lo que hará más difícil mantenerla y mas propensa a errores (modificas un elemento y se estropean 3), aumentaran los costos de mantenimiento, necesitara mayor QA y el cliente/usuario recibirá mas lento actualizaciones o actualizaciones con errores.

Como vemos, la deuda técnica de un producto digital o sistema puede afectar:

  • Su performance o rendimiento.
  • Su mantenimiento y evolución.
  • La seguridad.
  • La experiencia.

Por otro lado, hay 4 formas de clasificar la deuda técnica, respecto de cómo esta surge.

Para Finalizar, ¿Cómo gestionarla?

1° La deuda técnica debe ir en el Product Backlog como otro Product Backlog Item y debe priorizarse para hacerse cargo de ella durante algún Sprint. (Mientras antes mejor)

2° El Product Owner debe entender la deuda técnica para tomar decisiones, no necesita entender la profundidad técnica, pero si el impacto que tiene un su Producto y el que tendrá en sus Clientes/Usuarios.

Una buena técnica para el punto 2, que tome de https://www.linkedin.com/in/jemdjelal/ son las historias de usuario negativas, este es el formato:

Si no hacemos esto < Acción requerida para eliminar la deuda técnica>
se producida el siguiente impacto < performance, seguridad, mantenimiento, etc.>
y eso resultara en <Disminución de alguna métrica del producto> y/o <Impacto Monetario>

Estos conceptos y otras técnicas son enseñados y practicados en mis Workshops:

https://fabianthinking.com/scrum-in-action/

https://fabianthinking.com/product-ownership-in-action/

Saludos

¿Qué es la Agilidad realmente, un tema de Software?

Pues este tema, no es tan fácil de tratar, hay muchas miradas y también cierto fanatismo a veces ciego. Pero realmente me interesa educar y quiero que se entienda, por eso para comenzar vamos con un poco de historia.

Febrero 2001 – 17 Representantes de Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming y otros simpatizan con la necesidad de una alternativa a los procesos de desarrollo de software pesado basados en documentación. Y firman el mal llamado Manifiesto Ágil.

Agosto 2011 – Se publica en The Wall Street Journal el artículo “Why Software Is Eating The World“

Y efectivamente así fue, ya antes de la publicación del articulo en The Wall Street Journal el Software se venia comiendo al mundo y se veía como crecían compañías como Google, Facebook y Twitter por nombrar algunas.

Se popularizaron mundialmente las nuevas formas de hacer Software y así como el Software se comió el mundo también lo hicieron Scrum, XP, el mal llamado Manifiesto Ágil, etc.

Y para muchos esta es toda la historia y el origen de la Agilidad.

Voy a complementar un poco esa línea temporal con lo siguiente:

1991 – Se creó un proyecto de industria / gobierno que se realizó en la Universidad de Lehigh con el objetivo de identificar el futuro de la frontera competitiva en 2005. Este proyecto dio origen al concepto de Agile Enterprise. Las predicciones se basaron en observaciones de que el entorno empresarial se estaba volviendo menos estable, que las fuerzas impulsoras hacia una mayor incertidumbre estaban y continuarían acelerándose, y que las organizaciones actuales no estaban equipadas para operar en estas condiciones.

1996 – Desde el planteamiento de Agile Enterprise, muchos investigadores corporativos, universitarios e iniciativas gubernamentales, se juntaron para desarrollar un modelo de referencia integral de Agile Enterprise el cual se presento en 1996 en The Agility Forum. http://www.parshift.com/docs/aermodA0.htm

De hecho, pre-firma del manifiesto ágil, se pueden encontrar una serie de papers relacionados a estudios de la agilidad en empresas de manufactura y el como desarrollar la agilidad empresarial en operaciones y logística con el soporte de tecnologías de información:

https://www.researchgate.net/publication/3847469_Framework_for_the_development_of_agile_manufacturing_enterprises

https://www.researchgate.net/publication/235290021_The_Twenty-first_Century_Enterprise_Agile_Manufacturing_and_Something_Called_CALS

https://www.researchgate.net/publication/240259815_Enterprise_agility_A_view_from_the_PRISM_lab

¿Y entonces?

Quiero dejar en claro y el principal objetivo de este Post, es enseñar que la Agilidad o Agile es un tema que se hablaba ya desde antes del Manifiesto para el desarrollo ágil de software, y se discutía en un contexto empresarial , por tanto, compete a toda la organización.

¿Qué es la Agilidad ?

Es la capacidad de adaptarse al cambio, de manera efectiva, en un entorno cambiante. Permitiéndose así seguir compitiendo (generando valor) y mantenerse relevante. Es lo que hacen los equipos ágiles, abrazan el cambio y la incertidumbre, y la enfrentan con la auto-organización, la mejora continua y el empirismo.

¿Que es la Agilidad Empresarial u Organizacional?

Acá lo explica Chistopher Worley

Otra Definición:

http://www.businessdictionary.com/definition/organizational-agility.html

¿Con esto quiero decir que toda la organización debe hacer Scrum? (Como alguna vez me dijo un experto en agilidad, que me discutía que la agilidad no aplicaba a la gente de contabilidad)

Pues No, no digo que toda la organización deba hacer Scrum, de hecho, he escrito anteriormente “Mal llamado manifiesto ágil” porque su nombre realmente es “Manifiesto para el desarrollo Ágil de Software” y aplica perfecto al mundo del software, pero no a toda la organización.

La agilidad empresarial, por así decirlo “es una ciencia en desarrollo”, todavía estamos descubriendo nuevas formas de estructura organizacional, de toma de decisiones, de gestión del cambio, de liderazgo, etc.

Y si tiene que ver con equipos agiles autogestionados, pero también con la forma en que se toman decisiones en la organización y se definen prioridades, en cómo se ejecuta el liderazgo, en cómo se capturan ideas, se exploran soluciones, se conecta con el cliente y se orquesta la organización en base a objetivos estratégicos derribando silos operacionales.

El movimiento ágil (y con movimiento ágil me refiero al impulsado por el https://agilemanifesto.org/), ha hecho tremendos aportes en la agilidad empresarial, Primero al mostrar resultados, Segundo por poner primero a las personas y los equipos como base fundamental de la agilidad y Tercero porque sus principios fundamentales orientados a las personas, abrazar el cambio, mejora continua, etc. han impulsado otros movimientos como:

https://www.agilehrmanifesto.org/

agile finance, agile operations, agile leadership, etc.

Para Concluir

La agilidad es un tema que compete a toda la organización, y como agilidad empresarial es una de las capacidades organizacionales vitales para competir y mantenerse relevante en los contextos actuales cambiantes, donde la tecnología cambia frecuentemente, habilita a que aparezcan nuevos jugadores en la industria (que pueden cambiar las reglas del juego) y crea a un cliente mucho mas empoderado, informado, más difícil de fidelizar y que constantemente quiere más.

Toda transformación digital debe entender lo que es la agilidad empresarial y buscar desarrollar esa capacidad organizacional, en caso contrario necesita replantearse su estrategia de transformación.

Saludos!

Referencias

El libro más antiguo que conozco de agilidad empresarias es de uno de los lideres del The Agility Forum y es del año 2001 (la versión Kindle que pongo es del 2007)

Liderazgo para la agilidad empresarial del 2006, versión Kindle 2007

Business Agility del 2009

Los más recientes

10 Errores Comunes de Equipos Agiles

Y que provocan la desilusión de la agilidad

En esta entrada solo describiré los principales síntomas que tienen los equipos agiles y el contexto que los rodea, como indicadores de altas posibilidades de desilusión o fracaso.

  1. No entender como líderes y organización el rol del Scrum Master y del Product Owner.
  2. Esperar los rendimientos de un equipo ágil y lo que dice la literatura, de un equipo que acaba de empezar y que claramente, no es ni equipo, ni ágil.
  3. Exigir velocidad, cuando el equipo esta rodeado de un contexto en el que la gestión de las ideas y del producto esta lleno de burocracias y pasos y cuando el equipo entrega algo ese algo pasa por un proceso largo de aprobaciones y burocracia (Correr en el Bus).
  4. Medir el éxito como una Feature Factory (Output) y no respecto de los resultados (Outcome).
  5. Formar y lanzar Scrum Teams (Scrum Master, Dev Team, Product Owner) sin experiencia ni acompañamiento de alguien con experiencia real.
  6. No dar espacio ni tiempo para la mejora continua del equipo.
  7. No educar a los stakeholders en agile.
  8. Poco involucramiento de los stakeholders y líderes alrededor del equipo.
  9. Seguir gestionando como Proyecto y no como Producto.
  10. Creer que agile o Scrum es un Método y como método la única implicancia es el seguimiento de pasos para lograr sus beneficios (nada mas lejos de la realidad).

¿Cuál de estos síntomas tiene tu equipo y organización?

¿Esta tan mal que los tenga?

Desde mi punto de vista no, mas bien, en mi experiencia estos síntomas lo sufren todos los equipos y organizaciones que inician con agile, el problema no es tener estos síntomas, el verdadero problema es no verlos o aceptarlos con resignación sin buscar el cambio y eliminación de cada uno de ellos.

Un buen libro

¿Qué es realmente la Transformación Digital?

Pues claramente es la palabra de Moda, el desafío de muchas organizaciones y el nuevo negocio de muchas consultoras y expertos en transformación digital.

La mal llamada transformación digital viene impulsada por la cuarta revolución industrial, que tiene sus cimientos en la internet y tecnologías de información. Si, la internet globalizada, revoluciono las formas de comunicación y de interacción cliente – empresa. Permitió el surgimiento de los punto Com y el comercio electrónico y es el principal hilo conductor que permite que hoy puedas hacer prácticamente todo desde tu celular o computadora. La internet fue y es uno de los principales medios que permitio desarrollo de las tecnologías digitales de la cuarta revolución industrial, revolución que hoy continua su camino con tecnologías como Internet of Things, Machine Learning, Artificial Intelligence, Mobile, Cloud, Augmented Reality, etc.

¿Es solo un tema de Tecnología?

Si y No.

Si, por que efectivamente todas las revoluciones han sido impulsadas por tecnologías, de hecho, en su libro Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages de Carlota Perez , describe 5 revoluciones tecnológicas o eras tecnológicas  que tuvieron un impacto socio-económico en el mundo.

Pasando por el uso del agua (ríos, canales) como fuente de energía, luego la era del carbón y la máquina de vapor, posteriormente el acero, la electricidad y la ingeniería pesada, para luego pasar a la era del petróleo, los automóviles y la producción en masa hasta la era actual de la información y telecomunicaciones.

Cada una de estas eras que tienen diferentes tecnologías, tiempos y periodos de desarrollo, comparten 4 estados de evolución:

  • Irruption: Una nueva tecnología prometedora aparece, se genera un crecimiento explosivo en su inversión, compañías innovadoras invierten en ella y demuestran resultados.
  • Frenzy: Las inversiones alcanzan un nivel de exuberancia irracional. Las organizaciones corren y compiten por adoptar la tecnología y las nuevas formas de trabajo, muchas expectativas iniciales se verán decepcionadas.
  • Turning Point: Es el punto decisivo de crash económico, donde muchas compañías e industrias fallan en adoptar las nuevas tecnologías, lo que conducirá al colapso de las burbujas creadas por la especulación financiera.
  • Synergy: Se produce un crecimiento robusto, construido sobre la infraestructura de instalación. La tecnología se adopta ampliamente en toda la economía y conduce a un crecimiento fundamental en una “nueva economía”.
  • Maturity: En la madurez, la tecnología ve rendimientos decrecientes. Las principales compañías se han fusionado y se han convertido en oligopolios, reduciendo la ferocidad de la competencia y un interés común en márgenes de beneficio cómodos.

Y No, porque cada revolución o Era provoco cambios sociales, culturales y económicos a escala mundial.

Y por sobre todo en nuestra era actual, la era digital, que ha sido el periodo de evolución tecnológica mas exponencial, impactando a la misma velocidad las formas de comunicación, las formas de interacción humana, las formas de educación, ha pasado el poder de negociación a los consumidores, cambio el concepto y valor de la privacidad, la forma de hacer política, la forma de hacer noticias, formas de trabajo, etc. Y es que es muy difícil predecir hoy, como seguirán cambiando las cosas en 10 años mas las tecnologías digitales.

Entonces ¿Qué es la Transformación Digital?

La mal llamada transformación digital, es el desafío actual de las organizaciones para competir y mantenerse relevantes en la era digital. Y la palabra Transformación no es menor, es lo que realmente hace la diferencia.

Lo que debemos entender como compañías es que:

  • No es solo una mejora operacional y tecnológica.
  • No se trata de comprar las tecnologías de moda, si no de entenderlas y sacarles ventaja constantemente.
  • La competencia cambio, ahora las compañías ya no compiten a escala nacional, si no, que la globalización, las plataformas y los nuevos modelos de negocio han hecho que ahora pierdas clientes contra grandes players que originalmente no eran tu competencia.
  • El poder de negociación y la información esta del lado de los clientes y es cada vez más difícil fidelizarlos.
  • Tu mercado será cada ves más competitivo y estas obligado a buscar nuevos mercados.
  • La ventaja competitiva ya no es lo mismo que antes, su concepto y vida útil cambiaron.
  • Ya no solo debes mirar o cuidarte de las grandes compañías, las Startup y Fintech tienen el poder de cambiar las reglas del juego.
  • Las formas de hacer negocio, estrategia, gestión, liderazgo, etc. ya no son las mismas que te permitieron ser la empresa que eres hoy.

Lo que debemos preguntarnos:

  • ¿Cómo compito en un entorno donde las variables cambian constantemente?
  • ¿Cómo uso realmente las tecnologías para diferenciar mi negocio actual o llegar a nuevos mercados?
  • ¿Cómo entiendo y me conectado con mis clientes constantemente para ofrecerles servicios y experiencias digitales?
  • ¿Cómo puedo cambiar mi interacción con proveedores y competidores para mantenerme relevante en el juego?
  • ¿Cuánto tiempo seguiré confiado y estático hasta que un nuevo competidor cambie las reglas de mi industria?
  • ¿Cómo podemos conectarnos mejor con nuestros colaboradores, generando y gestionando el talento?
  • ¿El liderazgo y cultura de mi compañía, realmente va acorde a los desafíos que enfrentare?

La verdadera transformación digital es más sobre desarrollar capacidades organizacionales como la agilidad empresarial y la innovación, que permitan a las organizaciones adaptarse a los cambios en los mercados y al surgimiento y aprovechamiento de nuevas tecnologías, con estrategias de entendimiento y conexión con los clientes para mejorar sus propuestas de valor o desarrollar nuevas (customer centric), donde las verdaderas ventajas competitivas (difíciles de replicar) están en el liderazgo y cultura de la organización. Y menos sobre canales digitales para servicios y productos que siguen siendo tradicionales.

Lo primero es lo que realmente hace la diferencia y permitirá a la organización seguir compitiendo y mantenerse relevante, lo último es solo la puesta al día.

Referencias

https://www.amazon.com/Technological-Revolutions-Financial-Capital-Dynamics-dp-1840649224/dp/1840649224/

Charla de Carlota Pérez respecto de la revolución tecnológica actual y sus cambios socio-económicos

https://www.researchgate.net/figure/Carlota-Perez-view-of-technological-revolutions_fig1_51986252

https://www.researchgate.net/figure/The-phases-of-technology-life-cycles-Source-Carlota-Perez_fig1_39993531