¿Cómo solucionar el impedimento de los "Travelers"?

Impacto de un "Traveler" en un equipo - Cortesía de Pixabay

Es habitual escuchar nuevos "roles" como Agile Master, Agile Link y Agile Ambasador, roles que en realidad representan un rol disfuncional del Scrum Masters o del coach ágil. Quiero decir disfuncional en el sentido de que sus valores, responsabilidades y empoderamientos son parciales con respecto a los valores y principios de la Agilidad. 

Me llamó mucho la atención el término "Traveler" cuando este se refiere a esas personas miembros de equipos que pertenecen a porcentajes a varios equipos y saltan con la lengua fuera de uno a otro. Quizá el supuesto "rol" haya nacido como una disfunción del concepto de Traveler en el contexto de la polinización cruzada.

Scrum propone claramente miembros de equipo dedicados al 100% y evitar compartirlos en más de un equipo. El hecho de tener miembros de equipo que tengan que repartir su esfuerzo en varios equipos provoca que las estimaciones y las horas disponibles dejen de ser confiables. En cuantos más equipos tenga que participar una persona, más tiempo perderá en cambiar de contexto, y en más eventos recurrentes de Scrum (planificaciones, diarias, refinamientos, revisiones y retrospectivas) deberá de participar quedándole un tiempo muy limitado para hacer su trabajo.

Además resulta que, tal como describen James Shore y Shane Warden en su libro "The Art of Agile Development (2007)", según la perspectiva emocional "... los trabajadores parciales no se vinculan con sus equipos, a menudo no están cerca para escuchar conversaciones y responder preguntas, hecho que impacta fuertemente su trabajo y sus tareas, provocando que se incurra en una penalización oculta significativa".

Puede ser frustrante para la persona tener dos o más objetivos, puede que éstos entren en conflicto por intereses divergentes de los Propietarios del Producto o los jefes directos. También es frustrante cuando los objetivos de diferentes equipos los hayan de cumplir al 100% y eso no fuera alcanzable: si la persona se queda en un equipo más de su porcentaje de tiempo por las razones correctas, estará penalizando al otro equipo, al que no tiene la culpa... y eso genera mucho estrés que bloqueará a la persona.

La existencia de este tipo de "Travelers" probablemente indique pensamiento tradicional en términos de proyectos donde varios jefes de proyecto necesitan de un mismo recurso. 

Coste de la multitarea según Gerald Weinber
Quality Software Management: Vol. 1 System Thinking

La primera opción es tratar la disfuncionalidad como un impedimento e intentar cuantificarlo en dinero (porque ese es un idioma que todo manager entiende). Intentar medir el tiempo que el equipo pierde debido al cambio de contexto en las tareas, pidiéndole a los desarrolladores que den una estimación al respecto. Ellos lo saben muy bien, lo viven día a día. Sabemos que con cada equipo en que participe una persona de forma parcial ¡se reduce la productividad en promedio un 20% de todo el equipo! Una vez que tengamos algunos números hemos de hacerlos transparentes a managers y compañía y mostrarles el coste por no tener miembros de equipo dedicados al 100%. Si una persona tiene que ser compartida por varios equipos eso probablemente sea una señal de que necesitamos contratar otra persona con esas habilidades.

Otra opción, cuando se trata de un especialista en algo muy concreto y necesario en más de dos proyectos a la vez, es considerar tratarlos como consultores, mentores y capacitadores para el resto de los equipos. En lugar de incluirlos como parte de un equipo de desarrollo la idea es compartirlos entre varios equipos para apoyar y ayudar en tareas específicas y a la vez formar a otros miembros en cada equipo.

Y como última opción podemos escalar los equipos a una tribu o tren (ART). Lo interesante de las tribus es que todos los equipos que la forman tienen un objetivo común y una pila de producto común, con lo que estamos fomentando el alineamiento en una sola dirección y la colaboración por encima de los intereses individuales de los equipos. En la planificación trimestral (PI Planning), cuando los equipos planifican en paralelo los siguientes tres meses, lo harán basándose en los recursos existentes, y si hay necesidad de un especialista en varios equipos, ellos, los miembros de los equipos, los que van a hacer el trabajo, van a encontrar soluciones con las que todos se sientan comprometidos. Estas soluciones pueden materializarse en unos planes coordinados para las intervenciones del especialista, además de incluir actividades de formación y capacitación por parte del mismo, que aunque no se sienta parte de un equipo se siente parte de la tribu.

¿Se pueden visualizar frases o párrafos complejos?

Frank Wesseler exponiendo en el meetup

