Buscar en Gazafatonario IT

domingo, octubre 09, 2022

De historias de usuario a historias de persona

 Y una forma más de delimitar y hacer pequeñas las historias de usuario

El problema actual

Dividir historias de usuario se ha convertido en un dolor de cabeza para los practicantes ágiles, principalmente para quienes usan esa técnica como motor para describir las necesidades de los usuarios y las características finales de los productos.

Lo voy a decir de otra forma: en mi trasegar diario con equipos y empresas que acompaño en el uso del enfoque y prácticas y marcos de trabajo ágil, he visto que dividir historias de usuario es algo de lo que todos hablan y tratan de practicar, pero les está costando.

Una de las causas de fondo de todo esto es la subvaloración que se le ha dado a la práctica de historias de usuario. Por ser algo tan sencillo, tan liviano, se estudia con poco detalle, de manera superficial y muy rápido. Los practicantes ágiles apenas si le están dedicando algunos minutos con la creencia de que ya conocen todo lo que deben conocer al respecto. Pero no es así. De ser algo tan simple, pasó a ser algo tan poco entendido y muy mal practicado. Quizás pasa lo mismo que con Scrum, liviano y fácil de entender, pero difícil de llegar a dominar.

Voy a ir más a fondo: el problema no es dividir historias de usuario en sí. Es tener historias de usuario lo suficientemente pequeñas, pero de Valor para el negocio y para el usuario, que se puedan elaborar en muy poco tiempo, desde unas pocas horas, hasta dos o tres días máximo, teniendo en cuenta iteraciones cortas de 10 días. Y cuando digo 2 o 3 días como máximo, me refiero a que la historia queda Terminada, cumple con todos los criterios de aceptación y con todas las condiciones de la Definición de Terminado para las historias de usuario individuales.

Entran las historias de persona

Soy Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una transferencia de dinero a mi nieta sin tener que ir al banco. No quiero exponerme a un contagio y ya no tengo fuerzas para esperar de pie haciendo largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.

Quiero hacer la transacción desde mi celular o en el PC de la casa.

Debe ser fácil de realizar porque no soy experta en el uso de estos dispositivos.

Quiero hacerlo de manera segura y rápida. Que no me roben mi platica.

 

Miguel es periodista. Viaja continuamente. Quiere saber cuándo le han consignado sus honorarios y sus gastos de viaje para llevar un control estricto de sus ingresos y gastos.

Miguel quiere recibir información de las consignaciones en su celular, quizás a través de mensajes de texto.

El mensaje debe incluir información sobre el valor de la consignación, el concepto por el cual se hizo y la fecha y hora de esta.

Miguel quiere que nadie más pueda tener acceso a esa información en caso de que se le extravíe el celular.

Aquí hay dos historias de usuario, dos historias, 2 relatos desde el punto de vista muy particular y hasta íntimo de dos personas. Tienen nombre propio, atraviesan vicisitudes específicas, necesidades singulares. Requieren que se cumplan algunas condiciones que consideran valiosas. Estas representan el éxito de su experiencia de cliente usando productos de alguna corporación o empresa. Son historias de persona.

Las historias de persona son concretas, en contraposición a las abstracciones naturales de una historia de usuario que señalan o lidian con, por ejemplo, Amas de Casa, Empleados, Clientes, Jubilados, trabajador autónomo o free lance, entre muchos otros. La misma historia permite conocer qué hace la persona, cómo lo hace, con quien lo hace, qué información intercambia y con quién la intercambia o quién es el receptor de esta. De alguna manera también deja ver sus principales problemas o inconvenientes al hacer lo que hacen. Es como si el equipo de trabajo, incluso los interesados y el mismo Product Owner o Product Manager, lo estuvieran viendo en acción, algo que se ha perdido en las últimas décadas en pro de prácticas que, de distintas manera, impiden el contacto o el acercamiento de quienes hacen productos con los consumidores o usuarios de estos.

Las historias de persona comienzan con la “persona” que originó la necesidad, con nombre y características demográficas únicas. Viene de la práctica User Persona. Esta persona tiene una identidad única y esto delimita el ámbito o el alcance de la historia y, por consiguiente, de la característica del producto que un equipo está forjando. He usado esta técnica en los últimos años y he comprobado que, en general, las historias resultantes son pequeñas, siguen siendo de valor y, efectivamente, se pueden labrar en muy pocas horas o, a lo sumo, en muy pocos días, junto a otras historias en una iteración breve.

