¿Qué dinámica se puede utilizar para trabajar la definición de hecho (DoD) en remoto?

DoD Kards de Thomas Wallet y Camilo Velásquez

Imaginemos que nuestro ámbito es el desarrollo de software y que tenemos un equipo disperso recién formado y necesitemos ayudarles a definir su lista de definición de hecho (DoD). O puede que tengamos un equipo ya formado que necesite refinar su DoD, y en ambos casos necesitamos hacerlo de forma remota.

Thomas Wallet y Camilo Velásquez han ideado un taller basado en un juego de cartas, las DoD Kards, que está disponible en el área de recursos de Kleer, y que nos pueden ayudar:

"Es un juego de cartas cuyo objetivo es reflexionar y consensuar entre todos los miembros de un equipo cuáles son los criterios a incluir en su definición de terminado (DoD por su sigla en inglés: Definition of Done)."

El juego propone cartas con criterios de DoD en los ámbitos de revisión, calidad, entornos y difusión, tanto predefinidas como personalizables. El taller consiste en distribuir esas cartas de criterios de DoD de forma colaborativa en tres columnas (mi recomendación es al menos una carta de cada ámbito):

• SÍ, para los criterios que queremos incluir a nuestra DoD a partir de ahora.
• AÚN NO, para los criterios que no podemos incluir por el momento pero que queremos reconsiderar en el futuro.
• NO, para los criterios que no aplican, no entendemos, no queremos incluir en nuestra DoD o para los cuales no logramos ponernos de acuerdo.

La actividad y las conversaciones que se producen durante el taller, entre los miembros del equipo de desarrollo y con el Propietario del Producto, crean alineamiento y una definición única de lo que significa "hecho".

En la cabecera del tablero están las instrucciones del juego, que básicamente sugiere que los asistentes muevan de forma rotativa carta a carta a la columna que creen que debe de ir. Antes de rotar a la siguiente persona se comprueba si hay alguien disconforme, en ese caso se le da oportunidad al equipo a conversar alrededor del criterio y a llegar un consenso sobre a qué columna debe de ir la carta. Al finalizar, la columna SÍ contendrá la nueva definición de hecho (DoD) del equipo.

Tablero inicial, como viene por defecto, y después de realizar el taller

Captura del taller de DoD de Scrum Manager

Quisimos averiguar como funcionaría el taller como actividad en un curso de Scrum remoto, así que lo probamos en un curso de historias de usuario de Scrum Manager.

El feedback fue muy esclarecedor: para un curso hay que contextualizar primero el equipo, exponer su madurez en Agilidad y la de la empresa en la que están. Probablemente la empresa tenga políticas que haya que tener en cuenta en la DoD. Por otro lado hay que contextualizar la infraestructura que les rodea. Por ejemplo, no es lo mismo una DoD para un equipo que tenga acceso a pruebas automatizadas que uno que realiza las pruebas de forma manual. Sin contextualizar ocurriría que iríamos a máximos ágiles y todas las cartas se considerarían como SÍ, como criterios DoD.

Mis agradecimientos a Thomas Wallet, Camilo Velásquez y a Kleer por poner a disposición de la comunidad ágil recursos tan valiosos como las DoD Kards. Y mis agradecimientos a los asistentes al curso de historias de usuario de noviembre de 2020 que direon un feedback muy valioso.

¿Puede tener un Propietario del Producto diferentes posturas?

En este post quiero compartir una descripción general de las posturas malentendidas y preferidas del Propietario del Producto que la Scrum.org incluye en los aprendizajes de Professional Product Owner avanzado. El post se basa en el artículo "Product Owner Stances" de Robbin Schuurman que invito a leer ya que profundiza en cada una de las posturas.

Una de las responsabilidades del rol del Propietario del Producto es, inspirar y motivar a través de la visión de producto, al equipo de desarrollo y a los interesados, potenciando así el propósito del producto de manera que hace entender las necesidades de los clientes. A su vez busca crear las mejores experiencias de usuario en los clientes, buscando las mejores soluciones posibles que sean viables a las necesidades de estos. Para todo ello puede adoptar diferentes posturas que le permiten interactuar en diversos escenarios, con diferentes tipos de interesados y circunstancias, y así maximizar la entrega de valor.

Las posturas se dividen en dos grupos:

1. Las posturas malentendidas: resume 6 patrones que son usuales en muchas organizaciones que han empezado a trabajar con Scrum y que han llevado a posturas no ágiles. Recordemos que una transformación ágil es un camino de aprendizaje continuo en le que las personas que realizan el trabajo tienen permiso de cometer errores, lo que se considera positivo ya que nos permite aprender y mejorar.
2. Las posturas preferidas: estas son 6 posturas constructivas, positivas y valiosas que han sido adoptadas por Propietarios del Producto exitosos.

Las posturas de un Propietario del Producto de "Product Owner Stances" de Robbin Schuurman

LAS POSTURAS MALENTENDIDAS

The Story Writer (el escritor de historias)

El escritor de historias, o escriba, transcribe ideas e información en nombre de otros; a veces copiando de otro documento, a veces de instrucciones orales de personas que desconocen el formato de historias de usuario, a veces transcribiendo una grabación o notas personales. Se centra en especificar historias de gran nivel de detalle, su pila de producto suele estar perfectamente organizada. las historias en la parte superior son realmente pequeñas, claras, muy especificadas, con diseños detallados y con estimaciones precisas.

Su pila de producto está pensada para evitar que el equipo de desarrollo tenga dudas... y tenga que pensar. Este enfoque tradicional fomenta equipos que quieran historias detalladas para que no se les pueda culpar por construir lo incorrecto, y refuerza la creencia que el Propietario del Producto maximiza el rendimiento del equipo evitando que piensen en otras cosas que no sea codificar. El desperdicio que se produce al utilizar este enfoque es no usar el cerebro de los miembros del equipo para tomar buenas decisiones; sus decisiones están mermadas por no entender la visión más amplia y las necesidades del cliente, y estar inmersos en un entorno que no fomente la proactividad y el pensamiento.

También conocido como scribe (escriba), secretary (secretario), business analyst (analista de negocio), technical writer (redactor técnico) y note taker (tomador de notas).

The Project Manager (el jefe de proyecto)

La postura del jefe de proyecto es la que se centra en el progreso del día a día del equipo de desarrollo: asiste a todas las reuniones diarias y mengua la autonomía del equipo convirtiendo la reunión en una reunión de seguimiento preguntando a los miembros "qué han hecho", "qué van a hacer" y "si hay algo que les bloquee". Suele medir el éxito del equipo en forma de más velocidad, a poner el foco en los puntos de historia hechos, burn-down charts y la utilización de recursos, pretendiendo maximizar resultados, lo que no es lo mismo que ofrecer más valor al cliente, a los usuarios y a la organización.

También conocido como velocity maximizer (maximizador de velocidad), resource utilization maximizer (maximizador de utilización de recursos), wishlist administrator (administrador de la lista de deseos), sidekick to management (compañero de administración) y progress reporter (reportero de progreso).

The Subject Matter Expert (el experto en la materia)

El experto en la materia, o SME, es un experto en explicarle al equipo cómo funcionan las cosas. El Propietario del Producto que adopta esta postura es una bendición y a la vez una maldición, ya que por un lado aporta conocimiento de dominio relevante al equipo lo que les permite tomar mejores decisiones y crear mejores planes para lograr los objetivos del sprint, y por otro lado mengua la autoorganización del equipo limitando el aprendizaje y la obtención de conocimiento de negocio, usuarios, cliente y producto, porque les es muy fácil preguntar al experto en la materia.

También conocido como senior user (usuario senior), key user (usuario clave), process manager (administrador de procesos), domain expert (experto de dominio) y business expert (experto en negocio).

The Clerk (el sirviente)

El liderazgo al servicio es importante para las organizaciones ágiles, sin embargo el liderazgo al servicio no trata de ser un sirviente. Un Propietario del Producto sirviente trata de complacer a los interesados y nunca les dice "no", simplemente toma pedidos y actúa como mediador con el equipo de desarrollo. Se trata de un Propietario del Producto que no tiene ningún poder y que no está enfocado en lograr la visión del producto, ni en la elaboración de metas y objetivos claros. Su pila de producto suele ser larga y desordenada desde el punto de vista de valor de negocio, y no suele interactuar con el cliente y los interesados externos.

También conocido como admin (administrador), secretary (secretario), waiter (camarero), yes man (hombre del si) y order taker (tomador de pedidos).

