Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor

Hola a todos

Debido a recurrentes conversaciones y aclaraciones sobre:

• Épicas
• Historias de Usuario
• MVP (Minimun Viable Product o Producto Mínimo Viable)
• Agregar Valor
• Agregar Valor Incrementalmente
• y Scrum

Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

Comencemos.

Paso 1. Durante el Inception (9) se creó el siguiente User Story Map

Paso 2. Durante el Inception (9) se realiza la estimación de cada release

Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

Release 1 - MVP	7 sprints
Release 2	6 sprints
Release 3	6 sprints

Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:

Release	Épica	Historia de Usuario
Release 1 - MVP	Formato de solicitud básico	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados
	Validar referencia personales	HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Validación centrales de riesgo 1 y 2	Pendientes por definir (10)
	Calificación	Pendientes por definir (10)
	Creación del crédito	Pendientes por definir (10)
	Desembolso a cuenta propia	Pendientes por definir (10)

Release	Sprint	Historia de Usuario
Release 1 - MVP	Sprint 1	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge
	Sprint 2	HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud
	Sprint 3	HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Sprint 4	Pendientes por definir (10)
	Sprint 5	Pendientes por definir (10)
	Sprint 6	Pendientes por definir (10)
	Sprint 7	Pendientes por definir (10)

Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

Realmente no es un punto, son varios, veamos:

1. Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
2. El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
3. El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
4. Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
5. El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:
• Es en serio, las historias usuario tienen que ser pequeñas (clic aquí)
• Consejo: Que tus Historias de Usuario no sean como Bruce Willis "Duras de Matar" (clic aquí)
6. Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
7. Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
8. Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
9. El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
10. Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelantes. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volatil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial." 
11. Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
12. En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente:  "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".

Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad

Tu Radar de Madurez Ágil no es la Meta, el Objetivo es Generar Valor

Hola a todos

Por lo general cuando realizamos una evaluación (assessment) del nivel de madurez ágil de un

• rol, 
• equipo, 
• grupo de equipos, 
• programa,
• área de negocio,
• framework,
• cadena de valor (value stream), 
• u organización

es común el uso de los radares (es la práctica común). Y respecto a los radadres los hay para todos los gustos, una lista por la cual podrías empezar son:

• los propuestos y sugeridos por agilityhealth https://agilityhealthradar.com/radars/
• TeamHealth® Radar
• Remote Work Health Radar
• DevOps Health Radar
• Agile Release Train
• Lean Product Health Radar
• Program Health Radar
• Enterprise Business Agility Health Radar
• Para roles tienen
• Enterprise Business Agility Strategist Health Radar
• Agile Coach Health Radar
• Agile Leader Health Radar
• Product Owner Health Radar
• ScrumMaster-Health-Radar
• SAFe® Release Train Engineer Health Radar
• Los usados en SAFe https://www.scaledagileframework.com/metrics/ :
• Business agility self-assessment
• Lean portfolio management self-assessment
• Continuous learning culture self-assessment
• Organizational agility self-assessment
• Enterprise solution delivery self-assessment
• DevOps Health Radar
• Lean-Agile leadership self-assessment
• Agile product delivery self-assessment
• Team and technical agility self-assessment
• Los de La lista de chequeo de Scrum Roosmalen (clic aquí) traducidos Lucho Salazar con:
• Lo fundamental
• Scrum Esencial
• Los Roles
• Los Eventos
• Los Artefactos
• Impedimentos
• Estimaciones
• Velocidad
• Product Backlog
• Grafica de Trabajo Pendiente
• Scrum Diario
• Escalado
• Indicadores Positivos
• Distribuido
• Reuniones
• Equipo

Sin negar, que según las organizaciones he participado en el desarrollo de los propios según los aspectos y cultura predominante - es una tarea común en este proceso de agile coaching- .

Lo que esta bien con los radares

Los radares:

• ayudan a identificar gaps
• muestran áreas de trabajo en las cuales la industria, un rol o una práctica esta poniendo interés
• permiten al agente de cambio el siguiente paso hacia el cual avanzar.

Lo que está mal con los radares y los niveles de madurez

El problema se presenta cuando el modelo de madurez se vuelve el objeto de deseo organizacional, perdiendo de vista lo realmente importante:

• la generación de valor
• la reducción del time to market
• la innovación
• la supervivencia
• la capacidad de adaptarse al cambio
• la satisfacción del cliente.

Los problemas fundamentales que he observado con los radares y modelos de madurez, son los siguientes:

• Son estáticos y de mentalidad fija
• nos hacen creer que no hay "más allá" y que si logramos eso estamos en el cima del desempeño o el objetivo buscado
• quedan facilmente obsoletos, debido a requieren de agregar otro anillo u otro sector según se progresa en el conocimento o en la práctica
• pueden llegar a convertise en el objetivo en vez de ser un medio para la mejora
• proliferan y es probable que estemos cayendo en el problema de los estandares (ver chiste abajo)
• podemos estar midiendo muchas cosas sin generar resultado o perdiendo de vista lo importante

Qué hacer entonces

Tal como lo sugiere el título del artículo debemos enfocarnos primordialmente en métricas (valores que aumentan o disminuyen) que nos muestren si estamos o no generando valor, si estamos innovando, mejorando nuestra adaptabilidad y resilienciam, tales como:

• reducción del time to market (que cada vez sea menor 🡻)
• flujo de una pieza (que cada vez la unidad de generación de valor sea más pequeña y de a una pieza 🡻)
• cantidad de defectos (que cada vez sea menor 🡻)
• satisfacción del cliente interno (que cada vez sea mayor 🡹)
• satisfacción del cliente externo (que cada vez sea mayor 🡹)
• adopción de innovaciones propuestas (que cada vez sea mayor 🡹)
• salud, bienestar o felicidad de los equipos de trabajo (que cada vez sea mayor 🡹)

Esta forma de medir te moverá hacia la mejora continua de lo que estas buscando y tu objetivo será alcanzar la perfección tan deseada y sanamente inalcanzable (kaizen), y en consecuencia al tratar de mover estas métricas claves (aumentar o reducir su valor) hará que sistémicamente tomes decisiones que te dirijan hacia tu objetivo, con el beneficio adicional que este tipo de drivers nunca queda obsoleto.

Similar a como lo adopta el State of Devops (2), con 4 métricas puedes comprender cual es el performance de una organización respecto a este conjunto de prácticas o cultura:

Tomado de (2)

• Deployment frecuency 🡹 - Frecuencia de despliegues  
• Lead time for changes 🡻- Tiempo del proceso para cambios (desde el commit hasta producción)- 
• Time to restore service🡻 - Tiempo para restaurar el servicio
• Change failure rate 🡻- Tasa de cambios fallidos -  (aunque la verdad prefiero traducir esto como: tasa de problemas desplegados a producción)

Cerrando

No se trata pues de satanizar los radares, ¡No, ni más faltaba! pues estos sirven de guía, pero no podemos perder del foco de lo que buscamos, por lo tanto, la próxima vez que te enfrentes determinar un estado de madurez, en primer lugar, diseña y adopta métricas que te ayuden a validar si se genera valor al cliente final desde un:

• rol 
• equipo
• grupo de equipos
• programa
• área de negocio
• framework
• cadena de valor
• capacidad
• organización

y luego si lo deseas apóyate adicionalmente en los radares.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. The Key to High Performance: What the Data Says - Dr. Nicole Forsgren
• https://www.youtube.com/watch?v=RBuPlMTXuFc
• https://es.slideshare.net/nicolefv/the-key-to-high-performance-what-the-data-says 
2. State of Devops
• https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
• https://cloud.google.com/devops/state-of-devops/
• https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles (clic aquí) 

Capacidades de la Agilidad Organizacional

• Sensiblidad (capacidad de percibir el cambio y dar respuesta)
• Versatilidad 
• Flexibilidad 
• Resistencia y Resiliencia
• Capacidad de Innovar
• Adaptabilidad

Tomado de: Enterprise Agility: Being Agile in a Changing World

¿Por qué Amazon no usa un marco de escalado y por qué puede que tú sí lo necesites?

---

¿Por qué amazon no usa un marco de escalado y por qué puede que tú sí lo necesites? from Jorge Hernán Abad Londoño

En Qué Radica el Éxito de la Transformación Ágil y los Diferentes Marcos de Escalamiento

---

Con mi gran amiga Paola Becerra, líder del mundo de Banca Empresarial y Telecomunicaciones, con experiencia en procesos de cambio, formación de equipos agiles y administración de portafolios de transformación; luego de conversar sobre un post anterior - ver acá - decidimos reescribirlo y darle más profundidad. A continuación, les compartimos nuestro primer post juntos, esperamos lo disfruten.

---

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado y su trascendencia en la Transformación Ágil de las organizaciones, algunos temas recurrentes son:

• Hay diversas interpretaciones y expectativas acerca de lo que es el escalar ágil, sus beneficios y desventajas.
• Organizaciones pagan millones de dólares a las consultoras top para que al final de tres meses les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2).
• Discutimos sobre cuáles son los beneficios y falencias de cada framework de escalado, cuál es más prescriptivo y cuál es más adaptativo, y como aportan a la transformación organizacional.
• Comparamos sus estrategias de gestión del cambio y confrontamos cual framework es más exitoso, mejor mercadeado, que autor prominente lo creo o que referente promulga y defiende.

Pero luego de desgastarnos varias horas en discusiones bizantinas, nos damos cuenta que los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican y mercadean fuertemente en sus páginas y redes sociales, pero que luego, cuando las empresas citadas fracasan (por razones que se vuelven más un chisme de redes, pero de seguro fueron muchas las causas las que generaron esa debacle– ver Cynefin, espacio del problema complejo (3)- ), los “despublican”, dejándolos de mercadear, y así se concluye que son muchos los factores que impactan el logro o no de un proceso de escalamiento y transformación ágil y este no depende únicamente del framework utilizado.

A continuación, revisaremos algunos de estos aspectos.

Comencemos

Para iniciar, es importante aclarar que escalar ágil (o desescalar una organización - como lo citan varios autores (4) -) es una herramienta de transformación del Management y del Delivery, y como toda herramienta tiene sus beneficios y sus desventajas, por lo que es muy importante conocer el contexto empresarial donde se hace la transformación, haciendo una profundización en:

• conocer la empresa,
• el tamaño,
• su presente y su pasado,
• su cultura organizacional visible e invisible (esta es más importante aún),
• su estilo de liderazgo
• el estado de la tecnología para habilitar el negocio,
• entre otros factores,

ya que no todas las organizaciones necesitan y están dispuestas a hacer lo mismo.

"Ágil es la capacidad de crear y responder al cambio. Es una forma de lidiar y finalmente tener éxito en un entorno incierto y turbulento."  - https://www.agilealliance.org/agile101/

Muchas de las organizaciones quieren ser Ágiles o mejorar su nivel de Agilidad, simplemente porque está de moda decirlo, y debido a esto, los ejecutivos ponen expectativas a veces irreales acerca de lo que implica hacer una iniciativa de escalamiento y transformación ágil, ya que las historias que publican tienen finales felices, que tienen un antes y un después, pero quienes han iniciado el proceso saben muy bien que detrás de esas historias, pues hay innumerables cambios que impactan a la empresa y que redefinen por completo su ADN.

"La agilidad empresarial es la capacidad de una organización para detectar cambios internos o externos y responder en consecuencia para entregar valor a sus clientes."  - https://www.agilealliance.org/glossary/business-agility

Forzar no es Ágil

Por otro lado, las organizaciones no están en el mismo nivel para gestionar una transformación ágil que implicará adoptar uno u otro marco de escalamiento (5); y al igual que las personas tienen su propio “tiempo”, las empresas tienen sus propios ciclos y es importante manejar el cambio sin tratar de presionar tantas modificaciones simultáneas, pues la experiencia nos ha mostrado: primero, forzar es “antiágil”; segundo, lleva a la confusión de las personas quienes no saben cómo comportarse, no entienden qué de lo que hacían estuvo mal antes y qué es lo nuevo que viene a traerles la agilidad; y tercero, se pierde foco de lo que se debe hacer o no; surgiendo preguntas como:

• ¿debo hacer el daily para ser ágil?
• ¿un tablero kanban o Jira, me cambian mi forma de trabajo?
• ¿debo hacer mi día a día operativo como venía haciéndolo?

Dando lugar a interpretaciones y ejecuciones erróneas que terminan torpedeando el proceso, y generando más detractores que promotores. Es de aclarar, que muchos de esos malentendidos surgen al tratar de leer el Paradigma Ágil desde el Tradicional.

Decisión Genuina e involucramiento de la Alta Gerencia

Por lo anterior, es clave que la Transformación Ágil sea una decisión genuina de los ejecutivos del más alto nivel, no es un “cambio para la gente” es un cambio donde la alta dirección participa activamente, entiende, se pone la camiseta, cambia su forma de interactuar, priorizar y decidir; lidera con el ejemplo y son el referente principal de esta nueva forma de trabajo.

Este liderazgo es fundamental, pues mantiene en alto la moral y el foco, guía a los equipos a continuar con flujo constante y es fuente de determinación para hacer el cambio a pesar de las vicisitudes que se encuentren en el camino, pues cuentan con el apoyo y entendimiento de la alta dirección.

Enseñar a los silos a coordinarse para generar valor

Las organizaciones tradicionales tienen en sus estructuras jerárquicas silos funcionales que por años han funcionado de forma aislada (y hasta egoísta) y que bajo este nuevo reto de generar valor más rápido y con menos desperdicio, requieren aprender a funcionar en redes que terminaran generando nuevas topologías de equipos.

El Piloto y los primeros equipos

Tomar la decisión de quienes son los primeros equipos en escalar ágil y las misiones que deben abordar son fundamentales, para enfocar la transformación, pues con ello se da inicio al rediseño del “organigrama” y la identificación de las áreas a comenzar a transformar, pues son las que primero generan fricción con esta forma de trabajo.

Los equipos que inician la transformación ágil requieren un alto grado de coordinación y acompañamiento para fortalecerlos y hacer de ellos casos de éxito, para los siguientes equipos; esos equipos pioneros llevan un peso en sus hombros que no es fácil de manejar; están en la curva de aprendizaje de planear por sprint, manejar la transparencia del error, generar aportes e ideas para un equipo, cambiar de mentalidad y entender el agilísimo integralmente, con los temores que representa el cambio.

Está bien visto fallar, pero no todos están listos

Hay que cuidar a los miembros de los equipos, pues para ellos antes era mal visto equivocarse, estaban solo para hacer caso, no podían aportar o hablar, este cambio genera un choque a nivel personal y estos miembros del equipo tienen bajos niveles de resiliencia, si no se administra el proceso positivamente. Estas personas mal acompañadas pueden llegar a convertirse en los resistentes pasivos de una transformación, algunos de estos miembros pueden impactar negativamente a sus equipos y a los resultados, pues no están convencidos de las virtudes de la agilidad al 100% y prefieren hacer lo de antes, lo que han conocido siempre y desconfiguran lo que se espera de un equipo ágil desde el principio, impactando su desempeño y las iniciativas de escalamiento ágil.

Condiciones de éxito y fracaso

A continuación se comparten algunas condiciones de éxito y fracaso que hemos observado en los procesos de transformación y en la adopción de marcos de escalamiento ágil a nivel organizacional.

Factor	Hacia el éxito	Hacia el fracaso
Compromiso del Top-Management	·       alto compromiso e involucramento	·         Delegación completa y desentendimiento
Gestion el cambio organizacional	·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.	·       Fija, predictiva y forzada.
Procesos y contratos	·       Modificados y en continua mejora hacia la agilidad	·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset	·        Capacitados y empoderados para liderar con el ejemplo	·        La difusión del mindset es delegada en los consultores y algunos roles específicos
Tolerancia al fracaso	·       Alta	·        Baja
Comunicación	·       Fuerte y constante difusión de la estrategia de cambio, de éxitos, fracasos, logros y retos. ·        Pone a todos en el mismo barco.	·       Tímida, orienta solo al área funcional que la lidera sin involucrar toda la organización.
Espacios de trabajo y herramientas de colaboración	·        Acondicionados para la colaboración (recordar: los espacios moldean el comportamiento)	·        Limitados y restringidos
Silos organizacionales	·         Colaborando en torno al valor	·        Enfocados en optimizar la agilidad en su área
Métricas de gestión	·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda: "como me midas me comporto")(5)	·        No sufren cambios
Agilidad Técnica	·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica y Excelencia Operacional.	·        Adoptada como la compra de herramientas
Cultura	·        incentivar los nuevos comportamientos ·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización	·        No intervenidos
Respecto a los frameworks ágiles	·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores	·        Adoptados con modificaciones y personalizaciones que los terminan desfigurando y replicando la situación actual.
Mindset	·        Constante difusión y adopción del mindset lean - agile a todo nivel en la organización(8), viéndose reflejado de forma gradual en los procesos y decisiones de la organización.	·        No intervenido
Respecto a los consultores (7)	·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento	·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio

Cerrando

En conclusión, hacer escalamiento de equipos ágiles y transformar una organización hacia la agilidad es un camino de rosas con espinas, no es fácil, y es clave saber armonizar elementos que están colaborando y compitiendo entre sí, pues no es una receta, adicional que no soluciona todos los problemas de una empresa, es un medio para mejorar permanentemente, no es el fin en sí mismo,

Lo que se observa (y faltará que se compruebe estadísticamente) es que:

"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, radica en las personas y su disposición a liderar y adoptar este cambio que cada vez es menos opcional.


Saludos Ágiles
Jorge Abad y Paola Becerra

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
2. Sobre el "Modelo Spotify"
• Failed #SquadGoals https://www.jeremiahlee.com/posts/failed-squad-goals/
• There is No Spotify Model - https://www.infoq.com/presentations/spotify-culture-stc/
• The ‘Spotify model’ is not a model. Here is why. - https://www.linkedin.com/pulse/spotify-model-here-why-jasper-verdooren/
3. Cynefin - https://martinalaimo.com/es/blog/cynefin
4. Interesantes links sobre desescalar:
• The Descaling Manifesto https://xscalealliance.org/
• Descaling Organizations with LeSS- https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html
• How to Descale an Organization - https://www.infoq.com/news/2015/05/descaling-organization/ 
• The Shu Ha Ri of Scrum @ Scale https://www.scruminc.com/wp-content/uploads/2016/11/Scrum-at-Scale-GTFS-22-Nov-2016.pdf 
• Welcome to the GOTO Night – Jeff Sutherland & Klaus Bucka-Lassen - https://confadmin.trifork.com/dl/scrum/GOTONight_Jeff%20Sutherland_Scrum%20at%20Scale%20.pdf
• Don’t scale agile – descale your organization! - https://fuehrung-erfahren.de/en/2019/02/dont-scale-agile-descale-your-organization/
5. Algunos Marcos de Escalamiento de equipos ágiles:
• Scrum de Scrums
• Nexus - https://www.scrum.org/resources/nexus-guide
• Discipline Agile Delivery (DAD) - https://www.pmi.org/disciplined-agile
• LeSS (Large-Scale Scrum)- https://less.works/
• Enterprise Scrum - http://www.enterprisescrum.com/
• SAFe (Scaled Agile Framework) - https://www.scaledagileframework.com/
• Scrum at Scale - https://www.scrumatscale.com/
• Enterprise Kanban - https://resources.kanban.university/enterprise-kanban-where-to-start/
6. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
7. Sugerencias de Lucho Salazar
8. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

Diapositivas - Seminario-Taller sobre Transformación Ágil

Hola a todos


A finales del año pasado tuve la oportunidad de brindar un Seminario-Taller sobre Transformación Ágil para una prestigiosa universidad de la ciudad de Medellín dirigido específicamente a una importante organización del sector energético.

Hoy quiero compartirles TODO el material que elaboré y trabajamos; sin restricciones.

Pero también he observado que por más bueno que sea el material, sin la explicación y heridas de guerra del experto, queda incompleto; por lo tanto, si estas interesad@ en ir más allá del material y participar en un Webinar que dictaré:

• Cuándo: en el mes de Julio de 2020
• Intensidad: 3 sábados ( 18 de Julio, 25 de Julio, 1 de agosto)
• Duración: 9 horas (3 horas cada sesión)
• Inversión: 90 dólares

Diligencia el siguiente formato y te estaré contactando para los siguientes pasos (clic aquí) 

Saludos Ágiles


Jorge Abad.

Diapositivas - Seminario Taller sobre Transformación Ágil from Jorge Hernán Abad Londoño

Sobre Lean Thinking y Lean Manufacturing

"Lean Manufacturing es un proceso de cinco pasos: definir el valor del cliente, definir el flujo de valor, hacerlo "fluir", tirarlo (pull) desde el final (cliente), perseguir la excelencia"

James Womack y Daniel Jones, Lean Thinking

Valor, según Alistair Cockburn

"El cliente sabe lo que es valor"  Alistair Cockburn (ver más)

Presentación: El Valor del Escalamiento de los Marcos en la Agilidad Organizacional

El Valor del Escalamiento de los Marcos en la Agilidad Organizacional from Jorge Hernán Abad Londoño

Presentación: Algunos Conceptos Claves de DevOps

Algunos Conceptos Claves de DevOps from Jorge Hernán Abad Londoño

Para No olvidar: Si duele hazlo más veces

Este viejo adagio aplicable a muchos aspectos de la vida (el de porte es uno de ellos), es muy usuado en el mundo de Agile y de DevOps:

if it hurts, do it more often(1)

if its painful do it more often!(2)

Que puede ser traducido como:

si te duele, hazlo más seguido

si te duele, hazlo más veces

si es doloroso, ¡hazlo más a menudo!

tomado de (1)

Aplica en el proceso de desarrollo de software para:

• pruebas (testing), de cualquier tipo
• refactorización
• merge del código al tronco
• integración continua
• despliegue continuo
• y cualquier tarea o cosa que te moleste dentro del proceso de software

Si lo haces mas frecuente, desaparecerá el dolor y serás mas fuerte.

Incluso, en la ingería del caos lo interpreta Netflix y muchos, de la siguiente forma

si te duelen los ataques de DDoS, atácate a ti mismo

si te duele que se te caigan los servidores, túmbalos tu mismo

si te duele que se te desborde la memoria, desbórdala tu mismo

Todas estas medidas le dan resiliencia a tu sistema o arquitectura.

Saludos Ágiles

Jorge Abad.

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1.  https://martinfowler.com/bliki/FrequencyReducesDifficulty.html
2. https://vinayakjoglekar.wordpress.com/2013/08/28/if-its-painful-do-it-more-often/

Mindset Lean-Agile

---

En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ágil

Te recomiendo visitar la versión mejorada de este artículo: http://www.lecciones-aprendidas.info/2020/06/en-que-radica-el-exito-de-la-transformacion-agil.html

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:

• organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
• discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
• comparamos sus estrategias de gestión del cambio
• confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 

Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

Factor	Hacia el éxito	Hacia el fracaso
Compromiso del Top-Management	·       alto compromiso e involucramento	·         Delegación completa y desentendimiento
Gestion el cambio organizacional	·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.	·       Fija y predictiva
procesos y contratos	·       Modificados y en continua mejora hacia la agilidad	·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset	·        Capacitados y empoderados para compartir el mindset	·        La difusión del mindset es de lagada en los consultores y algunos roles
Tolerancia al fracaso	·       Alta	·        Baja
Comunicación	·       Fuerte y constante comunicación de la estrategia de cambio ·        Comunicación de la estrategia de cambio	·        Poca o nula comunicación
Espacios de trabajo y herramientas de colaboración	·        Acondicionados para la colaboración (los espacios moldean el comportamiento)	·        Limitados y restringidos
Silos organizacionales	·         Colaborando en torno al valor	·        Enfocados en optimizar la agilidad en su área
Métricas de gestión	·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)	·        No sufren cambios
Agilidad Técnica	·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica.	·        Adoptada como la compra de herramientas
Cultura	·        incentivar los nuevos comportamientos. ·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización	·        No intervenidos
Respecto a los frameworks ágiles	·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores	·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
Mindset	·        Constante difusión y adopción del mindset lean - agile (5)	·        No intervenido
Respecto a los consultores (3)	·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento	·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
Entre otros

Yo me quedo con mi conclusión

"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

Saludos Ágiles

Jorge Abad.

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
3. Sugerencias de mi amigo Lucho Salazar
4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html