Recientemente estuvimos en un meetup titulado "Diálogo Visual usando la técnica Bikablo® en el que Frank Wesseler nos enseñó a dibujar conceptos complejos y abstractos, "con el fin de lograr un entendimiento común de los puntos más importantes a través del "diálogo visual" con clientes y compañeros de trabajo".

El diálogo visual, o thought sketching, no trata de crear hermosas hojas de rotafolio para una presentación, sino ser un cuestionamiento visual, un punto de partida para conversaciones posteriores, para asegurarnos que todos hemos entendido lo mismo:

• ¿Lo he entendido bien?
• ¿Es correcto presentarlo de esta manera?
• ¿Qué tengo que cambiar para que refleje correctamente su significado?
• ¿Qué tipo de soluciones conjuntas podemos encontrar cuando miramos el dibujo?

El diálogo visual nos puede ayudar de forma muy potente a coaches ágiles y Scrum Masters cuando entrenamos a equipos, facilitamos talleres como Value Stream Mappings o modelado de sistemas.

Dimensiones en las que las personas "escuchamos"

Teoría del aprendizaje

La visualización abre un segundo canal de comunicación para una mejor comprensión ("Dual coding theory").

Teoría de codificación dual (de la Wikipedia)

---

"... La teoría de la codificación dual postula que la información tanto visual como verbal se usa para representar información. La información visual y verbal se procesa de manera diferente y en distintos canales en la mente humana, creando representaciones separadas para la información procesada en cada canal. Los códigos mentales correspondientes a estas representaciones se utilizan para organizar la información entrante sobre la que se puede actuar, almacenar y recuperar para su uso posterior. Se pueden usar códigos tanto visuales como verbales para recordar información..."

"...Por ejemplo, digamos que una persona ha almacenado el concepto de estímulo "perro" como la palabra "perro" y como la imagen de un perro. Cuando se le pide que recuerde el estímulo, la persona puede recuperar la palabra o la imagen individualmente, o ambas simultáneamente. Si se recuerda la palabra, la imagen del perro no se pierde y aún puede recuperarse en un momento posterior. La capacidad de codificar un estímulo de dos maneras diferentes aumenta la posibilidad de recordar ese elemento en comparación con si el estímulo solo se codificó de una manera...".

---

Vocabulario visual

Diccionario visual 1

Para una visualización rápida necesitamos pictogramas, figuras, contenedores de texto y elementos gráficos. Bikablo®, que aporta este tipo de herramientas y de soluciones, se define como una empresa pionera que se considera un laboratorio para la visualización gráfica que con su "quick & dirty-technique" aporta nuevas imágenes y métodos visuales al mundo.

Entre sus productos hay una serie de diccionarios visuales, donde en cada uno de ellos explica como funciona el método y contiene más de cien páginas con palabras clave, cada una de ellas relacionadas con dibujos muy simples pero impactantes para usar en nuestras visualizaciones.

El diccionario visual 1 es el más interesante para nosotros ya que está especialmente diseñado para las necesidades de visualización de coaches ágiles, Scrum Masters, moderadores y consultores.

Visualizar y reflejar tus ideas junto con un compañero

Pasos para el diálogo visual

Después de ver la teoría de aprendizaje y obtener herramientas de visualización, el meetup consistió en practicar el diálogo visual. En la primera parte del ejercicio todos pensamos una frase a visualizar. Yo, con ánimo de reto, escribí la siguiente:

Vamos a iniciar un proyecto aplicando Scrum

con sprints de dos semanas,

obtener un primer MPV para obtener feedback temprano,

y seguir construyendo guiados por valor

¿Sería posible visualizar eso? Me parecería algo muy espectacular si fuera posible.

Las instrucciones del taller fueron las de la imagen a la derecha:

1. Formar grupos de 4 personas
2. Seleccionar frases del ejercicio previo
3. Una primera persona lee su frase y la enseña
4. Todo el mundo visualiza la frase en 2 minutos
5. Cada uno enseña su resultado
• ¿Qué dibujo funciona bien?
• ¿Cuáles son los factores de éxito?
6. Pasamos a la siguiente frase y veamos como mejoramos

Y he aquí el resultado... tengo que admitir que visualizar una frase tan compleja y a la vez técnica en 2 minutos, y que transmita perfectamente el contenido, me ha sorprendido muy gratamente. Está claro que aquí hay una habilidad a desarrollar. :-)

Mi resultado hecho en 2 minutos

El resultado de Gertru y el mío :-D

¿Cómo crear equipos ágiles?

A semejanza de como se forman los equipos en un meetup,
la autoorganización es la forma óptima de creación de equipos

