domingo, diciembre 04, 2022

Video: Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO





___

Frase sobre priorización

----

"Construir algo que no fue correctamente priorizado es destruir valor para la organización" 
- Jorge Abad

----


"Building something that was not correctly prioritized is destroying value for the organization" 
- Jorge Abad

---

10 Anti-patterns (bad practices) in prioritization of Product Owners, PMO and VMO


Hello everyone

One of the factors that most destroys agility is the lack of adequate prioritization patterns according to the context in which it is located, that is, both upstream (1) and downstream (2) practices are used (which even from the good intention) destroy value for the organization. In general, we can incur:

  • Building unnecessary things
  • Building things that are necessary but worthless
  • You don't build what's important
  • We let ourselves be carried away by intuition
  • We let ourselves be carried away by authority
  • We let ourselves be carried away by feelings of friendship or enmity
  • etc.

We destroy value and generate waste by dedicating time, effort and money from business areas, execution areas and suppliers in things that should not have been developed and relegating others, which would allow better financial performance or customer satisfaction.

---
---
---
(and one of mine)

"Building something that was not correctly prioritized is destroying value for the organization"

---

Below, I share some of the anti-patterns that I have observed when prioritizing both PMO - Project Management Office -, VMO -Value Management Office- and Product owners, and that I promote to be removed in processes of agile transformation or team agile coaching.  

I hope they will help you advance in the knowledge of better ways to prioritize the work to be done.

Expect more articles on this topic.

Agile greetings,

Jorge Abad.


 

References, notes, or comments

  1. Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
  2. Downstream: where the product is being developed, and the solution team builds the different functionalities.

sábado, diciembre 03, 2022

De Colección: 10 Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO



Hola a todos,

Uno de los factores que más destruye la agilidad es la carencia de patrones adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En general podemos incurrir en:

  • construir cosas innecesarias
  • construir cosas necesarias pero carentes de valor
  • no se construye lo realmente importante
  • nos dejamos llevar por la intuición
  • nos dejamos llevar por la autoridad
  • nos dejamos llevar por los sentimientos de amistad o enemistad
  • etc.
En últimas, destruimos valor y hacemos que se genere desperdicio por dedicar tiempo, esfuerzo y dinero de áreas de negocio, áreas de ejecución y proveedores en cosas que no debían haber sido elaboradas y relegando otras, que permitirían un mejor desempeño financiero o de satisfacción del cliente.


---
---


(y una mía)

"Construir algo que no fue correctamente priorizado es destruir valor para la organización"
---

A continuación, te comparto algunos de los antipatrones que he observado al momento de priorizar tanto por PMO - Project Management Office -, VMO -Value Management Office- y Product owners, y que promuevo sean removidos en procesos de transformación ágil organizacional o de acompañamiento de equipos.

Espero te sirvan para avanzar en el conocimiento de mejores formas de priorizar el trabajo a realizar.

Espera más artículos sobre este tema.

Saludos ágiles,

Jorge Abad.


--- Ver video explicativo aquí ---


Referencias, notas o comentarios

  1. Upstream: donde se prioriza el proyecto, producto o iniciativa por parte de la PMO, VMO o quienes se encargan de priorizar el portafolio.
  2. Downstream: donde se está desarrollando el producto, y los equipos de solucionadores a construyen las diferentes funcionalidades.

viernes, diciembre 02, 2022

Definición de Ágil, en mis Propias Palabras

 Hola a todos

Confieso que me gusta mucho ir a las fuentes, e investigar qué dijeron, qué opinaron y cómo nacieron los conceptos. Dentro de esa búsqueda y entendimiento de lo ¿Qué es Ágil?, siempre uso la definición oficial de la Agile Alliance:

Traducido de (1)

-----

¿Qué es Ágil?

Ágil es la capacidad de crear y responder al cambio. Es una forma de lidiar con un entorno incierto y turbulento y, en última instancia, de tener éxito en él.

