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.