Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Mejoramiento continuo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Mejoramiento continuo. Mostrar todas las entradas

martes, abril 27, 2021

Un instrumento para ayudarte a mejorar como Scrum Master

 


Un Scrum Master adecuado puede manejar dos o tres equipos a la vez. Si está contento con limitar su función a la organización de reuniones, el cumplimiento de los plazos y la respuesta a los impedimentos que las personas informan explícitamente puede arreglárselas con la atención de medio tiempo a esta función. Es probable que el equipo aún supere la línea de base, las expectativas previas a Scrum en su organización y probablemente no sucederá nada catastrófico.

Pero si puedes imaginarte un equipo que se lo pasa en grande logrando algo que nadie antes creía posible, dentro de una organización transformada, considera ser un Scrum Master extraordinario.

Un Scrum Master Extraordinario puede liderar un equipo a la vez.

Recomendamos un Scrum Master dedicado por equipo de aproximadamente ocho personas o menos al comenzar.

Si no has descubierto todo el trabajo que hay que hacer, sintonízate con tu Product Owner, tu equipo, las prácticas de ingeniería de tu equipo y la organización en el entorno de tu equipo. Si bien no existe una receta única para todos, esta lista describe cosas típicas que muchos Scrum Masters pasan por alto, sobre todo quienes apenas están iniciando a caminar por el sendero de la agilidad.

Esta lista de chequeo es una adaptación, más que una simple traducción, del trabajo de Michael James (mj4scrum@gmail.com). He incluido algunos aspectos que me parecieron relevantes a la luz de los últimos cambios en la guía de Scrum y de mi propia experiencia usando la lista.

Para usar el instrumento

Diligencia la lista de chequeo, puedes seguir algunas de las recomendaciones en la página de Documentación de la herramienta. Luego haz clic en el botón “Todo preparado. Muéstrame las gráficas” que encontrarás en la parte superior derecha de la hoja de “Datos de Entrada”.

Como con otros instrumentos de este tipo, para usar la lista de chequeo correctamente, diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y tendrás la oportunidad de debatirlas en equipo. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo puede ser el comienzo de un plan de mejoramiento! Eso sí, no pienses en juzgar tu desempeño como Scrum Master basado solo en esta lista de chequeo. Recuerda que lo importante es generar Valor, entregar lo que el negocio necesita más y mejorar el proceso continuamente.

Para limpiar los datos y volver a llenar la lista, simplemente haz clic en el botón “Limpiar Datos”.

Usa la herramienta y déjame saber en el foro de tus experiencias y de cómo podemos mejorarla.

Puedes descargar el instrumento aquí. 👇

sábado, noviembre 21, 2020

Un mejor Scrum o cómo mejorar tu práctica ágil para entregar resultados asombrosos

 

Estoy comprometido con mejorar la práctica de Scrum en las organizaciones y comunidades que acompaño y me he convencido de que todos los equipos, sin importar su estado de desarrollo, pueden optimizar su capacidad de inspeccionar y adaptarse para hacer mejor las cosas.

En mi continuo trasegar por las organizaciones que usan Scrum o intentan hacerlo me he encontrado con manifiestos desordenes en ese ámbito: desde el uso de un Scrum fundamentalista o Scrumdamentalismo, ese que raya en lo sectario, pasando por el-mismo-Scrum-para-todo-el-mundo, sin dejar atrás el Cascrumcada o “Scrum-cascada”, el Scrum mecánico, apenas para un apocalipsis zombi, o el extremista “Scrum-solo-para-mí” porque mi organización es única en el mundo, hasta el muy común en las empresas que apenas comienzan, el Scrum-sin-terminar, con el que todavía están extendiendo el Sprint, usan el tiempo de la retrospectiva para terminar de probar y no la hacen o simplemente no hay entrega de incremento probado y funcionando la mayoría de las veces.

Al enfrentar estas alteraciones he encontrado muy útil determinar no solo el nivel de desarrollo de los equipos sino el estado general de la organización en materia de pensamiento lean-ágil, estructura y cultura organizacional, identidad de los equipos, trabajo colaborativo y qué tanto está arraigado el mejoramiento continuo en la forma de hacer las cosas de la empresa, para así tratar de curar no solo los síntomas sino las causas raíz de estas disfunciones y empezar a entregar mejores resultados, cumpliendo así con la promesa ágil.

