sábado, octubre 17, 2020

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:
  • individual
  • de equipo
  • de áreas de construcción o ejecución de proyectos y productos de software,
con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:
  • pérdida de foco
  • grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
  • retrasos en la entrega, que a su vez generará:
    • más inconformidad en las áreas que esperan resultados
    • pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
    • sobrecostos por los cambios introducidos
  • pérdida de dinero debido a la no generación oportuna de valor
  • poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.



Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:
  • tengas foco
  • hagas una o pocas cosas a la vez
  • Limita el Work In Progres (WIP) o trabajo en progreso
  • Aprende a decir ¡No!
Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad



lunes, octubre 12, 2020

domingo, septiembre 27, 2020

Cita: Siempre que haya miedo, obtendrás los números equivocados - Deming



"Siempre que haya miedo, obtendrás los números equivocados" Deming

 

--
 cita de "Accelerate" 

"As Deming said, ’whenever there is fear, you get the wrong numbers’ "http://a.co/g8vh4FE


-----
De lo que también se puede inferir

"Donde hay miedo, no habrá transparencia"
----

Para la Reflexión 

  • ¿Te temen?
  • ¿Tu liderazgo es desde el temor?
  • ¿Qué tipo de liderazgo ejercen las personas que te reportan y tienen equipos a cargo?
  • ¿Tu jefe te produce temor? 
  • ¿En el área u organización en la que te encuentras, las relaciones son relaciones basadas en el temor?

Saludos ágiles
Jorge Abad

martes, septiembre 22, 2020

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í -





domingo, septiembre 20, 2020

¿Debe un Product Owner saber de tecnología?






sábado, septiembre 12, 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

sábado, septiembre 05, 2020

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."

jueves, agosto 27, 2020

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


martes, agosto 25, 2020

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



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



    lunes, agosto 24, 2020

    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

    jueves, agosto 13, 2020

    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


    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 

    tomadas de: 

    Algunas Frases sobre Equipos de Alto Desempeño

    lunes, agosto 10, 2020

    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:


    domingo, agosto 02, 2020

    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

    Control Chart.png (1368×552)
    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
    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

    domingo, julio 26, 2020

    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
    3. Alguno links sobre excelencia técnica

    martes, julio 21, 2020

    Algunas Frases y Referencias Claves sobre Gestión de Equipos (post en construcción)

    Tomado de (13)



    Hola a todos

    A continuación te comparto algunas frases claves de gestión de equipos, algunas desde mi experiencia y otra citando las fuentes.

    Nota: lo que encuentras entre paréntesis, son referencias a links con información que sustenta la afirmación.


    Equipos
    • Autónomos (1)
    • Coubicados (2)
    • Multidisciplinarios (3)
    • Autoorganizad4os(4)
    • Pequeños (4 a 6 personas)(5)(24)(31)
    • Estables(6)
    • Competentes técnicamente (7)
    • Con seguridad sicológica (28)(29)
    • Con acuerdos y normas correctas (28)(29)
    • Con foco (que no trabajen en paralelo, sino en una o dos cosas a la vez)(8)
    • Que tienen tiempo para la mejora y la innovación (aproximadamente un 20%)(9)
    • Con control sutil, autoorganizado, avanzando en ciclos cortos y con un objetivo retador(10)
    • Felices y motivados (11)
    • Que hacen el daily son más(25)
    • Que alcanzan resultados, estarán mas motivados y por ende (7)
    • Que tienen objetivos alcanzables (máximo un mes), estarán más motivados y por ende (12)
    • Que terminan temprano, aceleran más rapido y por ende (13)
    • Que hacen retrospectivas ( - añadiría que hacen buenas retrospectivas (15)- )(16)
    • Que incluyen la mejora más importante en la planeación y ejecución de su siguiente ciclo de trabajo -scrumming the scrum - (17)
    • Que guardan en su planeación espacio para las interrupciones (18)
    • Que para planear usan el clima del día de ayer (19)
    • Que construyen historias de usuario pequeñas - o ítemes de backlog pequeños - , es decir de 2 a 3 dias en alcanzar la Definition of Done (21)
    • Que usan la Definición de Preparado - Definition of Ready-  (23) y la Definición de Terminado - Definition of Done (24) para la planeación, ejecución y entrega de su trabajo.
    • Que usan radiadores de información (tableros kanban, burndown, burnup, entre otros) y son transparentes respecto a su progreso (12).
    Respecto a lo técnico
    • Orientados a la excelencia técnica (22)
    • Que tienen Practicas Ágiles Técnicas (clean code, automatización, etc) (26) (27)
    • Que remueven constantemente su Deuda Técnica (27)
    son más veloces y productivos (20)

    "Tener cadencia en un escenario complejo, genera cierta predictibilidad en las estimaciones y en la construcción de lo pactado" (7)
    -------

    "Equipos exitosos en un contexto agresivo, no tendrán resultados sostenibles o no generarán resultados(7)
    -------

    "Dar resultados, pero tener un equipo infeliz no es sostenible en el tiempo"(7)
    -------

    "Un equipo feliz que no da resultados, no es sostenible en el tiempo"(7)
    -------

    "Un equipo motivado que no da resultados, no es sostenible en el tiempo"(7)
    -------
    "Un equipo multidisciplinario con las competencias erróneas, no dará nunca resultados"(7)

    -------
    "El verdadero desempeño tiene poco que ver con la presión y todo que ver con la motivación" (true performance has little to do with pressure, and everything to do with motivation)"(30)
    ---

    Hasta acá este compartir, si tienes alguna frase que quieras compartir, te invito a hacerlo en la zona de comentarios, con seguridad nos servirá a todos.

    Saludos ágiles

    Jorge Abad.


    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. http://scrumbook.org/product-organization-pattern-language/development-team/autonomous-team.html
    2. http://scrumbook.org/product-organization-pattern-language/development-team/collocated-team.html
    3. http://scrumbook.org/product-organization-pattern-language/development-team/cross-functional-team.html
    4. http://scrumbook.org/product-organization-pattern-language/development-team/self-organizing-team.html
    5. http://scrumbook.org/product-organization-pattern-language/development-team/small-teams.html
    6. http://scrumbook.org/product-organization-pattern-language/development-team/stable-teams.html
    7. Observación, deducción, multiples lecturas o experiencia.
    8. http://scrumbook.org/product-organization-pattern-language/development-team/swarming--one-piece-continuous-flow.html
    9. http://www.lecciones-aprendidas.info/2016/10/slack-o-el-tiempo-para-afilar-el-hacha.html
    10. https://hbr.org/1986/01/the-new-new-product-development-game
    11. Sobre la felicidad en los equipos
    12. Inferido de la guía de Scrum - https://scrumguides.org/
    13. https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/teams-that-finish-early-accelerate-faster
    14. Photo credit: woodleywonderworks on Visual Hunt / CC BY
    15. http://www.lecciones-aprendidas.info/2019/11/y-tus-retrospectivas-cuando-van-ser-de-tipo-elite.html
    16. Sobre la retrospectiva
    17. https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrum
    18. https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/estimation-points/yesterday-s-weather
    19. En este caso concreto la velocidad se refiere a que construyes el producto correcto. De nada sirve construir algo el mercado no quiere.
    20. Sobre las historias de usuario pequeñas
    21. http://agilemanifesto.org/iso/es/principles.html  - "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad."
    22. http://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
    23. http://scrumbook.org/value-stream/definition-of-done.html
    24. https://www.qsm.com/process_improvement_01.html
    25. El daily
    26. http://www.lecciones-aprendidas.info/2020/07/algunas-practicas-tecnicas-de-equipos.html
    27. Deuda Técnica
    28. http://sdhumancapital.com/2018/09/24/los-secretos-de-google-sobre-como-trabajar-en-equipo/
    29. Seguridad Sicológica
    30. https://www.thoughtworks.com/insights/blog/how-to-grow-effective-teams
    31. https://www.qsm.com/blog/2012/top-performing-projects-use-small-teams