Esta es una regla general, por supuesto. Es posible que algunas de estas historias todavía tengan que dividirse aún más para que se puedan trabajar en un sprint corto sin el riesgo visible de que no se puedan terminar junto a las demás.

No es la primera vez que uso el concepto de persona relacionado con las historias de usuario. El primer bloque o nodo de mi User Story Conversation Canvas es sobre las personas. Sobre esto explico que “el equipo debe conocer muy bien el perfil de estas personas, los aspectos personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos y servicios para seres humanos. El equipo debe sentir que conoce al usuario”.

El enigma del “usuario” en la historia de “usuario” y cómo resolverlo

Imagen de OpenClipart-Vectors en Pixabay
No me malentiendan. He escrito lo suficiente sobre historias de usuario, incluso he publicado un libro con mi gran amigo Jorge Abad sobre estos menesteres cuya edición en inglés recientemente fue referenciada por la Agile Alliance. No hay un problema de fondo con el usuario en la historia de usuario. Pero conocer más al usuario sí ayuda.

En general, un “usuario” es un concepto abstracto con cierto nivel de vaguedad que se puede automatizar o categorizar para trabajar con él, pero su uso ha mostrado ser de mucha valía en los negocios y en la industria. Un “usuario” describe actividades y responsabilidades de un grupo de individuos. Escribí ampliamente sobre eso en mi libro Asuntos de la Ingeniería de Software, cuando hacía referencia a los Casos de Uso de Ivar Jacobson y a un elemento fundamental de los casos de uso: el Actor. Y un usuario es precisamente eso, un actor. De hecho, decía en una de mis Lecturas Fundamentales, en noviembre de 2006 que “Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve”, nada diferente de lo que estoy diciendo hoy nuevamente, 16 años después.

Un usuario es un rol que se define a través de una tarea o acción concreta o un grupo de funciones con mucha afinidad, que son ejecutadas por personas durante el consumo de un producto o el uso de un sistema. Sin embargo, los usuarios no son algo tan simple como pueden parecer para el practicante ágil inexperto y aún para muchos expertos. Los usuarios pueden llegar a gozar de una ambigüedad tal que vuelven problemática la obtención de historias de usuario pequeñas y de valor. He revisado conjuntos de historias de usuario donde los usuarios exhiben incompatibilidades entre ellos o donde unos tienen sobrecarga de responsabilidades o donde se presenta cierta tensión entre unos usuarios y otros, además de algunas otras tramas inesperadas.

En particular, la ambigüedad es un aspecto destacado para el diseño de productos porque nos muestra una fotografía de la ausencia de precisión que una persona, sus colegas e incluso todos en la empresa pueden llegar a tener sobre los roles y sus responsabilidades. He dedicado más de dos décadas a estudiar este fenómeno y he tenido experiencia de primera mano cuando de usuarios o consumidores y sus responsabilidades o acciones se trata. Por ejemplo, he leído, debatido y ayudado a mejorar decenas de historias de usuario con usuarios como “cliente”, “visitante”, “abonado”, “cliente potencial”, “interesado” o “solicitante” que dicen muy poco o nada sobre el contexto de uso de la historia de usuario y que obstaculizan de distintas formas la división de una épica en historias más pequeñas y trabajables.

Una de las pocas formas que me ha funcionado para resolver todo esto es que todos los interesados en el producto, es decir, el equipo de producto y el equipo de trabajo en pleno vean al usuario en acción. Hay disponer de la logística necesaria, a lo Ojo del Gran Hermano, para que todas estas personas tengan la oportunidad de ver a sus potenciales usuarios o consumidores trabajando. ¿Qué hacen? ¿Cómo lo hacen? ¿Cuándo? ¿Con quién lo hacen? ¿Qué información intercambian unos con otros y quienes de estos también son usuarios y quienes no? ¿Cuáles son sus principales problemas o las dificultades más frecuentes que impactan su desempeño? ¿Cuáles son los criterios de éxito que tienen en cuenta en su accionar habitual?

Resolver estas cuestiones es de suma importancia antes de pensar en la solución que necesitan estos clientes o consumidores.

De vuelta a las historias de persona

Imagen de Gerd Altmann en Pixabay

Hola, soy Mabel, Gerente de Crédito Hipotecario. Quiero un informe de solicitudes de crédito para realizar proyección de aprovisionamiento y trabajar en las próximas campañas con el área de Marketing.

El informe debe ser diario y debo poder clasificarlo por tipo de crédito, pero también quiero tener un resumen por tipo de crédito y la tendencia respecto a los últimos 5 días.

