domingo, mayo 24, 2020

Diapositivas - Seminario-Taller sobre Transformación Ágil


Hola a todos


A finales del año pasado tuve la oportunidad de brindar un Seminario-Taller sobre Transformación Ágil para una prestigiosa universidad de la ciudad de Medellín dirigido específicamente a una importante organización del sector energético.

Hoy quiero compartirles TODO el material que elaboré y trabajamos; sin restricciones.

Pero también he observado que por más bueno que sea el material, sin la explicación y heridas de guerra del experto, queda incompleto; por lo tanto, si estas interesad@ en ir más allá del material y participar en un Webinar que dictaré:
  • Cuándo: en el mes de Julio de 2020
  • Intensidad: 3 sábados
  • Duración: 9 horas (3 horas cada sesión)
  • Inversión: 90 dólares
diligencia el siguiente formato y te estaré contactando para los siguientes pasos (clic aquí


Saludos Ágiles


Jorge Abad.



Sobre Lean Thinking y Lean Manufacturing




"Lean Manufacturing es un proceso de cinco pasos:
definir el valor del cliente,
definir el flujo de valor,
hacerlo "fluir",
tirarlo (pull) desde el final (cliente), perseguir la excelencia
"
 










James Womack y Daniel Jones, Lean Thinking 


Valor, según Alistair Cockburn



"El cliente sabe lo que es valor" 
Alistair Cockburn (ver más)




    viernes, mayo 22, 2020

    Para No olvidar: Si duele hazlo más veces

    Este viejo adagio aplicable a muchos aspectos de la vida (el de porte es uno de ellos), es muy usuado en el mundo de Agile y de DevOps:

    if it hurts, do it more often(1)
    if its painful do it more often!(2)

    Que puede ser traducido como:
    si te duele, hazlo más seguido
    si te duele, hazlo más veces
    si es doloroso, ¡hazlo más a menudo!


    tomado de (1)


    Aplica en el proceso de desarrollo de software para:

    • pruebas (testing), de cualquier tipo
    • refactorización
    • merge del código al tronco
    • integración continua
    • despliegue continuo
    • y cualquier tarea o cosa que te moleste dentro del proceso de software

    Si lo haces mas frecuente, desaparecerá el dolor y serás mas fuerte.

    Incluso, en la ingería del caos lo interpreta Netflix y muchos, de la siguiente forma

    si te duelen los ataques de DDoS, atácate a ti mismo
    si te duele que se te caigan los servidores, túmbalos tu mismo
    si te duele que se te desborde la memoria, desbórdala tu mismo

    Todas estas medidas le dan resiliencia a tu sistema o arquitectura.

    Saludos Ágiles

    Jorge Abad.


    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1.  https://martinfowler.com/bliki/FrequencyReducesDifficulty.html
    2. https://vinayakjoglekar.wordpress.com/2013/08/28/if-its-painful-do-it-more-often/

    domingo, mayo 17, 2020

    Mindset Lean-Agile










    En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ági)l


    Tomado de (1)

    Hola a todos

    Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:
    • organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
    • discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
    • comparamos sus estrategias de gestión del cambio
    • confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 
    Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

    Factor
    Hacia el éxito
     Hacia el fracaso
    Compromiso del Top-Management
    ·       alto compromiso e involucramento
    ·         Delegación completa y desentendimiento
    Gestion el cambio organizacional
    ·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.
    ·       Fija y predictiva
    procesos y contratos
    ·       Modificados y en continua mejora hacia la agilidad
    ·       Sin modificar y orientados a la culpa en vez de la colaboración
    Respecto a los líderes y al mindset
    ·        Capacitados y empoderados para compartir el mindset
    ·        La difusión del mindset es de lagada en los consultores y algunos roles 
    Tolerancia al fracaso
    ·       Alta
    ·        Baja
    Comunicación
    ·       Fuerte y constante comunicación de la estrategia de cambio
    ·        Comunicación de la estrategia de cambio
    ·        Poca o nula comunicación
    Espacios de trabajo y herramientas de colaboración
    ·        Acondicionados para la colaboración (los espacios moldean el comportamiento)
    ·        Limitados y restringidos
    Silos organizacionales
    ·         Colaborando en torno al valor
    ·        Enfocados en optimizar la agilidad en su área
    Métricas de gestión
    ·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)
    ·        No sufren cambios
    Agilidad Técnica
    ·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica. 
    ·        Adoptada como la compra de herramientas
    Cultura
    ·        incentivar los nuevos comportamientos.
    ·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización
    ·        No intervenidos
    Respecto a los frameworks ágiles
    ·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores
    ·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
    Mindset
    ·        Constante difusión y adopción del mindset lean - agile (5)
    ·        No intervenido
    Respecto a los consultores (3)
    ·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento
    ·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
    Entre otros



    Yo me quedo con mi conclusión
    "Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

    Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

    Saludos Ágiles

    Jorge Abad.

    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
    2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
    3. Sugerencias de mi amigo Lucho Salazar
    4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
    5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

    martes, mayo 12, 2020

    Los Pedidos Efectivos y las Historias de Usuario

    Tomado de (1)

    Hola a todos

    Fred Kofman en su libro La Empresa Consciente(2)(3), comparte que el Liderazgo Consciente (el que logra grandes resultados) esta basado en estas siete importantes cualidades
    • Tienen responsabilidad incondicional
    • Integridad Esencial
    • Humildad Ontológica
    • Coordinación Impecable
    • Comunicación Auténtica
    • Negociación Constructiva
    • Competencia Emocional
    Y una forma que propone de lograr esa Coordinación Impecable es a través de los Pedidos Efectivos. El autor recomienda que los pedidos o solicitudes efectivas, deben tener:
    • Expresión clara
    • Solicitante
    • Receptor
    • Estándares Claros
    • Necesidad Subyacente
    • Aceptación Explícita
    Y una forma mencionada para hacer un pedido es:


    Para Lograr X

    te pido Y

    en un tiempo Z



    Ejemplo

    para el Informe Semestral
    te pido / necesito que hagas unas gráficas de ventas por sector
    para este viernes al mediodía


    La respuesta a este pedido puede ser:
    • Si
    • No
    • Necesito aclaración con
    • Te respondo en
    • Negociar algun elemento del pedido o la fecha

    Pero de tanto trabajar con historias de usuario en el mundo ágil y su popular (mas no obligatorio formato -clic aquí para mas detalle - ),



    Yo como  Usuario
    Quiero Una funcionalidad
    Para un beneficio de negocio

    Criterios de Aceptación
    1....
    2....
    3....

    he llevado la forma sugerida de hacer pedidos un poco más allá, incluyendo los criterios de aceptación de las historias de usuario dentro de mi forma de hacer y recibir pedidos, mejorando mi efectividad y la de mis compañeros de trabajo cuando interactuamos. Bajo esta modificación la forma recomendada de pedido queda de la siguiente manera:


    Para Lograr X

    te pido Y

    Con los siguientes criterios de aceptación
    1....
    2....
    3....

    Para el día Z, a tal hora





    en consecuencia el ejemplo sería :


    para el Informe Semestral
    te pido / necesito que hagas unas gráficas de ventas por sector
    con los siguientes criterios de aceptación
    -  gráficos de torta
    - máximo dos por hoja
    - y toma como base el que se presentó hace dos meses 
    para este viernes al mediodía

    Luego de esto, por lo general
    1. Pregunto si el pedido puede ser aceptado, modificado o rechazado.
    2. y si existe alguna duda, buscando afinamieno y confirmación de los criterios de aceptación

    Una Reflexión Adicional 

    Se observa que el formato sugerido de historias de usuario es una excelente forma de hacer pedidos y de lograr la coordinación impecable entre Negocio y TI, entre Product Owner y el Equipo de Desarrollo, mejorando la comunicación y la coordinación entre los mismos. Por lo tanto, (como tantas veces lo he compartido en este blog y lo ha hecho en su blog mi amigo Lucho Salazar) las historias de usuario no son especificaciones, son instrumentos para hacer pedidos y tener excelentes conversaciones.


    Hasta acá este compartir.

    Saludos Ágiles

    Jorge Abad



    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. Vector de Negocios creado por studiogstock - www.freepik.es
    2. La Empresa Consciente: Cómo construir valor a través de valores (Spanish Edition) (Clic aquí)
    3. Podcast del Libro -La Empresa Consciente.

    miércoles, mayo 06, 2020

    One on One - Uno a Uno - Una Excelente Práctica de Gestión y Alineación

    Ejemplo One on One - Uno a Uno (1)
    Hola a todos

    Existen muchas prácticas de Management que potencializan el trabajo de personas, equipos y organizaciones: Management 3.0 recoge algunas de estas prácticas, otras están por fuera de la propuesta de Jurgen Apelo, pero coinciden con alguna de sus vistas. En este post quiero compartirles una práctica: el Uno a Uno (o One on One en inglés) que dentro de las vistas de Management 3.0 cae tanto en Energizar Personas (Energize People) y de Alinear Restricciones (Align Constrains); el cual me ha sido bastante útil tanto con las personas que he podido liderar como con las empresas que he acompañado.

    Management 3.0 - ¿Qué es? • Jeronimo Palacios & Associates
    Seis vistas y  dos pilares de Management 3.0 


    ¿Qué es?

    Es una reunión corta, entre 30 a 45 minutos; de retroalimentación mutua, en la que líder y colaborador alinean expectativas y buscan mejorar mutuamente su colaboración y desempeño con mira a los objetivos organizacionales, grupales y personales.

    ¿Por qué?

    Aunque por lo general se realizan evaluaciones de desempeño anual con base en unos objetivos asignados previamente (a principios de año), y estos, en algunos casos son revisados trimestralmente con el líder, es común ver como el logro de estos objetivos terminan diluyendose en el día a día de las operaciones y los proyectos, pues son una tarea mas a cumplir que entre tanto compromiso terminan desaparenciendo.

    Otra razón de usar esta reunión es la continua afirmación tanto de líderes como de colaboradores
    - A mí nadie me había dicho eso, si hubiera sabido que estaban esperando eso de mí, no hubiese hecho "X" o "Y"
    (Nota importante:  muchas veces asumimos que por interactuar mucho con una persona o grupo de personas, mutuamente nos leemos el pensamiento y no necesitamos decirnos lo que consideramos obvio.)

    En esta reunión mensual (o tal vez en ciclos más cortos dependiendo del negocio) se logra una alineación hacia los objetivos organizacionales, de equipo y personales de una forma más natural y sin generar fricción.

    Posible Agenda

    Se basan en dos o tres preguntas:
    • [El líder pregunta al colaborador] 
      • ¿Qué necesitas para hacer mejor tu trabajo en la organización y que yo pueda ayudarte a conseguirlo?
    • [el líder dice algo así] 
      • Voy a compartirte qué necesito de ti para que tengas y tengamos o un mejor resultado y desempeño
    • [la otra pregunta opcional, el líder dice:] 
      • Revisemos como vas con tus objetivos trimestrales o anuales.

    Resueltas las preguntas, se generan dos salidas:
    • Compromisos a ser resueltos durante el siguiente mes del líder con el colaborador
    • Compromisos a ser resueltos durante el siguiente mes del colaborador con el líder
    Tareas que sugiero hagan parte de un kanban  o un listado de pendientes.
    Entradas y Salidas del One on One

    Para la siguiente sesión (o sea al próximo mes) y la agenda podría ser:
    • Compromisos pendientes de ambas partes, su estado, cuáles fueron resueltos, cuáles no, cuáles están avanzando.
    • Qué necesitas para hacer mejor tu trabajo en la organización
    • Qué necesito como tu líder para que generes mejores resultados
    • Cómo estas respecto al avance de tus objetivos trimestrales, semestrales o anuales.

    Duración y frecuencia

    El tiempo que dedicamos a menudo es de 30 a 45 min y recomiendo sean al menos cada mes o  periodos más cortos si el negocio así lo exige.

    ¿Qué se debe hacer?

    • generar un escenario de seguirdad sicológica
    • enfatizar que es una reunión de maximización de colaboración y privada
    • comenzar la reunión conectándose con la persona, tal vez preguntando por el proyecto actual o familia
    • hablar basados en hechos
    • terminar la sesión preguntando el resultado de la sesión ha sido satisfactorio o si desea cambiar algo
    • Considere más este espacio como Mentoring

    ¿Qué no se debe hacer?

    • no basarse en hechos
    • hacer juicios de valor sin tener datos que lo avalen
    • hacer generalizaciones
    • no ser cordial
    • generar un escenario tenso, agresivo o coercitivo, es decir, no propiciar seguridad psicológica
    • divulgar el resultado de la sesión o los acuerdos hechos
    • considerar esta conversación como un coaching, su foco es primordialmente laboral no a nivel personal.

    Beneficios

    • alineación de las personas y el equipo de trabajo
    • manejo de expectativas mutuas, tanto el colaborador como el líder saben que esperar el uno del otro.
    • mejora en la agilidad a nivel personal y empresarial si la práctica es usada organizacionalmente, pues se generan espacios de conversación, reflexión, colaboración, mejora continua y orientación al valor.

    Hasta acá este compartir, espero les sea tan útil como a mí.

    Bienvenidos tus comentarios

    Saludos ágiles

    Jorge Abad.


    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. Imagen tomada de Foto de Negocios creado por pressfoto - www.freepik.es
    2. Agradecimientos por sus correcciones y comentarios

    sábado, mayo 02, 2020

    Agilizando Equipos de Operaciones - El Daily




    Hola a todos


    Cuando he trabajando con equipos de soporte para volverlos ágiles, es decir, aumentar su colaboración, entrega de valor, reflexión y mejora continua; por lo general mantengo dos reuniones que han resultado de valor:
    • La sicronización diaria o daily y
    • La retrospectiva
    Hoy quiero compartirles algunas preguntas que nos han sido de valor:

    • ¿Qué fue lo más importante que hice ayer?
    • ¿Qué es lo más importante que voy a hacer hoy?
    • ¿Qué impedimentos hay o identifico?
    • ¿Cuál es mi porcentaje de ocupación el día de hoy?
    • Necesito ayuda con...
    • Ofrezco ayuda con...

    Las primeras dos preguntas están pensadas en que sean cortas, pues los equipos de soporte u operaciones hacen muchas tareas repetitivas, dar información sobre ellas no agrega mucho valor y aburre a todos, respecto al ofrecer y pedir ayuda ha dado como resultado colaboración entre las personas que están presentes y un mejor espíritu de equipo.

    Hasta acá este corto compartir.

    Saludos Ágiles
    Jorge Abad

    viernes, mayo 01, 2020

    Morir Debemos: Una invitación a Vivir un Liderazgo Pleno

    Tomado de (6)
    Hola a todos

    Hace unos meses terminé de leer un libro de Fred Kofman “La Revolución del Sentido: El poder del Liderazgo Trascendente” ( “The Meaning Revolution: The Power of Transcendent Leadership” en Inglés)(1), el libro navega por muchas experiencias de liderazgos y termina hablando del liderazgo trascendente [si estás interesado en leer el libro este es el momento en el que te sugiero que te detengas, pues este escrito contiene varios spoilers acerca de él, hecha la advertencia, ahora sí continuemos], y este se basa en el hecho inalterable de la muerte, y en cómo los líderes que han tenido experiencias cercanas a morir o estos que son conscientes de su existencia y la tienen presente:
    • toman mejores decisiones
    • se entregan más a las personas,
    • tienen un presente pleno (un aquí y ahora constante) y
    • generan una abundancia sobrecogedora en todo lo que se embarcan
    Pues saben que todo será efímero y la trascendencia es la entrega total de sí, a cada momento y en cada decisión. No se trata entonces de un gran heroísmo, sino de un heroísmo significativo cada segundo, cada instante entregado.

    En el célebre discurso a la promoción del 2005, Steve Jobs dijo:

    "Cuando tenía 17 años leí una cita que decía algo así: “si vives cada día como si fuera el último, es muy probable que algún día hagas lo correcto”, me impresionó mucho y desde entonces durante los últimos 33 años cada mañana me miro en el espejo y me pregunto: “Si hoy fuera el último día de mi vida, ¿querría hacer lo que estoy a punto de hacer hoy?”, y si la respuesta lleva siendo “No”, demasiados días seguidos, entonces sé que tengo que cambiar algo"(2)



    El haberme topado con esta definición me recordó un texto que había leído hace algunos años sobre los monjes cartujos(3), los monjes más austeros y con reglas más estrictas dentro de la iglesia católica, estos tienen voto de silencio, solo cuando se topan se saludan “Morir debemos” y el otro responde “ya lo sabemos” (4), cavan su propia tumba y cuando la completan, vuelven y la tapan y vuelven a empezar, tienen una vida de constante oración y de tensión hacia la muerte como fruto de una entrega plena hacia Dios, hacia los demás y hacia sí mismos.

    Pero no se trata de pasar la vida como unos monjes y vivir como unos ascetas, plantea Kofman en el capítulo “Muere antes de morir”(1), es darnos el regalo de saber que no tenemos la seguridad del mañana, solo tenemos la seguridad del presente, el mañana solo lo descubriremos cuando estemos ahí, antes no, por lo que cada acción y conversación es única, esto invita a que nuestras decisiones y acciones estén plenas de consciencia - lo que sea que estemos haciendo -, pues nunca más se repetirá ese instante. Por lo tanto, sin importar las circunstancias, cuando un miembro de tu organización, equipo o tu familia te pida ayuda o guía y se la puedas dar, lo hagas con consciencia plena, abandonando el piloto automático, la locura de las redes sociales, y el mirar constantemente la pantalla del celular. Es entonces una invitación a estar de cuerpo y mente presente en cada acto y cada reunión, en cada conversación, acción y decisión, dándose plenamente - no sabes si mañana o más tarde vas a estar- , no generando “deuda existencial” o pendientes consigo mismo y los demás.

    Como lo expresa Kofman:

    "La perspectiva de la muerte nos lleva a centrarnos en lo que realmente importa: verdad, felicidad, sentido, amor, gratitud, asombro, compasión, paz, plenitud y libertad"(1)
    Desde mi punto de vista, es lo mejor que puedes regalarte, verte mortal, sentirte mortal, saber que todos morirán, incluido tú, y que definitivamente no sabes cuando y ese regalo que te des te permitirá vivir como el dicho zen:

    "Muere antes de morir, para poder verdaderamente vivir"
    Es importante aclarar algo, no todo el que tiene la muerte presente es más pleno, es quienes ven en el regalo de la mortalidad una oportunidad para darse del todo.

    Mi intención con este ensayo no es que vayas por allí, saludando como los cartujos o que se convierta en un rito de tu equipo scrum, o equipo ágil, es más buscar que seas pleno, que busques la plenitud como líder (desde cualquier posición dentro de tu equipo u organización) ya sea como líder técnico, team member, scrum master, product owner, gerente, o cualquier otro rol y esa decisión en plenitud te dejará libre, hará que tu interacción sea sincera y abundante, que tu entrega a los demás, a tu familia, a tus amigos, a tus compañeros de trabajo, a la sociedad en general y a ti mismo sea completa y sin “deudas existenciales” que luego te atormenten.

    Saludos Ágiles

    Jorge Abad



    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. Kofman, Fred. La revolución del sentido. https://www.amazon.com/revoluci%C3%B3n-del-sentido-liderazgo-transcendente-ebook/dp/B07B9MVL4L
    2. [HD] Discurso De Steve Jobs En Stanford(Subtitulado En Español) Completo https://youtu.be/ZF0Omfp2rFM?t=540
    3. Cartuja de MIraflores - https://www.cartuja.org/
    4. Morir tenemos, ya lo sabemos” https://es.aleteia.org/2017/02/24/morir-tenemos-ya-lo-sabemos/
    5. Agradecimiento: Gracias Rose Restrepo por tus comentarios en la creación de este artículo.
    6. Foto de Personas creado por drobotdean - www.freepik.es

    lunes, abril 06, 2020

    La Guía de Scrum 2017 - En Mapa Mental

    Hola a todos

    La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

    Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

    Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

    Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.


    Mapa Mental - Capítulos
    Mapa Mental - Capítulos y Subcapítulos
    El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.


    Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

    De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.


    Descárgalo y Úsalo

    A continuación, pongo a su disposición varios formatos de descarga y visualización


    Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

    Disfruten las perlas (las que estan con asterisco (*) y en verde)

    Saludos ágiles

    Jorge Abad

    sábado, abril 04, 2020

    Conversaciones del Scrum Master según la Madurez del Equipo


    Hola a todos

    Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar  del lider (recomiendo ver (1)).

    El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe  

    "Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)

    Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:
    • Equipo en Formación - Conversación tipo: Comando y Control
      • "-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
    • Equipo en Conflicto - Conversación tipo: Persuación
      • "- ¿Les parece si revisan el log de transacciones?"
    • Equipo en Normalización - Conversación tipo: Participación
      • "-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
    • Equipo en Desempeño - Conversación tipo: Delegación
      • "-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?

    Respecto a la Caducidad del Scrum Master

    Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:
    ¿El Scrum Master caduca, o deja de ser necesario?
    Es como si se afirmara,
    como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico
    Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación-  las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.

    Para cerrar te comparto algo que me ha mostrado la experiencia,
    • En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua
    Saludos Ágiles

    Jorge Abad



    Notas, Referencias, Aclaraciones, Comentarios y Observaciones

    1. Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
    2. Guía oficial de Scrum- https://scrumguides.org/
    3. Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos - clic aquí-
    4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - clic aquí -.
    5. Lecturas recomendadas:
      • La caducidad del Scrum Master… y por extrapolación del coach ágil - clic aquí-.
      • El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo - clic aquí -.




    Sketch - Explicación de Scrum

    Hola a todos

    les comparto este boceto que realicé hace poco explicando el marco de Scrum





    les comparto este boceto que realicé hace poco explicando el marco de Scrum


    También puedes descargarlo en png de alta resolución del siguiente link - clic acá- .

    Saludos ágiles

    Jorge Abad

    lunes, marzo 30, 2020

    De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

    Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg


    At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.
    There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.
    The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.
    So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.
    An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.
    Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.





    Traducción



    En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

    Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

    Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

    Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

    Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

    Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.