The Gatekeeper (el portero)

El Propietario del Producto portero es aquel que actúa de único punto de contacto entre el equipo y el mundo exterior, bloquea todas las conexiones entre el equipo de desarrollo y los interesados, toda comunicación debe de pasar por él. Piensa que con esta postura ayuda al equipo a mantenerse enfocado, pero su postura le convierte en un cuello de botella, y por tanto suele tener poco tiempo para el equipo. Su enfoque de control hace que quiera que toda idea, deseo y demanda sea en forma de historia de usuario, y que quiera aprobar cada uno de esos requisitos para que al equipo los construya solo enfocado en codificar. El resultado es un bloqueo total del feedback de interesados a equipo, incluso suele haber una merma significativa del feedback en la revisión de sprint.

También conocido como protector (protector), guard (guardia), shield (escudo), gateway (puerta de enlace) y single point of contact (punto de contacto único).

The Manager (el gerente)

El Propietario del Producto gerente se preocupa por el bienestar de su equipo, le encanta ver personas felices, comprometidas y motivadas que se están desarrollando, aprendiendo nuevas habilidades, obteniendo nuevos conocimientos y cometiendo errores. Es el responsable de la gestión del desempeño y la evaluación del equipo. Todo esto está bien, el problema es que es una postura que no está enfocada en el desarrollo de producto y maximizar el valor del mismo.

También conocido team boss (jefe de equipo), team lead (líder de equipo), technical lead (líder técnico), Product Owner & Scrum Master y HR-responsible person (responsable de RRHH).

LAS POSTURAS PREFERIDAS

The Visionary (el visionario)

El Propietarios del Producto visionario comunica e inspira claramente la visión del producto, la estrategia, las metas y los objetivos comerciales a todas las partes relevantes, su enfoque es en lo que puede ser en lugar de lo que es. Adoptar la postura visionaria de vez en cuando es clave para maximizar el valor del producto y una forma de ver el valor como contribución potencial para lograr la visión.

Este Propietarios del Producto se compromete personalmente con la visión. Es como si la visión estuviera dentro de el. Tiene gran imaginación y capacidad de visualización, tiene voluntad de compartir la visión con el mundo porque sabe que no puede llegar al destino solo. Necesita a otros para este viaje y, por lo tanto comunica su visión y sueños a otros para atraer a las personas adecuadas. Con una visión sólida sabe que habrá desafíos en el camino, nunca se rinde y sabe que los fracasos son parte del proceso de aprendizaje.

También conocido como inspirator (inspirador), challenger of the status quo (retador del status quo), the dreamer (el soñador) e imaginative product owner (Propietario del Producto imaginativo).

The Collaborator (el colaborador)

Un Propietario del Producto colaborador interactúa y trabajar estrechamente con los interesados y el equipo de desarrollo, apoyando a las personas en su propio proceso de descubrimiento, ya sea para definir objetivos, aclarar historias o analizar las necesidades del cliente.

Es abierto y transparente, comparte abiertamente información que pueda ser o no ser relevante para interesados y equipo, generando así gran confianza. Trabaja en equipo y entiende qué significa colaborar con personas, habla de "todos" nosotros y se pregunta qué está contribuyendo a la relación con los demás y al bien común. Escucha para comprender, no para responder, y sabe mantenerse fiel a su yo auténtico. También entiende que, si como Propietario del Producto desea maximizar el valor de su producto, ha de ser amable con aquellos que construyen el producto y con aquellos que lo consumen.

También conocido como team player (jugador de equipo) y team worker (trabajador de equipo).

The Customer Representative (el representante del cliente)

El Propietario del Producto representante del cliente es la persona a la que recurren aquellos que deseen comprender qué buscan los clientes y los usuarios en el producto, cuáles son sus desafíos, y qué dolores y ganancias tienen. Al adoptar la postura de representante del cliente es capaz de explicar cómo nuestro trabajo impacta a los clientes. y poder expresar lo que los clientes valoran y cómo calificar y cuantificar ese valor.