Los autores del Manifiesto Ágil eligieron "Ágil" como la etiqueta para toda esta idea porque esa palabra representaba la adaptabilidad y la respuesta al cambio que era tan importante para su enfoque.

Realmente se trata de pensar cómo puede comprender lo que está sucediendo en el entorno en el que se encuentra hoy, identificar qué incertidumbre enfrenta y descubrir cómo puede adaptarse a eso a medida que avanza.

-----

Tomado de (1)
-----

What is Agile?

Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.

The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.

It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.


-----

Pero cuando me piden que lo diga en mis propias palabras, lo expreso más o menos de la siguiente forma:


"Ágil es trabajar de forma eficiente e inteligente, sin desperdicio, logrando con el mismo o tal vez menos esfuerzo: más valor, mejor productividad, mejores resultados y felicidad para equipo. Revisando frecuentemente, si estamos avanzando en la dirección correcta que necesitan nuestros clientes o si requiere que nos adaptemos."
 - Jorge Abad


----

"Agile is working efficiently and intelligently, without waste, achieving with the same or perhaps less effort: more value, better productivity, better results and happiness for the team. Checking frequently, if we are moving in the right direction that our clients need or if it requires us to adapt."
 - Jorge Abad
---

Llamado a la acción

¿Te animarías a crear tu propia definición de ágil? Es un buen ejercicio individual y de equipo. Eso sí toma siempre el manifiesto ágil, los principios ágiles y la definición de ágil de la Agile Alliance, puede que te lleves grandes excelentes sorpresas.


Saludos ágiles
Jorge Abad.


Referencias

  1. Agil 101 -  https://www.agilealliance.org/agile101/

domingo, noviembre 27, 2022

Agile Manifesto. Lost in Translation (and Business Areas Lost in Context)


En estos más de 12 años de trabajar directamente con la agilidad y más de 20 como profesor universitario, constantemente en entrenamientos y cursos he hablado del manifiesto ágil, y cuando lo hago sigo el siguiente proceso:

  • Muestro el manifiesto en inglés (no difiero mucho con la traducción) - agilemanifesto.org 
  • Lo presento en español -  agilemanifesto.org/iso/es/manifesto.html 
  • Lo explico y discuto.
  • Explico quiénes son los que firmaron el manifiesto ágil e invito a que los busquen y sigan en redes, blogs, empresas, Twitter, Facebook, Youtube, LinkedIn (como dicen modernamente, los invito a stalkear).
  • Luego paso a los principios en español - agilemanifesto.org/iso/es/principles.html y similarmente los explico y discuto en detalle.
Y aunque he brindado cursos de agilidad y de SAFe (www.scaledagileframework.com) en inglés, me ocurre como a todos, a veces pasamos por encima de las cosas sin hacernos conscientes de ellas. 

Bueno, quiero compartirles algo que me impactó luego de 20 años de explicar el manifiesto ágil a mis estudiantes (1); existe una discrepancia radicalmente importante entre el texto en inglés y español en el tercer principio del manifiesto, el cual reza:

En inglés:
  • Business people and developers must work together daily throughout the project.
En español
  • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Se observa que en la traducción hacia el español se pierde el must, el cual denota obligatoriedad o imposición. Considerando lo anterior, unas posibles traducciones más fieles al texto en inglés podrían ser:

  • Los responsables de negocio y los desarrolladores debemos trabajar juntos diariamente durante todo el proyecto.
  • Los responsables de negocio y los desarrolladores tenemos que trabajar juntos diariamente durante todo el proyecto.
  • Los responsables de negocio y los desarrolladores tenemos la obligación de trabajar juntos diariamente durante todo el proyecto
Completamente diferente, ¿No es cierto? Una sola palabra genera una realidad distinta en español, como dicen en coaching “el lenguaje crea realidad”, y nos hace ver que es conditio sine qua non no funciona la agilidad que promovemos, pues partimos de la base que quienes hacemos agilidad cumplimos los 4 valores y 12 principios, y fallar en el involucramiento diario de la gente de negocio generará que fallemos en nuestro propósito de construir soluciones que coincidan con las necesidades de los clientes y usuarios.

De igual forma, cambié la palabra cotidiana (2) por diariamente, aunque significan lo mismo, quiero hacer este hecho aún más explícito.

Otra traducción un poco débil dentro del manifiesto ágil se encuentra en el segundo valor, el cual expresa: 

En inglés
  • Working software over comprehensive documentation
En español
  • Software funcionando sobre documentación extensiva
Según el diccionario Oxford son sinónimos de comprehensive: complete, full (3); por lo cual unas traducciones más cercanas a la intención en inglés podrían ser:
  • Software funcionando sobre documentación completa
  • Software funcionando sobre documentación integral

Pongamos foco en el punto de dolor

No dudo que al igual que yo, muchos instructores, agile coaches, scrum masters, practicantes ágiles, áreas de TI, áreas de negocio, etcétera, han leído y usado la traducción del manifiesto ágil en español interpretando ese trabajamos juntos sin el énfasis que le pusieron los autores en inglés, pero el hecho más preocupante es que existen muchas áreas de negocio y clientes que insisten en hacer agilidad sin estar involucradas, delegando a los equipos de software la construcción de la solución, sin entender que es un factor de éxito en escenarios de incertidumbre y de construcción incremental. 

Cabe adicionar que varios informes del caos del Standish Group  - www.standishgroup.com - a lo largo de las últimas tres décadas han demostrado que los proyectos de software más exitosos son aquellos en los que está el cliente involucrado y comprometido diariamente.

Áreas de negocio perdidas en el contexto del desarrollo de software

Aunado a lo anterior, existe desde las áreas de negocio (y aun desde algunas vicepresidencias, direcciones o gerencias de TI) una ingenuidad sana pero que a la vez trae consecuencias negativas en los procesos de construcción de soluciones de software, y es creer que hacer software es un proceso predictivo, estable y que puede ser delegado sí existe una buena documentación.

Existen varios factores, que compiten en contra de la predictibilidad y la estabilidad de los procesos de software:

  1. El proceso de desarrollo software es un proceso de adquisición de conocimiento (4), entre más se interactúa con el cliente, mejor se entiende su necesidad y lo solución es moldeada de acuerdo con el entendimiento de esta. 
  2. Como lo afirmaba Watts S. Humphrey (conocido como padre de la calidad del software) "Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después que los usuarios hayan usado el sistema", por lo tanto, implica una validación de la constante del software para descubrir la solución deseada (5).
  3. La complejidad creciente del software, la cantidad de conexiones de este y las posibles interacciones y comportamientos requiere de un proceso de acompañamiento de quien lo solicita.
  4. De una solución de software solo el 20% es usado frecuentemente, 30% usado algunas veces, 50% poco o nunca usadas (6). Por lo tanto, si queremos llegar a construir software más rápido debemos evitar a toda costa construir software que no será usado y esto solo se logrará con un ejercicio constante de priorización y validación por parte del cliente del área usuaria.
  5. Los requisitos de software son inestables en un mundo cambiante o VUCA (7). Actualmente los requisitos tienen una vida útil de seis meses o menos (8). Ver imagen continuación
En conclusión, el proceso moderno de hacer software, es decir, como se hace hoy en el Siglo XXI, se podría resumir en:

Define un poco* de software a ser construido
↪ Construye lo poco anteriormente definido
↪ Entrega a los usuarios lo construido lo antes posible para validar si es lo requerido o no

*Entiéndase poco como la cantidad de requisitos suficientes para un mes de trabajo (o menos) de un equipo de desarrollo de software.

Cerrando