Esta es una pregunta recurrente tanto en mis acompañamientos como coach ágil así como en mis clases; hay mucha curiosidad sobre como crear de forma óptima los equipos que hayan de trabajar en uno o varios productos y decidir qué persona pertenece a qué equipo.

Tradicionalmente un manager o un jefe de proyecto se basa en una skill matrix (matriz de habilidades) para crear su equipo. Una matriz de habilidades es una tabla que muestra el dominio de las personas en habilidades y conocimientos específicos, así como su interés en trabajar en determinadas tareas utilizando estas habilidades y conocimientos. Este tipo de herramienta tiene en cuenta toda la información visible externa, y los equipos ágiles óptimos e hiperproductivos requieren que se creen también en base a otros factores como intereses emergentes, motivaciones y valores, talentos no desarrollados, deseos, habilidades blandas...

Como en toda dinámica o evento de Agilidad, la forma de maximizar la colaboración e ir más allá de los métodos tradicionales es resolver la complejidad con complejidad; lo que quiere decir que para resolver problemas complejos hay que hacer que cada persona del grupo asociado trabaje su parte desde su perspectiva, y a la vez tenga el máximo interés en colaborar y compartir con los demás. Resaltar que ese es uno de los mayores retos de las compañías actuales; aplicar System Thinking y crear el entorno, las estructuras y las métricas que pongan el interés de las personas en la colaboración.

Resolver complejidad con complejidad en la creación de equipos quiere decir que sea el propio grupo de miembros los que crean los equipos, y permitir que el grupo se autoorganice y se divida en equipos. Las mejores decisiones sobre quién y cómo trabajar juntos para lograr incrementos de valor solo las pueden tomar los miembros de equipo involucrados en el trabajo.

Como managers deberemos de proporcionar las pautas adecuadas y ayudar a promover la autoorganización, la creatividad y la resolución de problemas. Para ello podemos reunir a los miembros involucrados, explicarles el objetivo de la iniciativa, los usuarios específicos y sus objetivos, exponerles la visión y los objetivos de nuestros productos y cómo pensamos asegurar el éxito. Antes de la actividad de creación de equipos hemos de indicarles que deben tratar de equilibrar las habilidades y la experiencia, y que como líderes brindamos en todo momento toda asistencia que sea necesaria. La transparencia ayudará a aquellos dentro y fuera del equipo a ajustarse en consecuencia para mantenerse alineados en esa dirección.

La mejor actividad que he vivido para formar equipos es la Big Room Planning, PI Planning en SAFe® o Sprint Planning 1 en LeSS. En este evento de planificación se exponen las funcionalidades a construir, probablemente en forma de epics, y los miembros de los futuros equipos se deciden individualmente por una de las funcionalidades y se quedan situados debajo o frente a la misma para formar equipo con otros miembros interesados.

Básicamente visito todas las funcionalidades y me quedo en la que me "mola" e intento formar equipo con otros miembros que les "mole" construir esa funcionalidad. Por supuesto el equipo nuevo ha de tener todas las habilidades necesarias para construir esa funcionalidad, y no hay nadie mejor que los que van a hacer el trabajo para saberlo. A veces hay que reclutar a alguien con una habilidad específica, a veces alguien tiene que ir a otro equipo porque ya están cubiertas todas las necesidades para construir la funcionalidad. En un ambiente de colaboración eso no es un problema, hoy por ti, mañana por mi.

De esta manera se forman equipos óptimos y motivados, también ocurre que con cada planificación a lo largo del tiempo se reconfiguran los equipos de forma natural:

• Se crean los mejores equipos posibles para las funcionalidades dadas
• Se tiene en cuenta los deseos e intereses emergentes de los miembros, por tanto se crean equipos basados en el talento de sus miembros
• Se difunde el conocimiento y se crean perfiles tipo "T"
• Se fomenta la unidad tribal y la inteligencia colectiva

Podemos pensar que esta forma de crear equipos requiere cierta madurez, cosa que es cierta, pero no a nivel de los miembros de los equipos, esto casi les sale de forma natural, sino a nivel de los managers y líderes que han de tomar una mentalidad ágil, confiar en sus empleados y crear y apoyar un entorno que fomente el pensamiento y la colaboración.

Recuerdo que en una PI Planning en un entorno recién incorporado a la Agilidad, en el tablero de dependencias dos equipos habían marcado una dependencia con una cuerda totalmente vertical. Esto aparentemente significaba que un equipo iba a resolver la dependencia a la vez que el equipo bloqueado hiciera su parte, y eso no estaba bien, primero dependencia y luego la parte dependiente. Así que les pregunté y me dijeron: "No Alex, hemos decidido crear un equipo temporal para esa funcionalidad y trabajar juntos" con lo que ¡eliminaron la dependencia y los riesgos asociados!

