sábado, octubre 16, 2021

El Verdadero Desafío Digital

 

Hace poco leí "Aquí no hay reglas" - https://www.amazon.com/-/es/Reed-Hastings-ebook/dp/B08D3BMBYG/ sobre Netflix  y "Crea y Divaga"- https://www.amazon.com/-/es/Jeff-Bezos-ebook/dp/B08LSJP5H8/ sobre JeffBezos y Amazon. Recomendados estos libros para todo CEO, CIO, CXO, gerente, director o líder.

No quiero hacer una reseña de ambos, lo que quiero plantear es diferente, veo muchas organizaciones preocupadas y ocupadas por la Transformacion Digital, pero debemos preocuparnos más por reinterpretar el liderazgo, por ejemplo uno lee la declaración de Cultura de Netflix https://jobs.netflix.com/culture y queda frío, la velocidad de la cultura que ha construido es altísma, es allí donde estamos compitiendo, con modelos mentales apoyados con tecnologia y esa velocidad no se alcanza con adquirir lo último en digital, se alcanza generando culturas que vayan a la velocidad del cambio o que generen cambio.

Los invito a que se lean los libros, pero mientras aceptan mi invitación y lo hacen, revisen la cultura de Netflix https://jobs.netflix.com/culture, son solo 10 minutos de lectura, y tal vez les pase como a mí, y lleguen a una conclusión similar:
"Ponerse a la altura de este tipo de organizaciones es un verdadero desafío que implica un salto exponencial en nuestros estilos de liderazgo y culturas empresariales"


Saludos ágiles

Jorge Abad


Referencia

domingo, octubre 03, 2021

Solo hay un jefe: EL CLIENTE

 



Años atrás, Sam Walton, fundador de la mayor red minorista del mundo, Wal-Mart, abrió un programa de entrenamiento para sus empleados, con mucha sabiduría. Cuando todos esperaban una conferencia sobre ventas y atención, inició con las siguientes palabras:

′′ Soy el hombre que va a un restaurante, se sienta a la mesa y espera pacientemente, mientras el mesero hace todo, menos anotar mi pedido.

Soy el hombre que va a una tienda y espera callado mientras los vendedores terminan sus conversaciones privadas.

Soy el hombre que entra en una gasolinera y nunca usa la bocina, pero espera pacientemente que el empleado termine la lectura de su periódico.

Soy el hombre que explica su desesperada urgencia por una pieza, pero no reclama que la recibe solamente después de tres semanas de espera.

Soy el hombre que, cuando entra en un establecimiento comercial, parece estar pidiendo un favor, rogando por una sonrisa o esperando solo ser notado.

Debes estar pensando que soy una persona quieta, paciente, del tipo que nunca crea problemas... Se equivoca.

Sabes quién soy? Soy el cliente que nunca volverá!

Me divierto viendo millones gastados todos los años en anuncios de todo orden, para llevarme de nuevo a su empresa. Siendo que cuando fui allí por primera vez, todo lo que deberían haber hecho era solo una pequeña gentileza, sencilla y barata: tratarme con algo más de cortesía.

Solo hay un jefe: el CLIENTE Y él puede despedir a todas las personas de la empresa, del presidente al limpiador, simplemente llevando su dinero para gastar en otro lado."

miércoles, septiembre 29, 2021

Ágil es - Agile is



    
   "Ágil es:
        Definición continua,
            Desarrollo continuo,
                Despliegue continuo y
                    Validación continua de valor"



    "Agile is:
             Continuous definition,
                 Continuous development,
                     Continuous deployment and
                         Continuous value validation" 



   

lunes, septiembre 13, 2021

Taiichi Ohno, Estándar y Kaizen

 

"Donde no hay estándar, no puede haber kaizen (mejora continua)" - Taiichi Ohno


---


"Where there is no standard, there can be no kaizen (continuous improvement)" - Taiichi Ohno




---

Sobre el poder y el proceso de cambio

 Algo que he aprendido:


"Sin poder en un proceso de cambio, estamos en el terreno de las buenas intenciones y los malos resultados" - Jorge Abad



lunes, septiembre 06, 2021

Seguridad Sicológica según Daniel Coyle

 Según Daniel Coyle, las seguridad sicológica se basa en tres ideas:

  • Estamos cerca.
  • Estamos seguros, estamos a salvo.
  • Se hace sentir a la otra persona que es única y que se valora
  • Tenemos un futuro en común






Libros:

jueves, agosto 19, 2021

La Agilidad más allá de las Áreas de TI - TalksByTCS


Hola a todos, les comparto una charla que tuve en el espacio de Talks by TCS en sobre Linkedin, con Martin Karich - Head of Marketing and Communications for TCS Latam y Roberto Moraga - Lean Agile Coach for TCS Latam, en donde compartimos cómo los enfoques ágiles son trasversales y no están diseñados solo para aplicarlas en las áreas de tecnología. 


Ver el video sobre en Linkedin en el siguiente enlace: https://www.linkedin.com/video/live/urn:li:ugcPost:6834227181288230912/ ,

Si tienes problema con el anterior link, usa el siguiente https://www.linkedin.com/events/laagilidadm-sall-delas-reasdeti6830834489338474496/ .






martes, agosto 17, 2021

Conversatorio “Llevando agilidad a la estrategia” - Video

Conversatorio con Jorge Abad Londoño, Enterprise Agile Regional Coach LATAM y Roberto Moraga, Lean Agile Coach de TCS, como parte del ciclo de actividades enfocadas en el desarrollo de estrategias, innovación e impacto digital en la gestión de las organizaciones, organizadas por la Carrera de Administración de Empresas con el apoyo de TCS, Relatto y SAEJ. Facultad de Ciencias Económicas y Administrativas "Fcea-UAS" de la Universidad Javeriana Bogota. 

 - Ver en Facebook -



- Ver en Youtube -

miércoles, agosto 04, 2021

Frase: Agilidad - Jeff Bezos

 


“In today’s era of volatility, there is no other way but to re-invent. The only sustainable advantage you can have over others is agility, that’s it.  Because nothing else is sustainable, everything else you create, somebody will replicate.” - Jeff Bezos


---


“En la era actual de volatilidad, no hay otro camino que reinventarse. La única ventaja sostenible que puedes tener sobre los demás es la agilidad, eso es todo. Porque nada más es sostenible, todo lo demás que inventes, alguien más lo replicará ".- Jeff Bezos





lunes, julio 26, 2021

¿Estás midiendo el porcentaje de valor entregado de tu equipo ágil o de tu portafolio?

 

Modificada de (4)

Hola a todos

Año tras año vemos el informe de Version One sobre el Estado de Ágil (State of Agile) entre los que respondieron a nivel global - https://stateofagile.com/ - .

Uno de los aspectos que me llama la atención, es ver cómo las organizaciones miden el éxito de la implementación de ágil, a continuación ver imagen del reporte de este año:

Cómo mide su organización la entrega ágil. State of Agile 15th (2021)


Y año tras año, la métrica ganadora es Valor de negocio entregado (Business value delivered), y estando cerca: Satisfacción del cliente / usuario (Customer/user satisfaction) y Velocidad (Velocity).

Lo que me causa curiosidad es que dada la visual Latinoamérica de mi cargo (ver mi perfil en linkedin), observo que esta métrica no es considerada en la mayoría de las organizaciones. Sigo notando a las organizaciones después de cierto avance en gestión ágil haciendo "rollback" a estas prácticas y enfocándose en la microgestión, en medir las horas de los equipos, en vez de enfocarse si están o no entregando valor.

Lo cierto, es que un equipo ágil en el mediano plazo, dos a tres meses de conformado, comenzará a generar una velocidad o tasa de entrega relativamente estable, por ejemplo: 7 historias de usuario del mismo tamaño, o 45 puntos de historia por sprint o por semana, como prefiera la organización medirlo, pero la clave radical de ágil no está en el ritmo sostenible (que es importante para tener "cierta predictiblidad" en entornos V.U.C.A.(1)), la clave radical de ágil está orientada a la generación de valor, como reza el primer principio del manifiesto ágil:


"Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor"(2)
.

Sin valor, todo producto que hagamos es desperdicio, sin importar que tan buena velocidad tengamos, por lo tanto, la cantidad de historias de usuario o los puntos por sprint son métricas vanidosas que no nos orientan a lo importante: el impacto que se está generando en el usuario final.

Parece que nos quedamos mirando el dedo y no lo que está señalando.

Para terminar, te dejo estas preguntas:

  • ¿Estás midiendo el porcentaje de valor entregado de tu equipo ágil o de tu portafolio de proyectos o productos?
  • ¿Para cuándo vas a comenzar a hacerlo?
  • ¿Sabes cómo medir el valor entregado?
  • ¿Sabes cómo medir el valor generado?
  • ¿Vas a seguir enfocado en el hacer (generar entregables, u outputs) en vez de estar enfocado en el impacto (generar resultados, u outcomes)?

Saludos ágiles

Jorge Abad


Referencias, notas, observaciones y comentarios

miércoles, junio 16, 2021

Un pensamiento sobre Transformación Digital


"No es solo herramientas y proyectos, los cambios que ofrece la Transformación Digital, pasan del cambio lineal, al exponencial. Aprovecharlos siempre dependerá del mindset y la cultura que se promueva en la organización." - Jorge Abad


martes, mayo 18, 2021

100% de CPU es lento en nuestras máquinas, ahora llévalo a un 100% de ocupación tuyo de forma constante

Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.

Te invito a leer este artículo, donde está el sustento científico de esta "ineficiencia" en los humanos y una sugerencia para solucionarlo: "Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización" 



domingo, mayo 09, 2021

Mi viaje como Agile Coach




Hola a todos,

Hace poco cuando compartía con un equipo de Scrum Masters, hablando sobre prácticas y métodos revisábamos la famosa imagen (1) en la cual se presentan los valores, principios, prácticas y frameworks,

Imagen adaptada de Ahamed Sidky

y que si la giras un poco, vas a ver los elementos visibles e invisibles de la cultura,


aquellos que consisten en "Hacer" y "Ser", y en nuestro contexto "Hacer Ágil" y "Ser Ágil".


En donde, todo viaje de transformación parte desde los elementos visibles hacia los invisibles, transformándonos de afuera hacia adentro,


o ¿Quién cambia por arte de magia? La verdad, desde mi punto de vista y experiencia, no creo en los cambios repentinos, creo en los procesos, todo cambio requiere un esfuerzo, un delta que me permita pasar de un estado A a un estado B, y parte de algo afuera que te lleva a mover cosas adentro.

Pero bueno, el punto acá es como ha sido mi jornada de cambio, recuerdo mucho a mis inicios en el mundo ágil me reencontré con un gran estudiante que tuve en la clase de Taller de Ingeniería de Software en Eafit, Jorge Luis Valderrama, recuerdo que estaba por Colombia, pues vivía en Londres, y en varias charlas suyas y conversaciones a la que asistí, hablaba siempre desde el Manifiesto Ágil - http://agilemanifesto.org/-, y recitaba sin titubear sus valores y principios, y ante cualquier duda buscaba que principios promovía o violaba aquello sobre lo que era cuestionado. Debido a esto, me animé a imprimir y pegar en frente mío, en mi escritorio de oficina los valores y principios del manifiesto ágil, y ante cualquier duda me remitía al manifiesto ágil, frase que repite constantemente mi gran amigo Juan Andrés Ochoa:


"Ante una duda en cómo actuar, remítase al Manifiesto Ágil" -Juan Andrés Ochoa

 

De esa manera, emprendí mi viaje desde los principios y valores, luego aprendí en orden Scrum, Nexus, el Modelo Spotify, Kanban, SAFe, LeSS, Scrum at Scale, Discipline Agile. No fue fácil esa jornada, recuerdo que me tomó al menos 6 meses dejar el micromanagement y hacer gestión de horas, para comenzar a confiar en los puntos de historia.


Y en ese viaje de ida, siempre la mentalidad ágil me ha acompañado, permitiéndome ser crítico y ver valor en prácticas tradicionales y flexibilizar mi mente y prácticas en procesos de transición organizacional que acompaño (les recomiendo leer Empático mas no Complaciente). Pero al toparme con SAFe y Kanban, observé que me faltaba algo, y era Lean (o el Modelo de Producción de Toyota escrito en términos occidentales). Comprendí que en mi jornada había olvidado las bases del mindset ágil, y comencé mi recorrido de regreso, centrándome en dos preguntas fundamentales: 

¿qué es el mindset ágil?

 ¿y qué rayos es lean?


En ese viaje de regreso, he tenido bastantes libros, charlas y conversaciones como compañeros, y recomiendo revisar detalladamente:

  • El corazón de la agilidad, promovido por Alistair Cockburn (2)
  • La Agilidad Moderna, promovido por Joshua Kerievsky (3)
  • Lean (4)


 
El Corazón de la Agilidad (2)

Agilidad Moderna (3)

A este punto de la historia, he logrado sintetizar lo que es para mí el mindset Lean-Agile, la clave que desencadena la productividad, la felicidad y alto desempeño:

  • Flujo
  • Entrega de Valor
  • Reflexión (Inspección y Adaptación)
  • Colaboración
  • Mejora Continua
  • Eliminación de desperdicios
Pilares de la mentalidad Lean-Agile. Elaboración propia.

Al tuétano, al núcleo de este asunto que me apasiona y por el cual llegaste hasta este punto del artículo, lo comparto constantemente, lo considero fundamental, para poder desenvolverse en este mundo disruptivo y exigente; mis entrenamientos y conversaciones tienen un énfasis en el mindset lean-agile y cómo este funciona independiente del framework, marco, metodología o proceso y con esta perspectiva acompaño a equipos y organizaciones en su jornada de transformación.

Sé que no hay que dejar de hacer una cosa sin descuidar la otra, es decir, avanzar en el conocimiento de nuevas aproximaciones y marcos, pues hace parte de "estamos descubriendo formas mejores de"(5),  sin dejar el corazón, el corazón te permite moverte con propósito y libertad entre las diferentes interpretaciones, implementaciones o, más aún, desarrollar tu propia versión de la agilidad y de lean.

Yo no sé cómo será tu viaje, te he compartido el mío, con seguridad en tantos ires y venires nos terminaremos encontrando. Solo te quiero hacer tres preguntas:


¿En dónde estás en tu viaje hacia la agilidad, como Scrum Master, como Agile Coach, o como líder en tu organización?

¿Qué tanto conoces y dominas Lean?


¿Ves útil o inútiles artículos sobre mindset o atraen más los marcos complejos e hiperconectados con flechas?


Hasta acá este compartir, bienvenidos sus comentarios.


Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Imagen de Ahamed Sidky
  2. Corazón de la Agilidad - https://heartofagile.com/
  3. Agilidad Moderna (Modern Agile) - https://modernagile.org/
  4. Lecturas recomendadas sobre lean
  5. Agile Manifesto - http://agilemanifesto.org/iso/es/manifesto.html


viernes, mayo 07, 2021

Las historias de usuario no son requisitos de software, son solo necesidades de usuario. Un poco de Ingeniería de Software y Requisitos


Hola a todos

Recuerdo hace más de 15 años cuando enseñaba taller de ingeniería de software, casos de uso, programar en Java en Eafit y otras cosas antiguas, que le explicaba a los estudiantes que las especificaciones de software según el estándar IEEE 830-1998 (1) deberían ser:

  • Completas. Todos los requisitos deben estar reflejados en ella y todas las referencias deben estar definidas.
  • Consistentes. Debe ser coherente con los propios requisitos y también con otros documentos de especificación.
  • Inequívocas (no ambiguas). La redacción debe ser clara de modo que no se pueda mal interpretar.
  • Correctas. El software debe cumplir con los requisitos de la especificación. Se tienen que cumplir y construir.
  • Trazables. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
  • Priorizables. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
  • Modificables. Aunque todo requisito es modificable, se refiere a que debe ser fácilmente modificable.
  • Verificables. Debe existir un método finito sin costo para poder probarlo.
Lo cierto, es que el tiempo pasó, las historias de usuario se hicieron populares dentro del mundo ágil y luego dentro del desarrollo de software, y esto sucedió  debido a que cada vez evidenciamos más que ser rigurosos en la especificación no aumenta la precisión del desarrollo, que es mejor un breve enunciando con criterios de aceptación, o un boceto y una conversación cara a cara para sincronizar las expectativas del cliente con los desarrolladores, que documentos grandes y estrictos que nos demorábamos meses construyendo, verificando y validando, para luego llegar tarde construir la solución incorrecta.

No volví a toparme mis amados Caso de Uso, con sus relaciones de inclusión y exclusión, ni sus flujos básicos y alternativos, ni con sus diagramas respectivos, todo eso pasó, y pasó para darle lugar a una interacción fluida que nos está permitiendo entregar valor de forma temprana y continua, y reduciendo radicalmente los errores de implementación debido a que nunca adivinábamos todo lo que el usuario tenía en mente.

Constantemente le insisto a las empresas y equipos con los que trabajo:


    "Ágil es:
        Definición continua
            Desarrollo continuo
                Despliegue continuo y
                    Validación continua de valor"(2)


Pero este artículo no es sobre nostalgias, su propósito es dar claridad sobre las historias de usuario y que estas no cumplen con los criterios requeridos para ser especificaciones de software como lo pide la norma, pues:
  • No están completas: son dinámicas y se actualizan cada que se requiera.
  • Algunas son ambiguas: puede que al momento de redactarse falten algunos aspectos (3) y en el momento de la planning (en el mundo Scrum) o durante el desarrollose hagan preguntas que logren resolver la ambigüedad y esto permita una mejor comprensión de lo que quiere el usuario. Lo anterior muchas veces es más valioso que creer correctamente entendido y no se hacen preguntas que permitan validar lo expresado.
  • No todas son correctas: no necesariamente se van a construir dentro del software, algunas quedarán en el olvido o se decidirá libremente no hacerlas pues ya no generan valor.
  • Probablemente no sean trazables: no siempre habrá trazabilidad pues probablemente se registró en un post-it y este luego se tiró a la basura y, por lo tanto, la única evidencia que quedó de esa historia de usuario es el software funcionando aprobado en producción.
Es por esto, que continuamente en los entrenamientos que imparto en los cuales debo hablar de las historias de usuario, lo primero que enfatizo es en que:

"Las historias de usuario no son requisitos de software, son solo necesidades de un usuario",

 

Para cerrar los dejo con esta frase de Jeff Patton, quien ideó el User Story Map:

"No necesitamos un documento preciso, necesitamos un entendimiento compartido",- Jeff Patton 



-----

¿Quieres saber más sobre historias de usuario?


En junio mi gran amigo Lucho Salazar y yo estaremos facilitando un curso donde te contaremos de nuestras experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:


¡Te esperamos!


Notas, Aclaraciones, Referencias y Comentarios

  1. https://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software 
  2. Lo escribo escalonado pues no se da de forma paralela, sino de forma escalonada y más cercana en el tiempo, desde unas cuantas horas hasta máximo dos meses.
  3. http://www.lecciones-aprendidas.info/2018/07/aclarando-sobre-historias-de-usuario.html

miércoles, abril 28, 2021

Frases: Cultura - Miedo - Innovación

 



"Si usted tiene una cultura del miedo, ninguna de sus prácticas o procesos sofisticados le ayudará" Josua Keriesvky (clic aquí)


"Donde hay miedo, no habrá transparencia" (clic aquí)

--

"Siempre que haya miedo, obtendrás los números equivocados" Deming  (clic aquí)


En esa misma dirección he observado:

"El miedo inhibe la innovación"

--

"El miedo inhibe la creatividad"

--

"El miedo inhibe el feedback"

 


viernes, abril 23, 2021

Frases Jeff Bezos

"Si duplicas la cantidad veces que experimentas con algo, duplicarás tu capacidad para inventar y desarrollar nuevas cosas".

---

“Lo que tenemos que hacer siempre es mirar hacia el futuro. Cuando el mundo cambia a nuestro alrededor, y cuando los cambios nos perjudican (lo que solía ser un viento a favor, ahora es un viento en contra) tienes que afrontar el problema e intentar descubrir qué puedes hacer para eliminarlo, porque quejarse no es una opción".

---

"El mejor servicio al cliente es si el cliente no necesita utilizarlo, no necesita hablar contigo, simplemente tu negocio funciona bien".

---

 “Si ofreces un buen servicio, los clientes lo comentarán entre sí. El boca a boca es muy poderoso".

---

"Sabía que si fallaba no me arrepentiría, pero sabía que de lo único que podría arrepentirme era de no intentarlo".

---

“Si solo estás pendiente de la competencia, estás condenado a esperar hasta que un competidor tome la iniciativa. Estar centrado en el cliente es lo verdaderamente revolucionario".

---

“Hay dos tipos de empresas, las que trabajan para intentar cobrar más y las que trabajan para cobrar menos. Nosotros somos de las segundas ".

---

"Si no eres terco renuncias demasiado pronto, y si no eres flexible te calentarás la cabeza sin verle una solución diferente al problema que estás tratando de resolver ".

---

 “Esperamos que todos nuestros negocios tengan un impacto positivo en nuestra cuenta de resultados. La rentabilidad es muy importante para nosotros porque si no, no estaríamos en este negocio".

---

 "Es muy difícil conseguir que la gente se concentre en las cosas verdaderamente importantes cuando estás en una época de bonanza".

Presentación: ¿Cómo estropear tu Transformación Digital?






El video lo puedes encontrar en: http://www.lecciones-aprendidas.info/2021/05/video-como-estropear-su-transformacion.html



lunes, abril 19, 2021

Cómo evaluar a un Líder de Transformación Ágil y Un Agile Coach



Hola a todos

Hace poco un amigo me preguntó ¿Qué métricas usaría evaluar a un Líder de Transformación Ágil? o ¿Cómo le evaluaría? A continuación, les comparto mi respuesta.

En mi criterio se deben evaluar tres dimensiones:

  • Mejora de la agilidad de los equipos a cargo
    • Madurez ágil.: ¿Qué tanto han madurado los equipos ágiles a cargo respecto al último periodo? Para esta métrica se requiere un modelo de madurez instaurado en la organización para evaluación de la agilidad de equipos ágiles, y como se puede observar la idea es que es líder mejore la agilidad de esos equipos, es decir, su madurez en términos de uso de principios, marcos ágiles, prácticas ágiles de desarrollo y DevOps.
    • Número de releases: Incremento del número de releases respecto al último periodo. Esta métrica tiene como propósito determinar si el líder ha incrementado la cantidad de salidas a producción, lo que implica, que hay  uso de conceptos de Mínimo Producto Viable, y salidas a producción incrementales. Otra métrica posible a adicionar de este mismo tipo sobre la cual el líder tiene influencia directa es el Time to Market, medido desde que nace la inciativa hasta el primer release.
  • Resultados de Negocio
    • Satisfacción del cliente: ¿Qué tanto ha mejorado la satisfacción del cliente desde el último periodo?, El propósito de esta métrica es hacer al líder responsable de lograr que se mueva esta importante métrica de negocio, de forma que se haga cargo de que los releases a producción sean de valor y se esté evaluando constantemente la satisfacción del cliente, ya sea con métricas directas como el NPS o encuestas, o indirectas derivadas del uso del sistema, tales como recomendación de las soluciones hacia otros usuarios, incremento de intalaciones, aumento de uso de las plataformas, tiempo de uso la solución más altos, entre otras.
  • Agente de Cambio
    • Calidad de sus interacciones: Evaluación 360 de las personas con las que interactúa. El propósito de esta métrica es identificar cómo es la relación con su entorno y cómo ejerce su liderazgo de agente de cambio. 

Notas Finales
  • El peso de cada medida lo decidirá el contexto, yo recomiendo el mismo para las tres dimensiones.
  • Este tipo de evaluaciones también servirían para un Agile Coach
  • Estas dimensiones son las que usamos para evaluar Agile Coaches y Líderes de Transformación en mi entorno y nos han dado buenos resultados, es decir, hablo de ellas con conocimiento de causa.
Bienvenidos sus comentarios.


Saludos ágiles

Jorge Abad

jueves, abril 01, 2021

Seguimiento de OKRs empleando Scrum como marco de gestión




Hola a todos

En un artículo anterior: "OKR - Pasando de la Intención a la Acción" (clic aquí),  presenté de una manera muy somera cómo se podría identificar un Product Backlog teniendo como partida unos OKR (si no lo has revisado, te invito a hacerlo), hoy con este artículo quisiera dar más claridad en los pasos a seguir de forma que Scrum nos sirva como marco de gestión y ejecución de los OKRs, adicionando que he visto funcionar exitosamente este matrimonio por más de dos años, vamos entonces:


Prerequisitos y supuestos
  • Ya tienes tus OKRs 
  • Vamos a suponer que tienes definición trimestral de los mismos
  • Ya se identificaron las metas mensuales para cada KR (key result)
  • Este ejemplo aplica cuando las personas tienen los OKR como una herramienta de transformar la ejecución de su día a día, por lo que deberán tomar una porción de su tiempo de operaciones diarias para ejecutar scrum y conformar un Scrum Team.



Paso 1: Se identifican las tareas a realizar cada mes para lograr cada meta mensual. Tienes un resultado similar al siguiente:


Paso 2: Cada KR lo asignas a un Scrum Team, con las siguientes recomendaciones:
    • Roles
      • El Product Owner, el cual es el dueño del KR
      • Los Developers encargados de ayudar a cumplir el KR y
      • El Scrum Master es encargado de facilitar los eventos de Scrum y de la mejora continua del equipo
    • Eventos
      • Sprint de dos semanas
      • Planning, Review, daily y Retrospectiva según la guía de scrum (Scrumguides.org)
    • Artefactos
      • Product Backlog: las tareas identificadas previamente, con Objetivo del Producto lograr el KR del trimestre
      • Sprint Backlog: un subconjunto de tareas seleccionadas del mes en curso. Este sprint backlog tendrá como Objetivo de Sprint un objetivo intermedio valioso o la meta propuesta para el mes en curso.
      • Increment: como resultado de las tareas finalizadas


Paso 3: Cada tarea del sprint backlog se puede descomponer en subtareas que permitan ver un progreso del equipo hacia el objetivo del sprint.

Proceso de Definición del Product Backlog y Sprint Backlog en la combinacion de Scrum y OKR

Vista general del proceso

En general el proceso se vería de la siguiente forma:

Proceso de Gestión para lograr los objetivos planteados en el Sprint

Proceso de Definición y Gestión de los OKR empleando Scrum como marco de gestión

Conclusiones, recomendaciones y comentarios finales

  • A los equipos encargados de cumplir OKRs les ha sido de gran valor emplear Scrum como marco de gestión y de ejecución. Lo he vivido en equipos de transformación y lo he visto funcionar en varias organizaciones y equipos de forma exitosa.
  • Scrum le permite a las áreas operativas adaptarse al menos cada dos semanas con miras a lograr el objetivo mensual, y cinco veces con miras al objetivo trimestral. 
  • Recomiendo que al menos mensualmente se realice una reunión de progreso, donde todos los equipos encargados de los KR reporten mutuamente su progreso y lo compartan con un nivel superior.
  • El uso de Burndown y Burnup Charts y Gráficos de control es clave para que el equipo tenga herramientas para decidir si va en la dirección correcta o no, y poder inspeccionar y adaptarse en busqueda del objetivo y sus KRs asociados.



Hasta acá este compartir. 

Saludos ágiles, Jorge Abad. 

lunes, marzo 15, 2021

Video: Entrevista con Germán Ortíz (CEO) - Sobre los OKR, experiencia, retos y resultados

Entrevista con Germán Ortiz es el CEO (Líder) de Ingeniería Apropiada, sobre cual han sido los experiencias, retos y resultados de usar OKR durante los últimos dos años en la gestión de la organización.

Ingeniería Apropiada http://iapropiada.com/​ , una empresa dedicada a crear soluciones de hardware y software para estaciones de servicio de gasolina y a realizar innovación en el campo de ingeniería electrónica, cuenta con más de 50 colaboradores y presta servicio en todo el territorio colombiano.



martes, marzo 02, 2021

Un buen Equipo Ágil gestiona también la excelencia técnica de su producto

 “Un buen Equipo Ágil en su búsqueda de la excelencia, gestionará la calidad del producto mejorando frecuentemente las características técnicas en cual fue concebido o recibido.


En la medida que al producto se le adicionan funcionalidades, también se le debe mejorar el desempeño y sus atributos arquitectónicos."




jueves, febrero 25, 2021

Tres Ejemplos de Productos concebidos de Forma Ágil - Agile Inception

Hola a todos

A mi criterio, una de las mejores formas de aprender ciertas técnicas, a parte de experimentarlas, es viendo ejemplos, es por esto que a continuación les comparto tres casos de Agile Inception de productos digitales, el resultado final es un plan de releases del cual se pueden luego detallar las historias de usuario.

Estos ejemplos fueron desarrollados por los Estudiantes de la Cohorte 2020-Sem02 de la ESPECIALIZACIÓN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE de la Unab, a quienes tuve la oportunidad de enseñarles la Materia de Metodologías y Marcos Ágiles.

Se desarrollo un caso al cual se le identificó:

  • El Problema: qué es lo que intenta ser resuelto con el sistema
  • La Visión: Elevator pitch
  • El Vecindario: áreas y sistemas con los cuales se relacionará el sistema
  • Product Vision Board: usuarios, necesidades, productos y metricas
  • User Story Map con identificación del Producto Mínimo Viable - MVP: Épicas priorizadas con estimación de esfuerzo y asignación de valor
  • Estimación de Tiempo y Costo
  • The Go Product Roadmap: Este artefacto también puede ser conocido como el plan de releases.
  • Historias de Usuario con Criterios de Aceptación: se seleccionaron algunas épicas de forma aleatoria y se les escribieron las historias de usuario, simulando un refinamiento.

Espero estos ejemplos les sean de utilidad,

Saludos ágiles

Jorge Abad.












domingo, enero 31, 2021

Haciendo Retrospectivas Inútiles

 



Las retrospectivas perderán valor o terminarán perdiendo importancia bajo varias circunstancias:

  1. Las mejoras no se implementan, convirtiéndose en un ritual sin valor.
  2. Similar al anterior, las mejoras escaladas hacia el entorno, es decir, fuera del equipo no son tenidas en cuenta, ni consideradas.
  3. Se vuelven un rito para el equipo, el cual tiene que hacer, porque así lo dice un proceso, pero no se vuelve un espacio de aprendizaje y reflexión.
  4. Cuando se hacen con afán o a la carrera, buscando terminar rápido y posiblemente terminen con: “envíenme un email con sus mejoras, yo las organizo”.
  5. Cuando una persona es la que manipula las retrospectivas, opacando al grupo.
  6. Cuando existe temor, desconfianza y no hay transparencia.
  7. Siempre se realizan las mismas actividades de interacción.
  8. Las mejoras implementadas son carentes de valor y no generan impacto, ni retan el statu quo del equipo. 
  9. Se juega, se come, se brinda, se hacen bromas, es decir, se hace de todo, pero no hay una reflexión sobre el pasado y acciones concretas hacia el futuro.

Evita por tu bien y el de tu equipo las retrospectivas inútiles.


Saludos ágiles

Jorge Abad




Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon:


domingo, enero 24, 2021

Video: Scrum: cambió la guía ¿y ahora qué hago?



Hay que Ahorrar Costos, ya Aprendimos Ágil, Volvamos a la Estimaciones


Hola a todos

El COVID19 generó impactos a todo nivel, el primero y más doloroso de todos en vidas irrecuperables, pero adicionalmente continúa golpeando la economía, la forma en que trabajamos, nos reunimos, interactuamos, entre muchos otros. Hoy quiero poner luz en algo que he observado como Líder Regional Ágil dentro de una gran corporación, y es que muchos clientes en diferentes regiones afirman debido a la pandemia de forma más o menos similar: 


"¡Hay que controlar costos, ya aprendimos Ágil, volvamos a las estimaciones!"

 

Es decir, vamos a hacer estimaciones al inicio del proyecto pero ejecutaremos a tiempo, alcance, costo fijos, scrum con sprints fijos y plan de releases inamovible (te recomiendo leer; ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?), esto siempre me recuerda la citada frase de mi gran amigo Lucho Salazar @LuchoSalazarC) "Exigir los compromisos no los garantiza". Lamentablemente, nada más en contra de los propios intereses de la organización, pues pierde la organización y probablemente también lo haga el proveedor, estas son las razones:

  • Una estimación buena implica conocer "TODO" desde el inicio, cosa que nunca tendrás, en un mundo tan cambiante como este, considerando adicionalmente la distorsión e inestabilidad que ha generado el COVID19.
  • Genera desperdicios al construir producto innecesario que fue pactado a construirse totalmente desde el inicio.
  • Genera desperdicios funcionales y técnicos de partes innecesarias.
  • Nunca se logran identificar todas las dependencias a priori.
  • El plan perfecto no existe, y como lo dice este tweet contestado por Elon Musk con un 100 : "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad"
  • Siempre que hay dependencias externas hay probabilidad alta de fallo, pues las dependencias no siempre están a tiempo.
  • Implica que se construye algo que se pactó, así sea que se identifique que no va a generar valor
  • Quien estima, extenderá tiempos en búsqueda de cubrir las incertidumbres.
  • Entre más grande el proyecto, más grandes las suposiciones, más grandes los riesgos, más grandes "los colchones", mayor costo, y mayor probabilidad de fracaso.
  • El enfoque en los costos y en el ahorro, pondrá foco en las áreas de gestión en el ahorro, en la maximización del tiempo comprado y en el cumplimiento estricto de lo pactado en etapas tempranas, pero por lo general (y lo he observado muchas veces), nunca se valida la generación de valor, ni se ve con buenos ojos la adaptabilidad a nuevas circunstancias.

Mi recomendación para estos casos siempre es:

  • A nivel de priorización y estimación
    • Priorizar las iniciativas con casos de negocio livianos, es decir, la estimación no podemos evitarla, pero no tiene sentido invertir demasiado tiempo en una actividad en la cual más le inviertas, más desperdicio es. 
    • Usar como método de priorización de iniciativas del Costo del Retraso dividido por la duración (conocido como CD3 - Cost of Delay Divided by Duration - o WSJF -Weighted Shortest Job First -) (http://www.lecciones-aprendidas.info/2020/09/Un-Ejemplo-Practico-de-Gestion-Lean-Agile-de-Portafolio.html ver diapositivas18,19 y 20)
    • Asignar un presupuesto al programa o portafolio de forma que se esten buscando siempre las alternativas de mayor impacto y valor para el negocio.
    • Orientar las áreas de gestión a que se cuestione siempre la generación y validación del valor generado sobre el cumplimiento, ya hemos vivido, que cumplir el plan no implica generar valor, solo cumplir y ya. Son innumerables los casos de proyectos que se engavetan o nadie usa usa.
  • A nivel de ejecución
    • Poner un Product Owner empoderado que:
      • priorice por valor
      • acompañe al desarrollo
      • decida qué construir y qué no sobre el producto
      • asegure que se esté construyendo el producto correcto
    • Validar constantemente la generación de valor, poniendo en producción versiones del producto, de forma que se identifique si se requiere detener el desarrollo o  perseverar para mejorar los resultados.
En resumen, el costo se controla más construyendo el producto correcto y valioso, que desde la estimación, al menos en el mundo de tecnología y desarrollo de soluciones de software.

Saludos ágiles,

Jorge Abad