Si eres cliente o del área de negocio, cuando se están creando soluciones de alto valor para la organización que cuestan varios cientos de miles de dólares y que van a generar un impacto en la satisfacción, en la eficiencia o en el entorno, se requiere no solo involucramiento, sino compromiso.

Imagen generada con Dall-e (9)

Algunos consejos para ti, sí eres de negocio o Product Owner:
  • Participa activamente en las sesiones del marco de trabajo
  • Prioriza por valor el trabajo a realizar o Product Backlog
  • Proporciona retroalimentación sobre el software funcionando
  • Interactúa diariamente con el equipo
  • Interactúa con tus usuarios y conócelos, valida sus expectativas y valida el uso de la aplicación una vez la comiencen a usar
  • Si careces de tiempo para estar con el equipo solucionador, y quieres entregar los requerimientos y que otros lo construyan sin tu compromiso; la agilidad y el construir soluciones de software de alto valor y retorno no es lo que tu o tu organizacion están buscando; y con seguridad construirás software de desperdicio.
Si eres del equipo solucionador, de TI o desarrollador:
  • Involucra y compromete al cliente
  • Muéstrale el valor de participar con el equipo
  • Enséñale a priorizar
  • Garantiza a que comprenda el valor de las entregas tempranas
  • Compártele experiencias de otras personas en la industria acerca de usar marcos ágiles
  • Instrúyele como puede generar valor más rápido con menos alcance
  • Convéncelo que en escenarios de incertidumbre su interacción diaria y continua es garantía de éxito.
  • Demuestra progreso con software de valor funcionando en periodos de un mes o menos, con preferencia al periodo más corto.

Ahora, respecto a las traducciones del tercer principio del manifiesto, usa la que mejor se adapte a tu entorno.



Saludos ágiles,

Jorge Abad.


Nota de agradecimiento

Quisiera agradecer a mi gran amigo Lucho Salazar, pues al momento de  hacer traducciones me ha hecho mucho énfasis en la rigurosidad de la traducción y respetar la intención del autor, por ejemplo, en la actual Guía de Scrum 2020, en la cual soy uno de los colaboradores bajo la guía de Lucho, y allí hemos puesto mucho esfuerzo en que las palabras en inglés sean lo mismo que en español, al igual que las frases e intención de los autores, algunos de los retos interesantes estuvieron con:
  • Openess, traducido como apertura normalmente, pero una traducción más fiel sería Franqueza
  • Accountability: que significa responsable de que algo se haga, aunque no sea el ejecutor, pero en español no tiene traducción directa y quedó con la palabra de responsabilidad que significa lo mismo, sea que se delegue o no.

Comentarios, referencias y aclaraciones

  1. Sí, es cierto, si estás haciendo cuentas, luego de firmado el manifiesto en el 2001 comencé a compartirlo en las clases de ingeniería de software y taller de ingeniería de software en la Universidad Eafit en Medellín www.eafit.edu.co 
  2. Cotidiano, na: diario - dle.rae.es/cotidiano 
  3. Comprehensive - https://www.oxfordlearnersdictionaries.com/definition/english/comprehensive_1?q=comprehensive
  4. Esta frase se la escuché a mi gran amigo y agilista Hernán Wilkinson y resueno bastante con ella.
  5. https://es.wikipedia.org/wiki/VUCA
  6. https://www.infoq.com/articles/contract-model-failure
  7. Imagen generada con Dell-e https://labs.openai.com/s/ml4XX2e8frHQ8yc2sRidpG9u
  8. Algunas imágenes de referencia
---

sábado, noviembre 05, 2022

Manual para Remar en Arequipe (Dulce de Leche) o Cómo ser Agile Coach (o Scrum Master) en Entornos Adversos a la Agilidad

 

Hombre remando en Arequipe -Creada con DALL-E (1)
Hola a todos,

Con frecuencia al hablar con Agile Coaches y Scrum Masters les digo que muchas veces nos encontramos en una organización en la que estamos 

¡Remando en arequipe! (2)

 o 

¡Remando en dulce de leche! (2)

haciendo referencia a que no es fácil el entorno en el que nos encontramos, y buscando generar cambios. Lo cierto, es que no es una buena noticia, pero ¡Para eso estamos!¡Para eso nos contrataron! Si fuera sencillo no estaríamos allí. para ayudar a las personas, equipos y organizaciones a reformular sus paradigmas y a encontrar formas mejores de interactuar y generar valor.

La resistencia al cambio es natural, no nos gusta cambiar, preferimos la inercia del estado en el que nos encontremos, la zona de confort o el statu quo; y si se quiere generar un cambio habrá que vencer dos fuerzas:

  • hacer un Δ (delta) de esfuerzo para cambiar de estado, es decir, salir de la zona de confort y
  • vencer el miedo a la incertidumbre de si ese nuevo estado es mejor que el actual o no.
Adicionalmente, está apareciendo otra fuerza para aquellos que estamos trabajando con la agilidad:
  • ya hemos estado ahí y no nos gustó (3)
Esta última se puede leer como: no supimos cómo avanzar o no nos acompañaron bien. Todo lo anterior se puede ver ilustrado en el siguiente análisis de campo de fuerzas de Kurt Lewin:

Cómo entonces generar el cambio

No hay una fórmula secreta para lograrlo, al leer sobre gestión del cambio y experimentar muchos modelos, voy a compartirte algunas estrategias que han servido:
  1. Identifica si existe alguna métrica, indicador, OKR, KPI, evaluación de desempeño en la que se puede incluir el propósito que quieres lograr. Es una de las más efectivas pues, hay una máxima de la gestión "Cómo me midas me comporto" (4) y esto ayudará en el propósito buscado. Bajo esta premisa, encuentra una buena métrica que ayude a generar los comportamientos adecuados, lo contrario, es peligroso.
  2. Usa el Método Kanban (5), pues este tiene un lema: "EMPIEZA CON LO QUE HACES AHORA" (el cual es cierto) y poco a poco introduce el método - te sugiero revisar con calma la referencia (5) en la zona de recursos y la 6)-.


  3. Aplica Agilidad Orgánica o Scrum Orgánico, es decir, invita a hacer retrospectivas máximo cada mes y ve introduciendo prácticas que el equipo vaya necesitando - ver referencia (7)-.
  4. Use el lenguaje tradicional para fuera del equipo, pero al interior use la agilidad - ver referencia (8) - 


  5. Logra que tu proyecto reporte resultados a quienes te contrataron, de forma que puedas informar avance, impedimentos o riesgos según se vayan presentando.
  6. Un último consejo, ponte en los zapatos de ellos, se Empático mas no Complaciente(9), y pregúntate:
    • ¿Por qué actúan de esa manera? ¿Qué les impide ayudar?
    • ¿Cómo son medidos?
    • ¿Qué sucede si acontece el cambio con los cargos de ellos?
    • ¿Tienen el conocimiento necesario?
    • ¿Cómo puedo ayudar desde mi experiencia aumentar el grado de consciencia respecto a la agilidad?
    • entre muchas otras.
  7. Declarar experimentos y buscar como implementarlos en la organización por tiempo corto. Lean Change Management es una buena opción para hacerlo:





Lo cierto, es que no hay una sola estrategia para motivar el cambio o generarlo. Es valioso que como agente de cambio estés monitoreando el entorno, tomando métricas, comparando versus líneas base e identificando efectivamente si la organización desea avanzar hacia la dirección deseada, en caso de que sí, persevera, en caso de que por un tiempo prudente (y ese solo lo sabes tu) observas que efectivamente no desea el cambio, entonces busca otra oportunidad en otra organización o equipo., 


Saludos ágiles,

Jorge Abad.