¿Cómo transicionar de equipos de componentes a equipos funcionales?

Usualmente las compañías tradicionales están organizadas a modo de silos con departamentos formados por especialistas y sus managers. A su vez los departamentos de ingeniería suelen estar organizado en equipos aislados que se especializan por funciones; por ejemplo, diseño, front, back, base de datos, pruebas... a ese tipo de equipos se conocen como equipos de especialistas o de componentes.

Los equipos ágiles, como los equipos de Scrum, son equipos que pueden construir funcionalidades de principio a fin; para ello es necesario que incluyan especialistas de todas las disciplinas necesarias para diseñar, construir, probar y desplegar funcionalidades completas de valor maximizando la velocidad y minimizando las dependencias. Debido a que todas las habilidades y competencias están dentro del equipo, la sobrecarga de comunicación es reducida. A este tipo de equipos multifuncionales se les conoce como equipos funcionales.

En una transformación ágil, al igual que transicionamos de actividades o tareas especificas a historias de usuario, que representan funcionalidades de principio a fin, debemos de transicionar paulatinamente equipos de componentes a equipos funcionales que por si mismos puedan construir funcionalidades de principio a fin.

Transición de equipos de componentes a funcionales - Equipo y flecha cortesía de Pixbay

• Creando habilitadores para crear una arquitectura que permita implementar y desplegar con más frecuencia
• Rotando cuidadosamente a los miembros de los equipos entre los diferentes equipos de componentes para difundir el conocimiento
• Promoviendo el entrenamiento cruzado y el pair programming para mitigar cuellos de botella y crear perfiles tipo "T"

Hemos de ser conscientes que transicionar a equipos funcionales podría reducir la productividad en las primeras etapas. La fase inicial un equipo nuevo podría causar interrupciones a corto plazo, ya que sus miembros necesitan tiempo para descubrir la mejor manera de trabajar juntos. Tener un entorno que esté alineado con los valores de Scrum reduce la complejidad, así como obtener apoyo del lado de negocio facilitan la transición.

En un entorno de escalado, en un equipo de equipos, una tribu o un tren en el que hay varios equipos trabajando en un mismo producto o con una misma infraestructura, puede ser necesario mantener algunos equipos de componentes. Con este tipo de equipos se puede garantizar la robustez arquitectónica. Éstos se suelen mantener para construir componentes de alta reutilización, de alta especialización técnica y requerimientos funcionales críticos: son equipos que suelen dar servicio a los equipos funcionales y cuya colaboración y entendimiento de una responsabilidad compartida es esencial para la entrega de valor sostenible.

¿En una empresa ágil el manager es responsable de la calidad?

Codificando - Cortesía de Pixabay

En empresas tradicionales, en las que existe jerarquía de mando y control en la que los managers dicen a sus empleados lo que han de hacer, ocurre que éstos son los responsables máximos de todo lo que dependa de ellos, incluida la calidad del producto, si procede.

En Agilidad y en Scrum las personas que realizan el trabajo forman equipos multifuncionales y autoorganizados con autoridad sobre como realizan las tareas y actividades de construcción, por tanto la responsabilidad de la calidad debe recaer en los mismos equipos de desarrollo. Un líder ágil, un líder al servicio, sirve al equipo para proporcionarle un entorno en el que sus miembros puedan crear productos de alta calidad, y así el mismo equipo pueda responsabilizarse de la calidad.

Un codificador de un equipo de Scrum por ejemplo, entiende que él es el responsable de la calidad de todo el código que escriba, y que él, junto al equipo del que forma parte, es quien está a cargo de la calidad del producto para satisfacer las necesidades de nuestros clientes. Él entiende que tiene que incorporar gradualmente pruebas unitarias a medida que codifica, de manera que su código resulte comprobable y testeable. Él, junto a su equipo, siente que es responsable de lo que llegue a producción, y es consciente de como la calidad impacta en la resolución de las necesidades del cliente.

El equipo como responsable de la calidad ya que llega hasta el cliente
Cortesía de Pixabay

Para ello es muy importante que management delegue esa responsabilidad. Si a los equipos les damos la responsabilidad sobre la cadena de valor completa, ellos van a tomar esa responsabilidad y van a sentirse comprometidos. Una de las motivaciones más potentes es el propósito, y tener responsabilidad sobre la cadena completa hace sentir a cada individuo que es importante, que la empresa confía en él y cuál es su lugar dentro de la misma y del producto/proyecto.

