lunes, septiembre 09, 2019

Tratar a las personas como personas


"In real life, the most practical advice for leaders is not to treat pawns like pawns, nor princes like princes, but all persons like persons"
- James MacGregor Burns

"En la vida real, el consejo más práctico para los líderes no es tratar a los peones como peones, ni a los príncipes como príncipes, sino a todas las personas como personas" 
. -James MacGregor Burns
---
Somos personas, no recursos.

martes, septiembre 03, 2019

Una Reflexión sobre el Costo del Retraso, DevOps y la Curva de Maersk

Hola a todos

Desde hace un tiempo vengo trabajando, e incluyendo en mis entrenamientos el concepto de Costo del Retraso (Cost of Delay), el cual desarrolló magistralmente Donald Reinertsen  en su libro The Principles of Product Development Flow, y una de sus frases más famosas es:





"Si solo puede cuantificar una cosa, cuantifique el Costo del Retraso" -Donald Reinertsen

Algunas definiciones de este concepto son:

Costo del retraso:
  • El costo del retraso es "una forma de comunicar el impacto del tiempo en los resultados que esperamos lograr". (1)
  • "¿Cuánto nos costaría si esto se retrasara 1 mes?"(1)
    • "¿Qué valdría para nosotros si pudiéramos obtener esto 1 mes antes?"(1)
    •  ¿Cuánto dejamos de ganar si nos atrasamos un mes?
    • ¿Cuánto le cuesta a la compañía por unidad de tiempo no tener una funcionalidad liberada oportunamente?



    Y justo con esta aproximación me encontré en el reporte de DevOps elaborado por DORA en https://devops-research.com/, en este informe, se observa la gráfica elaborada en Maersk por el equipo de desarrollo de un proyecto en donde se representa el costo del retraso/semana vs la cantidad de requisitos liberados en esa unidad de tiempo (del cual se infiere el Lead Time promedio del requisito). 

    En esta gráfica se visualiza el costo del retraso generado por liberar tres requisitos por semana, sumando aproximadamente 7 millones de dólares, a liberar más de 23 requisitos en ese mismo periodo de tiempo y reduciendo este costo casi a cero.


    Esta curva es asombrosa, pues genera consciencia de varios aspectos:

    • la importancia de estar generando valor de forma continua
    • el impacto en los ingresos de la organización de una estrategia de liberación pausada o continua
    • cualquier esfuerzo de mejora en el ciclo de desarrollo de software y en su proceso de liberación, conlleva a un impacto económico que puede llegar a ser exponencial.
    • la importancia de liberar continuamente para validar hipótesis y adaptarse rápidamente al mercado.
    • la capacidad de validar hipótesis en un escenario de alto rendimiento es exponencial


    Bajo este panorama surgen varias preguntas

    • ¿Su organización mide el costo del retraso de sus proyectos?¿de uno solo? ¿de todo su portafolio?¿la PMO lo hace?
    • ¿Como sería la curva costo del retraso por semana para los requisitos de tu organización o de tu proyecto?
    • La discusión sobre si Ágil-DevOps es barato desaparece, la pregunta que aparece es 


    ¿qué tan costoso te esta saliendo no ser Ágil-DevOps (Agile-DevOps)?


    • ¿cómo será la curva en los de alto performance, es decir, Google, Facebook, Amazon, Netflix, etc?


    Hasta acá este compartir

    Saludos Ágiles


    Jorge Abad

    Referencias, Comentarios, Notas y Aclaraciones


    1. https://en.wikipedia.org/wiki/Cost_of_delay


    martes, agosto 27, 2019

    Antipatrón: Solo liderar la primera línea y no gestionar la red


    Hola a todos

    Quisiera compartir uno de las disfunciones que he observado en la gestión de equipos y de las redes vinculadas a los mismos, convirtiéndose en uno de los obstáculos en los esfuerzos  de cambio cultural y de liderazgo hacia ambientes de más colaboración, adaptación al cambio, innovación, mejora continua, y generación de valor.

    Utilizaré el esquema de antipatrón para compartirlo.

    Antipatrón: El líder solo exige y promueve un alto estándar a su equipo y no gestiona la red  de personas y el ecosistema a cargo.

    Problema: El líder solo gestiona su equipo adyacente exhibiendo y demandando valores de alto estándar pero no valida si su equipo y su entorno lo está haciendo, infiriendo o suponiendo que su equipo hará lo mismo con las personas a cargo.




    Consecuencias:
    existen varias consecuencias

    • positivas: que todo su equipo exhiba y demande estos valores de alto estándar generando una cultura altamente positiva.
    • negativas: 
      • que parte de su equipo exhiba y comparta hacia la red un alto estándar de valores y otra parte del equipo no lo haga generando una cultura desigual y heterogénea
      • que su equipo no exhiba los valores con los que son tratados y se generen resultados maltratando a las personas, con una cultura de presión, irrespeto y miedo.


    Causas:
    • Inocencia del líder
    • Tolerancia del líder de cualquier estilo de liderazgo sin importar el trato que se le da a su red

    Solución
    En caso de que el líder este interesado en que su cultura de alto estándar se propague por el resto de su red se sugiere:
    • no confiarse de evaluaciones 360
    • realizar reuniones o conversatorios con cierta cadencia (mensual, bimestral o trimestral) con los equipos de la red para validar estilos de liderazgo



      Se me vienen a la mente dos citas relacionadas con este tema:

      "La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar."- Gruenter and Whitaker, School Culture Rewired

      "La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar"- Jurgen Appelo

      Con base en lo expuesto en este post se le podría precisar algo a ambas citas:
      "La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"
      ----
      "La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"

      y como dice Deming:“Todos ya están haciendo lo mejor que pueden; los problemas están con el sistema ... solo el management puede cambiar el sistema", pero el sistema somos nosotros (1) y como nos relacionamos, ahí se encuentra la clave para generar el cambio o promover un alto estándar de cultura y valores.

      Hasta acá este compartir, bienvenidos sus comentarios.



      Saludos Ágiles

      Jorge Abad

      Referencia

      1. De Colección: Culpamos el sistema, pero el sistema somos nosotros  http://www.lecciones-aprendidas.info/2019/07/culpamos-el-sistema-pero-el-sistema.html



      lunes, agosto 26, 2019

      PMO - Una Propuesta de Responsabilidades y Nuevos Nombres en el Mundo Lean-Agile



      Hola a todos

      Relacionado con el post anterior sobre #NoProjects, se observa que el concepto de Proyecto para Desarrollo de Soluciones de Software en este entorno VUCA(1) no tiene mucho sentido, pues este va migrando a conceptos como:
      • productos
      • iniciativas
      • épicas de negocio (2)
      • flujos de valor
      • value streams
      • corrientes de valor
      • cadenas de valor
      Adicionalmente, las áreas que los coordinan también van migrando sus nombres a:
      • Centro de Excelencia
      • Centro de Excelencia Ágil 
      • Centro de Excelencia Lean y Ágil
      • LACE - Lean Agile Center of Excellence (3)
      • Lean Portfolio Management Office (4)
      De todo esto lo que me inquietan varias cosas
      • ¿será que va a ocurrir lo mismo que con los Centros de Innovación
        • Que solo el Centro de Innovación es responsable de la innovación en la organización y no es una capacidad requerida en toda la empresa (a propósito una mala aproximación al concepto)
      • si estamos en entornos donde los productos y value streams son responsables de su flujo de valor y de sus resultados. 
        • ¿Qué valor tiene que se gestionen como proyectos?, Pero más aun
        • ¿Que valor tiene que otro trate de gestionar los recursos que estoy administrando de forma eficiente?
      • Si decidimos llamar a la nueva PMO como "Centro de Excelencia Ágil" entonces se dedicará a medir: 
        • ¿cantidad de equipos ágiles, cantidad de retrospectivas, etc? ¿es de valor medir esto? -obvio que no-.
      • si la gestión de valor es realizada de forma excelente por los equipos de producto y value streams,¿tiene sentido una figura como una PMO o algo similar?

      Responsabilidades de la "Nueva PMO"

      Respecto a las funciones de esta "Nueva PMO" esta se podría dedicar entre otros:
      • Promover el pensamiento (mindset) lean-agile
      • Promover la experimentación (rapida y barata) que permita evolucionar o encontrar más fuentes de valor para la organización y sus clientes.
      • Promover una cultura de obsesión por el cliente y la generación de valor
      • Promover que la organización y su entorno sea medida como un reactor nuclear en tiempo real (Data Driven Organization)
      • Promover y medir la salud emocional de todos los equipos de la organización, promoviendo su estabilidad y alto desempeño
      • Medir la generación de valor de los diferentes:
        • productos, 
        • iniciativas, 
        • value streams 
        • y portafolios
      • Identificar los impedimentos organizacionales, removerlos o ayudar a removerlos
      • Identificar los riesgos organizacionales y trabajar en mitigarlos o reducirlos.
      • Promover la mejora continua del toda la organización (Delivery, Áreas de negocio, Áreas de soporte), al igual que sus ciclos a todo nivel.
      • Promover cadencias de sincronización y alineación tanto a nivel de equipo como de toda la organización.
      • Ayudar a validar si las hipótesis de los Casos de Negocio (Business Cases), se están cumpliendo.
      • Ayudar a que los procesos organizacionales sean cada vez más Lean
      Haciendo un símil esta Nueva PMO se parece más a un Scrum Master Organizacional (ver 5):

      • Promoviendo la generación de valor
      • Promoviendo la excelencia y la mejora continua.



      ¿Y el Nombre?

      Bajo este listado de responsabilidades un conjunto de nombres factibles para una Nueva PMO son:
      • Grupo Promotor del Valor
      • Grupo Promotor del Flujo de Valor
      • Grupo Promotor del Pensamiento Lean-Agile
      En últimas, el nombre es importante, pues da significado, pero las funciones que ejecute lo son más.



      y ¿tu tienes alguna propuesta de nombre?

      Bienvenido el feedback


      Saludos Ágiles

      Jorge Abad



      Notas, Comentarios, Referencias y Observaciones

      1. VUCA =  volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad, ver más en:
      2. https://www.scaledagileframework.com/epic/
      3. https://www.scaledagileframework.com/lace
      4. Basado en la propuesta de SAFe https://www.scaledagileframework.com/lean-portfolio-management/
      5. http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html


      domingo, agosto 25, 2019

      Mi Encuentro con NoProjects - Una Cultura de Valor Continuo

      Hola a todos


      Desde que comencé a caminar en el mundo ágil vi como poco a poco el concepto de proyecto de software iba perdiendo fuerza en el mundo corporativo y comenzaba a tomar fuerza el concepto de producto de software (a continuación un tweet de hace unos años)


      Aclarando sobre Proyectos y Productos

      Pero para entender mejor en que nos estamos metiendo, comencemos por las definiciones:

      Proyecto"Es un esfuerzo temporal realizado para crear un producto, servicio o resultado único". (1)

      La anterior es la definición técnicamente aceptada y elaborada por el PMI  -Project Management Institute . www.pmi.org, pero para producto la definición no es fácil de hallar, acá comparto algunas definiciones que tienen sentido en el propósito de este post:

      Producto: Cosa producida ( tipica definición de la RAE)(2)
      Producto: Un producto es una cosa o un objeto producido o fabricado, algo material que se elabora de manera natural o industrial mediante un proceso, para el consumo o utilidad de los individuos.(3)
      Producto: un producto es un objeto o sistema disponible para uso del consumidor; Es todo lo que se puede ofrecer a un mercado para satisfacer el deseo o la necesidad de un cliente. (4)
      Producto:
      • algo que es fabricado, cultivado para ser vendido, usualmente es algo que es producido por un proceso
      • Un servicio que los clientes pueden comprar de una organización financiera para invertir o ahorrar dinero
      • algo que está disponible para la venta(5)
      Producto: Del latín productus, se conoce como producto a aquello que ha sido fabricado (es decir, producido). Esta definición del término es bastante amplia y permite que objetos muy diversos se engloben dentro del concepto genérico de producto. De esta manera, una mesa, un libro y una computadora, por ejemplo, son productos. (6)
      Producto: Cualquier bien material, servicio o idea que posee un valor para el consumidor o usuario y sea susceptible de satisfacer una necesidad.(7)
      Podría entonces basado en lo anterior entender que un producto es elaborado y es de valor para un usuario o consumidor.

      Basado en las anteriores definiciones se entiende que los proyectos de software:
      Implicando por lo tanto:
      • se desarrollan en ambientes de certidumbre
      • su seguimiento y éxito esta basado en la gestión del alcance, tiempo y costo incurrido.
      • la administración de estos esté enfocada en la administración y optimización de los recursos (insumos, tiempo de las personas) y no en el valor generado.
      • su enfoque de alcance definido, genere definición previa del alcance, adicionalmente que su adaptabilidad sea lenta y requiera procesos adicionales de control de cambios.
      Generando algunas veces que estos:
      • cuenten con bajo involucramiento del negocio
      • cumplan el alcance pero no generen valor
      • usen sus recursos definidos pero no generen valor.
      Mientras, los productos de software
      • nacen
      • no tienen una fecha de finalización prevista
      • pueden ser construidos por uno o varios proyectos, o por un enfoque diferente
      • pueden construirse en escenarios de certidumbre como de Altísima Incertidumbre
      • pueden o no evolucionar
      • morirá el día que deje de ser rentable su uso o existencia
      • el alcance es un medio para generar valor
      • pueden alcanzar valor antes o después de lo planeado
      • están radicalmente enfocados en la generación de valor (o ¿Quién quiere hacer un producto que nadie va a usar?), por lo tanto validan si generan valor o no.
      • Su éxito no se mide en cumplimiento o la gestión optimizada de recursos sino en el valor generado.
      • Requieren de involucramiento del negocio
      Algunas veces es posible no se construya el producto correcto, pero esto se puede solucionar con validaciones tempranas con Productos Mínimos Viables - o MVP por sus siglas en inglés-  propuesta por Lean Starutp, y liberaciones o releases frecuentes que permitan retroalimentación de los usuarios y el mercado.

      Mi encuentro con #noprojects

      Justo en esa búsqueda de entender más sobre:
      • productos
      • cadenas de valor (value streams)
      • épicas de negocio (como las llamaría SAFe (8))
      • o iniciativas
       y como su gestión se diferencia de la gestión de proyectos, (la actualmente no aplica para el mundo del desarrollo de software(9)), me encontré hace unos meses con #noprojects - https://noprojects.org -  y el minilibro publicado en infoq.com - #noprojects - A Culture of Continuous Value (clic aquí) de Evan Leybourn y Shane Hastie, que explica una cultura orientada a la gestión del valor y como podemos tener éxito en ese enfoque.

      A continuación comparto dos imágenes que he traducido, y que son bastante útiles para entender este paradigma.

      Referencia : https://twitter.com/rkasper/status/1032251628143882240

      #noprojects




      Triangulo de #noprojects (10)


      Triángulo de #noprojects traducido



      Queda entonces la tarea de quedarse con estas imágenes o ir leerse el libro.

      Les dejo con esta frase de Mark Twain (o al menos se la atribuyen a él)

      Resultado de imagen para leer mark twain

      Saludos ágiles

      Jorge Abad


      Notas, Comentarios, Referencias y Observaciones

      1. “It's a temporary endeavor undertaken to create a unique product, service or result.”.https://www.pmi.org/about/learn-about-pmi/what-is-project-management
      2. https://dle.rae.es/?id=UH9P99t
      3. https://www.significados.com/producto/
      4. Traducido de wikipedia - https://en.wikipedia.org/wiki/Product_(business)
      5. https://dictionary.cambridge.org/es/diccionario/ingles/product
      6. https://definicion.de/producto/
      7. http://www.diclib.com/cgi-bin/d.cgi#.XWNHs-j0nIU#ixzz5xfhGQ3il
      8. https://www.scaledagileframework.com/epic/
      9. Este tópico no lo resolveré acá, pues es justo la explicación de por qué hoy los métodos ágiles son más exitosos que los tradicionales y hay cientos de post en ingles y español sobre esto.
      10. Referencia https://twitter.com/fbnkss/status/1133762339373813760
      11. Adicionalmente el ciclo de vida de proyectos y producto es distinta
        • proyecto = inicio, organización y preparación, ejecución y cierre
        • producto = introducción, crecimiento, madurez y retiro
      12. Felipe García compañero de la Ágiles Colombia me hacia la precisión que los proyectos tienen: alcance, costo, tiempo, riesgos, recursos y calidad, en total seis restricciones, cosa cierta, pero los esquemas de contratación tradicionales solo manejan estas tres variables (alcance, tiempo y costo) y penalizan al proveedor diciendo: "¡usted debe hacerse cargo de los recursos, la calidad y los riesgos, para eso los contratamos!",  - ¡hágame el bendito favor, que descaro!(clic aquí para regresar)


      domingo, agosto 18, 2019

      Una propuesta para Daily de un equipo Kanban




      Hola a todos

      Según la Guía de Scrum -https://scrumguides.org/ - respecto al daily afirma: "El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones.

      • ¿Qué hice ayer que ayudó al Equipo de Desarrollo lograr el Objetivo del Sprint?
      • ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
      • ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?"
      Algunos equipos Scrum siguen haciendo las famosas tres preguntas
      • ¿Qué hice ayer?
      • ¿Qué voy hacer hoy?
      • ¿Qué impedimentos tengo?
      Aun así lo que sugiere la guía respecto a preguntarnos "¿si vamos a lograr el objetivo?" es un elemento clave para generar incrementos de valor en el marco Scrum, pero este post es sobre Kanban, y en este modelo de trabajo lo que existe es un flujo continuo (se espera sea de valor, para el negocio o para el equipo), y para este tipo de equipos también se sugiere una sincronización diaria, a continuación les comparto una sugerencia para preguntas o afirmaciones para esta reunión corta de no máximo 15 minutos:


      • Afirmaciones o preguntas compartir por cada miembro del equipo:
        • ¿en qué he estado trabajando?
        • ¿qué necesito para cerrar lo que tengo en curso?
        • tengo impedimento(s) y es/son :____________/ no tengo impedimentos
        • yo me ofrezco a ayudar con__________
        • yo me ofrezco ayudar a________
      • un facilitador o líder del equipo podría al final del daily de cada mienbro de equipo, podría preguntar:
        • ¿quien necesita ayuda?
        • ¿en que estado están los impedimentos?¿como hacemos para resolverlos?
        • ¿algo importante a compartir que debamos saber todos?

      El facilitador o líder del equipo y el equipo mismo, deben poner foco en:
      • desbloquear el flujo
      • enfocarse en cerrar tareas
      • terminar de abrir

      Una sugerencia para equipos o dueños de una actividad o proceso

      En caso de que el daily sea realizado por varios equipos o personas encargadas de una parte del proceso, se sugiere realizar el daily comenzando por la persona o equipo que finaliza el proceso y terminar con el que comienza, de esa manera nos enfocamos en terminar cosas y no en abrir.


      hasta acá este compartir


      Saludos ágiles

      Jorge Abad.

      miércoles, julio 03, 2019

      Un mal líder puede estropear la cultura y el sistema

      Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

      "Un mal líder puede estropear la cultura y el sistema"

      Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:
      • organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
      • organizaciones sin procesos detallados con resultados lentos
      • organizaciones con procesos de adorno
      • organizaciones con líderes inspiradores y líderes desmotivadores
      • y toda clase de combinación pervesa, positiva y mediocre de las anteriores
      Llevándonos a decir con Deming

      Resultado de imagen para a bad system beats a good person

      Resultado de imagen para un mal sistema deming

      Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.




      Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:
      • el liderazgo
      • y la forma como interactuamos
      Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

      Hasta acá este compartir

      Saludos ágiles

      Jorge Abad

      De Colección: Culpamos el sistema, pero el sistema somos nosotros

      Me encanta esta cita de Seth Godin

      https://seths.blog/2016/06/the-problem-with-complaining-about-the-system/


      The problem with complaining about the system

      …is that the system can’t hear you. Only people can.

      And the problem is that people in the system are too often swayed to believe that they have no power over the system, that they are merely victims of it, pawns, cogs in a machine bigger than themselves.

      Alas, when the system can’t hear you, and those who can believe they have no power, nothing improves.

      Systems don’t mistreat us, misrepresent us, waste our resources, govern poorly, support an unfair status quo and generally screw things up–people do.

      If we care enough, we can make it change.


      Que podría traducirse como:


      El problema de quejarse acerca del sistema


      ... es que el sistema no te oye. Solo la gente puede oir.

      Y el problema es que las personas en el sistema a menudo se sienten inclinadas a creer que no tienen poder sobre el sistema, que son simplemente víctimas de él, peones, piñones en una máquina más grande que ellos mismos.

      Por desgracia, cuando juntas que el sistema no puede escucharte, con aquellos que creen que no tienen poder, nada mejora.

      Los sistemas no nos maltratan, no nos tergiversan, no malgastan nuestros recursos, no gobiernan mal, no apoyan un status quo injusto y, en general, no arruinan las cosas, las personas lo hacen.

      Si nos importa lo suficiente, podemos hacerlo que cambiar.

      lunes, junio 24, 2019

      Mi opinión sobre SAFe (Scaled Agile Framework): sí, es un buen comienzo y resuelve ciertos problemas de escalado



      Constantemente leo y escucho dentro del mundo ágil: fanáticos, detractores, amigos por conveniencia, amigos con derechos, relaciones casuales y relaciones duraderas, affairs, mercenarios, fundamentalistas y todo tipo de relaciones con los frameworks, métodos y metodologías que caen en la sombrilla del Manifiesto Ágil (clic aquí) y eso es bueno, pues genera interesantes discusiones, conclusiones y fuentes de aprendizaje.

      En este camino he aprendido que no hay recetas únicas para resolver problemas que tienen los equipos de trabajo que hacen soluciones de software. Desde el punto de vista ágil me declaro Scrum por fuera y Kanban por dentro - pongo de manifiesto que cualquier framework ágil sin excelencia técnica es un desperdicio y dolor de cabeza -, de ahí en adelante lo que funcione será útil para mí, o sea, en pocas palabras soy un mercenario del escalado de ágil.

      A nivel de frameworks he trabajado en el mundo ágil con:
      • Kanban
      • Scrum
      • Scrumban
      • Playbacks (para BPM)
      • Scrum de Scrums
      • Nexus
      • SAFe
      • Scrum@Scale
      • y en compañía con el equipo de profesionales que trabajo actualmente también hemos generado nuestros híbridos y combinaciones.
      Y aunque confieso que cuando vi el diagrama de SAFe - Scaled Agile Framework me asusté y me pareció algo complejo, quisiera compartir en este post lo que he vivido con el framework (1), cuándo recomiendo desplegarlo, los problemas que he visto que soluciona, y sus beneficios. Comencemos entonces.


      Algunos problemas sistémicos escalando la agilidad

      Cuando he trabajado escalando ágil con más de 3 equipos con el mismo Product Backlog, en grandes organizaciones me he topado con los siguientes problemas:
      • Product Owners que no están al menos tres sprints adelante de su equipo realizando definiciones y resolviendo dependencias
      • Product Owners reactivos (similar a la anterior)
      • Pobre gestión de dependencias entre equipos (consecuencia de la primera)
      • Crecimiento de la complejidad
      • Poca o nula comunicación entre equipos
      • Se excede la capacidad de los equipos de soporte (infraestructura, riesgos, pruebas no funcionales, legal, etc).
      • No se mejora sistemáticamente
      y aunque todo esto se podría resolver sin el marco de SAFe, en organizaciones grandes cuesta generar este tipo alineación y sincronización debido a que su cultura actual - que es justo la que se quiere dinamizar y aumentar la colaboración - no les permite espacios para este tipo de coordinación

      Cuándo recomiendo comenzar con SAFe

      Considerando lo anterior cuándo recomiendo comenzar con SAFe:
      • Existe una cultura de gestión tradicional muy fuerte
      • Existen al menos 4 equipos trabajando con el mismo Product Backlog
      • Los Product Owner no tiene dedicación de al menos el 50% para ejecutar el rol correctamente.
      • Se están presentando problemas de gestión de dependencias y
      • Se están presentando problemas de gestión de la capacidad de las áreas de soporte


      Algunos Beneficios

      A continuación comparto algunos beneficios conseguidos en las implementaciones de SAFe que he acompañado, así como algunas que he conocido en la industria:
      • Beneficios Generales
        • Usa Scrum y Kanban como base, lo que permite una mejora sistemática
        • Mínimo cada dos semanas hay software funcionando
        • Se sale a producción por demanda
        • Se tiene al cliente como fundamento y validación de hipótesis
        • El latir de Program Increment comienza a dinamizar las organizaciones y a fuerza del hábito termina agilizando el entorno.
        • SAFe y cualquier marco ágil requiere de excelencia técnica y de DevOps, SAFe lo pone de forma explícita como insumo para su ejecución.
        • La demo gigante al final del ciclo del Program Increment genera un espacio de celebración que genera motivación a los participantes y a la par "presión" social para equipos que han decidido no trabajar con el profesionalismo mínimo que deberían tener.
      • Beneficios Asociados al Program Increment Planning  (PI Plannig)
        • Genera Product Owners proactivos, pues deben estar adelantados al menos 2 o 3 meses en su horizonte de tiempo para la sesión.
        • Durante los dos días de PI Plannig genera alineación entre equipos y la organización
        • Se resuelven dependencias entre equipos, áreas de negocio y áreas de soporte
        • Los equipos de un mismo programa se alinean con el propósito de la solución
        • Los equipos del programa se ayudan entre sí, pareciendo una gran tribu. He visto a estos equipos:
          • tomar historias de usuario de otros equipos
          • probar software que otros equipos hicieron
          • expresar su disponibilidad para ayudar a otros
          • inquietarse como programa
          • celebrar juntos como programa
        • Existe validación de capacidad por áreas de soporte
        • No permite avanzar con supuestos irreales,
        • Permite identificar un plan factible (no fijo) para el próximo ciclo de 2 a 3 meses, es decir un plan sobre el cual se puede hacer inspección y adaptacion.
      Si deseas un ejemplo de resultados organizacionales generados con el framework de SAFe te recomiendo el link de la referencia (1).

      Y las Conclusiones

      A continuación comparto algunas conclusiones:
      • SAFe en su nivel esencial (o sea a nivel de programas) lo considero un buen comienzo, para agilizar la organización, los otros niveles (Portafolio, Grandes Soluciones, Full SAFe) contienen prácticas que son buenas guías, pero las organizaciones determinarán cuales implementar y cuales no.
      • No he conocido la primera gran organización que ha desplegado el 100% de SAFe
      • Es un buen comienzo, propone soluciones interesantes a nivel de portafolio y de priorización
      • Su orientación a flujos de valor - value streams -, propuesta por muchos en el Mundo Ágil, resuelve problemas sistémicos generados por los silos
      • Sugiero desplegar SAFe con Scrum@Scale para dinamizar la toma de decisiones, y acelerar el flujo de información a nivel organizacional, tanto horizontal como vertical.
      • SAFe es un medio, no el fin en sí, lo que se quiere es proporcionarle a la organización la capacidad de adaptarse al entorno de forma dinámica.
      • En caso de que la organización fuera proclive a la agilidad, prefiero un enfoque más orgánico con una combinacion de Design Thinking + Scrum + Kanban + DevOps y prácticas de Scrum@Scale
      Por último, quienes no lo han vivido, los invito a experimentarlo,  ver las sinergias organizacionales que son consecuencia de implementar el marco y después compartan sus experiencias, de esa manera todos crecemos.

      Hasta acá este compartir.


      Saludos ágiles

      Jorge Abad




      Notas, Comentarios, Referencias y Observaciones

      1. Testimonio de uno de los clientes en los que he participado en el despliegue de SAFe -Innovación en Claro para beneficio de sus clientes (clic aquí), los videos juntos los puedes ver aquí.
      2. Agradecimientos a mi amigo Lucho Salazar por su revisión y feedback en este articulo

      jueves, junio 06, 2019

      Más de un millón de mejoras en el año en Toyota

      Hola a todos

      Con frecuencia citamos cosas por que las hemos escuchado de personas que son relevantes para nosotros y que son referentes.

      Hace un tiempo escuché y constantemente compartía algo que varios referentes decían:

       "En Toyota se hacen más de un millón de mejoras en el año con su proceso de mejora continua o Kaizen"
      Decidí averiguar la referencia a esa cita y un agilista, Hugo Suaréz me proporcionó la referencia exacta,


      Kaizen, la clave de la cultura Japonesa por Masaaki Imai


      y la Cita exactamente reza:
      "Una de las características de los trabajadores japoneses es que usan tanto el cerebro como las manos. Nuestros trabajadores proporcionan 1.5 millones de sugerencias al año y el 95% de ellas se ponen en uso práctico. Existe un interés casi tangible por el mejoramiento en el aire de Toyota" 
      Eiji Toyoda, Presidente del Consejo de la Toyota Motor.

      Gracias Hugo por la referencia y esta es una invitación a no detenerse, quiero invitarlos a:
      no caer en la tentación de realizar mejora continua por que lo dice el proceso, el framework, el marco, la metodología, o la norma, esta aproximación es una mala interpretación del método de Toyota y se aleja radicalmente del propósito del Kaizen, hay que hacer mejora continua por que es la única forma de hacernos inalcanzables.
      Gracias a mis amigos y referentes que han compartido información que es verídica y comprobable, suena obvio, pero es importante saber a que líderes seguir en el mundo empresarial y de la agilidad.

      Saludos ágiles


      Jorge Abad

      martes, junio 04, 2019

      Una idea sobre cultura, propósito, principios, valores y procesos

      Una conclusión a partir de tantas lecturas y observaciones:

      "Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

      Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

      sábado, junio 01, 2019

      Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"




      Hola a todos

      Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

      Casca-Agile (TM)

      cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

      Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

      "El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

      "Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

      Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:



      Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

      Las desventajas que esto genera

      • Largos tiempo de entrega del incremento (al menos tres sprints más)
      • La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
      • Bajo involucramiento del PO
      • La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
      • la responsabilidad sobre el producto construido no existe.
      • Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
      • El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
      • Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
      • A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

      Las ventajas

      • Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

      Solución a este antipatrón

      La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.


      Cerrando

      Bien parafrasean muchos a Jeff Sutherland,

      "el peor enemigo de Scrum, es un mal Scrum" 

      o mejor como él lo dice:


      Referemcia(4)



      Hasta acá este compartir, bienvenidos los comentarios y experiencias.

      Saludos ágiles
      Jorge Abad


      Notas, Aclaraciones, Comentarios y Referencias

      1. La Guía Oficial de Scrum - https://scrumguides.org/
      2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
      3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
      4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
      5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

      martes, mayo 14, 2019

      DevOps sin Gestión por Valor También es Desperdicio




      Podemos tener el mejor Pipeline de DevOps, pero si no existe:
      • Priorización de Portafolio 
      • Priorización de Product Backlog
      • y validación de hipótesis a nivel de iniciativas y épicas.
      Seguiremos generando desperdicio y perdiendo costo de oportunidad.



      We could have the best DevOps Pipeline, but if it does not exist:
      • Portfolio Prioritization  
      • Product Backlog Prioritization 
      • and hypotheses validation at level of initiatives and epics..
      We will continue generating waste and losing opportunity cost.





      sábado, mayo 04, 2019

      Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática



      Hola a todos

      En el pasado ScrumDay en Perú 2019, mi estimado compañero y amigo Lucho Salazar tuvo la oportunidad de presentar un poco sobre nuestra experiencia y visión sobre las historias de usuario en la charla: "Historias de usuario: todo lo que querías saber y no te atreviste a preguntar", la cual resumía algunos de los aspectos plasmados en el Libro "Historias de Usuario: Una Visión Pragmática" que publicamos en el pasado Ágiles 2018 en México. En esta presentación se toco uno de los temas que hemos observado que más genera polémica y es los diferentes modos de representación, todos creemos que el

      "yo como usuario 
      deseo esta funcionalidad 
      para este beneficio"

      es el estándar y no, no lo es, es solo una propuesta de formato hecha por Mike Cohn, en últimas lo que recomiendan muchos expertos, autores, al igual que nosotros es:

      "cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."(1)


      Dentro de estos modos de representación Lucho y yo hemos identificado cinco modos de hacerlo, los cuales pueden ser usados de acuerdo al a madurez del Equipo y del Product Owner y del contexto en que se encuentren. A continuación presentamos un ejemplo desarrollado en el libro, y que sirve como base para esta explicación:










      Aprovecho esta oportunidad para invitarlos a compartir su conocimiento y experiencias, de esa manera todos creceremos más.


      Como siempre, bienvenida la retroalimentación.

      Saludos Ágiles

      Jorge Abad y Lucho Salazar



      Notas, Aclaraciones, Comentarios y Referencias

      1. La representación de Historias de Usuario no exime de cumplir las 3 Cs, el criterio Invest y muchas prácticas recomendadas en el libro y los post de Lucho y míos sobre este tópico:



      lunes, abril 29, 2019

      Propuesta de preguntas para la reunión de Scrum de Scrums (Scrum of Scrums)

      Hola a todos

      A continuación les presentamos unas recomendaciones para una buena reunión de Scrum de Scrums (Scrum of Scrums), o de sincronización de varios equipos ágiles que están trabajando con un mismo Product Backlog o Iniciativa.

      Este post fue redactado conjuntamente con mis compañeros:
      Ahora sí al grano:


      Frecuencia
      • Al menos una vez a la semana, 
      • Deseable diariamente.

      Timebox
      • 15 a 30 Minutos


      Preguntas
      • ¿Existieron problemas en la integración del código y en las pruebas integrales del producto el día anterior?
      • ¿Qué impedimentos tienen que debamos gestionar a nivel de equipos? *
      • ¿Qué dependencias o riesgos tienen o estan próximos a activarse?
      • ¿que información consideran que debe ser compartida con todos los equipos?
      • ¿Creen que van a bloquear a alguien?
      • ¿Alguna mejora encontrada que deba ser compartida con todos los equipos?
      • ¿Alguna ayuda adicional que requieran?
      • ¿Pueden ofrecer ayuda?
      *Nota: los impedimentos, bloqueos y riesgos que se presenten a este nivel corresponden al programa entero, no deben ser presentados los que corresponden al equipo y al ámbito del Scrum master.

      Recomendaciones
      Estas preguntas deben tener la misma dinámica del daily:
      • Solo se expone lo que se está preguntando.
      • El facilitador debe generar este foco 
      • Luego, en una reunión inmediatamente después (o Meet After) de este Daily de Scrum de Scrums, se resolverán los elementos factibles a resolver
      • Se sugiere que los elementos que no puedan ser resueltos se plasmen en un kanban impedimentos y riesgos del programa, con responsable y/o responsables asignados.


      Saludos ágiles
      Jorge Abad


      Referencias, Notas, Aclaraciónes y Comentarios

      1) Scrum de Scrums en SAFe  - https://www.scaledagileframework.com/program-increment/



      2) Scrum de Scrums en Nexus - https://www.scrum.org/resources/nexus-guide 

      • ¿El trabajo del día anterior fue integrado exitosamente? Si no fue así, ¿por qué no? 
      • ¿Cuáles nuevas dependencias han sido identificadas? 
      • ¿Qué información necesita compartirse entre los equipos del Nexus? 


      3) Scrum de Scrums en Scrum at Scale - Scrum@Scale - https://www.scrumatscale.com/scrum-at-scale-guide-read-online/
      • What impediments does my team have that will prevent them from accomplishing their Sprint Goal (or impact the upcoming release)?
      • Is my team doing anything that will prevent another team from accomplishing their Sprint Goal (or impact their upcoming release)?
      • Have we discovered any new dependencies between the teams or discovered a way to resolve an existing dependency?
      • What improvements have we discovered that can be leveraged across teams?



      jueves, abril 25, 2019

      Malos Olores en Transformaciones Ágiles - Bad Smells in Agile Transformations - Scrumday Perú 2019

      De Colección: 51 frases motivadoras para trabajar en equipo

      Hola a todos

      Buscando información para una presentación me encontré con esta selección de frases, realmente es una joya (la copié para que no se me perdiera la referencia):

      1. “No hay reto que no podamos alcanzar trabajando unidos con claridad de los objetivos y conociendo los instrumentos”. -Carlos Slim.
      2. “La fuerza está en la unidad. Con la colaboración y el trabajo en equipo es posible conseguir cosas maravillosas”. -Mattie Stepanek.
      3. “Nadie puede silbar una sinfonía. Se necesita una orquesta completa para tocarla”. -HE Luccock.
      4. “Este mundo no es un campo de batalla. Algún día te darás cuenta de cómo tu éxito depende de un montón de otras personas y ese día serás más sabio. Tú sabrás que todos estamos conectados. O lo hacemos todos o ninguno de nosotros lo hace”.-Jasleen Kaur Gumber.
      5. “Ten presente que el destino de todos depende de la conducta de cada uno”. -Alejandro Magno.
      6. “Jamás pongas en duda que un pequeño grupo de personas comprometidas pueden cambiar el mundo. En efecto, es lo único capaz de lograrlo”. -Margaret Meade.
      7. “Ninguno de nosotros es tan bueno como todos nosotros juntos”. -Ray Kroc.
      8. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
      9. “Cuando las arañas tejen juntas, pueden atar a un león”.-Proverbio Etíope.
      10. “La fortaleza del equipo está en cada miembro por separado. La fortaleza de cada miembro es el equipo”. -Phil Jackson.
      11. “El trabajo en equipo es el secreto que hace que la gente común logre resultados increíbles”. – Ifeanyi Onuoha.
      12. “El trabajo en equipo es la capacidad de trabajar juntos hacia una visión común. La capacidad de dirigir los logros individuales hacia los objetivos de la organización. Es el combustible que permite que la gente normal logre resultados poco comunes”. –Andrew Carnegie.
      13. “El trabajo en equipo permite que los sueños se cumplan”. –Bang Gae.
      14. “Si un equipo quiere alcanzar su potencial, cada miembro debe estar dispuesto a doblegar sus metas personales para el bien de todos”. -Bud Wilkinson.
      15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará”. -Winston Churchill.
      16. “Con un equipo lleno de entusiasmo puedes conseguir casi cualquier cosa”. -Tahir Shah.
      17. “Un barco no avanza si cada uno está remando en una dirección”. – Proverbio Swahili.
      18. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores”. -George Clements.
      19. “Mejor perder con el equipo adecuado que ganar con el equipo equivocado”. Ogwo David Emenike.
      20. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización”. -James Cash Penney.
      21. “No existe un hombre hecho a sí mismo. Alcanzarás tus metas con la ayuda de los demás”. -George Shinn.
      22. “No hay equipo sin los miembros individuales; un individuo nunca puede ser un equipo”. -Michael Joling.
      23. “Es mucho más gratificante llegar a la cima de la montaña y compartir tu experiencia con otros que mostrarte tu solo exhausto”. -Shandel Slaten.
      24. “Solos podemos hacer muy poco; unidos podemos hacer mucho”. -Hellen Keller.
      25. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito”. -Henry Ford.
      26. “Trabaja en equipo. Unos inofensivos copos de nieve juntos pueden desatar una avalancha de destrucción.” – Justin Sewell.
      27. “Si podéis reír juntos, podéis trabajar juntos”. – Robert Orben.
      28. “Nadie puede conseguir el éxito solo”. -Ifeanyi Enoch Onuoha.
      29. “Sólo llegando a estar unidos, como una sola fuerza, nos mantendremos fuertes e inconquistables”. –Chris Bradford.
      30. “El ego es el asesino definitivo en un equipo”. – Patrick Lencioni.
      31. “El mejor trabajo en equipo proviene de aquellos hombres que trabajan de forma independiente para conseguir una meta en conjunto”. –James Cash Penney.
      32. “Tienes que ser consciente de lo que están haciendo los otros, aplaudir sus esfuerzos, reconocer sus éxitos, y animarlos en sus metas. Cuando todo el mundo se ayuda, todo el mundo gana”. – Jim Stovall.
      33. “El trabajo en equipo comienza por crear confianza. La única forma de hacerlo es superar nuestra necesidad de invulnerabilidad”. –Patrick Lencioni.
      34. “Construye en tu equipo un sentimiento de unidad, de dependencia de uno para el otro, de fortaleza derivada de la unidad”. -Vince Lombardi.
      35. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas”. -Madre Teresa de Calcuta.
      36. “Hay que unirse, no para estar juntos, sino para hacer algo juntos”. – Donoso Cortes.
      37. “Algunas veces, el mayor desafío de un jugador viene en relación con su papel en el equipo”. -Scottie Pippen.
      38. “Los equipos comparten la carga y dividen el dolor”. -Doug Smith.
      39. “Es increíble lo que se puede conseguir cuando a nadie le importa quién se lleva el crédito”. -Robert Yates.
      40. “Es literalmente verdad que puedes tener éxito mejor y más rápido al ayudar a otros a tener éxito”. -Napoleon Hill.
      41. “Un equipo es una combinación de miles de factores humanos y psicológicos encaminados hacia el mismo objetivo: La victoria”. -Manuel Gomez Brufal.
      42. “No importan cuantos logros hayas conseguido, alguien te ayudó”. -Althea Gibson.
      43. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos”. -Lyndon Johnson.
      44. “Invito a todos a elegir el perdón en lugar de la división, el trabajo en equipo en lugar de la ambición personal”. -Jean-Francois Cope.
      45. “El talento gana juegos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
      46. “Con un equipo entusiasta se puede lograr casi cualquier cosa”. -Tahir Shah.
      47. “El trabajo en equipo es el secreto que hace que la gente común logre resultados poco comunes”. -Ifeanyi Onuoha.
      48. “La velocidad del jefe es la velocidad del equipo”. -Lee Iacocca.
      49. “La colaboración no tiene jerarquía. El Sol colabora con el suelo para traer flores a la tierra”. -Amit Ray.
      50. “Mi trabajo es hacer a todo el equipo ejecutivo lo suficientemente bueno como para que sean mis sucesores”. –Steve Jobs.

      51 (Bonus) . "Si quieres ir rápido camina solo, si quieres llegar lejos ve acompañado". Proverbio Africano




      Tomada de: https://gananci.com/frases-para-trabajar-en-equipo/

      sábado, abril 20, 2019

      De colección: Un excelente tweet sobre estimación, esfuerzo y capacidad

      jueves, abril 04, 2019

      Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles

      A ratos veo tantos "modelos" ágiles, radares, métricas, modelos de madurez ágil para organizaciones, equipos, personas, roles, etc. que me da la sensación que terminamos pareciéndonos más CMMi, y a marcos tradicionales que a la agilidad que promulgamos. Tendemos a parametrizar todo, es nuestra inclinación innata, tratamos de generar fórmulas, y estandarizar y generar patrones.

      Pero olvidamos que el "driver" principal es la generación de valor al cliente, llegarle con mejores servicios y de forma temprana y continua; los radares, las métricas, los modelos de madurez son secundarios.

      Las únicas métricas importantes en todo esto son: si generamos valor y si estamos sobreviviendo en el mercado, el resto es informativo.

      lunes, abril 01, 2019

      El Equipo Oculto de Scrum: El Equipo del Product Owner o Equipo del Producto




      Hola a todos

      Este corresponde a uno de esos post que tengo en mi lista de pendientes que por fin salen a la luz después de presionarme internamente una y otra vez por ser escritos.

      Definitivamente el título del artículo es el "spoiler", pero aunque saben para donde voy, vamos a conocer las razones de esta afirmación.

      Un Product Owner con Pleno Conocimiento

      En primer lugar, tenemos equipos scrum, con esquemas muy simples de trabajo donde el Product Owner (PO), es alguien que tiene todo el conocimiento sobre el producto y le es fácil tomar decisiones sobre lo que se esta construyendo.

      Desde mi punto de vista esta es la configuración más simple pero muy escasa, principalmente en espacios corporativos, pues muchas veces para diseñar un Producto un PO debe interactuar con muchos interesados; y eso nos lleva a la siguiente configuración.


      Un PO Interactuando un Grupo de Interesados

      En este caso el PO, posible que tenga conocimiento de una parte del universo del problema pero requiere de áreas adicionales para diseñar el producto correcto.
      En este caso, cada una de esas áreas proporciona conocimiento y decisiones claves sobre el mismo, y le ayuda a entender al PO, como gestionar las dependencias, y diseñar estrategias para hacer exitosa la construcción del producto.


      El Equipo del Producto

      Bajo el contexto anterior en la medida que los productos son más complejos, los PO deben interactuar con más áreas y esas áreas son de contacto frecuente, adicionalmente estas terminan volviéndose lo que en muchos entornos se denomina "El Equipo del Producto".

      Este Equipo del producto, debido al rol que desempeñan se podrían definir como son un grupo de personas que  proporcionan información estratégica, táctica, operativa y técnica sobre el producto y que debe ser considerada para la elaboración y refinamiento del Product Backlog.




      Este Equipo del producto,es muy probable que:
      • sea con el que se realice el Inception y el continuo refinamiento del producto
      • tenga un ciclo de reuniones para hablar sobre el producto, su presente y futuro.
      • algunos de sus integrantes hagan parte de los stakeholders a los cuales después de cada sprint se presenta incremento del producto cada sprint
      • se presenten conflictos entre ellos, pues donde donde hay restricciones y diferentes intereses, lo más natural es que aparezca el conflicto
      • tengan necesidades de un facilitador, es decir,  de alguien que les ayude a coordinarse, resolver sus conflictos para no perder su foco. 

      El Equipo del Producto ¿Es realmente un equipo?

      Lo cierto, es que este Equipo del Producto permanece oculto a la vista de todos, pero es frecuente escuchar por parte del PO, del SM y hasta del Equipo de Desarrollo, quejarse de problemas de:falta de coordinación
      • involucramientos tardíos
      • falta de compromiso
      • conflicto de intereses
      • entre otros
      Y aunque este grupo de personas tengan un interés común, no implica que se vean como un equipo, pero esto no los exime de las necesidades de que exista un facilitador entre ellos que permita la fluencia de los diferentes temas que ellos tratan. Este rol de facilitador podría ser ejercido por:

      • El Product Owner (aunque sería viable por su ubicación estratégica entre el equipo Scrum y los Stakeholders, es probable que no cuente con las habilidades de facilitación)
      • El Scrum Master
      • El Agile Coach del ecosistema ágil al que pertenece el producto
      Este facilitador, determinará si avanza a formarlos como equipo, o los sigue gestionando como un grupo con un interés común.








      Unos consejos: Al menos una Sincronización Semanal y una Retrospectiva Mensual

      Ahora, sea que ellos se vean o no como equipo, es altamente recomendado:
      • Ejecutar al menos una sincronización semanal para identificar avance de pendientes y necesidades de ayuda, esto podría ser apoyado por la gestión visual que proporciona un tablero kanban.  
      • Realizar una retrospectiva cíclica, al menos una vez al mes que busque mejorar tanto las interacciones al interior como con el Equipo Scrum.
      Estas dos dinámicas serán de gran valor y sumarán bastante a la dinámica de la construcción del producto.



      Cerrando

      Por último unas preguntas:

      • ¿tienes un "equipo del producto"?¿realmente son un equipo?¿les interesa serlo?
      • ¿ya lo identificaste?¿o justo ahora te haces consciente de el?
      • ¿necesita facilitador?
      • ¿podría ser el scrum master del equipo scrum?
      • ¿podría ser otro scrum master?¿o un agile coach?
      • ¿que cadencia de sesiones tienen?
      • ¿sería útil una sicronización diaria, semanal?
      • ¿sería valioso tener al menos una retrospectiva mensual para corregir problemas y lograr responder a a las necesidades del equipo scrum?

      Hasta acá este compartir, bienvenido el feedback.

      Saludos ágiles
      Jorge Abad.





      Saludos Ágiles
      Jorge Abad