De estos asuntos trata esta presentación que hice en el Regional Scrum Gathering México 2020.

Puedes ver y descargar la presentación aquí.

miércoles, junio 03, 2020

Conociendo OKR

Imagen de 3D Animation Production Company en Pixabay
Imagen de 3D Animation Production Company en Pixabay

Los OKR son un protocolo de colaboración para establecer objetivos en empresas, equipos y personas.

OKR son las siglas de Objective and Key Results, u Objetivo y Resultados Clave.

Un Objetivo responde a Qué hay que lograr. Es concreto, trascendente, realiza un llamado a la acción e inspira.

Entre tanto, los Resultados Clave son un marcador de referencia y monitorizan cómo llegamos a ese objetivo. Son específicos y se establecen en un marco temporal. Los Resultados Clave son agresivos pero realistas. Por sobre todas las cosas, deben ser medibles y verificables.

Esta es una sesión introductoria a los OKR, explico de manera sencilla de qué se tratan los OKR, cómo lucen, con algunos ejemplos y qué hacer con ellos una vez se establecen. En este apartado, hago una propuesta simple pero adaptativa para el ciclo de vida de los OKR, desde su definición hasta el cierre del ciclo temporal para el cual fueron definidos.

Al final, enumero ocho aspectos importantes a tener en cuenta cuando quieres utilizar OKR.

Puedes ver y descargar la presentación aquí:



domingo, febrero 02, 2020

Soy un buen Scrum Master pero la empresa no está preparada


O “Soy un buen Scrum Master pero la empresa no es ágil”

Imagen de mohamed Hassan en Pixabay
Cuando eres Scrum Master, sea cual fuere tu nivel de experiencia o de madurez en el rol, nunca más se da el caso de “no soy yo, son ellos”:
  • Es que apenas están implementando Scrum, ellos (la organización, los equipos, las personas) no están maduros. | ¿Es posible “implementar” Scrum?
  • Es que todavía están (los equipos, las personas) atascados en los modos tradicionales de gestión y creen que soy el jefe o el gerente.
  • Es que ellos necesitan entender la nueva forma ágil de trabajar que quieren adoptar. | ¿”Adoptar”, luego no era “implementar” Scrum?
  • Es que están esperando que yo comande al equipo desde alguna suerte de puesto de control o cabina de mando.
  • Es que yo no tengo autoridad sobre el equipo. Soy solo un líder servicial a su servicio, como dice la guía de Scrum. Y el equipo es autogestionado. Funciona por sí solo. | ¿Un equipo “funciona”?
  • Y la lista de razones puede llegar a ser interminable.
Muchas organizaciones con una fuerte cultura de comando y control no te tomarán en serio como Scrum Master si no muestras habilidades para tomar el control de la situación. Las formas de hacer las cosas y mucho menos las formas de pensar actuales se cambian en pocos meses. Hacer que la empresa, los equipos y las personas maduren o siquiera estén conscientes de su nivel de agilidad es tu responsabilidad también.

Imagen de Gerd Altmann en Pixabay
No puedes simplemente ignorar la cultura actual de la organización y conducirte sobre los nuevos preceptos que te “dicta” la agilidad, el pensamiento Lean o prácticas como Scrum. “Es que ellos no entienden nada de liderazgo servicial ni de mejoramiento continuo”. No hay tal cosa como “ellos y nosotros” en el pensamiento ágil.

No te apresures. Da un paso a la vez y aprende de la reacción del entorno. Concéntrate primero en el equipo y ve escuchando al resto de la organización sin atribularte por la avalancha de ideas, solicitudes, advertencias, restricciones, desafíos, oposiciones y demás escenarios que vas a vivenciar. Para ello, viene bien hacerse acompañar de otros Scrum Masters, coaches ágiles o de cualesquiera que te proporcione ideas y que desee llevarlas a cabo contigo.

Estás allí para enseñarle a cada miembro del equipo a ser un líder, para empoderarlo y ayudarlo a aclarar su rol en este nuevo orden de las cosas, para remover algunos de los obstáculos en su camino pero más que a nada para instruirlo en cómo eliminarlos por sí mismo. Por sobre todas las cosas, no pierdas de vista que vienen de la cultura de ser recursos, así que piensa en ellos como personas y haz todo lo que esté a tu alcance para aumentar su felicidad.

Eres su entrenador pero deja que ellos también te entrenen. Aprende de la cultura y de los comportamientos imperantes. Luego, comienza a promover y a resaltar nuevos comportamientos “a lo ágil” y a desalentar, sin presión, las conductas actuales que no posibilitan el mejoramiento del equipo. Define un buen conjunto de valores que sean consistentes con el mensaje que quieres enviar y con el nuevo camino que les quieres mostrar, los valores de Scrum te ayudan, sí.

Asegura victorias tempranas. Una matriz de Esfuerzo versus Valor siempre viene bien en estos casos. Asegúrate de hacer con tu nuevo equipo lo que está en la zona de mayor Valor pero menor Esfuerzo y por ningún motivo mires la zona de mayor valor y menor esfuerzo.

Matriz de Esfuerzo versus Valor
Esfuerzo y Valor son relativos. Asume que todo lo que haces genera Valor y requiere de cierto esfuerzo. Pero incluye las variables que necesites para garantizar que algunas tareas, de tres a cinco de ellas, generan más valor que otras y requieren menos esfuerzo que otras. Y así, hasta completar la matriz. Distintos ejercicios te pueden llevar a lograr esto en pocos minutos, aun si tu equipo no es el mejor comunicándose.

Ve a lo seguro, sin dejar de experimentar. Después de todo, de eso se trata, de aprender mediante experimentos rápidos y baratos. Sigue la línea Shu-Ha-Ri como en esta infografía que preparé con mi gran amigo, compañero de batallas ágiles, Jorge Abad (@Jorge_Abad):

Scrum Master Shu-Ha-Ri
En esta etapa inicial, como Scrum Master, sigue la guía de Scrum con cierta precisión. Concéntrate en cómo organizar y llevar a cabo los eventos con el equipo, que se tengan los artefactos y que cada miembro del equipo Scrum se desempeñe como lo plantea la guía, sin preocuparte demasiado por la teoría subyacente; por ejemplo, en cómo planificar en un entorno empírico. Si hay múltiples variaciones sobre cómo hacer algo, solo decídete por la forma en que la guía lo establece o en como lo aprendiste. Tengo que decirlo, en este último caso, quizás estés equivocado, así que igual, hazte acompañar de alguien más experimentado, incluso de miembros de tu nuevo equipo. Ellos ahora son tu familia.

Más adelante pasarás a los demás estados. Recuerda que si ingresaste al equipo y a la organización, hay una alta probabilidad de que la madurez en materia de desempeño de todos quizás se reinicie “a lo Tuckman”, en donde los miembros del equipo tengan miedo (otra vez) de pedir ayuda unos a otros y a ti, no confiarán completamente en ti y te monitorean de cerca cuando estés trabajando en una tarea específica, con o sin ellos; muchos de ellos tendrán sus propias ideas sobre el proceso y las agendas personales serán rampantes; quizás te encuentres con roles específicos dentro del equipo, como líder técnico, facilitador, diseñador, documentador, incluso gerente; volverán las discusiones abstractas (si alguna vez se fueron) sobre distintos conceptos y temas y algunos miembros estarán impacientes con estos debates. Entre otros comportamientos típicos de la etapa de Formación de un equipo tradicional.

Incluso parecerá que estás logrando poco hacia la consecución de los objetivos del proyecto (sí, todavía se llamará “proyecto) y recibirás toda la carga de la culpa cuando te señalen a ti y a la nueva forma ágil de hacer las cosas que intentas poner de manifiesto en el ambiente. No te preocupes mucho por ello, aunque no estén completamente seguros de las metas y problemas del proyecto, algunos, quizás todos, estarán entusiasmados y orgullosos de estar en el equipo y a la expectativa de lo que pueda venir.

Las cosas así, quizás no puedas ir más allá del estado Shu, así te sientas con la fuerza, la experiencia y el coraje para empezar con el estado Ri. Lo leí de Melina Jajamovich (@latodoterreno) recientemente, “No hay seniority que valga cuando se trata de #agilidad | El mindset es un desafío de cada día”. Eres un eterno aprendiz, inculca eso en tu equipo, estás allí para acompañarlos a ser mejores.

Finalmente, empieza a pensar en el futuro del equipo. De hecho, esto se convertirá en lo más común y en lo mejor que podrás hacer en tu nuevo rol. Con el tiempo aprenderás que para un Scrum Master extraordinario no hay tal cosa como “no puedo hacer esto o aquello porque surgió algo urgente”. Debes adelantarte en el tiempo y visionar cómo llevarás al equipo al siguiente nivel de crecimiento, sin dejar de vivir en el presente para estar al frente de las tareas menos mundanas de protección y liderazgo del equipo.

Ya eres Scrum Master, no lo eches a perder solo porque el resto de la organización no te entiende. Asume tu responsabilidad, toma el control y muéstrales las cosas fantásticas que pueden lograr con agilidad. Es tiempo de cambiar.

jueves, enero 09, 2020

El último día del sprint

Imagen tomada de Pixabay
"Comenzar fuerte es bueno. Terminar fuerte es épico". [Robin Sharma]

Desde siempre he visto como los equipos de desarrollo de producto, especialmente los de desarrollo de software, emprenden los más titánicos proyectos con unas ganas inconmensurables, una fuerza interior, personal y grupal, que parece infinita y una pasión energizante que enciende los motores de la creación, el trabajo en equipo y los deseos de triunfar.

Nada muy distinto a lo que ocurre hoy en cada iteración de cualquier iniciativa o esfuerzo de desarrollo: el primer día los equipos planifican su propósito de vida para las siguientes jornadas y hasta son capaces de hacer un pronóstico de cómo alcanzarán la meta del sprint que comienza. Y diariamente acuden a la cita de la colaboración y la creación de valor con la mejor sonrisa y disposición.

O así es… ¡hasta que se acerca el fin de la iteración!

Un sprint es un bloque de tiempo breve en el que hay que mantener el foco y el esfuerzo regulado para terminarlo como lo empezamos. Con brío y pundonor. Pero eso no está ocurriendo con muchos equipos. En mis continuos ejercicios de acompañamiento y consultoría me sigo encontrando las historias de nunca acabar:
  • Es que no hicimos retrospectiva para terminar las historias de usuario
  • Programadores escribiendo programas minutos antes de la revisión con los interesados. ¿Y las pruebas?
  • Vamos a aplazar la revisión. Mañana hacemos la planificación del próximo sprint, luego la retrospectiva. Pasado mañana hacemos la revisión de este sprint que termina.
  • Solicitemos un aplazamiento del paso a producción para el próximo sprint.
  • Pidamos una extensión del sprint. Necesitamos dos o tres días más para terminar lo prometido.
  • Y la lista continúa.
Entre otras cosas, es a lo que se refieren Jeff y Ken cuando dicen que Scrum es “difícil de llegar a dominar”. Pero no se trata solo de Scrum. Es esa falta de disciplina que tenemos para hacer que las cosas terminen, ese apego a lo que es y no queremos dejar ir, inherente a todo ser humano. Es esa facilidad para conjugar el verbo empezar pero a la vez esa dificultad para conjugar la voz finalizar.

El último día del Sprint comienza el primer día del Sprint

Imagen tomada de Pixabay
Hagamos un plan hasta el penúltimo día del sprint, sea cual fuere su duración. Sí, con historias de usuario más pequeñas es posible. Y sí, todavía pueden ser entre 6 y 10 historias de usuario.

Recordemos en la planificación que la revisión y la retrospectiva requieren de preparación. No es algo que ocurre solo porque llegó la hora de hacerse o porque el marco de trabajo lo exige. Nunca veo esas tareas de preparación en el backlog del sprint. Y no, no son historias de usuario. Son actividades que bien pueden realizar el Scrum Master, pero también el Dueño de Producto o cualquier otro miembro del equipo, aunque preferiblemente uno de los dos primeros.

En cada reunión diaria, examinemos efectivamente cómo vamos hacia el cumplimiento de la meta del sprint y qué estamos haciendo específicamente para preparar esa gran fiesta que es la revisión del incremento con los interesados, no solo con el Dueño de Producto. Y, ni más faltaba, vayamos pensando qué clase de retrospectiva queremos hacer. Y sí, quince minutos es suficiente para ello. Durante la preparación de estos eventos finales también surgen impedimentos que hay que resolver con prontitud.

Recordemos, si no aseguramos la calidad del producto, no está terminado. Siempre pongamos de manifiesto que solo revisaremos lo que verdaderamente está terminado. Y no, casi terminado no es terminado.

El Scrum Master bien puede crear una campaña de expectativa hacia el exterior del equipo, dirigida a los interesados, sobre la próxima revisión, el siguiente gran hito. Y también hacia el interior del equipo: la siguiente gran oportunidad de inspección y adaptación, la retrospectiva. Sin que esto quiera decir que los demás eventos no son oportunidades de evaluación y ajuste, en el sentido de mejora continua.

Promovamos el descanso placentero y el sueño profundo, incluso la relajación y la meditación, la noche antes del día final del sprint. Descansemos, estemos con nuestras familias o amigos, salgamos a cenar, a disfrutar de una caminata a la luz de la luna con quien mejor nos sintamos o simplemente reposemos al ritmo que nuestro corazón dicte. Preparémonos así para la gestación de un día de buenas noticias con el resto del ecosistema organizacional.

Participemos de los preparativos, una revisión interna previa del producto no está demás. Lleguemos antes que todos los demás y recibamos a los invitados a la revisión, si los hay, con una gran sonrisa, con sendos mensajes de bienvenida, con una bebida. Y no, no es hora de licor.

[De la revisión propiamente dicha hemos hablado en variadas ocasiones así que no voy a entrar detalles sobre lo que debe o debería ocurrir durante la misma]*.

Aunque esto es del ámbito de la reunión misma, no dejemos de solicitar y recibir con la mente bien abierta toda la retroalimentación que nos brinden los asistentes. Ese será el motor que nos permita hacerlo mejor la siguiente vez. Y finalicemos con los agradecimientos respectivos, los aplausos, los abrazos, ¿por qué no? Después de todo, estamos todos en el desafío de deleitar a los consumidores finales de nuestro producto.

Finalmente, hagamos una pausa, tomemos un café y vamos a la retrospectiva. Esa cita íntima y necesaria en cada iteración. [Tampoco me extenderé mucho en este apartado]**

Al final del día, piensa que mañana seguirás mejorando. Es todo lo que necesitas para triunfar.


Apostilla:

No solo el último día, sino todos los días de tu vida, tiende la cama antes de salir. Si al final tienes un mal día o muchos malos días, siempre te recibirá una cama limpia y tendida. ¡Es la clave para cambiar el mundo!


-----
* Por ejemplo, además de lo que dice la guía de Scrum, mi gran amigo Jorge Abad ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:





Los invito a que los lean. Encontrarán consejos muy útiles cuando de preparar y realizar este evento del que les he hablado se trata.

** Por ejemplo, pueden leer mis artículos:




Aquí mismo en este Gazafatonario.


miércoles, abril 10, 2019

La caducidad del Scrum Master… y por extrapolación del coach ágil



El 10 de abril de 2019 un grupo de contactos de la comunidad Ágiles Colombia revivió este debate en el que yo no participaba quizás en los últimos cinco años. Hablamos de la “fecha de vencimiento del Scrum Master”, de la madurez del equipo, de si el Scrum Master agrega valor o no. Varios y distintos puntos de vista, una discusión con respeto y apertura, tengo que decirlo, lo que muestra que, de alguna manera, hemos madurado y que estamos aprendiendo a soportarnos, que hay apertura, y que ya no somos tan políticamente correctos. ¡Eso es bueno, creo!

Esta es mi opinión, ni más faltaba, soportada en mi experiencia:

Quiero empezar por dejarlos con la siguiente reflexión: llegar a considerar esto (que en algún momento no se requiere el Scrum Master) quiere decir que el desarrollo del equipo tiene un “techo”, es decir, un nivel máximo (de madurez). Algunos dirán que el equipo (de producto) y el Dueño de Producto pueden seguir evolucionando por sí solos; quizás sea posible, ¿pero hasta qué nivel? El equipo tiene una tarea principal y es precisamente el producto, la entrega de valor.

Al considerar este escenario, estamos diciendo que el así llamado mejoramiento continuo tiene un límite. Que en algún momento del tiempo no necesitaremos mejorar más, que llegamos a un nivel de madurez “non plus ultra”, que somos los más más, los que todo lo pueden y no hay nada ni nadie más allá.

Yo estoy hablando del rol, pero no veo al equipo “distribuyéndose” este rol de Scrum Master, en principio “as per Scrum guide”, entre sus miembros. El equipo tiene sus propios retos, inherentes a su papel, hablo de todo eso en lo que confluye la excelencia técnica y, sobre todo, en la entrega continua de producto con valor.

Quizás son dos cosas muy distintas, pero no veo un equipo de fútbol, aun uno de Rugby, o a una orquesta sinfónica, todos conformados por grandes estrellas en sus respectivos campos, jugando o interpretando sin el entrenador adecuado.

Lo escuché por primera vez de Ángel Medinilla: el Scrum Master vive en el futuro del equipo. Le compré la idea. Bueno, ¡en realidad, la tomé prestada! La promuevo en mis equipos y en las organizaciones con la que colaboro habitualmente. Me ha dado buenos resultados. Vivir en el futuro quiere decir que está pensando en cómo llevar a su equipo al siguiente nivel y en cómo preparar a la organización para ese “nuevo” y mejorado equipo. Mejoramiento continuo.

También sabemos que cuando una persona entra o sale del equipo, el resultado no es el mismo equipo, se trata de un nuevo equipo. Aun para equipos de alto desempeño, equipos maduros, equipos en el nivel desempeño del modelo Tuckman, aun para esta clase de equipos, el esfuerzo de “volver” a integrarse los hará regresar de nuevo a la etapa de formación. Y este impulso seguramente seguirá requiriendo de un gran Scrum Master cuyo foco sea llevar nuevamente al equipo a su estado de madurez más alto conseguido.

Voy a ir más allá. Hemos establecido ampliamente que el Scrum Master, al menos uno extraordinario, juega en distintas posiciones:

1.    Coach
2.    Maestro
3.    Líder servicial
4.    Gestor
5.    Agente de cambio
6.    Mentor
7.    Facilitador

Entre otras no menos importantes. Distribuir cada una de estas funciones en el equipo no es algo de poca monta y puede llegar a ser algo perturbador para los miembros de ese equipo. ¿Una por cada miembro del equipo? ¿Y qué pasa si es un equipo de menos de siete personas?

¿Y las tareas mundanas?

Veamos otro contexto:

En algún momento, abstraerse de las complejidades propias de un producto y dedicarse a preparar una retrospectiva puede ser un aliciente, una “pausa activa” para uno o dos miembros del equipo de producto. Pero no veo a largo plazo los beneficios de implementar tal práctica. Necesitamos a los miembros del equipo concentrando todo su esfuerzo en la generación de valor de manera frecuente para la organización.

Sí, ya sé, algunos van a decir que estoy tratando a la retrospectiva como algo frívolo, “terrenal”. ¿Y no es de eso de lo que estamos hablando cuando hablamos de jubilar al Scrum Master? Mirémoslo desde otro ángulo: a la luz de un equipo maduro, que seguramente estará enfrentando problemas de alta complejidad y de mucha incertidumbre, preparar y realizar un evento de Planificación o una Retrospectiva parecerá algo profano y hasta superfluo.

Pero no se equivoquen: no, los eventos Scrum no son para nada momentos vanos, ni siquiera para un equipo realmente “avanzado”. Mucho menos lo son la gran cantidad de otros eventos, sesiones, ceremonias, reuniones, actividades y prácticas que emergen alrededor del desarrollo de productos con Scrum y, por extensión, con pensamiento ágil o lean.

Sobre VUCA y Cynefin

Ah, y ya que toco este no menos peliagudo asunto de la complejidad y la incertidumbre, ¿qué hay acerca del mundo VUCA que habitamos hoy? ¿Qué hay acerca del caos que nos consume? Es en estos ambientes de altísima volatilidad y ambigüedad en los que se necesitan soluciones expeditas, prácticas y categóricas. Un equipo, aun uno con un alto grado de madurez, quizás no sea capaz de reaccionar por sí solo a esos escenarios que emergen de repente y mucho menos en iteraciones cortas de una o dos semanas. Es allí donde un Scrum Master, de esos que he dado en llamar “Extraordinarios” es útil. Incluso si el Scrum Master está parcialmente en el equipo, como plantean algunos, sus respuestas pueden llegar tardías o simplemente no llegar.

Y el Coach Ágil

Un Scrum Master extraordinario sabe que necesita un mentor, alguien que lo acompañe en el camino mientras se forma, mientras madura. Tanto uno como el otro no deben entorpecer las labores del equipo, tampoco deben generar dependencia. En ese sentido deben ser “invisibles”, pero esto no quiere decir que no sean indispensables para ayudar en la mejora de las personas del equipo.

Mi Conclusión

En mi opinión, sí es necesario el Scrum Master. La persona. ¡Y el rol que juega! Quizás sea posible un modelo donde no esté. Ni el coach ágil. Pero en mi experiencia, la evolución de este equipo se va a detener o se va a hacer excesivamente lenta.

¿Qué piensas de todo esto? Déjamelo saber en el foro.

Sobre el Scrum Master Extraordinario

Los invito a leer algunas de mis contribuciones al respecto:


domingo, abril 01, 2018

Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

4 estacions cicles arbre, por Espai Satvas

(Tiempo aproximado de lectura: 7 minutos, 15 segundos)
“Uno de los principales problemas con las Transformaciones Ágiles es que nosotros, las personas que hacemos estas transformaciones, no estamos realmente cambiando nuestros valores, nuestros corazones. Queremos practicar la Agilidad sin cambiar nosotros mismos. Eso nos impide hacer y liderar la Agilidad”. (Junio 7 de 2017)
Mike Beedle. En su honor…

El marco de trabajo Scrum y mucho menos el pensamiento Ágil o la Agilidad se venden en cajas o se prescriben como recetas en clínicas de coaching.
De allá venimos, de las propuestas de marcos metodológicos “mágicos” que, según sus promotores, funcionaban en cualquier lugar del universo, aun en una galaxia muy muy lejana, sin importar los escenarios locales, la idiosincrasia, la cultura organizacional o las personas involucradas.
Hoy por hoy las áreas de TI y las organizaciones en general saben que necesitan un cambio en su forma de trabajo y han escuchado poco o mucho del enfoque Ágil, este se ha vuelto un objeto del deseo, uno oscuro, pero no están dispuestas a generar el entorno que se requiere para cambiar. ¡Quieren empezar a jugar Rugby pero con las reglas del Fútbol!
El pensamiento Ágil es como un caleidoscopio para las personas, los equipos y las organizaciones del tercer milenio. Debido a la enorme cantidad de factores y al cambio continuado de contexto, dadas la volatilidad y la incertidumbre inherentes a las empresas actuales, una leve vibración del caleidoscopio genera una forma muy diferente a la anterior.
En cualquier caso, una imagen (modelo) apropiada para una organización puede no ser la correcta para otra, aun entre áreas de la misma empresa la estrategia y las tácticas pueden llegar a ser muy distintas. Cuánta agilidad necesita cada quien es una cuestión muy subjetiva que debe abordarse a nivel local.
La agilidad es la capacidad de evolución de las personas y de las compañías. Aquellas y estas deben estar conscientes de que, al igual que la evolución, el viaje de Agilidad no tiene un destino final, es un desplazamiento continuo, un éxodo perenne si así lo queremos ver.
Lo advertía hace siglos Nicolás Maquiavelo: nada más difícil de emprender ni más peligroso de conducir que tomar la iniciativa en la introducción de un nuevo orden de cosas, porque la innovación tropieza con la hostilidad de todos aquellos a quienes les sonrió la situación anterior y solo encuentra tibios defensores en quienes esperan beneficios de la nueva.
Es muy difícil que una persona cambie sus hábitos y mucho más complejo puede resultar si quiere cambiar su forma de pensar. Ni hablar entonces de lo caótico que puede resultar hacer esto para todo un equipo, por pequeño que este sea, y más aún para una organización entera.

Además, nuestro cerebro es muy bueno esgrimiendo argumentos de por qué no salir de su zona cómoda. El “siempre lo hemos hecho así” y otras razones corporativas para no cambiar.
Las organizaciones del siglo XXI quieren mejorar pero no quieren cambiar. Se mantienen en un estado de inmovilidad colmado de voluntades de cambio fingidas. A lo largo de mis años como agente de cambio me he encontrado con entidades cuyo propósito de renovación es simplemente un disfraz con el que ocultan su ánimo de permanecer estáticas en el tiempo. Lo que no saben estas compañías es que de no cambiar se exponen a su desaparición o al trágico rezago del que difícilmente podrán volver.
Para ninguno de nosotros es desconocido que la visión de la mayoría de las empresas es obsoleta en este siglo que apenas comienza. Las evidencias abundan: Blackberry, Xerox, Kodak, Nokia y Blockbuster, solo para mencionar algunas cercanas a nuestro sector. En general, el 88% de las compañías Fortune 500 de 1955 habían desaparecido de la lista o de la faz de la Tierra en 2014 (ver referencia). Lo que no están dispuestas a hacer estas corporaciones o no quieren hacer o simplemente no saben cómo, es cambiar su forma actual de trabajar, sus procesos y procedimientos. Por ejemplo, quieren medir el progreso de los cambios como miden sus proyectos tradicionales.
En general, este tipo de empresas no está interesado en sacrificar su “modus vivendi”. Las personas que pone a conducir la iniciativa de cambio no están allí exclusivamente para ello. Lo que ocurre casi siempre es que les asignan trabajo adicional al que ya realizan. Son personas que inician su nueva labor desmotivadas y cansadas, muchas veces sin entender del todo lo que está por suceder.
Lo que sí sabemos los agentes de cambio es que al iniciar una transformación no podemos ir contra ese “statu quo” de manera frontal o “guerrerista” como anuncian algunos, tratando de cambiar todo de una buena vez. Esto es así porque en un entorno complejo, altamente volátil y vulnerable, incierto y ambiguo, como el que rodea a las empresas hoy, no sabremos qué acciones conducirán al resultado deseado.
Primero tenemos que conocer la cultura organizacional, hacernos a una percepción de las personas, los escenarios, los equipos, su forma de trabajo vigente y una vez adentro iniciar la transformación de manera natural u orgánica, en pequeños pasos, sin violentar las estructuras o procedimientos actuales pero con paso firme y con determinación.
Curva de adopción/innovación de Rogers
Esta será útil para dispersar aquellas conductas que, inevitablemente, seguirán exhibiéndose hostiles incluso cuando el cambio se encuentre en un estado avanzado, esos comportamientos de los grupos de la mayoría tardía y de los rezagados identificados por nuestro amigo Everett Rogers en su muy referenciada curva de adopción/innovación.
Otra cosa que ocurre es que nuestras organizaciones están sobrecargadas de gestión y de gerentes en todos los niveles y siguen sin desarrollar su capacidad de ejercitar el liderazgo de sus miembros. Recordemos que los líderes de hoy son todas las personas que puedan transformar su contexto o generar nuevos y mejores espacios para los demás y cuya confianza, eficiencia y alcance combinados sirvan de base para la cultura de la organización.
Y bueno, mientras preparo más apuntes, cuéntanos amigo lector, sobre tus vicisitudes y rendimientos durante el proceso de cambio en el que estás comprometido. Puedes dejar tus propios apuntes en el foro, más abajo.
Coletilla de los apuntes:
Cada quien debe encontrar su significado de Valor y de Temprano y de Frecuente, para aquello de “entrega temprana y frecuente de valor”.
Lucho Salazar, Ciudad de los Reyes, marzo 30 de 2018
Referencias
http://www.aei.org/publication/fortune-500-firms-in-1955-vs-2014-89-are-gone-and-were-all-better-off-because-of-that-dynamic-creative-destruction/
*************************************************************
Parte 2 de los apuntes:
La segunda parte de esta serie de apuntes está en:
http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

Puedes descargar la presentación complementaria del siguiente enlace:

miércoles, enero 17, 2018

Revisión a la Guía de Nexus 2018


Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.
Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.
Estos son los cambios más significativos:
1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.
2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.
3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.
4.    Claridad alrededor del rol del Equipo de Integración Nexus:
a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.
b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.
c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.
5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.
a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.
b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.
c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.
6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.
a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.
b.    Se eliminó de la Tabla de Contenido.
7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.
a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.
b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.
8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.
9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.
a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.
10. El Incremento Integrado representa el estado actual del trabajo integrado.
11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.
12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.
13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.
14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.
Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.
La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.
Para conocer más de Nexus, pueden leer mi artículo:
En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.