Buenos managers que sirven a los equipos hacen que éstos construyan grandes cosas, desarrollando sus capacidades individuales y como equipo, proveyéndolos de recursos, creando entornos de confianza adecuados y resolviendo impedimentos, sobre todo aquellos que los equipos consideren como más importantes y bloqueantes. Cuidan de sus equipos y empleados y éstos a su vez cuidan de los clientes.

¿Se puede estandarizar el punto de historia en un elemento estimador base?

Café, elemento estimador base para estimar el
coste de la vida, gracias Asier - cortesía de Pixabay

Asier, un asistente a un curso on-line de Scrum Manager, en la lección de estimación relativa nos contó una de sus historias:

"A modo anecdótico, cuando viajo por cualquier país que desconozco, y al objeto de hacerme una estimación de su coste de vida, siempre me tomo un café en un sitio normal (average), y sobre el precio del café estimo el coste de vida para los elementos cotidianos; ¡y me funciona muy bien!

En caso de trabajar con equipos de desarrollo, antes apuntabas al esfuerzo relativo a desarrollar una pantalla de login; ¿existe algún "elemento café" que nos sirva a título genérico para usarlo como elemento estimador base (E2B)? ;-))))"

Me encantó su anécdota sobre el elemento café, es tan representativo y probablemente exista en todos los países del mundo. Como ocurre con el café, las mejores estimaciones son fruto de la inteligencia emocional, la inteligencia emocional es superrápida y tiene en cuenta todos los aspectos que conocemos como expertos. Cuando compramos o alquilamos un piso ¿cuanto tardamos en decidir si este nos vale?... unos 2 minutos a lo máximo. Lo hacemos en base a nuestra experiencia y conocimiento del mundo sobre como es un piso deseable.

¿Cuántos "aseos" son necesarios para pintar este piso?

Imaginemos que le pedimos a un pintor estimar pintar el piso que acabamos de comprar. Vendrá a casa y se dará un paseo de unos minutos por las habitaciones a pintar y dirá "son tantos días y es tanto". En su paseo habrá estimado el impacto de los muebles, habrá visto donde amasillar... es un experto y con su experiencia verá todo lo que haya de verse para estimar con suficiente exactitud. Y probablemente tendrá interiorizado un E2B.

En el curso de Scrum Manager tenemos un ejercicio que consiste en estimar cuánto cuesta pintar las siete habitaciones de un piso, el que vemos representado en la imagen del plano a la izquierda.

El ejercicio trata de hacer una estimación por "juicio de experto" empleando una unidad relativa, un E2B, que en este caso es "el pintado del aseo", y que representa la experiencia del pintor para pintar el aseo (la habitación del centro del plano), y tratar de calcular, sin realizar ninguna medición en el plano ni cálculos numéricos, cuántos "aseos" cuesta pintar las 7 habitaciones.

El E2B debe de ser algo que surja de la experiencia del equipo, algo que defina este y con lo que este se sienta cómodo; puede ser una pantalla de login o cualquier otra cosa de su realidad profesional.

Recuerdo un equipo que estimaba en manolitos, empezaron estimado a base de esos croissants y al cabo de un par de sprints el manolito se convirtió en una unidad de esfuerzo relativa cuya naturaleza solo ellos comprendían, y que para ellos y para la estimación de la pila de producto y medida de velocidad funcionó muy bien.

Página de login, algo común a muchas aplicaciones

La clave es entender que la pantalla de login y el manolito son un elemento de partida que hay que interiorizar y calibrar. Para ello tenemos el ciclo de aprendizaje sobre el proceso que se produce con cada sprint en la restrospectiva. Si el entorno lo permite (me refiero si la empresa permite al equipo a equivocarse y a aprender) en tres sprints el E2B se habrá convertido en una unidad relativa bien entendida.

En un marco de escalado necesitamos E2Bs a nivel de equipo de equipos, tribus o trenes, ya que para poder planificar y proyectar a fechas necesitamos un E2B que signifique lo mismo para todos. Si deberemos de estandarizar ese E2B y lo debemos de hacer a través del aprendizaje a nivel del equipo de equipos y efectuar talleres de normalización por ejemplo.

Lo que no funciona es basarnos en E2Bs obtenidos desde fuera de los equipos, E2Bs que no hayan nacido en los equipos y por tanto estos no hayan interiorizado. Eso me recuerda a algunos excels estimadores de grandes empresas que pretenden estandarizar lo inestandarizable, y eso sin tener en cuenta a las personas que hacen el trabajo.

Mi agradecimiento a Asier :-) Y para los que hayáis intentado estimar pintar el piso estimaciones entre 13 y 16 "aseos" son buenas cifras