Tiene una comprensión clara de las personas del cliente y del usuario, y comprende muy bien que escuchar al cliente es mucho más importante que hablar con el. Tiene reuniones periódicas con clientes y usuarios reales para identificar las necesidades de éstos observando y haciendo preguntas poderosas. La creación de un gran producto, que a los clientes les encante, no se logra haciendo preguntas sencillas, sino con preguntas poderosas que tratan de comprender realmente a los clientes y a los usuarios.

También conocido como customer advocate (defensor del cliente), voice of the customer (voz del cliente), user representative (representante del usuario), user advocate (defensor del usuario) y voice of the user (voz del usuario).

The Decision Maker (tomador de decisiones)

El Propietario del Producto tomador de decisiones ayuda a los interesados y al equipo a reducir el time-to-market reduciendo el tiempo de toma de decisiones que ocurren a diario; algunas las delega al equipo o interesados, otras las toma él mismo. Decide qué historias añadir a la pila de producto, como priorizarla y qué elementos eliminar, toma decisiones sobre la visión y estrategia del producto y cuándo lanzar el incremento de producto al mercado. Al contrario del escritor de historias, evalúa varias opciones y toma una decisión racional que ayude al equipo, a los interesados y al producto en general. Favorece las decisiones en las que todos estén de acuerdo, pero puede tomar las decisiones difíciles cuando sea necesario.

Otro rasgo clave de un Propietario del Producto tomador de decisiones es el uso de datos; conoce el valor de mercado de su producto, el tamaño del mercado que podría comprar el producto, y el de la competencia, ingresos, costos, crecimiento, cadena de valor, ..., los conoce y puede respaldarlos con números.

The Experimenter (el experimentador)

Al adoptar la postura de un experimentador este Propietario del Producto enuncia hipótesis y suposiciones, en lugar de historias de usuario y requisitos. Ven el trabajo que hace el equipo como experimentos para descubrir valor nuevo y oculto, en lugar de ejecutar y entregar paquetes de trabajo "inamovibles". El experimentador comprende que hay más cosas desconocidas que conocidas y, por tanto, siente la necesidad de probar cosas nuevas, explorar, innovar y experimentar. Es optimista sobre el futuro y siente el impulso de hacer que el mañana sea mejor que el hoy. No le teme a los fracasos porque sabe que estos son parte del proceso de aprendizaje.

The Influencer (el influenciador)

El Propietario del Producto que es un gran influenciador logra que las cosas se hagan sin ejercer una autoridad formal sobre el equipo. Los grandes influenciadores actúan y hablan de tal manera que apenas se les nota cuando están presentes, pero se les echa mucho de menos cuando se van. Ayuda a los interesados y al equipo a alinearse en torno a la visión, estrategia, metas y objetivos del producto. Utiliza habilidades efectivas de comunicación, negociación e influencia para lograr que las personas se unan a la causa. Es honesto, siempre abierto y transparente, generando credibilidad y confianza, que son la base para evocar la confianza y el respeto de quienes le rodean. Es flexible y excelente oyente para comprender los diferentes intereses de la organización.

¿Cómo preparar una PI Planning remota?

Hoja de ruta hacia la PI Planning
cortesía de Pixabay

Hemos hecho el taller de identificación del flujo de valor operativo (Operational Value Stream) y el del tren (ART)... estamos listos para preparar la PI Planning remota que se nos avecina, y lo primero que ya hemos hecho es marcar la fecha del evento. En este post quiero mostrar una guía de cuando hemos de prestar atención a qué tareas para crear una hoja de ruta que nos lleve a maximizar el éxito de la PI Planning.

Al menos 2 meses antes:

• Identificar y preparar al RTE (Release Train Engineer)
• Establecer un equipo para la preparación (RTE. Scrum Masters, SPC, sistemas para herramientas digitales e infraestructura remota, y si la hubiera, miembros de la LACE)
• Refinar la lista de los integrantes del tren (equipos, Propietarios del Producto, Product Managers, arquitecto, Business Owners e interesados)
• Enviar invitaciones (informando que el evento será en remoto)
• Establecer los nuevos roles
• Trabajar con Business Owners para que entienda la importancia de su rol
• Empezar a preparar la pila del programa con las primeras features
• Definir métricas iniciales
• Evaluar e identificar posibles herramientas digitales e infraestructura remota necesarias
• Comprobar las limitaciones organizativas (idiomas, horario de trabajo, etc.)
• Obtener presupuestos para las inversiones necesarias y una descripción general de los costes
• Tratar contratación de SAFe for Teams para los trabajadores externos

Mes y medio antes:

• Identificar herramientas digitales e infraestructura: Videoconferencia (Zoom, Teams, Appear.in, ...), Backchannel (Slack, Whatsapp, Hangouts, ...), Colaboración (Miro, ConceptBoard, Mural, ...), Feedback (Mentimeter, Kahoot, FunRetro, ...) y Gestor de pilas (JIRA, VersionOne y SeviceNow, ...)
• Establecer el alcance (producto, sistemas, dominios tecnológicos) para la PI Planning, una pila del programa con una visión clara de lo que se pretende construir
• Refinar la pila de programa y las features
• Establecer la cadencia de PI e iteraciones
• Definir salas de la videoconferencia (central, equipos, dependencias y scrum de scrums)
• Preparar tableros virtuales (tableros de los equipos, el Program Board, el tablero de Riesgos, un tablero Kanban para el progreso de evento, el canvas con la composición del tren (ART), un parking lot y otros
• Preparación de Scrum Masters para detallar su rol en la PI Planning
• Testear nuevas herramientas digitales e infraestructura
• Comprobar aspectos sobre la seguridad y la privacidad de los datos

Un mes antes

• Establecer los acuerdos de trabajo para satisfacer las necesidades de los asistentes al evento (cámara abierta, micrófono en silencio si no se está hablando, ...)
• Comprar licencias de nuevas herramientas digitales
• Entrenar a todos en el uso de las nuevas herramientas digitales
• Asegurar que a cada individuo le funcionan las herramientas (y cámara) en su ordenador
• Crear la agenda/escaleta de la PI Planning, y si es el caso adaptarla a múltiples zonas horarias
• Incluir links en las invitaciones
• Socializar la pila del programa a equipos, Business Owners y otros interesados del tren (ART)
• Preparar las presentaciones del CEO, Product Manager y arquitecto
• Identificar un miembro de equipo que sea el responsable de tratar dependencias con otros equipos
• Distribuir el material usado en la PI Planning (guías de herramientas, accesos, mapa de equipos y salas, ...)
• Identificar ideas sobre como reaccionar ante emergencias

2 semanas antes (iteración IP en caso de venir de un PI)

• Chequear que la pila del programa esté lista
• Si es la primera PI Planning formar a todos con SAFe for Teams
• Efectuar un ensayo general y captar dependencias
• Realizar las últimas sesiones de información abiertas a todos los participantes
• Cerrar la lista final de participantes
• Finalizar la configuración de las herramientas digitales
• Probar, probar, probar... y probar otra vez

PI Planning

• Una hora antes de la PI Planning ensayar presentaciones, videos, conexiones
• Ejecutar la PI Planning
• Posteriormente a la PI Planning recoger los resultados en la herramienta gestora de pilas

Ejemplo de hoja de ruta de preparación para una PI Planning remota - cortesía de Pixabay

¿Cuáles son los aprendizajes sobre infraestructura para PI Plannings remotas?

Ejemplo de cada tipo de herramienta

Ya llevamos más de medio año afectados por el COVID-19, y eso nos ha llevado a efectuar todo tipo de eventos de trabajo de forma remota y dispersa, entre ellos la PI Planning. En este post quiero abordar los 5 tipos de herramientas digitales que necesitamos para dotar a las PI Plannings de una infraestructura adecuada:

• Videoconferencia: La herramienta central que conecta todo y sirve de nexo y comunicación entre personas y artefactos. La sesión central de principio a fin de la PI Planning transcurre en esta herramienta, allí es donde las personas nos vemos las caras y colaboramos, y también donde compartimos información a través de chats y pantallas. La herramienta debe de incluir salas para grupos pequeños para las sesiones individuales de equipos. Estas salas deben de coexistir a la vez y ser visitables por cualquier persona; si un equipo necesita hablar con otro equipo u grupo, por ejemplo para para resolver una dependencia o aclarar una duda, ha de poder contactar y moverse fácilmente a través de las salas. Una opción excelente, y a fechas de hoy la más adecuada, es Zoom con sus breakout rooms. Necesitaremos una sala por equipo, una para Product Management, otra para arquitectura/sistemas/UX, una para el Scrum de Scrums, varias salas para conversaciones grupales esporádicas y también es muy recomendable una sala tipo cafetería para quienes estén descansando y/o quieran tener charlas informales.
• Backchannel: Canales de mensajería instantánea adicionales que sirvan para potenciar y acelerar la comunicación. Recordemos la PI Planning es un evento de alrededor de cien personas, o más, entre las que se producirán cientos de conversaciones. Algunas de estas conversaciones pueden producirse perfectamente en herramientas como Whatsapp o Slack. Slack es especialmente útil por su sistema de canales que permite estructurar fácilmente las conversaciones de forma similar a los breackout rooms de la videoconferencia, además de permitir conversaciones por pares entre todos los asistentes. Otra función clave del backchannel es ser canal secundario cuando la videoconferencia falle. Al ser un canal totalmente independientemente la combinación de ambos nos asegura que haya un canal de comunicación con todo el mundo en todo momento.
• Colaboración: Tableros de colaboración virtual tipo whiteboards para las sesiones de trabajo de los equipos, como lo son los tableros de los equipos, el Program Board, el tablero de Riesgos, un tablero Kanban para el progreso de evento, el canvas con la composición del tren (ART), un parking lot y otros. Estos tableros digitales son el punto de referencia para visibilizar el trabajo colaborativo de los equipos y del tren (ART). Se trata de herramientas como Miro, ConceptBoard y Mural. También podríamos utilizar herramientas como PIPLanning.app que están diseñadas exclusiva y únicamente para PI Plannings.
• Feedback: Herramienta que permita recoger feedback para sesiones como lo son el voto de confianza y la retrospectiva de final de PI PLanning. Mentimeter y Kahoot son herramientas de este tipo que además son adecuadas para pequeños rompehielos a lo largo del evento para mantener el nivel de energía alto.
• Gestor de pilas: Para la ejecución del PI es adecuado que el seguimiento de las pilas y del trabajo se realice en herramienta de gestión de proyectos ágiles, herramientas como JIRA, VersionOne y SeviceNow. Tableros colaborativos tipo whiteboard maximizan la colaboración síncrona y visibilidad en la PI Planning, y este tipo de herramientas de gestión facilitan la ejecución y colaboración asíncrona a lo largo del PI de pequeños grupos, como lo son los equipos.

La infraestructura para PI Plannings remotas y dispersas tiene sus retos con los que lidiar. Es crítico ensayar todos los aspectos y efectuar un ensayo general previo a la primera PI Planning. Mi consejo clave se podría resumir en: "probar, probar, probar... y probar otra vez".

Hemos de asegurarnos que todos los asistentes estén capacitados para el uso de todas las herramientas a utilizar; y que todos ellos tengan acceso a la infraestructura con los permisos necesarios. Por otro lado debemos de asegurarnos que la infraestructura pueda hacer frente a esa cantidad de usuarios concurrentes, no olvidemos que las VPNs se convierten fácilmente en un cuellos de botella. Y no nos olvidemos de las licencias, si una licencia hubiera de fallar o expirar sin duda ocurrirá en la PI Planning.

Todos los asistentes deben de tener cámaras y micrófono, y pensemos que el hecho de que un portátil tenga una cámara y micrófono no significa que esté preparado para funcionar el día de la PI Planning... podemos asegurarnos a través de los Scrum Masters, por ejemplo, que todos los miembros de los equipos tengan capacidad de videoconferencia.

PI Planning con videoconferencia por Zoom, tableros colaborativos en Miro y voto de confianza con Mentimeter

¿Cómo tratar a los "externos"?

"Externos" versus "internos" - cortesía de Pixabay

Me sorprende una y otra vez que, cuando hablamos de arrancar una tribu o un tren (Agile Release Train), surja la duda sobre si formar y entrenar a los "externos". Como "externos" se entiende personas subcontratadas de lo que conocemos como consultoras. Me sorprende, porque si estamos introduciendo nuevas formas de trabajar se debe de entender, por puro sentido común, que estas formas de trabajar han de ser bien entendidas por todas aquellas personas que participen de las mismas, independientemente de que sean "internos" o "externos".

Entre otras surgen dudas legales, como que no se puede pagar formación a "externos", pero una cosa es asistir a una formación y otra quién la paga. Si queremos introducir Agilidad, como cualquier nueva forma de trabajar, la solución más eficiente es formar a todas las personas de la misma manera, de una sola vez y sin distinguir "internos" y "externos". Obtendremos varios beneficios:

• Aprendizaje acelerado: la formación se realiza de una sola vez a modo de bootcamp en lugar de en un período de meses, lo que acelera el tiempo y el aprendizaje de todos y permite acelerar el lanzamiento de la tribu o del ART.
• Un paradigma ágil común: todas las personas reciben la misma formación al mismo tiempo y del mismo trainer, eliminando la variabilidad de diferentes sesiones de formación por diferentes trainers que pueden utilizar cursos diferentes.
• Rentabilidad: uno de los desafíos de una transformación ágil a nivel escalado es la disponibilidad y el coste de la formación. Los trainers talentosos y probados son difíciles de encontrar, no siempre están disponibles y su valor y coste son proporcionalmente altos. El enfoque de bootcamp suele ser de tres a cinco veces mas rentable que la formación de equipos individuales.

Hay que entender que lo que importa es que las personas que ejecuten el trabajo lo hagan en las mejores condiciones de trabajo posible, y para ello es necesario entrenarlos en Agilidad, apoyarles y darles los recursos necesarios. No importa si son "externos" o "internos".

Recordemos que las personas que hacen el trabajo toman decisiones a su nivel a diario, decisiones que inevitablemente impactan en la calidad de producto, y por ende en la competitividad de la compañía. Necesitamos personas competentes y motivadas, y de nuevo no importa si son "externos" o "internos".

El mayor activo de las empresas que se basan en trabajadores del conocimiento, como lo es el desarrollo de software por ejemplo, es el conocimiento de las personas. Es por ello que hoy en día se habla de capital humano. Un "externo" que por ejemplo lleve 4 años en una empresa cliente puede tener más conocimiento institucional y una red social más extensa y conectada que otros empleados "internos".

Las personas somos emocionales, nos sentimos ligados y orgullosos de lo que formamos parte. Si preguntamos a un "externo", que lleve en una empresa cliente un periodo mayor a un año por ejemplo, de qué empresa se siente parte, probablemente nos diga que de la empresa cliente y no de la empresa consultora que es quién le paga el sueldo. Si no lo tratamos como igual sus intereses probablemente se focalizarán en los propios en lugar de contribuir a los objetivos de la compañía cliente.

Los que hacen competitiva a la compañía, tienen buenas ideas y fomentan la innovación y crean productos de calidad son las personas que hacen el trabajo, independiente si son "externos" o "internos". Por tanto los líderes, liderando a través del ejemplo, debemos de tratar a todas esas personas de igual manera.

¿Qué técnica de retrospectiva se basa en el nivel de felicidad de los equipos?

Medición del índice de felicidad
en individual con Mentimeter

Los Scrum Masters debemos de introducir diferentes técnicas en las retrospectivas de los equipos ágiles. Una técnica enfocada a las emociones trata de la medición del índice de felicidad del equipo y permite traer a la consciencia el nivel de felicidad y buscar acciones de mejora concretas.

Está técnica está especialmente indicada para cuando el equipo ha experimentado muchas emociones diferentes durante un sprint y desea analizar las consecuencias. También cuando hubo varios retos dentro del sprint y el equipo quiere entender mejor cuándo y cómo surgieron los problemas.

La técnica ocurre en tres pasos:

1. Medición del índice de felicidad individual para consolidarlo en el nivel actual del equipo
2. Recoger razones del nivel de felicidad recogido
3. Efectuar conversaciones alrededor de las razones principales

En los tiempos actuales, con los miembros de equipo dispersos, las dinámicas las hacemos con herramientas virtuales, en nuestro caso funciona muy bien Mentimeter. Cada miembro del equipo marca en su móvil u ordenador el nivel de felicidad desde la perspectiva de las emociones que ha vivido a lo largo del sprint.

En la sesión del Scrum Master, o facilitador, Mentimeter muestra el nivel de felicidad consolidado del equipo, que este comparte con todos.

Nivel de felicidad consolidado del equipo

Visto el nivel de felicidad consolidado recogemos las razones que han llevado a ese nivel mediante una nube de palabras. Las palabras las escriben los miembros de forma individual, y aquellas palabras que tengan más ocurrencias se desplazan automáticamente hacia el centro y toman un tipo de letra más grande. De esta manera es muy fácil identificar de forma visual cuales son las razones principales.

Nube de palabras con las razones del nivel de felicidad

A través de la nube de palabras el equipo puede identificar lo que afectó al sprint y generar una conversación sobre estas razones y buscar mejoras. Conocer las causas directas puede ayudar al equipo a resolver problemas en el futuro. Del mismo modo, si el equipo se siente positivo, ¿por qué no aplicar la misma técnica para tener éxito con problemas similares en el futuro?

Como toda retrospectiva esta técnica sirve también para ventilar problemas y celebrar éxitos, en definitiva reforzar a los equipos y generar team-building.

Mis agradecimientos a Gertru que aportó sus experiencias a este post :-*

¿Qué hacer con quienes se resistan a la transformación hasta la muerte?

John Kotter - Resistance to Change

Una transformación ágil es un cambio mayor en una compañía, un cambio tan crítico que requiere un alineamiento de todos, desde el CEO a cada uno de los empleados. Muchos abrazaran el cambio, para mucho otros el alineamiento será gradual, y algunos se resistirán a muerte...

En este post quiero mostrar el consejo que da John Kotter en su video sobre resistencia al cambio, y lo hago transcribiendo y traduciendo sus palabras:

---

"Tengo un consejo para ti y luego retrocederé y explicaré por qué es importante.

En un proceso de cambio siempre encontrarás a tu alrededor algunas personas que básicamente siempre dicen que "no no", y lo dicen en serio. Estos son los tipos que se resisten hasta la muerte. Tenemos una tendencia a tratar de atraerlos, de cooptarlos en el proceso, de trabajar con ellos para cambiar su opinión. Y mi consejo es "olvídalo". Sácalos del camino sin importar quiénes sean en términos de poder o relaciones contigo, porque si los dejas dentro harán tanto daño que el cambio se verá socavado.

Ahora déjame retroceder.

Todavía tengo que ver un cambio importante en una empresa u organización gubernamental donde no se encuentren en todos los niveles algunas personas cuya reacción a cualquier nueva estrategia o idea sea "no no". Ahora, algunas de estas personas, si están en posiciones poderosas, serán muy francas contigo, otras no, estarán muy calladas, pero eso es lo que piensan y eso es lo que sienten. Y la tendencia que veo con demasiada frecuencia ante este problema, y que creo que habría hecho yo mismo hace 10 años antes de entender a través de múltiples estudios, es decir: "Bueno, si tan solo pudiéramos pasar un poco más de tiempo con Jorge, lo ganaremos o, ya sabes, es lo suficientemente importante como para tener que cooptarlo. Lo haremos parte del equipo clave, y si lo atraemos sentirá eventualmente algo de propiedad por este programa, lo que acabará por resolver el problema.

Mi observación ha sido: si los "no no" son lo suficientemente fuertes, es inútil, es absolutamente inútil, y la única alternativa que tienes es sacarlos del camino, distraerlos, mantenerlos fuera del camino, porque el daño que pueden hacer es casi infinito. La travesura, por ejemplo, de simplemente sonreírte y decir "sí, sí" pero luego ir por detrás, porque ya no les prestas atención, y hacer cosas que deshacen los cambios que has hecho, como hablar con grupos de aquí diciendo "sabes que esto es un poco loco" y empezar a ganárselos, de prometerles hacer algo y luego "oh Dios, ya sabes, se me olvidó... o, tenía esta otra prioridad", y eso te frena... el daño que pueden crear es casi infinito.

Creo que a la mayoría de nosotros no nos gusta la idea de decir que "no tiene esperanza". Tenemos que sacarlos de esto y mantenerlos fuera de esto de alguna manera. Creo que a la mayoría de nosotros no nos gusta eso, pero creo que en los casos de cambios significativos, cuando hay esos "no no" alrededor, esa es la única solución. Realmente la única solución".

---

Quiero añadir que debemos de cuestionarnos si queremos personas en nuestra compañía cuyos valores personales no estén alineados, al menos en parte, con los valores de la compañía. No olvidemos que los valores son los fundamentos que guían la conducta para llevar a equipos y empresas a nuevas formas de trabajar con mejores resultados de negocio, entre ellas a Business Agility.