También quiero clasificarlo por tipo de solicitante y tener un subtotal de lo solicitado por tipo de solicitante.

De manera predeterminada quiero ver el informe del día inmediatamente anterior, pero también quiero tener la posibilidad de ver el informe de una fecha anterior.

He estado usando una ligera variación de la forma Davies-Cohn para representar las historias de persona:

Como [usuario] Quiero [esta característica] Para [lograr este beneficio u objetivo]

que puede llegar a ser innecesariamente prolija y repetitiva, aunque muy fácil de entender y de usar en muchos entornos dada la gran difusión y documentación que ha tenido en las últimas dos décadas.

Pero bien podría usar muchas otras grafías para representar historias de usuario. Por ejemplo, puedo usar las historias de usuario estilo BDD, como en:

Registrar datos personales.

Dado que Ibeth, asesora de prensa de la alcaldía, solicitante de crédito de libre inversión, se mantiene muy ocupada en su día a día y tiene poco tiempo para hacer gestiones de manera presencial, ingresó los datos solicitados y existe al menos un dato sin diligenciar. Cuando ella intente enviar los datos, entonces recibirá un mensaje informándole de los datos sin diligenciar y estos datos aparecerán marcados en rojo y no se podrán almacenar los datos, aunque se le permitirá almacenar los datos de manera temporal si ella así lo prefiere.

En conclusión, hay tantas o más formas para representar historias de persona que para representar historias de usuario. Y una vez más, noten amigos lectores que uso el término “representar” como lo he hecho desde hace años, para alejarme y alejarlos de la limitante y problemática expresión “escribir historias de usuario”. Aquel es más abierto, indica que se pueden usar no solo palabras sino también figuras y simbología de distinto tipo que la mente y la imaginación sean capaces de retener. No sobra decir aquí que lo más importante de las historias de persona también es la conversación que se mantenga alrededor de cada una de ellas.

Las personas son instancias de los usuarios. Son ejemplos. Y los ejemplos te ayudan a encontrar inconsistencias en las historias y porque te delimitan un contexto. Pero sobre todo, los ejemplos son buenos porque te ayudan a iniciar conversaciones.

Y bueno, además del innegable beneficio del tamaño (sucinto, en el sentido de pequeño) de las historias de persona, de su contexto concreto e individualizado, otras ventajas de este instrumento derivado son los siguientes:

·       Ayudan a definir un mejor y más aproximado Producto Mínimo Viable, ya que, por naturaleza, estas historias de persona son mínimas y minimalistas, en el sentido de que son esenciales y eliminan o ayudan a eliminar lo que puede llegar a ser superfluo en el producto, es decir, nos ayudan a eliminar desperdicio, a elaborar el producto correcto desde el comienzo.

·       Las personas son, por naturaleza, colaborativas. Cada una usa o consume un producto de una manera diferente, pero entre todas colaboran para que el consumo o utilización del producto se maximice.

·       Ayudan a que quienes se encargan de exponer los productos a sus usuarios, es decir, aquellos que tienen la difícil pero fascinante labor de brindar la mejor experiencia de usuario y de cliente posible, tengan éxito, dado que las personas se conocen mejor, son más concretas, generan más empatía y puedes imaginarlas con una sonrisa cuando el producto las esté ayudando a lograr sus propios objetivos. Las personas nos permiten conectarnos emocionalmente con ellas, los usuarios abstractos quizás no.

·       Las historias de persona ayudan a iniciar y a mantener conversaciones más fluidas y verosímiles que las historias de usuario. Incluso nos permiten crear otras personas (personajes de la historia) para los eventos alternativos de la historia o para los procesos de manejo de excepciones en esta.

·       Las personas son más imaginables o creíbles o comprensibles que los usuarios porque tienen un rostro y un nombre y una identidad.

Llamado a la acción

Finalmente, te invito a que uses este modelo de historia, de historia de persona. Eso sí, cuéntame y cuéntanos cómo lo podemos extender y practicar mejor. Y no dejes de contactarme con cualquier inquietud que tengas respecto a este o a cualquiera otra inquietud sobre las historias, sean de usuario o de persona.

viernes, septiembre 30, 2022

La dimensión desconocida de las transformaciones ágiles (#Agiles2022)

 

En el pasado Ágiles Latinoamérica 2022 (#Agiles2022) en Armenia, Colombia, tuve la oportunidad de conducir una sesión sobre transformaciones ágiles.

La llamé La dimensión desconocida de las transformaciones ágiles y fue más que todo una conversación con los asistentes sobre este asunto de cómo abordan o cómo están afrontando las empresas actuales esto del cambio organizacional y cultural.

Específicamente, la transformación ágil.

El punto de partida fue precisamente esto de la “instalación de la agilidad” como un paquete (de software). Los líderes organizacionales quieren que el cambio ocurra en “un dos por tres”, muy rápido, con mínimo esfuerzo y esto es simplemente un imposible.

Entonces presenté en primicia mundial este “instalador” de agilidad, a la mejor usanza de un paquete tipo ERP pero para agilidad y Lean y muchas de las prácticas y conceptos que giran alrededor de estos.

Muchos me han preguntado que si hay un video de la charla, no lo hay, fue una conversación amena, donde también participó mi gran amigo Jorge Abad, con quien facilité otras sesiones en el evento. Pero lo que sí tenemos es un video del instalador, aquí se los dejo.

Algunos otros aspectos de los que hablamos en la sesión fueron:

El Manifiesto por la transformación frágil, una suerte de antimanifiesto que abstrae la realidad de cómo estamos ayudando a las organizaciones con sus programas de cambio y cuyo contenido encuentras en:

http://www.gazafatonarioit.com/2019/01/algunos-errores-comunes-que-estan.html

Finalmente, algunas conclusiones, a manera de cosecha:

Las empresas exitosas no hablan de #agile o #scrum, ¡simplemente lo hacen!

Y mientras muchos #coaches y empresas se enfocan en #frameworks, roles y nuevos procesos, quienes quieren alcanzar el éxito saben que todo comienza con las #personas.

“Si deseas una cultura ágil con alta autonomía e innovación, debes contratar para ello. Los grandes líderes contratan a los grandes talentos, los grandes talentos permiten una gran cultura”.

Las personas y la #cultura no son una ocurrencia tardía, son la BASE de la agilidad. Todo lo demás se basa en esto (o se desmorona, si no tienes la gente y la cultura).

Pero si contratas personas principalmente por sus habilidades o para obedecer órdenes, ninguna cantidad de Scrum, Kanban, Scrum@Scale o SAFe te ayudarán.

¡Como #AgileCoach sé que todo comienza con las personas y la cultura! Aquí es donde debe comenzar la transformación.

 

¿Estuviste en el #Ágiles2022 en Armenia? ¿Qué te pareció? Por favor, déjamelo saber en el foro.

English Version 

I leave here the English version of the installer.

miércoles, septiembre 14, 2022

Apuntes sobre transformaciones ágiles IV: los expertos en agilidad, la resistencia al cambio y el pensamiento generativo

 

Image by Gerd Altmann from Pixabay 

Algo debemos estar haciendo bien.

Hace una década, los estudios de adopción ágil decían que la cultura organizacional de entre 6 y 8 de cada 10 empresas estaba en oposición a los valores y principios ágiles. Hoy ese número ha descendido hasta 4 de cada 10, según el último reporte del estado de agilidad.[1] De hecho, en el reporte del estado de adopción de agilidad, más significativo para Latinoamérica dado que alrededor del 75 % de los encuestados somos de esta región, este número bajó del 34 % al 12 % en 2022.[2]

Pero todavía falta.

Hoy por hoy, muchas empresas consideran el cambio organizacional, sobre todo este de la transformación al enfoque ágil, como un proyecto que los lleva de un estado A o punto inicial a un estado B o punto final. Eso está bien. Al menos para empezar. Lo que conocen la mayoría de las empresas es la gestión por proyectos y en principio no hay que atribular a sus líderes con cosas más allá de lo conocido.

Pero rápidamente debemos ayudar a que eso cambie. Ayudarles de distintas maneras a que entiendan que el cambio es un proceso continuo y lo que buscamos con él es alinear y realinear a la organización a un entorno en constante cambio. Un Líder Transformacional sabe que la empresa debe estar en un estado de Emergencia Ágil todo el tiempo.

Entran los expertos en agilidad

Image by Gerd Altmann from Pixabay 
En general y, en el mejor de los casos, estas organizaciones trabajan con compañías consultoras a las que acuden para contar con ayuda experta en los temas que los angustian. Normalmente, estos expertos llegan investidos de un aire de pericia y con habilidades novedosas para la organización.

Diestros en pensamiento ágil, maestros en pensamiento Lean y Kanban, consejeros en liderazgo y cambio, coaches y mentores empresariales ágiles, especialistas en marcos de trabajo y modelos como Scrum, Nexus, LeSS, SAFe, Scrum@Scale, UnFix, Spotify, Design Thinking y otros “Design”; Senséis de los OKR, los VSM (Value Stream Maps), el feedback transparente y continuo, y de las mejores retrospectivas; y hasta guías espirituales. Clasificados por niveles de experiencia: ultra seniors, semi seniors, juniors y aprendices.

Estos expertos llegan enumerando a diestra y siniestra todos los modelos de gestión del cambio conocidos y otros no tan conocidos: la organización empieza a escuchar apellidos como Kotter y siglas como ADKAR, reencauchados pero que siempre vienen bien, como Drucker, modelos como LCM (Lean Change Management) y técnicas como Management 3.0, junto con un sinnúmero de ideas, prácticas, propuestas y formas de hacer las cosas preplanificadas aún antes de tocar las puertas organizacionales.

No son recetas, anuncian, pero sí lo son.

Muchas veces, esos expertos en agilidad llegan de compañías que no practican lo que predican. Empiezan a hablar de aplanar la organización y de trabajo en redes, de manera colaborativa, pero vienen de un silo en su propia empresa, la misma cuya estructura está lejos de ser considerada como plana o donde se puedan registrar comportamientos de trabajo en clanes o de adhocracia, y donde muchas veces nadie más los conoce. Otras veces llegan de consultoras que están muy distanciados de conocer los problemas diarios de sus clientes.

La gran receta de cambio, anuncian a los cuatro vientos empresariales, es entonces:

1.    Reconocer o definir el problema a resolver

2.    Analizar y diagnosticar (los infames assessments)

3.    Identificar posibles soluciones por parte de los expertos

4.    Plasmar y ejecutar un plan de acción

Con los consabidos objetivos de:

·       Disminuir el time-to-market

·       Mejorar el clima laboral

·       Reducir los desperdicios en los procesos

·       Aumentar el RoI

·       Alinear las áreas de TI con el negocio

Entre tantos otros. Incluso, en los últimos años, todo esto está cubierto del manto de los OKR. OKR para esto y OKR para lo otro. OKR para la estrategia y OKR para la operación. OKR para los equipos y OKR para las personas. Y más.

Soy John Connor: si estás leyendo esto, eres de la resistencia

Image by Gerd Altmann from Pixabay 
Durante la última década he estado en muchas de esas posiciones de las que hablo. Soy de esos consultores “expertos” que van por las empresas con buenos deseos de aportar algo al mejoramiento de estas. Y he llegado a una conclusión perentoria:

Los modelos planificados y preparados de cambio suscitan resistencia.

Lo sabíamos hace mucho: las personas no batallan, al menos no mucho, cuando de usar prácticas ágiles se trata, por eso se les da muy bien el Scrum y el SAFe y los OKR y todas esas. Pero las personas sí libran una guerra “fratricida” contra el cambio de mentalidad. La amígdala cerebral hace aquí su trabajo muy bien hecho y genera un temor que muchas veces es incomprendido, pero natural. Es un miedo cuyo propósito es la supervivencia laboral, por decirlo de alguna manera. La amígdala logra o ayuda a que las personas eviten situaciones, otras personas, objetos o aspectos que pongan en riesgo máximo su estabilidad profesional, económica, social y su salud.

Los expertos en agilidad también llegan con la vacuna antiresistencia, en una o dos dosis, con miras a una dosis de refuerzo más adelante. Entonces hablan de la curva de innovación de Rogers y de los conservadores y ultraconservadores (mayoría tardía y rezagados) en la empresa y qué hacer con ellos a continuación. Pero muchas veces, los expertos no alcanzan a detectar, mucho menos a ver, esta resistencia como una retroalimentación a gritos por parte de los involucrados. De hecho, algo que ocurre mucho en las iniciativas de cambio es que los ciclos de retroalimentación son extensos o no se presentan del todo.

Sí, también nos da miedo la retroalimentación.

Finalmente, en los entornos complejos y altamente complejos que caracterizan las organizaciones en las que trabajamos habitualmente, los desafíos están desbordados de alta incertidumbre y ambigüedad, de falta de precisión. En estos ambientes, las soluciones a esos retos emergen vía experimentación. Hay que establecer una hipótesis, realizar un experimento y analizar los resultados en retrospectiva. Y esto hay que hacerlo de manera frecuente, implacablemente.

Entran el pensamiento generativo y el triple impacto

Image by Gerd Altmann from Pixabay 
Algo que he aprendido en la última década es que los procesos de cambio requieren primero de una TPP o transformación personal profunda. Esta TPP requiere de adquirir atributos o especias que nos permitan a cada uno de los líderes del cambio y a cada uno de los líderes de la organización y quizás a cada persona de esta comenzar a producir ideas generativas, a tener un pensamiento emergente, uno cuya capacidad de originarse sea cruda pero flexible, un pensamiento que a su vez habilite nuevas formas de pensar y de hacer las cosas, incluso que genere emociones, información y conocimiento de manera frecuente. Esto hará que germinen formas novedosas de cultura.

Junto a este pensamiento generativo, bien puedes tener en cuenta las siguientes recomendaciones:

1.    Los expertos están allí para proporcionar y facilitar espacios de diálogo entre las personas y equipos comprometidos con el cambio, no para realizar el cambio en sí mismo. Hasta tanto ellos mismos no se comprometan, más que involucrarse, o hasta tanto no formen otros expertos internos a la organización, no estarán haciendo bien su trabajo desde el exterior. Y eso no ocurrirá hasta tanto no conozcan en detalle la cultura organizacional, la forma de hacer las cosas en los distintos niveles corporativos y los innumerables escenarios que sirven de atmósfera a las tareas diarias en la empresa.

2.    Acorta los ciclos de retroalimentación, tanto como a todos los días. Estos ciclos no deben ser más extensos que unos muy pocos días de trabajo. Interioriza, practica y promueve una cultura de feedback efectivo y frecuente. De hecho, en vez de “retroalimentación”, promueve en tus equipos las conversaciones de mejora. Estos son diálogos donde la información se transmite de tal forma que recaiga sobre la huella que deja el comportamiento del otro en el objetivo trazado y en ti mismo, y donde esa información se comparte sin juicios.

3.    Ya lo dije. Pero insisto. El experimento y la experimentación implacable son el camino en entornos VUCA/BANI y lo que venga al respecto en el futuro próximo. La complejidad de los problemas y de los eventos que ocurren en una organización cuya base de trabajo es el conocimiento es extremadamente alta. Déjenme repetirlo con un sinónimo: la complejidad inherente a las empresas de conocimiento es considerablemente alta. Y por ello, para resolver cualquier cosa, para sobrepasarlos, se hace necesario una mentalidad diferente, un pensamiento adaptativo que incluya el Trabajo Conducido por Hipótesis (TCH), uno donde continuamente se establezcan hipótesis y se conduzcan experimentos que prueben esas hipótesis o las refuten. Esto es promover una cultura proclive al ensayo y al error, una cultura donde estos últimos incluso tengan sus quince minutos de fama.

4.    Siempre hablamos de interiorizar, practicar y promover comportamientos que en el mediano plazo, y más en el largo plazo, empiecen a cambiar la cultura de la empresa. En este contexto, promover significa hacer viral esos comportamientos, es decir, viralizar la cultura. Difundirla. Distribuirla a todos los rincones de la organización. Lograr que cada ser humano que trabaja en, que entrega algo a, o que recibe algo de la empresa, respire el mismo aire cultural, en distintos tonos, colores y sabores, pero bajo el mismo manto al fin y al cabo, el manto de la cultura.

Advertencia: es muy posible que en el camino hacia esa nueva cultura, tengas que exigirla de alguna manera. Eso sí, nunca, antes de haberla demostrado con ejemplos y más ejemplos y de haberte asegurado de que los demás la hayan entendido.

5.    Hoy, ningún proceso de cambio será efectivo ni contribuirá al desarrollo personal, profesional y motivacional de los integrantes de una empresa y de sus clientes, si no tiene en cuenta el triple impacto de las organizaciones Brillantes. Para una transformación auténtica, una que encauce el propósito superior de la empresa no solo hacia lo financiero, sino también hacia lo social y lo ambiental, los agentes de cambio y los líderes transformacionales deben sembrar el gen que recodifique la organización con un ADN cuya doble hélice esté constituida por la adaptabilidad y el pensamiento generativo. Si no piensas en el beneficio social y ambiental, y te quedas solo en el necesario fruto económico, es muy probable que el cambio que quieras originar no tenga trascendencia más allá de los límites de la empresa.

En este sentido te invito a conocer más del LBAM o Lean Business Agility Model, un modelo creado por mi gran amigo Jorge Abad [3] y en cuyo desarrollo he colaborado. El LBAM es un modelo simplificado que reúne en una única perspectiva la agilidad a nivel estratégico, táctico y operativo; también, la agilidad en los equipos transversales y de soporte; la Mentalidad Lean-Agil, el Liderazgo Transformacional y de Crecimiento soportando todas las funciones y áreas de la organización, con foco en el cliente, como la mayor obsesión de todos en la empresa. [4]

Es definitivo: “Un negocio saludable no puede existir en una sociedad enferma”.[5]

Como siempre, no dejes de contarme en el foro cómo te va con todo esto.

Referencias

[1] 15th Annual State Of Agile Report. 2022. digital.ai.

https://digital.ai/resource-center/analyst-reports/state-of-agile-report

[2] Agile Adoption Report 2021. 2022. Certiprof.

https://certiprof.com/pages/certiprof-agile-adoption-report-2021

[3] Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital. 2022. Jorge Abad.

http://www.lecciones-aprendidas.info/2022/07/zarpamos-ya-esta-disponible-mi-nuevo-libro-nuevas-aguas-nuevos-navios-nuevos-navegantes-business-agility-con-notas-sobre-transformacion-digital.html

[4] Lean Business Agility Model. 2022. Jorge Abad y Lucho Salazar.

http://www.gazafatonarioit.com/2022/09/lean-business-agility-model.html

[5] Drucker Report 2020 * Drucker Institute. 2020. La frase fue escrita por Peter Drucker en 1974. A healthy business, a healthy university, a healthy hospital cannot exist in a sick society.”

Sobre los apuntes anteriores

I. Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html

II. Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto

http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

III. Apuntes sobre transformaciones ágiles: lo bueno, lo malo y lo feo

http://www.gazafatonarioit.com/2020/10/apuntes-sobre-transformaciones-agiles.html

 

viernes, septiembre 09, 2022

Aprende Scrum con Lucho Salazar

Scrum es un marco de trabajo liviano e iterativo que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente.

En esta clase en línea aprenderás un poco más sobre el marco de trabajo Scrum para poder aplicarlo mejor en tu entorno de trabajo.



Si quieres saber más sobre Scrum, con mi gran amigo y coautor Jorge Abad estamos pensando en facilitar un nuevo curso de Scrum a finales de octubre o principios de noviembre en Medellín (presencial) y queremos saber si hay interesados. Si te llama la atención, por favor, diligencia este breve formulario para enviarte información.


miércoles, septiembre 07, 2022

Lean Business Agility Model

 

El Lean Business Agility Model o LBAM es un modelo simplificado que reúne en una única perspectiva la agilidad a nivel estratégico, táctico y operativo; también, la agilidad en los equipos transversales y de soporte; la Mentalidad Lean-Agil, el Liderazgo Transformacional y de Crecimiento soportando todas las funciones y áreas de la organización; y toda la organización con un foco en el cliente, como la mayor obsesión de todos en la organización.

Además, el modelo tiene en cuenta y se fundamenta desde su raíz en lo que se conoce como el triple impacto: financiero, ambiental y social. Esta tríada se debe convertir en el cuadrante dominante de las organizaciones que tienen o están pensando tener o proponer acciones basadas en en el enfoque ágil y lean.

Es imperativo: para construir, orquestar y participar en ecosistemas organizacionales con propósito, las empresas necesitarán recodificarse genéticamente para infundir agilidad y adaptabilidad en su ADN. Una organización que base su desarrollo en el triple impacto tiene que ser robusta pero ágil y adaptable, modular pero estrechamente unida. Al pensar en el beneficio social y en el ambiental, además del rendimiento financiero, no solo será capaz de detectar y responder a tiempo y con clase a las necesidades del cliente, sino que también desarrollará habilidades y destrezas para construir y orquestar con voluntad e inspiración todo su ecosistema organizacional. La evolución, transformación y adaptación de las empresas que usen el Lean Business Agility Model será implacable y estas organizaciones autocontendrán las competencias suficientes y necesarias para ayudar a otras a pasar a un modelo de crecimiento sostenible.

En particular, Una buena Business Agility debe llevar a la organización a mantener los recursos disponibles para lograr el éxito financiero, generar ingresos y crear valor económico para todos los interesados. De esto se trata el impacto financiero.

Mientras tanto, el impacto ambiental busca, entre otras cosas, que Las métricas y OKR que uses deben considerar el medio ambiente. Mide el impacto que una organización tiene en el medio ambiente a través de factores como la huella de carbono, la contaminación del aire y del agua, la producción y el reciclaje de desechos, la fuente responsable de materiales, la conservación de la biodiversidad, etcétera.

Y más allá del ROI habitual, busca el ROI Social, el impacto social. Decimos que la agilidad es sobre personas, pero ¿nos estamos teniendo en cuenta realmente? El foco principal de las organizaciones que usan el LBAM son las personas con las que interactúan directa o indirectamente, , incluidos sus propios empleados, clientes, proveedores y otros interesados en la comunidad local y el entorno regional e internacional en general.

Orígenes del Lean Business Agility Model

Este modelo es fruto de un trabajo de muchos años acompañando equipos y organizaciones en su trasegar hacia la agilidad y la agilidad empresarial. Está basado fuertemente en:

·       El pensamiento Lean

·       Los valores y principios ágiles

·       El Corazón de la Agilidad

·       Agilidad Moderna

·       Las tres leyes de ágil*

·       Y la experiencia de sus autores.

Las tres leyes de la agilidad

Estas son las tres leyes de la agilidad de Steve Denning que sirven como uno las bases del modelo:

·       La ley del Cliente: una obsesión con la entrega de valor a los clientes como el todo y el fin de toda la organización;

·  La ley del Equipo Pequeño: la presunción de que todo el trabajo debe ser realizado por pequeños equipos autoorganizados, que trabajan en ciclos cortos y se centran en brindar valor a los clientes; y

·   La ley de la Red: un esfuerzo continuo para eliminar la burocracia y la jerarquía de arriba hacia abajo para que la empresa funcione como una red interactiva de equipos, todos enfocados en trabajar juntos para entregar un valor creciente a los clientes.


En general, el modelo:

·       Es una propuesta, de muchas que existen

·       No es la solución ni la respuesta a todo

·       Empieza con unos principios esenciales

·       Promueve la mejora continua

·       Hemos observado que sirve en cualquier empresa

·       Complementa otros modelos y puede ser complementado por otros modelos e instrumentos

·       No es un marco de trabajo (framework)

·       Es y trataremos de mantenerlo liviano y simple

·       Está compuesto de patrones y abstracciones de la realidad

·       ¡Es nuestro! Es latino. Tiene nuestra idiosincrasia.

Principios del LBAM

El modelo se fundamenta principalmente en unos principios que seguimos y que constituyen la columna vertebral del mismo. Tratamos de no contribuir a la sobredecoración de la agilidad y creemos firmemente que estos principios mantienen simple y limpio el modelo, a la vez que habilitan a quienes lo usen para dar el primer paso en las organizaciones que buscan una mejor business agility.

Estos son los principios:

·       Buscamos siempre generar valor para los clientes y atrapar valor para la organización.

·       Nos ocupamos de:

o   la sostenibilidad organizacional (incluye lo financiero y lo cultural),

o   la sostenibilidad Ambiental, y

o   la sostenibilidad social.

·       Seguimos los principios Lean y Ágil (colaboración, entrega de valor, reflexión, mejora continua, flujo, eliminación de desperdicios).

·       Creemos que la base de una buena Business Agility son los equipos lean-agile, pequeños, multidisciplinarios y autogestionados.

·       Promovemos estructuras cada vez más planas pues hemos aprendido que mejoran la agilidad, aunque creemos que el reto más importante no es la estructura, sino la colaboración. Maximizar la generación de valor a través de la adecuada colaboración es la clave.

·       Todos los equipos y áreas tienen foco en el cliente externo e interno.

·       Todos los líderes ejemplificamos la mentalidad Lean - Ágil y sabemos cómo usarla en su contexto.

·       Los líderes promovemos una mentalidad de crecimiento, un liderazgo transformacional y una cultura de innovación.

·       La agilidad es la misma y buscamos constantemente formas adecuadas para aplicarla en nuestra área, equipo, función o flujo de generación de valor.

·       Creemos en la mejora continua sobre la mejora discontinua. Buscamos cómo mejorar al menos una vez al mes la Agilidad Estratégica, Táctica y operativa, de equipos transversales y soporte; equipos y áreas de trabajo. Y conjuntamente nos reunimos como organización a mejorar al menos una vez trimestralmente.

·       Pocas métricas significativas, que midan lo que importa, compartidas por todos, son la mejor estrategia de alineación.

·       El uso y exploración frecuente de tecnologías que mejoren la entrega de valor, la cultura de la innovación y experimentación son esenciales para responder, e incluso liderar el cambio.

- Jorge Abad y Lucho Salazar -



Para continuar en contacto con el modelo y sus autores, puedes compartirnos tus datos y comentarios en:



Para ver la presentación del modelo:

Usamos un tablero Mural para elaborar la presentación. Puedes ver y descargar el PDF resultante aquí: