Mostrando las entradas con la etiqueta coaching team. Mostrar todas las entradas
Mostrando las entradas con la etiqueta coaching team. Mostrar todas las entradas

domingo, marzo 17, 2024

4 Frases para incrementar nuestra inteligencia emocional

El liderazgo no es solo mostrar la dirección del cambio, sino tener u na conexión genuina y sincera con las personas, para esto la inteligencia emocional y la empatía juegan un rol importante.

En un artículo publicado recientemente en el períodico El Tiempo de Colombia titulado: "Si usa una de estas 4 frases tiene más inteligencia emocional que la mayoría", presentaba que Matt Abrahams, profesor de la Universidad de Stanford y experto en comunicación, compartió cuáles son las frases que suelen caracterizar a una persona con mayor inteligencia emocional:

  • Lo que te oigo decir es...
  • Déjame hacer esto bien.
  • ¿Cómo te hizo sentir eso?
  • ¿Qué pudo haberte llevado a eso?

Las anteriores preguntas "dejan ver que hay una preocupación hacia los sentimientos personales, pero también hacia los de los otros."


Saludos ágiles,


Jorge Abad.

miércoles, marzo 15, 2023

Frase equipos

 

 

“Un hombre puede ser imprescindible para un equipo, pero ningún equipo está compuesto por un solo hombre”. Kareem Abdul-Jabbar



 

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

    jueves, abril 25, 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/

    lunes, septiembre 24, 2018

    Tu Equipo Ágil no comienza siendo Ágil. Unas poderosas tres razones.



    Muchas veces pensamos que por el hecho de poner a personas juntas, pedirles que le pongan un nombre al equipo, asignarles un backlog, automáticamente se convierten en un equipo (1), y no solo eso, creemos que al primer sprint el equipo va tener la velocidad (ej: 50 puntos por sprint)  que planearon - http://www.lecciones-aprendidas.info/2017/12/un-cuarto-metodo-para-estimar-la-velocidad.html -  y que con esa velocidad podremos terminar en una fecha determinada el primer release ( ej: si el primer release se estima en 350 puntos, lo tendremos en 7 sprints).

    La verdad, esto es lejano de la realidad, los equipos toman un tiempo en crearse y madurarse - tal vez  8 sprints, más o menos, y esto dependerá de muchos factores - y alcanzar un buen desempeño, en este post compartiré las razones por las cuales esto se presenta y algunas recomendaciones para ayudarte en este proceso.



    1. La Curva de Tuckman



    Este modelo muestra las diferentes etapas por las cuales pasa un equipo (2),  ella muestra el esfuerzo que toma lograr el mismo estado de desempeño inicial en el cual se formo el equipo. Solo imaginémonos haciendo parte de un equipo de fútbol, rugby, baloncesto, voleibol, musical - en fin cualquier equipo - y el esfuerzo que nos toma acoplarnos, las veces que debemos jugar / tocar  juntos para sentirnos cómodos los unos con los otros.


    2. La Curva del Cambio o Curva "J" (fuentes: Elisabeth Kübler-Ross, Albretch, David Viney y otros)


    Ver fuente (3)
    Ver fuente (4)


    Ver fuente (5) - Un excelente post- 

    Las causas por las cuales se transita esta curva son muchas, pues cuando llegamos a un nuevo proyecto se vienen cambios como:
    • El nuevo proyecto (obviamente)
    • Conocer una nueva tecnolología
    • Conocer a mis compañeros
    • Conocerme interactuando con mis compañeros
    • Conocer un nuevo negocio
    • Conocer una nueva metodología
    • Conocer una nueva empresa y sus reglas
    • Conocer los nuevos sistemas
    • Conocer la forma de interactuar en esa organización.

    Lo que nos demandará inevitablemente avanzar por esta "J" del cambio y desempeño.

    y por último (aunque no sé si sea la última causa, puede que existan más)

    3. La Zona de Reducción de Riesgos en TI  de Cockburn



    Esta curva ya la habíamos discutido en otro post anterior - ¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)? clic aquí - y observábamos que cuando un equipo supera la zona de adquisición de conocimiento la generación de valor fluye a ritmo constante, por lo tanto, aunque los equipos conozcan:

    • la metodología, 
    • el lenguaje de programación 
    • y la tecnología que están manejando, 
    existe el conocimiento que no poseen y que directamente implica un esfuerzo como:
    • nuevas reglas de negocio
    • los sistemas con los que interactuarán
    • la interacción para la empresa en la que estan comenzando a trabajar (suponiendo que son proveedores, aun si son internos pero todos son nuevos)
    Y es en consecuencia, natural que exista una fricción inicial para alcanzar rendimiento y puedan jugar bien como equipo scrum o como un equipo ágil.

    Ahora, habrá mucha más fricción si:
    • la tecnología es nueva
    • es primera vez que trabajan como equipo
    • es primera vez que interactúan usando la metodología o framework de trabajo


    Unas Cuantas Conclusiones

    1. Es inevitable pasar por la zona de baja productividad
    2. En mi experiencia, he observado que los equipos logran llegar a la Fase Normalización de Tuckman aproximadamente  entre 4 y 8 sprints - sprints de duración de dos semanas-, antes no. Si alguien tiene mejores datos al respecto agradecería mucho los compartiera. 
    3. El periodo de 4 a 8 sprints podría ser más largo pero he observado que los ciclos continuos de feedback aceleran el proceso de maduración, permitiendo avanzar rápidamente en la curva J - ver este post donde afirmo que Scrum es un modelo de Auto-Coaching de equipos http://www.lecciones-aprendidas.info/2018/08/scrum-como-modelo-de-auto-coaching.html -.
    4. Se requiere de un buen liderazgo situacional del Scrum Master para que este periodo sea cubierto de forma exitosa. - ver este post Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización http://www.lecciones-aprendidas.info/2015/11/como-ensenando-montar-en-bicicleta-como.html -
    5. La verdadera velocidad o capacidad del equipo debe considerarse después del ciclo de estabilización, o sea, después del quinto o noveno sprint según el caso.
    6. Recordemos que el Product Owner,  el Scrum Master y el Equipo de Desarrollo, son un equipo por lo tanto, todos están padeciendo los efectos de este inicio y acople.
    7. Luego de estabilizada la velocidad o capacidad del equipo, la forma de incrementarla poco a poco es:
      • promoviendo la excelencia técnica
      • no escribiendo código basura, apestoso o "crappy code"
      • removiendo la deuda técnica y haciendo refactors estratégicos
      • aplicando las prácticas ágiles de desarrollo (pair programming, tdd, propiedad colectiva del código, etc)
      • implementando las mejoras identificadas en las retrospectivas
      • tener retrospectivas exitosas que le permitan al equipo avanzar en la dirección correcta - ver post http://www.lecciones-aprendidas.info/2017/02/scrum-master-como-continuar-la-mejora.html
      • trabajar la felicidad del equipo


    Cerrando, Qué recomiendo

    1. No es una buena estrategia estar armando y desarmando equipos, se pierden estos procesos de acople, un principio importante a aplicar llevarle proyectos a los equipos en vez de armar equipos para los proyectos, es muchísimo más productivo para todos.
    2. Recomiendo que al menos la mitad más uno de los integrantes del equipo sean entre Semi-senior y senior, esto acelera los procesos de formación de equipo y reduce considerablemente la creación de código basura debido a inexperiencia de los Juniors, pues los desarrolladores maduros le hacen mentoring a los nuevos - esto es de bastante importancia en equipos que desarrollan software - 
    3. Hacer consciente a las organizaciones que comienzan con scrum, o con cualquier marco ágil,  que sus equipos agiles no van a ser "super- ágiles" y "super productivos" por el simple echo de que los pongamos juntos, con un tablero lleno de post-it, Jira u otro software instalado, un Product Owner y un Scrum Master,  es cierto van a ser mejores que en cascada o tradicional, pero es un hecho las primeras velocidades son lentas, y se requiere de acompañamiento incrementarlas.
    4. Se recomienda hacer las proyecciones de cuando se va a entregar el producto luego de la fase de estabilización, antes no tiene sentido hacer proyección alguna, 
    5. Liderazgo situacional es clave en este tipo de procesos. Sugiero se revise esta colección de post Tips para Comenzar con un Equipo Scrum - http://www.lecciones-aprendidas.info/search/label/comenzando%20con%20scrum proporciona herramientas útiles en el proceso de maduración y estabilización de tu equipo.

    Hasta acá este compartir. Bienvenido el feedback.

    Saludos Ágiles

    Jorge Abad.


    Notas, Comentarios, Observaciones y Referencias

    1. Les recomiendo este artículo de Martín Alaimo - http://www.martinalaimo.com/es/blog/hacia-un-equipo-real - y la serie de "Hacia un Equipos Real" - http://www.martinalaimo.com/es/blog/tag/equipos-reales-.
    2. Explicación de la curva de Tuckman en este post:  Equipos Estables por sobre Pool de Recursos - http://www.martinalaimo.com/es/blog/equipos-estables
    3. Curva de Cambio - http://activaconocimiento.es/curva-de-cambio/
    4. Las fases que vivimos ante un cambio -https://elpais.com/elpais/2013/12/16/laboratorio_de_felicidad/1387150998_138715.html
    5. Falsos Positivos (agárrense que vienen curvas) https://wynwin.wordpress.com/2013/05/10/falsos-positivos/

    martes, agosto 21, 2018

    Scrum Como Modelo de Auto-Coaching para los Equipos




    Hola a todos

    Hace unos días en una reunión de Ágiles Ecuador - en la que tuve la oportunidad de ser el facilitador de la Sesión de Migas de Pan(1)-, alguien sugería al cierre de la misma que para ser Scrum Master era necesario hacer un coach profesional como primer paso, y después de debatir un poco, decantábamos que no, que no era necesario, pues tanto un Scrum Master, un Agile Coach de Equipos o un Agile Coach Empresarial tienen más de mentor, de experto, de maestro, de líder, de entrenador de equipos, que alguien que a través de preguntas quiere acompañar a un individuo en su viaje de un estado a otro en su vida (y reconozco que este es un punto que aun no se termina de desarrollar en la comunidad ágil).

    Pero también en esa discusión observábamos que un equipo que hace Scrum, tiene un ciclo de mejora continua que esta cuestionando constantemente tres ejes:
    • La organización
    • El equipo
    • La persona que hace parte del equipo Scrum

    Cíclicamente un equipo que hace Scrum, se enfrenta a su verdad - gústele o no - pues al principio en el Planning hacen una compromiso de lo que creen que van a construir y al final en la Review están mostrando lo que lograron a los Stakeholders y luego se van a la Retrospectiva con su resultado a filosofar que pueden hacer distinto para ser más exitosos el siguiente ciclo. Este ejercicio de:
    • hacer una apuesta basados en su capacidad
    • ver el resultado
    • mostrar el resultado
    • enfrentarse al feedback de sus stakeholders
    • indagar por que se obtuvo el resultado
    • proponer que mejorar internamente para ser más exitosos la próxima vez
    • proponer que mejorar externamente para ser más exitosos la próxima vez
    Termina cambiando a las personas, equipos y organizaciones.


    Esta dinámica genera un circulo virtuoso transformador, pues:
    • te va haciendo responsable de tus compromisos
    • te hace revisar tus capacidades y buscar nuevas
    • te invita a tener mejores interacciones con tus compañeros para tener éxito
    • te invita a cuestionarte, cuestionar respetuosamente a los otros y cuestionar a la organización en la que estas inmerso
    En definitiva, no te puedes quedar quieto ante un marco que cada semana, dos semanas o máximo un mes te muestra tu verdad tal cual es, o cambias, o cambias (así lo he visto funcionar cantidad de veces)

    Scrum por sus ciclos de PHVA(2) continuos, termina cambiando al Equipo, al Scrum Master y al Product Owner, y al final de su viaje en la construcción del producto terminan siendo personas completamente distintas  y quienes hayan vivido este viaje sabrán darme la razón.

    Para cerrar es importante aclarar que no solo Scrum puede darte este beneficio, cualquier modelo de trabajo que en ciclos cortos (de no más de un mes) nos esté enfrentando a la verdad y nos esté retando a salir de nuestra zona confort generará resultado similares.

    Bonus Track

    Ahora, cuando alguien me pregunta ¿que tiene que hacer para ser Agile Coach? lo invito a que comience este camino con corazón (3) siendo Scrum Master - que es el Agile Coach del equipo Scrum-, y enfrente allí sus verdades, junto con su equipo, y luego de al menos cuestionarse, cuestionar, y retar durante un buen tiempo determine hacia donde seguir avanzando.


    Bueno, hasta acá esta corta reflexión y compartir.

    Si tienes algún comentario bienvenido el feedback en la zona de comentarios

    Saludos Ágiles

    Jorge Abad


    Notas, Aclaraciones, Comentarios y Referencias

    1. Actividad que le aprendí de mi gran amigo Carlos Gil
    2. El ciclo Planear - Hacer - Verificar - Actuar, promovido por E. Deming
    3."...Cualquier cosa es un camino entre cantidades de caminos. Por eso debes tener siempre presente que un camino es sólo un camino. Si sientes que no deberías seguirlo, no debes seguir en él bajo ninguna condición. Para tener esa claridad debes llevar una vida disciplinada.Sólo entonces sabrás que un camino es nada más un camino, y no hay afrenta, ni para ti ni para otros, en dejarlo si eso es lo que tu corazón te dice.

    Pero tu decisión de seguir en el camino o de dejarlo debe estar libre de miedo y de ambición. (...) Mira cada camino de cerca y con intención. Pruébalo tantas veces como consideres necesario.

    Luego hazte a ti mismo, y a ti solo, una pregunta: ¿Tiene corazón este camino?

    Si tiene, el camino es bueno; si no, de nada sirve. Todos los caminos son lo mismo, no llevan a ninguna parte. Son caminos que van por el matorral. Ningún camino lleva a ninguna parte, pero uno tiene corazón y el otro no..." Uno hace gozoso el viaje; mientras lo sigas, eres uno con él. El otro te hará maldecir tu vida. Uno te hace fuerte; el otro te debilita."

    El problema es que nadie se hace la pregunta, y cuando por fin se da cuenta de que ha tomado un camino sin corazón, el camino está ya a punto de matarlo.Un camino sin corazón nunca se puede disfrutar. Hay que trabajar duro tan sólo para tomarlo. En ese punto pocas personas pueden parar a pensar y dejar el camino...

    En cambio, un camino con corazón es fácil: no te hace trabajar por tomarle gusto. Para mí existe solamente el viajar por caminos con corazón, en cualquier camino que pueda tener corazón. Por ahí viajo, y el único desafío que vale la pena es atravesarlo en toda su longitud. Y por ahí viajo, buscando, buscando, sin aliento". (“Las enseñanzas de Don Juan” de Carlos Castañeda.)

    viernes, febrero 17, 2017

    Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo



    Hola a todos:

    Hace poco en una sesión de acompañamiento a Scrum Master, alguien me preguntó

    ¿Hacia dónde seguir mejorando el equipo, pues creo que no podemos mejorar más?

    Ante esta pregunta, comencé a explicar el Modelo Operativo de Generación de Valor (1) el cual se basa en:

    • Personas
    • Procesos y
    • Herramientas


    Por lo tanto, si el Scrum Master se centra solo en personas y procesos "rápidamente" (tal vez en 10 sprints, tal vez muchos más, tal vez menos ) el equipo logrará sinergia y alcanzará la maestría en el manejo de Scrum, sus ceremonias, priorización del backlog, etc.,  y caerán en una "zona cómoda" en la cual la pregunta realizada tiene todo el sentido.

    Bajo este contexto la frase de Ken Schwaber - cocreador de Scrum -  toma todo el sentido:

    “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”( no dudo que la hubiera querido terminar con otra palabra)


    Es necesario entonces, que como Scrum Masters y Coaches adicionemos a los procesos de mejora del equipo las herramientas (2) -o prácticas técnicas- y lograr que los equipos adquieran la maestría en ellas, aun más que sean sanamente insatisfechos y estén siempre buscando una mejor manera de hacer las cosas. De esta forma se genera valor hacia el interior y exterior del equipo estando en constante crecimiento.

    Cerrando

    A continuación quiero compartirles una pequeño listado de prácticas técnicas con las que pueden y deben retar a sus equipos como Coaches Agiles que son de ellos, la lista en esta en continuo crecimiento, este es el pequeño listado que encontré a la fecha:



    Herramientas (Prácticas ágiles) 

    Zona 1: Personas y Herramientas
    • Inspección o revision por pares
    Zona 2: Procesos y Herramientas
    • Pruebas unitarias
    • Test Driven Development (TDD)
    • Aceptance Driven Development (ATDD)
    • Refactoring
    Zona 3: Personas, Procesos y Herramientas
    • Pair Programming
    • Mob Programming
    Zona 4: Solo Herramientas
    • Integración Continua
    • Despliegue Continuo
    • Revisión de código estática
    • Pruebas funcionales Automatizadas
    • Principios SOLID de POO (Programación orientada a objetos)
    • Clean Code
    • Automatizar lo automatizable
    • etc, etc, etc.




    Para terminar les comparto esta frase que constantemente me inquieta "los pacientes se enferman de lo que el médico sabe (3)", por lo tanto si como Scrum master o Coach no estas en constante aprendizaje de estas tres áreas no podrás ayudar apropiadamente a tu equipo


    Bienvenido el feedback


    Saludos ágiles
    Jorge Abad


    Notas, Aclaraciones, Comentarios y Referencias


    1. Operating model - https://en.wikipedia.org/wiki/Operating_model
    2. El tablero Kanban, la Gestión Visual, etc también son herramientas, el objetivo del post es hacer visible el punto de las prácticas técnicas ágiles.
    3. "los pacientes se enferman de lo que el médico sabe" - clic aquí para ver post relacionado




    viernes, octubre 21, 2016

    Cumplimiento de Promesas y Ofertas como Generadores de Confianza y Tejido en los Equipos



    Diagrama basado en el libro de Ontología del Lenguaje de Rafael Echeverría

    Hola a todos

    les comparto las reflexiones asociadas a este diagrama que me fue explicado por mi amigo Wbeimar Vásquez:

    • Hacia el interior del equipo
      • El cumplimiento de ofertas y promesas entre los miembros del equipo  produce CONFIANZA
      • La CONFIANZA logra tejido social y relaciones fuertes al interior del equipo y capacidad para asumir compromisos y realizarceles pedidos que serán cumplidos
    • Hacia el exterior del equipo
      • El cumplimiento de ofertas y promesas del equipo produce CONFIANZA en el equipo.
      • La CONFIANZA en el equipo logra tejido social y relaciones fuertes con el equipo y capacidad para asumir y asignarles pedidos retos, compromisos.

    En el sentido negativo sería:
    • Hacia el interior del equipo
      • El incumplimiento de ofertas y promesas entre los miembros del equipo  produce DESCONFIANZA
      • La DESCONFIANZA deteriora tejido social, debilita y destruye relaciones al interior del equipo y genera incapacidad para asumir compromisos y pedidos
    • Hacia el exterior del equipo
      • El incumplimiento de ofertas y promesas del equipo produce DESCONFIANZA en el equipo.
      • La DESCONFIANZA en el equipo deteriora tejido social, debilita y destruye las relaciones con el equipo y se duda en su capacidad de asumir compromisos, asignarle retos y realizarceles pedidos.
    Hasta acá esta pequeña reflexión


    Saludos Ágiles
    Jorge Abad


    sábado, octubre 01, 2016

    Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión




    Hola a todos

    He notado que además del Planning que compromete al equipo y el Review en el cual el equipo entrega el incremento al Product Owner y a los interesados, una de las grandes herramientas que tiene el Scrum Master para la incentivar y lograr la autoorganización de un equipo son las Preguntas Poderosas (1), estas son una herramienta común del coaching de personas y  equipos (2)  y permiten:

    • Generar curiosidad
    • Estimular la reflexión y el pensamiento
    • Sacar a la superficie creencias y supuestos
    • Abre la creatividad y nuevas posibilidades
    • Generar energía, invitar a la acción
    • Canalizar y enfoca la atención
    • Tocar un significado profundo
    • Empoderar, responsabilizar
    • Cuestionar al equipo y no a una sola persona
    • Evidenciar al equipo lo responsables que son del resultado
    • Invitar a encontrar soluciones entre ellos
    • Permitirque el equipo se escuche y surjan ideas creativas, innovadoras y divergentes
    • Suscitar más preguntas
    muy a diferencia de la estrategia tradicional de gestión de proyectos en "comando-control" donde el gerente asigna las tareas a cada miembro del equipo y este estos reportan su avance. En este aspecto se diferencian los estilos de liderazgo mientras el el Scrum Master  cuestiona y empodera el Gerente de Proyecto dirige y asigna para lograr el objetivo.


    Mientras el Gerente de Proyecto dirige y asigna, el Scrum Master cuestiona y empodera para lograr el objetivo. 

    El poder de las preguntas poderosas esta dado en la capacidad de abrir posibilidades, acciones y proporcionar información valiosa, por lo tanto, las preguntas abiertas proporcionan más información que las cerradas, sin demeritar que un simple "Sí", "No" o "Estamos de acuerdo" según el contexto nos permiten actuar o no en cierta dirección. A continuación bajo esta óptica presento una simple clasificación de estilos de pregunta
    • Alta importancia (proporcionan mucha información)
      • Qué 
      • Por qué
      • Cómo
      • Para qué
      • Qué tal si
    • Media importancia (proporcionan menos información)
      • Cuándo
      • Dónde
      • Quién
    • Baja importancia (proporcionan poca información)
      • Cierto o falso
      • Te gustaría
      • Podrías
      • Están de acuerdo
      • Estás de acuerdo

    Cómo se usan en Scrum

    A continuación comparto algunas unas preguntas que se pueden realizar en cada uno de los momentos que se viven durante un sprint, igual no dudo que en el instante apropiado el Scrum Master sabrá cuales realizar ya sean estas que están propuestas u otras mejores:


    Planning
    • ¿Cómo consideran ustedes que van a lograr construir todas las historias comprometidas en este planning?
    • ¿Se sienten tranquilos con el sprint backlog?¿Por qué?

    Durante el sprint
    • En la mitad del sprint
      • ¿Creen que podremos lograr el objetivo del sprint y las historias comprometidas?¿Qué estrategia podemos idearnos como equipo para lograrlo?
      • ¿Se encuentran tranquilos con la calidad del producto que estamos logrando?¿Qué podemos hacer?
      • ¿Cómo creen que se debe resolver esta situación?
      • ¿Qué deberíamos hacer para estar completamente tranquilos?
    • Si algo va mal
      • ¿Creen ustedes qué vamos en la dirección correcta?¿Qué podemos hacer para corregirla?
      • ¿Qué necesitan para hacerse cargo? 
      • ¿Cuándo se van a hacer cargo? 

    En la retrospectiva (el lugar más natural de las preguntas poderosas)
    • ¿Qué podríamos hacer diferente el próximo sprint para que nos fuera mejor?
    • ¿Usted qué cree que anda mal en el equipo? ¿Como lo mejoraría?
    • ¿Qué necesitamos hacer para ser un mejor equipo?
    • ¿Estamos tranquilos con la forma como estamos construyendo el producto?¿Por qué?
    • ¿Qué Podemos construir el producto mejor?
    • ¿Cómo podría la organización soportar mejor al equipo?
    • ¿y si nos atrevemos a?
    • ¿ y si vemos esto desde otra óptica?
    • entre muchas otras.

    Para terminar quisiera dejar esta pregunta:

    ¿Cómo Scrum Master o Team Member(3) que preguntas le haces a tu equipo?


    Si lo deseas únete a la conversación a través de twitter, este es el tweet:



    Bienvenido el feedback


    Saludos Ágiles
    Jorge Abad



    Notas, Aclaraciones, Comentarios y Referencias

    1. No es mi tradición subrayar, pero desde mi punto de vista la idea es clave para llegar a ser un buen Scrum Master.
    2. Algunas características tomadas de http://es.slideshare.net/CoachingTalanton/preguntas-poderosas-12961845
    3. Un miembro del equipo también es alguien llamado a cuestionar a su equipo.
    4. Buenos ejemplos de preguntas poderosas - http://www.coactive.com/learning-hub/es/intermediate/fulfillment/res/tools/FUL-Ejemplos-de-preguntas-poderosas.pdf

    jueves, septiembre 29, 2016

    sábado, septiembre 03, 2016

    Comenzando con un equipo Scrum: Actividades para activar un equipo el primer día, team canvas y otras técnicas

    Hola a todos

    Hoy quiero compartirles una agenda de trabajo que pueden emplear el primer día que comienzan con un equipo ya sea tu rol como facilitador, scrum master, gerente ágil o gerente de proyectos.

    Primero: Conozcamos nuestros nombres y una comida que no nos gusta

    • Tiempo máximo : 30 minutos (dependiendo de la cantidad de personas)
    En esta parte hago una ronda con el equipo y lo comenzamos por la derecha contestando varias preguntas sencillas

    • Nombre
    • Rol o cargo
    • comida que no nos gusta (he notado que genera mucha empatía este tema), pero se puede reemplazar por:
      • Película de cine que más le gusto
      • lugar bonito al que haya ido
      • última película de cine
      • un restaurante
      • etc.
    La segunda persona contesta este sencillo esquema y repite el de su compañero de la izquierda junto con la comida con le gusta, la tercera persona lo mismo con sus dos compañeros, hasta que el último (o sea el facilitador) dirá el nombre de todos y la comida que no le gusta.

    Segundo: Una actividad de equipo

    • Tiempo máximo : 60 minutos (dependiendo de la actividad)

    Resulta que el equipo aun no es un ser como tal, saben todos que ese es el objetivo pero aun no nace, es un imaginario. entonces en este punto recomiendo realizar un reto de equipo, dentro de este reto de equipo los ponga a trabajar juntos y les de sinergia, dentro de estos retos pueden estar los siguientes:

    Tercero: Un nombre y una imagen

    • Tiempo máximo : 30 minutos 
    Habiendo interactuado juntos, la idea es que cada uno se dibuje dentro de un pliego de papel y busquen un nombre para el equipo, esta actividad les da identidad, pertenencia y los ubica en un mismo espacio.



    Cuarto: Personal Maps o Mapas Personales

    • Tiempo máximo : 45 minutos 
    Luego cada uno de los integrantes del equipo debe realizar un mapa personal (o elaborarlo entrevistado por un compañero) y lo presenta el equipo, esta actividad ayuda a mejorar las interacciones y a entender que no somos roles, ni cargos, somos personas que tienen una vida, metas y aspectos muy variados fuera de la zona de interacción, y permite mejorar la forma como vamos a trabajar.





    Y para cerrar, Team Canvas (2)

    • Tiempo máximo : 120 minutos
    En esta actividad el equipo en conjunto define aspectos fundamentales de su interacción
    • Propósito
    • Personas y roles
    • Objetivos comunes
    • Valores
    • Reglas y actividades
    • Fortalezas
    • Debilidades y riesgos
    Van navegando por cada de uno de ellos con un timebox determinado, en este link encontrarán la guía para realizarlo - http://theteamcanvas.com/use/



    Con esto definido, están listos para los retos que juntos van a enfrentar.


    Concluyendo

    Esta agenda es una propuesta inicial, pueden haber muchas agendas de trabajo, si tienen mejoras me encantaría que me las compartieran.

    Saludos ágiles

    Jorge Abad


    Referencias, comentarios, aclaraciones y notas

    1. Esta actividad la conocí gracias a mi estimado compañero y amigo Sebastián Velásquez - @sebasla
    2. Este lienzo lo conocí gracias a mi amigo y maestro Lucho Salazar - @LuchoSalazarC


    sábado, julio 16, 2016

    ¿Cuáles son las fronteras de un scrum master como coach?

    (1) Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal


    Hola a todos

    Hace unos días reflexionaba sobre ¿hasta dónde debería llegar el Scrum Master en su rol de Coach del Equipo y del Product Owner?(2)(3), pues muchas veces observo compañeros que estoy acompañando en este proceso de ser Scrum Master  en líos cuando aparecían personas dentro de sus equipos que:
    • no querían o no les interesa trabajar en equipo
    • son lobos solitarios
    • son perezosos 
    • incumplen frecuentemente sus compromisos ante el equipo
    • maltratan constante a sus compañeros con su comportamiento y palabras
    • son tóxicos
    • o que con su dinámica de día a día afectan de forma negativa al equipo de trabajo

    Estas personas se convierten en un reto tanto para el equipo como para el scrum master, ni con las retrospectivas, ni con sesiones personales de feedback se logra que las condiciones mejoren, es allí donde el Scrum Master debe reconocer que este no es su área y debe delegar esto en talento humano organizacional (o recursos humanos - como se llama en algunas empresas -), en este caso es posible que se activen varios caminos:
    • el team member comience un trabajo de mejora acompañado por talento humano
    • el team member comience un trabajo sicologico
    • el team member no continue trabajando con el equipo
    • el team member no continue en la organización

    No son caminos fáciles, pero en Agile las disfunciones se evidencian más rápido pues los ciclos cortos de feedback habilitan que los problemas salgan mas pronto a flote.

    Espero este post sea de ayuda, bienvenido el feedback


    Saludos ágiles
    Jorge Abad


    Notas, aclaraciones, comentarios y referencias

    1. Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal
    2. Realicé esta pregunta al foro de ágiles latinoamérica  para ver las respuestas  hacer clic aquí
    3. También realice a Martin Alaimo @MartinAlaimo (autor y agilista de renombre en Latinoamérica) y esta fue su respuesta: "Desde el punto de vista del Coaching, uno debería darse cuenta cuándo alguien está fuera de las posibilidades del coach y ahí entra en juego la humildad para decir "con esto yo no puedo" y derivar el caso a un profesional"

    domingo, noviembre 22, 2015

    Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado





    "Un gran poder conlleva una gran responsabilidad", le decía el tío Ben a Spiderman, y la verdad, es de los primeros mensajes que se debe dar a un equipo cuando se les habla de autooganización

    Muchos team members (miembros de equipo en Scrum) malinterpretan el término y lo consideran una declaración de anarquía que implica que ya no deben cumplir su contrato laboral, con expresiones como:




    • "Como soy autogestionado no tengo que avisar a nadie a que horas entro o salgo de trabajar", considerando que tienen una jornada laboral contratada de 8 ó 9 horas (según el contrato laboral (¡¡¡PLOP!!! - caso real -)
    • "Trabajaré haciendo lo que mejor pueda, aunque pueda dar más no lo voy a hacer"
    • "Como soy autogestionado, puedo dedicar todo el tiempo que desee a facebook o whatsapp"
    • "Salgo a hacer una vuelta y no tengo por que avisarle a nadie"
    • "Aunque todos llegan a las 8 am para el daily, la verdad  a mi eso no me aporta llegaré todos los días a las 9 am y no estaré en el daily por qué eso no me aporta" (¡¡¡RE_PLOP!!! - caso real -)
    • "Ya hice mi parte y la pasé al equipo de Quality Assurance"
    • Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado"
    • Cuando inflo las estimaciones en el planning para trabajar con "muy buena holgura" 
    • etc.[1]


    Mike Cohn (@mikewcohn) argumenta (clic aquí)
    • Autogestión no significa (clic aquí)
      • El equipo decide que objetivo alcanzar
      • o incluso quien es parte del equipo
    • Autogestión es:
      • acerca como el equipo determina como responder al ambiente (a los objetivos planteados)
      • y los líderes y gerentes influencian el ambiente
    La autogestión es mas orientada a ser capaces de gestionar el trabajo en progreso y monitorear el progreso, y en un nivel superior cuando el equipo es autoorganizado (cuando el equipo es más maduro) ser capaces de diseñar el equipo y su contexto, como lo muestra la siguiente imagen:
    tomada de[2]: 

    Entre tantas cosas he descubierto que un equipo es autogestionado cuando

    • Son dueños del sprint backlog durante el sprint.
    • Deciden cual es la mejor estrategia para consumir el sprint backlog durante el sprint.
    • Honran los compromisos y la palabra dada en el planning  y utilizan el timebox del sprint lo más productivo posible, y en caso de que se termine el sprint backlog pedir al PO más ítemes
    • Si me comprometí con mi equipo a hacer una cantidad de puntos, a no dejar tirado a mi equipo con el compromiso
    • Dan visibilidad de los impedimentos
    • Ponen todo el empeño para que en la jornada laboral se cumpla el compromiso y en caso de observar que no se va a cumplir dar visibilidad de las razones que ocasionaron que no se cumpliera
    • Gestionan el progreso durante el sprint tanto en el kanban, burdown chart o cualquier herramienta de gestión y/o gestión visual
    • Sus team members cumplen con el contrato laboral (la verdad es lo mínimo, pero hay personas que es necesario explicárselo)

    Y es allí donde el papel del Scrum Master toma importancia pues guía al equipo y a los respectivos team members a entender el concepto, a hacerles entender la responsabilidad que tienen y el poder que tienen en sus manos. De manera  que están cambiando el micro-seguimiento o RC [3], por la libertad de dar visibilidad del progreso y de potencializar la interacción con sus compañeros generando verdadero trabajo de equipo.

    Yo creo en el agilismo, lo he visto funcionar, pero siempre que comienzo con un equipo scrum es de los primeros mensajes que doy, pues libertad no significa libertinaje, y agilismo no significa que no te enfoques responsable y maduramente en cumplir los compromisos que adquieres al principio de cada ciclo o sprint.


    Termino como empecé, parafraseando un poco

    "Team Member ser autogestionado es un gran poder, y un gran poder conlleva una gran responsabilidad"

    Saludos ágiles

    Jorge Abad



    Referencias 
    1. Hay algunos pensamientos extractados en el hashtag de twitter #LesaAgilidad (sería genial que aportaras algunos que consideres)
    2. http://www.applitude.se/2011/05/self-organizing-teams-the-most-debated-agile-principle/
    3. RC: "Respiración en el Cuello" del gerente de proyecto, que por ejemplo pregunta cada hora, ¿cómo vas?



    lunes, noviembre 16, 2015

    Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización


    Desde hace un tiempo vengo profundizando en cómo lograr la autoorganización en los equipos,  este tema me apasiona entenderlo e intriga de forma insistente a quienes pasan de la gestión tradicional (comando - control) a la agilidad, como lograr la autoorganización (la confianza, la inspección y adaptación). He escrito varios post con este tema de trasfondo:
    • Ejecutando proyectos con equipos autogestionados - clic aquí
    • ¿Y por qué dudamos de la auto-organización de los equipos? - clic aquí
    • Como Jugando Fútbol - Un Símil con Scrum - clic aquí
    • Cualquiera puede ser ágil / Cualquier equipo puede ser ágil - clic aquí
    • Más en el label Autoorganización- clic aquí

    Y lo que quiero compartir hoy es, como un Scrum Master lleva al equipo a la autoorganización (algo comencé en este post - Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos -) pues es allí donde toma valor la presencia de un Scrum Master como parte del equipo.

    Coincido plenamente en el modelo propuesto Ángel Medinilla  @angel_m, para los pasos o edades que vive un Scrum Master, en el cual se pasa de "The Scrum Guy" hasta "Scrum Sensei"


    Pero, aunque se alcance el estado de "The True Scrum Master" o "Scrum Sensei", es necesario considerar el liderazgo situacional (propuesto por Blanchard) cada que se inicia un nuevo team de Scrum.


    Ese liderazgo situacional (o estilo de acompañar a un equipo Scrum por parte del Scrum Master) debe ser según el estado de madurez del equipo





    *Etapas del equipo vs Tipo de Scrum Master Requerido (elaboración propia)
    Etapa del equipo (Tuckman)
    Tipo de Scrum Master Requerido

    Scrum Dude / Scrum Guy
    1. Formación ( Forming)
    Scrum Mom
    2. Conflicto (Storming)
    True Scrum Master
    3. Normalización (Norming),
    True Scrum Master
    4. Desempeño (Performing),
    Scrum Sensei / True Scrum Master
    5. Separación (Adjourning),
    Scrum Sensei / True Scrum Master


    Y ese estilo de acompañamiento que lo lleva a la autoorganización lo veo muy similar a Enseñar a Montar en Bicicleta (wow me tomo mucha argumentación llegar hasta acá, pero sentí que debía hacerlo .. continuemos) pues:

    • al principio tu debes guiar, dirigir, inspirar, dar instrucciones precisas para que el equipo vaya aprendiendo scrum (y el niño comience a montar en bicicleta) Acá es típico que:
      • se tiene que insistir en lo importante de los dailys y como hacerlos bien -clic aqui-
      • no falta quien diga: "soy autoorganizado entro a las 10 y me voy a las 2 ¡¡PLOP!! - prometo un post de esto - " y es necesario hablarle de compromiso, disciplina, confianza, madurez, de que la autoorganización se entiende como la capacidad del equipo de resolver independientemente su compromiso de sprint backlog sin faltar a sus compromisos laborales.
      • Timebox de las reuniones, etc.
    • luego comienzas a soltar poco a poco y es hasta probable que el equipo se caiga, aprenda y tropiece pero sigues soportándolo corriendo detrás de él agarrando el sillín/silla algunas veces.
      • Fallen experimentos
      • Propuestas de retrospectivas funcionen y otras no
    • y luego lo "dejas solo" sin dejar de acompañarlo, dándole instrucciones lejanas de cuidado, o advertencia, u otras muchas animándolo.
      • Tal vez, visitas el kanban y preguntas como van con la herramienta, si les ha servido, los felicitas o les explicas el por que de ciertas prácticas
    • hasta que ya no necesita de ti para ser autoorganizado y el equipo completamente independiente
    Aclaro, se sigue necesitando del Scrum Master para remover impedimentos y realizar las otras muchas tareas, pero ya no necesitan del Scrum Master para autoorganizarse, pero sí talvez para algún cuestionamiento que los lleve a ser cada vez mejores.


    Nota: No creo en coach de Scrum o Scrum Masters certificados o no, que nunca hayan practicado Scrum, no saben transmitir la esencia del mismo y el espíritu que hay detrás del Framework. En el lenguaje de la bicicleta sería: aunque no dudo que hayan casos de quienes enseñen a montar en bicicleta sin haberla montado, la experiencia de quien enseña es importante para que quien esta aprendiendo aprenda más rapido, aprenda correctamente y aprenda mejor.

    Hasta acá este compartir, hasta la próxima

    Saludos ágiles

    Jorge Abad.