Referencias 

  1. Imagen creada en DALL-E https://labs.openai.com/s/MFYbemXGsB7HnPDnQfuZSZvD
  2. En Colombia el dulce de leche es conocido como arequipe.
  3. La Agilidad ha Muerto, ¡Larga Vida a la Agilidad!  http://www.lecciones-aprendidas.info/2022/05/la-agilidad-ha-muerto-larga-vida-a-la-agilidad.html
  4. Cómo me midas me comporto:  http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
  5. Método Kanban - https://kanban.university/
  6. Infográfico del método kanban:
  7. Unas notas sobre Scrum Orgánico / Agilidad Orgánica - http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html
  8. Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales - http://www.lecciones-aprendidas.info/2019/09/como-evitar-la-ingenuidad-agil.html
  9. Reflexión: Empático mas no complaciente - http://www.lecciones-aprendidas.info/2020/03/reflexion-empatico-mas-no-complaciente.html

jueves, noviembre 03, 2022

Video: Agilidad en las organizaciones y en HR (talento humano)

Hola a todos,

Les comparto esta interesante conversación con Juan David Botero CEO de Talento Cloud, sobre agilidad organizacional y agilidad en las áreas de talento humano conocida también como Agile HR.

Pueden acceder al video en el siguiente enlace: https://youtu.be/yDnvgryvBtc






sábado, octubre 08, 2022

RespuestasAgiles ¿Cómo pagar la deuda técnica?

La Excusa SOX

Constantemente en procesos de Transformación Agile-DevOps me encuentro con lo que he llamado: “La Excusa SOX*”, es decir, me objetan alivianar los procesos diciendo: - “el proceso no puede ser más liviano porque SOX no lo permite”, a lo que respondo:


“Si tu freno para tener procesos más livianos (LEAN-Agile-DevOps) son todos los formatos de SOX ¿Cómo hacen en AMAZON, NETFLIX, etc., para salir a producción CIENTOS de veces al día, sabiendo que son empresas mucho más reguladas, tienen SOX y están en la bolsa de Nueva York?”


Siempre concluyo que el problema no es la regulación, sino la mentalidad en áreas de riesgos y procesos al implementarla; y su falta de mejora continua buscando simplificar y automatizar cada vez más el proceso. 

*SOX: Ley Sarbanes-Oxley - https://es.wikipedia.org/wiki/Ley_Sarbanes-Oxley




jueves, octubre 06, 2022

El peligroso espejismo de la "Metodología Híbrida" en el mundo del software


Hola a todos

Hace poco tuve tres momentos en donde la metodología o enfoque híbridos de trabajo me los he topado y considero que es valioso escribir y aclarar sobre ellos:

Primer Momento: hablando a cerca del Lean Business Agility Model (LBAM) con el PMI Antioquia, me preguntaban mi opinión sobre el modelo híbrido, en esencia mi respuesta fue:

"Si lo que se está pensando es llevar prácticas de lo tradicional al mundo ágil, esto NO es exitoso, lo contrario sí puede serlo"

Segundo Momento: en varios clientes para los cuales trabajo me están comenzando a decir: "No, no somos ágiles, tenemos una metodología híbrida" y cuando voy a ver, están haciendo proyectos a alcance, tiempo y costo fijo por sprints, sobre lo cual hablaré más adelante.

Tercer Momento: en el reporte de Certiprof Anual - clic aquí -, el cual recomiendo ampliamente pues la mayoría de quienes lo respondemos somos latinos, y cuenta con interesantes hallazgos para nuestra cultura y región; Lucho Salazar y yo opinábamos sobre la aproximación híbrida en la ejecución de proyectos:

CertiProf Agile Adoption Report 2022

"Muchas organizaciones en su acercamiento a la hacia la agilidad han adoptado marcos híbridos, es decir, combinan prácticas ágiles y tradicionales; lo cual es ilustrado en la gráfica. Aunque este enfoque no es la mejor práctica, es un inicio que invita a seguir cambiando, pero si se continua allí puede constituirse en un riesgo a largo plazo, debido a que quienes abrazan la agilidad completamente logran aumentar entre tres a cuatro veces su productividad, tomando una ventaja creciente sobre las híbridas" - Jorge H. Abad L.

---

“Cada día un mayor número de organizaciones están trabajando con un enfoque Agile y Lean. El hecho de que la mitad del estudio los participantes respondieron que usar un enfoque híbrido es natural, dado que la mayoría de las empresas se encuentran actualmente en un proceso de cambiar de las prácticas tradicionales de gestión y ejecución a los basados ​​en el pensamiento ágil. Este es un proceso lento que puede llevar años. Las organizaciones no pueden y no debe comprometerse con un gran cambio o un cambio de "todo o nada", porque primero deben aprender a lidiar con los impactos del cambio y es mejor empezar poco a poco, con una o dos iniciativas. A partir de ahí, a medida que aprenden de las reacciones del entorno, pueden agregar nuevos equipos y áreas de la empresa al proceso. El hecho de que una de cada tres empresas ya esté utilizando un enfoque Agile es consistente con el trabajo que se ha estado haciendo desde la década pasada. Estas empresas han recorrido un largo camino para entender, internalizar, practicar y promover una cultura de colaboración y innovación, pilares esenciales de las organizaciones exitosas de hoy”. - Lucho Salazar

Pero vamos por partes, entendamos el por qué del título de este artículo.


¿Qué es una metodología híbrida?

Inspirado en la "Figure 2-7. Development Approaches del PMBoK 7.0

Un enfoque híbrido, está definido por: "Un enfoque de desarrollo híbrido es una combinación de enfoques adaptativos y predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o riesgo en torno a los requisitos. Híbrido también es útil cuando los entregables se pueden modularizar, o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente adaptativo." (1).

Por lo tanto, no es un enfoque donde nos estamos preguntando y validando constantemente "si lo que se está construyendo o entregando es la solución correcta", como ocurre en el mundo del desarrollo de software, pero tampoco se tiene completa certidumbre sobre el resultado final, un ejemplo podría ser el despliegue de un nuevo proceso organizacional, que implique construcción de instalaciones, capacitaciones, desarrollo de software (este software se debe desarrollar con una aproximación ágil) y construcción de máquinas; son varios frentes que se pueden modularizar para entregar valor de forma incremental.

Alguien dirá: ¿Pero en el desarrollo de una solución de software sabemos que módulos vamos a tener? Posiblemente sí, pero el enfoque ágil (adaptativo) te garantiza que no construyas software de desperdicio, y la constante repriorización y refinamiento del backlog, sumado al despliegue continuo de la solución (que te permite su validación) puede significar que se halló valor mucho antes implicando que los supuestos iniciales quedaron obsoletos, pero logrando economias mayores 60% debido a su enfoque basado en Pareto (2).


¿Por qué es un espejismo peligroso en el mundo del desarrollo de software?

Por las siguientes razones:

  • Es una zona cómoda: he observado que se denomina híbrido a trabajar en cascada en grandes corporaciones, de forma que ya no es necesario tener al usuario con el equipo, ni es requerido que validen las soluciones. es decir,
el mismo desperdicio de siempre,

requerimientos al inicio, esfuerzo del proveedor, controles de cambio y quejas del cliente porque no entregaron lo que se pidió. Por lo tanto,

 Híbrido es el nombre de la nueva cascada corporativa

Observo que son organizaciones que no aprendieron a trabajar de forma ágil, no saben como hacer ahorros con este enfoque (aún siguen diciendo que ágil es costoso, lo cual es falso), pero para no verse muy anticuadas llamando a su metodología tradicional o cascada, le llaman híbrida, la cual es un desperdicio de tiempo, dinero, y oportunidad de generar valor por donde quiera que se le mire.

  • Están poniendo reglas de cascada a proyectos ágiles:  he visto que se llama metodología híbrida al ponerle al desarrollo ágil las reglas de cascada, es decir, alcance, tiempo y costo fijo, pero eso sí, hecho en sprints, pero sin retrospectivas porque no es necesario aprender más ¡Plop! - recomiendo leer la referencia (3)-.
  • Se está perdiendo oportunidad de generar y atrapar más valor: las organizaciones al casarse con este modelo híbrido (insisto no veo problema con que sea algo temporal, lo que veo peligroso es que de allí no se evolucione), están perdiendo oportunidad de capturar valor y de generarlo a sus clientes y más temprano que tarde, organizaciones que realmente si ejecuten ágil de forma disciplinada les tomarán una ventaja exponencial, debido a que la agilidad bien practicada cuadruplica la generación de valor y la eficiencia de los equipos.

¿Cómo evitar el espejismo?

Hay varias estrategias que pueden ayudar en evitar el espejismo:

  • Comprender en que consiste la mentalidad lean-agile (3).
  • Comprometerse a ejecutar los proyectos ágiles (y por ende de desarrollo de software) con las reglas de ágil, de forma que se generen ahorros y altos impactos.
  • Si se tiene un proyecto tradicional y quiere volverlo híbrido, identifique posibles módulos, formas de generar valor temprano y retroalimentación valiosa en caso de que aplique; de manera que logre adaptaciones en caso de ser posible.
  • No lleve prácticas tradicionales al mundo ágil, es decir, planeación predictiva para el mundo del software, pues estas no van a servir.


Para cerrar, algunas ideas ágiles para el mundo tradicional

Como se ha argumentado en el artículo, llevar prácticas tradicionales al mundo ágil es desperdicio y fricción, pero existen prácticas ágiles que pueden mejorar el mundo tradicional, a continuación, algunas ideas:

  • tener dailys de sincronización del equipo de trabajo
  • hacer retrospectivas o sesiones de mejora con cadencia de al menos de una vez al mes.
  • usar backlogs y priorizarlos constantemente si la naturaleza del proyecto lo permite.
  • preguntar y preguntarse constantemente ¿si lo que se hace está generando valor? y corregir en caso de que no.
  • Identificar mínimos productos viables y liberarlos incrementalmente: 
    • Ejemplo 1: Una casa de campo de forma incremental y adaptativa (pues no se posee todo el dinero), un posible plan de releases puede ser:
      • Release 1 o MVP (PMV - Producto mínimo viable): La cocina, el baño, y una habitación para dormir.
      • Release 2: otro cuarto
      • Release 3: la sala
      • Release 4: la piscina
      • Release 5, etc, etc.
    • Ejemplo 2: Una unidad residencial de 12 torres
      • Release 1: torre 1 y 2 
      • Release 2: torres 2 y 3
      • Release 3: la piscina y el salon social
      • Release 4: no se realizó debido a cambios económicos del entorno.

RespuestasAgiles ¿Existen las Historias de Usuario Técnicas?

martes, septiembre 27, 2022

Cómo escribir un libro (de forma ágil) - Lucho Salazar, Juan Andrés Ochoa y Jorge Abad

Hola a todos

En el pasado Ágiles Latam 2022, luego de que varias personas se me acercarán a preguntarme cómo escribíamos tantos libros Lucho y yo, me decidí a incluir una sesión al final del día, de una forma improvisada, en total fuimos como 40 personas y la sesión la lideramos:

Este es el video:



Algunas notas:



Y algunas fotos de la sesión:











Agradecimientos a Edwin Trujillo - https://www.linkedin.com/in/edwin-trujillob/ por haber grabado este video.

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:
    • la sostenibilidad organizacional (incluye lo financiero y lo cultural), 
    • la sostenibilidad social.
    • la sostenibilidad ambiental,
  • 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í: