Entrevista: Agilidad en Latinoamérica de Agustín Varela

---

Un Ejemplo Práctico de Gestión Lean-Agile de Portafolio

Ejemplo Técnico de Gestión Lean-Agile del Portafolio de Proyectos o Productos

(No incluye conversaciones del Meetup de Agiles Colombia)

Nota: Sí solo deseas ir al video del que explica la hoja de cálculo y como se obtuvieron los valores, el video a continuación es para tí (duración 41:20).

---

Video del Meetup de AgilesColombia sobre este ejemplo de Agilidad del Portafolio

Nota: El video a continuación incluye toda la sesión que se hizo en ÁgilesColombia el pasado 22 de septiembre (clic aquí para ir a sitio del meetup) : explicación del ejemplo, conversaciones, discusiones y reflexiones al respecto (duración 1:52:46)

---

Artículo en Linkedin:

Un Ejemplo Práctico de Agilidad en el Portafolio - clíc aquí -

---

¿Debe un Product Owner saber de tecnología?

---

Un #ProductOwner o #ProductManager no necesita saber de tecnología, pero

esta cita de "How Google Works", de Eric Schmidt, Jonathan Rosenberg .

"smart-creative product managers need to find the technical insights that make products better.

Info en https://t.co/q9DNhwvzQa

— Jorge Hernán Abad L. (@jorge_abad) September 19, 2020

Serie: Lesa Agilidad

-Mucho gusto soy el Product Owner

-¿Y vas a estar con el equipo?

- No, ya escribí todas las hu, solo vendré a los review a recibir el producto y ver el progreso

Reflexión sobre la Agilidad

"La Agilidad requiere entornos de abundancia, donde se comparta, se confíe, se aprenda y se vea el fracaso como una oportunidad."

FORO ERRORES COMETIDOS: C*GADAS EN AGILIDAD Y LECCIONES APRENDIDAS

Para tener presente - Cada vez que usted se encuentre en el lado de la mayoría, es tiempo de hacer una pausa y reflexionar. Frase atribuida a Mark Twain

Guía LEAN para el Pensamiento LEAN

Paso 1. Asegúrese de que el desempeño de hoy sea mejor que el de ayer. Parágrafo 1: Respete y cuide a las personas. Parágrafo 2: Obsesiónese por generarle valor a su cliente. Parágrafo 3: No sea conformista, busque formas distinas y novedosas de hacer las cosas.

Conozcamos Flowban de manos de su creador. Una herramienta para aprender Kanban

 Hola a todos

El pasado 26 de Agosto. Mauro Strione, Agile Coach de Argentina, Instructor Kanban, radicado en Chile, nos compartió Flowban, la herramienta que desarrllo en Angular para enseñar Kanban.

En la sesión tuvimos un breve repaso principios kanban, como se usa la herramienta y en paralelo ejecutamos tres simulaciones

A continaución el video de la sesión:

http://flowban.herokuapp.com/ desarrollada por @MauroStrione

FORO "COLABORACIÓN CON EL CLIENTE SOBRE NEGOCIACIÓN CONTRACTUAL" #AgilesCo2020

¡La base de los contratos ágiles es la confianza! 🤝

Comparto las notas visuales del Foro Colaboración con el cliente sobre Negociación Contractual, en @AgilesColombia 2020, edición Online.#agilesco2020 #contratosagiles #graphicrecording pic.twitter.com/nFdEzWPVPO

— Juliana Betancur (@julibetancur) August 22, 2020

Sobre el Product Backlog, Sprint Backlog y los ítems de Backlog

 

Hola a todos

La guía de Oficial de Scrum (la actual, la publicada en 2017 en https://scrumguides.org/  ), tiene una serie de definiciones sobre el Product Backlog, el Sprint Backlog y los Ítems de Backlog que comparto literalmente a continuación:

El Product Backlog es:

• una lista ordenada de todo lo que se conoce que es necesario en el producto
• esta compuesto por ítems de backlog
• un artefacto vivo
• enumera todas 
• las características
• funcionalidades
• requisitos
• mejoras
• y correciones que constituyen cambios a realizarse sobre el producto para entregas futuras
• varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
• se utiliza una única Lista de Producto para describir el trabajo a realizar

Un Ítem de Backlog:

• Tiene como atributos
• descripción
• orden
• estimación
• y el valor
• muchas veces incluyen descripciones de las pruebas  que demostrarán la completitud de tales elementos cuando estén “Terminados
• varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
• podría emplearse un atributo de la Lista de Producto para agrupar los elemento

Sprint Backlog contiene:

• objetivo del sprint: es una meta establecida para el Sprint
• el conjunto de elementos de la Lista de Producto seleccionados para el Sprint
• incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior para asegurar el mejoramiento continuo

Hasta acá este corto compartir

Saludos Ágiles

Jorge Abad

No existen historias de usuario técnicas, ni de frontend, ni de backend etc, solo existen historias de usuario

Hola a todos

Luego de este magistral post de mi gran amigo Lucho Salazar

 El extraño caso de las historias de usuario técnicas (clic aqui)

Solo queda pendiente esta aclaración:

"No existen las historias de usuario técnicas, ni de frontend, ni de backend, ni de certificación, etc., solo existen las historias de usuario y ya"

 

Espero esta imagen ayude a superar tanta confusión al respecto.

Saludos ágiles

Jorge Abad

Colaboración con el Cliente sobre Negociación Contractual con Historias de Usuario

DesEscalando Ágil: Cómo Evitar los Marcos de Escalamiento

Hablemos de Deuda Técnica - Otra Vez

Equipos Hiperproductivos - Hyperproductive Teams

Photo credit: woodleywonderworks on Visual Hunt / CC BY

Hola a todos 

He estadoestudiando y entendiendo ciertos patrones que hacen a los equipos hiperproductivos, según las experiencias de Jeff Sutherland (co-creador de Scrum)

Esta pequeña investigación surge del el afán de lograr y continuar experimentando esos resultados que nos asombran cuando hacemos correctamente Scrum.

Además -les comparto -, andamos muy ocupados complicándonos y perdemos de vista la clave de Scrum y de la Agilidad, EL EQUIPO.

A continuación te comparto algunos recursos claves para entenderlo

Tweet

@keithb_b hyperproductive is at least 400% of baseline and you don't get there without extreme focus. A healthy team is just the beginning.

— Jeff Sutherland (@jeffsutherland) September 30, 2012

Artículo

• Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams (ver acá)

Patrones de Hiperproductividad de Equipos (captura de imagen hecha del artículo)

Prácticas de Equipos Hiper Productivos 

1. Equipos Estables - Stable Teams - (clic aquí)
2. El Clima de Ayer - Yesterday’s Weather - (clic aquí)
3. Flujo de una Pieza - Swarming: One Piece Continuous Flow - (clic aquí)
4. Patrón de Interrupción - Interrupt Pattern: Illigitimus Non Interruptus - (clic aquí)
5. Códito Limpio Diariamente - Daily Clean Code - (clic aquí)
6. Procedimiento de Emergencia - Emergency Procedure - (clic aquí)
7. Scrumming the Scrum - (clic aquí)
8. Métrica de la Felicidad - Happiness Metric - (clic aquí)
9. Los Equipos que Terminan Temprano Aceleran más Rápido - Teams that Finish Early Accelerate Faster  - (clic aquí)

tomadas de: 

• http://scrumbook.org/ - 
• A Scrum Book: The Spirit of the Game https://www.amazon.com/-/es/Jeff-Sutherland/dp/1680506714 )

Algunas Frases sobre Equipos de Alto Desempeño

• http://www.lecciones-aprendidas.info/2020/07/algunas-frases-claves-sobre-gestion-de-equipos.html

Dos Preguntas (Casi Tres)

Veo con frecuencia tantas implementaciones cojas de Agile y DevOps, que en vez de burlarme de ellas y de los implementadores - como lamentablemente lo observo en las redes - quiero hacerle estas dos preguntas a los que son clientes:


Pregunta 1: ¿Cuando #Agile y #DevOps sean el estado del arte en tu organización y de la industria, es decir un commodity, por fin te vas a decidir a innovar y a poner realmente al negocio liderando equipos agiles enfocados en generarle valor al cliente? ¿No crees que será muy tarde?


Pregunta 2: ¿Basado en lo anterior, para cuándo te vas a decidir a hacer #Agile y #DevOps en serio, o vas a dejar que tu competencia te tome ventaja en ello?


Abro la discusión, si lo deseas en la zona de comentarios, o en mis redes sociales:

Linkedin: https://www.linkedin.com/feed/update/urn:li:activity:6698791093657501696/

Twitter: https://twitter.com/jorge_abad/status/1293026195228033024

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

¿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

OKR - Pasando de la Intención a la Acción

Tomado de (1)

Hola a todos

Los OKRs (2) (Objectives and Key Results) son una forma de generar alineación a todo nivel: estratégico, táctico y operativo, pero muchas veces tenemos problemas para pasar de la intención a la acción, y nos quedamos sin lograr lo planteado.

Obj2. Investigar y mejorar la satisfacción del cliente  kr1. Superar el puntaje neto del promotor (NPS) en un 30% kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual y analizar y obtener cual es el Pareto de las causas de insatisfacción kr3. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Ejemplo de un OKR

A continuación, voy a compartir algunos consejos que me han servido en la implementación de estos:

La Creación de los OKR

No hay una formula exacta de cómo crearlos, pues dependen mucho del estado de madurez de la organización, de las áreas y sus líderes, en ocasiones:

• los OKR los crea el equipo directivo
• los OKR los crea el equipo directivo y luego cada área realizar su interpretación y definición de los propios y los valida con el equipo directivo (este es el que más he empleado en mis talleres)
• los OKR los plantea el equipo directivo y los discute con los otros niveles para realizar ajustes
• Se plantean los Objetivos y las áreas deciden los KR, obvio luego de entender cuál es el propósito que buscará la organización en el trimestre
• Se realizan conversatorios y se hace una creación conjunta

Comparte el propósito

Luego de hacer la construcción de los OKR, asegúrate de compartirlos con las áreas encargadas para que comprendan el beneficio e impactos esperados.

Esta actividad no es requerida si las áreas fueron las que crearon los OKR propios o los KR de los que se harán responsables.

Asignar un líder para que se haga cargo del KR

Asignar un líder que esté encargado de:

• obtener el resultado, 
• ejecutar acciones, 
• coordinar actividades, 
• recopilar y 
• compartir métricas de un KR

hará que sea más fácil alcanzarlo.

Para romper silos, KR compartidos por áreas

Si quieres mejorar la colaboración entre áreas y romper los silos, asigna KRs compartidos entre áreas.

Crear una meta mensual 

Pon una meta mensual que cada vez se acerque más al valor KR buscado.

Un ejemplo

Identificar las acciones y experimentos a realizar cada mes, de forma que plantees una estrategia que te asegure lograr esa meta mensual o al menos estar lo más cerca posible del  valor deseado

Las tareas identificadas son preliminares (recordemos que estamos en un entorno VUCA (3) y pueden cambiar), pero ayudan en el proceso de identificación de responsabilidades y colaboraciones requeridas.

Una buena práctica es asignar a las acciones o experimentos criterios de aceptación, de forma que se tenga claridad sobre lo que se espera de cada una.

Crear un kanban para cada kr

Gestionar visualmente las metas de los KR 

Identifica las gráficas que más aplican para gestionar tu KR.

También trata de que sean:

• en la medida de lo posible actualizables online o actualizadas en ciclos regulares, menores o iguales a un mes.
• disponibles y visibles para todos 
• ubicadas en un lugar estratégico (ya sea físico o virtual) de forma que todos vean transparentemente el progreso (esto genera orientación al resultado del equipo de trabajo)

Burnup para KR deban subiendo

Burndown para KR que deban bajar

Gráficas de Control para KR que deban permanecer en ciertos rangos

Realiza al menos una reunión de avance mensual para identificar progreso y resolver impedimentos 

Con los líderes de los KR y sus áreas, o solo con los líderes (según el contexto); realiza al menos una reunión mensual de coordinación, validación de avance y remoción de impedimentos, de forma que todos estén enterados del progreso y las dificultades de todos; esto ayudará a generar sinergia, colaboración, y adaptación en caso de ser necesario.

Si un KR deja de ser necesario, pueden haber varias razones:

• el mercado cambió
• las condiciones que lo generaron cambiaron radicalmente

por lo tanto, evalúen conjuntamente vale la pena navegar en esa dirección, o se identifican esfuerzos más relevanyes.

Un último comentario

Ten paciencia y ve mejorando poco a poco; los OKRs demoran en aprenderse a usar, muchos autores y mi propia experiencia, muestran que requieren aproximadamente un año para que sea una práctica bien usada y entendida en la organización.

Hasta acá este compartir

Saludos Ágiles,

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Foto de Personas creado por freepik - www.freepik.es
   
2. Sobre los OKR y cómo funcionan
• Conociendo OKR - http://www.gazafatonarioit.com/2020/06/conociendo-okr.html
• Un ejemplo de OKR - http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
• Mis notas sobre OKR - http://www.lecciones-aprendidas.info/2019/11/mi-notas-sobre-okr.html
• Un tip para escribir mejores OKR - http://www.lecciones-aprendidas.info/2019/10/un-tip-para-escribir-mejores-okr_12.html
• Cómo Promover la Autoorganización Empleando OKR-  http://www.lecciones-aprendidas.info/2019/11/los-okr-promueven-la-autoorganizacion.html
3. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad. Ver más en https://es.wikipedia.org/wiki/VUCA

Algunas Prácticas Técnicas de Equipos Ágiles y DevOps

Hola a todos

La búsqueda de la Excelencia Técnica debe ser la obsesión de toda empresa, área y equipo que trabaje con tecnología, obvio de nada sirve la excelencia técnica sino hay personas trabajando en equipo, empoderadas y con seguridad sicológica (recordemos soy agilista y este tipo de empoderamiento da resultado y ha sido demostrado miles de veces en la industria), pero también es cierto, que sin excelencia técnica no hay agilidad, ni nada. Sin buen software todos estamos perdiendo el tiempo.

"Sin buen software, todos estamos perdiendo el tiempo"

A continuación, les comparto el listado del prácticas técnicas más usadas por los equipos hoy (Julio 26 de 2020) según el 14th State of Agile:

• Unit testing
• Coding standards
• Continuous integration
• Refactoring
• Continuous delivery
• Automated acceptance testing
• Continuous deployment
• Pair programming
• Test-driven development
• Collective code ownership
• Sustainable pace
• Behavior-driven development (bdd)
• Emergent design

Y las prácticas usadas por los equipos de élite  DORA Reseaarch (2):

• Code Maintainability
• Continuous Integration
• Continuous Testing 
• Database Change Management
• Deployment Automation
• Empowered Teams
• Loosely Coupled Architecture
• Monitoring & Observability 
• Proactive Notifications
• Shift Left on Security
• Test Automation
• Test Data Management
• Trunk-Based Development
• Version Control

Marqué en rojo las únicas que están en común, queda en tus manos determinar cuales utilizar en tu equipo, y si es que existe alguna brecha, cómo será tu proyecto de adopción.

Saludos ágiles
Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. https://stateofagile.com/
2. Dora Reseach Program
• http://services.google.com/fh/files/misc/dora_research_program.pdf
• https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
3. Alguno links sobre excelencia técnica
• http://www.lecciones-aprendidas.info/2017/07/noticia-falsa-en-cascada-no-existia.html
• http://www.lecciones-aprendidas.info/2018/03/un-tweet-de-un-grande-rip-mike-beedle.html
• http://agilemanifesto.org/iso/es/principles.html  - "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad."