Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, métodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos, productos, scrum masters, agile coaches, agentes de cambio, y líderes a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
Resumen del artículo "Para crear un equipo de alto rendimiento, pida un 85% de
esfuerzo"
El artículo "Para crear un equipo de alto rendimiento, pida un 85% de
esfuerzo" de Ben Horowitz, publicado en la revista Harvard Business Review en
junio de 2023, sostiene que la clave para crear un equipo de alto rendimiento
es pedir a los miembros del equipo que se esfuercen al 85%.
Horowitz argumenta que pedir a los miembros del equipo que se esfuercen al
100% todo el tiempo es contraproducente. Esto se debe a que el agotamiento y
el estrés que resultan de operar al máximo nivel pueden conducir a errores,
decisiones pobres y, en última instancia, a un rendimiento inferior.
En cambio, Horowitz sostiene que pedir a los miembros del equipo que se
esfuercen al 85% permite a los individuos y al equipo en su conjunto rendir de
manera óptima a largo plazo. Esto se debe a que deja espacio para la
creatividad, el aprendizaje y la recuperación.
Horowitz ofrece varios consejos para ayudar a los líderes a implementar la
regla del 85% en sus equipos:
Establezca expectativas claras. Los miembros del equipo deben saber qué se
espera de ellos en términos de rendimiento y esfuerzo.
Cree un entorno de confianza y apoyo. Los miembros del equipo deben sentirse
cómodos para admitir cuando necesitan ayuda o descanso.
Facilite el aprendizaje y el crecimiento. Los miembros del equipo deben
tener oportunidades para aprender y desarrollarse en sus roles.
Horowitz concluye que la regla del 85% es una forma efectiva de crear
equipos de alto rendimiento que sean productivos, innovadores y sostenibles.
Algunos ejemplos de cómo implementar la regla del 85%:
En lugar de exigir que los miembros del equipo trabajen horas extras,
ofrezca flexibilidad para que trabajen desde casa o en horarios flexibles.
En lugar de esperar la perfección, acepte que habrá errores.
En lugar de centrarse en la cantidad de trabajo realizado, concentre su
atención en la calidad del trabajo.
La regla del 85% es un enfoque simple pero poderoso para crear equipos de alto
rendimiento. Al pedir a los miembros del equipo que se esfuercen al 85%, los
líderes pueden ayudar a sus equipos a rendir de manera óptima a largo plazo.
Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.
Con frecuencia me encuentro dentro de las organizaciones ya sean clientes o
proveedores, expresiones en los gestores del personal, tales como:
"La ocupación de las personas debe ser del 100%, para eso se les paga"
o esta otra
"Exíjanles el 120% para que den el 100%"
Luego de esto, se activa el liderazgo egipcio, los látigos, las zanahorias, la
microgestión, las acusaciones de distracción, el estrés, la sensación de
esclavismo, el inflar las tareas para poder tener espacios para descansar, el
ambiente se vuelve tóxico, y cualquier sentido de pertenencia se convierte en desvinculación y ganas de renunciar.
Como te puedes dar cuenta esto termina degradando el sistema, en vez de
mejorarlo. El objetivo de este artículo es llevarte a que comprendas que:
"Una persona o un equipo con una asignación del 70% al 80% es mucho más
productivo y eficiente que uno con una ocupación del 100%"
Debido a que las personas y equipos tienen espacios para:
la mejora continua individual
la mejora continua grupal
para aceptar la variabilidad
hacer con mejor concentración las tareas
mejora colaborativa
eliminar desperdicios
innovar
agregarle valor a lo que hacen
Si lo deseas puedes terminar acá de leer, pues lo que sigue es una larga
justificación del por qué de esta afirmación, así que comencemos:
No podemos tratar a las personas como máquinas
En esta parte no voy a apelar a la evidencia científica sino a la experiencia
personal, actualmente estamos en el 2020, el año en que estalló la pandemia
del COVID-19 y muchos de nosotros nos hemos movido al trabajo virtual, adicional al impacto de esto en nuestras vidas,
¿no han sentido lo pesado de tener una agenda completa 100% todos los
días, por varias semanas?
¿al final de día no terminan sintiéndose exhaustos y quemados?
¿no les ha hecho falta espacios para café y conversar e interactuar con
sus compañeros? ¿tener conversaciones interesantes y conversaciones
triviales?
al menos yo sí, llevándome al punto que he tenido que insertar en mi agenda
espacios para descansar, pararme, tomarme un café, y estos descansos han
permitido que refresque mis ideas, que tenga más fluencia y
mejor concentración, que trabajar 100% todos los días.
Ahora, no niego que hay días de sobrecarga y se asumen, pero un ritmo
sobrecargado de forma constante termina yendo en contra de las personas y de
los equipos.
Dice Sun Tzu en el Arte de la Guerra:
"Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo
producirá calamidades. Como se ha dicho: "Los que a hierro matan, a hierro
mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas
tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán
de tu debilidad para sublevarse. Entonces, aunque tengas consejeros
sabios, al final no podrás hacer que las cosas salgan bien."
Te recomiendo estos dos artículos:
Ritmo Sostenible sobre Ritmo Insostenible -
(clic aquí)
Recomendaciones sobre el sobreesfuerzo del equipo en un proyecto -
(clic aquí)
En el trabajo de conocimiento nuestra aproximación es diferente
En el mundo de la fabricación de objetos físicos, las tareas son
repetitivas, las actividades son razonablemente predecibles y los elementos
que se crean pueden estar en un solo lugar a la vez. En el desarrollo de
productos, muchas tareas son únicas, los requisitos del proyecto cambian
constantemente y el resultado, gracias, en parte, al uso generalizado de
diseño y simulación avanzados asistidos por computadora y a la incorporación
de software en productos físicos, es información que puede residir en varios
lugares al mismo tiempo, o que puede ser construida de forma eficiente o ineficiente, generando alta variación en las tareas, las estimaciones y los compromisos. Creer que un grupo de ingenieros de software expertos garantizará el cumplimiento de un cronograma detallado de varios cientos de filas y meses de planeación es cada vez más irreal, los enfoques ágiles permiten validar rápidamente los resultados obtenidos y navegar exitosamente en estos escenarios de incertidumbre. Pero para que esto se lleve a cabo de forma exitosa es necesario que tanto gestores, gerentes de área, gerentes de proyectos directores, líderes, agile coaches, scrum masters, product owners y product managers, comprendan el pensamiento lean-agile, para que cultiven y permitan que funcionen muchas prácticas que van en contrasentido de la gestión tradicional, sin esto, cualquier esfuerzo de cambio será en vano.
100% de la utilización es un desastre económico
Es normal pensar que los proyectos toman más tiempo cuando las personas no
están trabajando el 100% de su capacidad, y, por lo tanto, una organización de
desarrollo ocupada será más rápida y eficiente que una que no sea tan buena
en utilizar a su gente, pero en el mundo Lean y en la práctica eso no
es cierto, cuando la ocupación o utilización del tiempo de las personas
se aproxima al 100% la eficiencia, la calidad y la velocidad disminuyen (2), existen
varias razones:
No se considera la variabilidad de procesos de trabajadores de conocimiento
Los trabajadores de conocimiento no hacen tareas estandarizadas, en un mundo
estandarizado un cambio del 7% en el trabajo generará un 7% más en
completarlo, algo que no ocurren procesos de TI. En general existen tres
fuentes de variación (3) en los procesos:
Recursos:
Ejemplos: unas máquinas son lentas y otras rápidas, los expertos
realizan las tareas más eficientemente que los novatos.
Unidades de flujo (o elementos que fluyen):
Ejemplos: en una fábrica de autos personalizados los vehículos tendrán diferentes características.
Factores externos
Ejemplos: los pacientes en una sala de urgencias no llegan de forma
fluida, a un equipo comercial la solicitud de propuestas no es un
flujo constante.
En el mundo de TI donde a pesar de usar la misma estrategia de
construcción de software puede cambiar:
la persona que los realiza (incluso la misma persona en distinto tiempo)
el estado de ánimo de la persona
disponibilidades tanto de personas, áreas, recursos (servidores, comunicaciones, componentes)
los requerimientos
insumos
la calidad de la documentación
resultados esperados
dependencias
transacciones
complejidad técnica
supuestos y premisas
entre otros
se constituyen en fuentes de variación del proceso, y estas fuentes de variación generan un tiempo de flujo diferente según el porcentaje de utilización de los recursos, tal como lo
formuló Sir John Kingman, el cual desarrollóla fórmula de teoría de colas que relaciona la variación, eficiencia de recursos y tiempo de travesía (16). Ver gráfica a continuación:
Relación entre variación, eficiencia de recursos y tiempo de travesía
- Gráfica de Sir John Kingman (3)
Por lo tanto:
entre más cercanos estemos al 100% de utilización del tiempo de las
personas más tiempo tomará la travesía del proceso
ampliar la utilización del 90 % al 95 % aumenta el tiempo de travesía en un nivel mayor, que el de aumentar la utilización del 80 % al
85 % (3)
agregar un 5% más de trabajo puede llevar un 100% más de
tiempo (2)
cuando el tiempo de travesía aumenta, el flujo (la cantidad de ítems,
requerimientos, tickets por unidad de tiempo) disminuye
Es importante anotar que, para TI aplica más la curva fucsia que la gris.
Por lo tanto:
"Cuanto mayor sea la utilización de tu equipo, más largo será el tiempo
de travesía, es decir, si tienen un ciclo fijo de trabajo, menos cosas
lograrán terminar"
-----
"Cuanto mayor sea la variación en el proceso, más largo será el
tiempo de travesía (3)"
Relación el Tiempo de Ciclo, la Utilización y el Tamaño de los Lotes
"Reduzca el tamaño de lote para: reducir la variabilidad e incrementar la predictibilidad"
se tenga un sprint backlog que contenga de 6 a 10 historias de usuario
de similar tamaño
se estima usando Fibonacci en el planning póker para amortiguar un poco
la variabilidad de las historias de usuario
se sugiere planear con el 70% al 85% de la capacidad del equipo
Durante décadas, 3M ha programado desarrolladores de productos al 85%
de su capacidad (2)
Y Google es famoso por su “20% de tiempo” (que permite a los
ingenieros trabajar un día a la semana en lo que quieran, una práctica
que significa que hay capacidad adicional disponible si un proyecto se
retrasa) (2)
Ericcson planea sus equipos de producto al 70% (7)
Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).
Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).
"Operar un proceso de desarrollo de productos cerca de su plena
utilización es un desastre económico" ― Donald G. Reinertsen, The
Principles of Product Development Flow: Second Generation Lean Product
Development
--
"100% de utilización conduce a la no predictibilidad" ― Donald G. Reinertsen
Principle Q6 & Fig 3-6 illustrate this point. Think of queueing
function as transforming a change in loading into a change in queue size
(& thus cycle time). Operating at high utilization amplifies
variability. Manufacturers have known this for a long time, developers not
so much
El tener un equipo o personas al 100% de su capacidad y con compromisos en
ciclos cortos, no permite aceptar la atención a imprevistos, pues cualquier imprevisto afectará el compromiso. En entregas
largas la aceptación de imprevistos es tomada más como un favor, pues no se visualiza el impacto del tiempo de desenfoque, pero ya
hemos aprendido que las entregas largas no son exitosas en el mundo del software, es por eso que enfoques como Scrum o XP son exitosos hoy en día. Por lo tanto, una estrategia
usada por equipos scrum para aceptar los imprevistos es usar el patrón:
Illegitimus Non Interruptus (clic aquí), el cual consiste en reservar de la capacidad del equipo un porcentaje para
atención de imprevistos en caso de que estos se presenten.
Tomado de (6)
Inhibe la colaboración y la innovación
Frases que nos decimos o nos dicen como:
"Te ayudaría, pero ahora no tengo tiempo"
"Esto se podría mejorar de esta manera, pero no tengo tiempo"
"Cuando tenga tiempo te voy a enseñar a ___________"
Con seguridad lo haríamos, pero estar 100% enfocados no permite ir más
alla; es un enfoque del 100% en la tarea encomendada, que ahoga espacios de
interacción y mejora que emergen al poder colaborar o al tener una carga
menor de trabajo. La mejora y la innovación no ocurren fuera del horario
laboral (de 6 pm a 10 pm), tal vez, vengan ideas fuera de este horario, pero
la implementación requiere de tiempo laboral.
Tomado de (7)
Tomado de (10)
Una experiencia observable en talleres (y en la realidad)
En talleres donde se ejemplifica como es el mundo Lean y Kanban, se realizan varias iteraciones con equipos constituidos entre 5 y 8 personas, en los cuales construimos hamburguesas ficticias, o pizzas, o retratos o cualquier proceso organizacional, se realizan varias iteraciones del proceso con diferentes porcentajes de utilización y limitando el WIP, una y otra vez demostramos que la utilización cercana o igual al 100% genera desperdicio.
Tomado de (11)
Tomado de (11)
Para este ejemplo tener utilizaciones del 98% produjo:
7 hamburguesas,
-1170 unidades de valor y
7 defectos,
mientras que con utilizaciones del 74% se lograron:
15 hamburguesas,
1340 unidades de valor y
0 defectos
Una y otra vez, concluimos que como gestores nuestro trabajo es maximizar el flujo de valor, no la utilización del recurso tiempo de las personas. Y esto se debe a la paradoja explicada en "Esto es Lean" (3), en la cual muestra que en el flujo de procesos esté en uno de los siguientes cuatro estados:
Baja eficiencia de flujo y baja utilización: desperdiciolandia
Alta eficiencia de utilización y baja flujo: islas eficientes
Alto flujo y baja utilización: océano eficiente
Alta eficiencia y alta utilización: el estado perfecto
Tomado de (3)
Lo cierto es que la perfección no va a ser posible alcanzarla debido a:
Tomado de (3)
variaciones en
lo que es solicitado
las variaciones en el proceso de lo que es solicitado
cuándo es solicitado
y la cantidad solicitada
Por lo que siempre estaremos rondando lo que se llama "Frontera de la Eficiencia"
Para llegar a esa frontera, tanto la literatura como la experiencia nos recomiendan
Identificar si estas en el estado de Islas Eficientes o Desperdiciolandia (por lo general estas allí)
buscar primero la eficiencia de flujo
y luego la eficiencia de utilización
Tomado de (3)
Para esto debes de valerte de:
Gestión visual del trabajo
Crear ambientes de colaboración
Tener una cultura de experimentación y aprendizaje (Toyota Kata (12) puede ser una gran herramienta en este escenario)
Visión Sistémica
Una cultura con seguridad sicológica en la que no exista temor a fallar
Una obsesión por la mejora continua (Kaizen)
Adaptado de (11)
Te invito a ver el siguiente video imperdible de Henrik Kniberg @HenrikKniberg, donde podrás ver el paradigma Lean, en donde se prioriza la generación de valor sobre la "utilización de los recursos" (pongo paréntesis pues constantemente los gestores denominan a sus colaboradores como "recursos", término que termina más destruyendo que ayudando, ver referencia (13)).
El perfil "T" ayuda a lo anterior
Imagina que tu trabajo fuera solo operativo y te dedicaras a hacer lo
mismo en una hamburguesería: picar tomates, si picas tomates y estas al 100% dedicado a esa tarea (podemos decir que estas siendo 100% eficiente en tu tarea), pero solo
el 60% de los tomates que picas son usados y el resto se echan a la basura pues no hubo hamburguesas a ser consumidas (solo el 60% de tu trabajo agregó valor). Similar a esto ocurre en un equipo donde todos son especialistas: los desarrolladores no pueden estar 100% desarrollando, los tester 100% probando o haciendo casos de prueba, y de igual forma con frontend, backend, automatización, etc., se generará desperdicio, y el flujo de valor estará limitado a la capacidad más pequeña, en el caso de la imagen inferior, en el "Caso 1" corresponderá al especialista 2.
Explicación de mayor flujo de valor con Perfil "T"
Pero si en vez de tener especialistas, existen generalistas (o perfiles T -ver más en (15)-) que son más expertos en unas áreas y en otras tienen suficiente conocimiento y experiencia para apoyar de forma valiosa, el flujo se aumenta, pues todos van a ayudar a los generalistas 2 y 4, como se observa en el "Caso 2" de la imagen superior.
Nota: La práctica de Pair Programming de XP (17), ayuda en la distribución de conocimiento y en asegurar la calidad de lo que se construye.
Cerrando
Muchas de las prácticas de Lean parecen un contrasentido, pero al aplicarlas permiten a las organizaciones, a los equipos y a las personas alcanzar estados de alto desempeño, generación de valor con menor esfuerzo, por lo tanto, cierro este largo artículo con una serie de recomendaciones:
Tu trabajo como gestor no es micromanejar a las personas o equipos para que estén al 100% ocupados, tu trabajo es
poner un objetivo, proveer los recursos para lograrlo, limitar el WIP, y maximizar el flujo.
Prioriza la eficiencia de flujo
Prioriza el aprendizaje continuo
Luego prioriza la utilización del recurso tiempo
Toma métricas y sigue experimentando
No satures a las personas o a los equipos de trabajo
Planea por debajo del 100% de la utilización crea un ambiente de
innovación, colaboración y que permite aceptar la variabilidad
Te sugiero realizar una asignación de una persona o equipo del 70% al 80% para lograr altos índices de generación de valor y fluencia
Si va a existir sobreesfuerzo que sea por corto tiempo y acordado con el equipo (14)
Reduzca el tamaño de lote o elementos del backlog
para:reducir la variabilidad e
incrementar la predictibilidad
ahora que comprendes como maximizar el flujo, la pregunta es:
¿En qué cosas de valor vas a poner a trabajar a tus equipos de
desarrollo de productos?
Hoy quiero compartirles la traducción de la imagen del inicio, la cual
encontré en el sitio de ScrumInc(1) de Jeff Sutherland - Cocreador del Marco
de Scrum -.
¿Cómo lograr que las cosas queden hechas (Done)? Primero las primeras
cosas (First Things First) - No encontré la referencia, al parecer esta
Deprecated, sugiero revisar esta
High Value First.
Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero
muy resumida.
Muchas veces al hacer una lectura de la misma, no somos conscientes de la
cantidad de información allí depositada, y como nos pasa a muchos, cada vez que
vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros
antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento
para entender lo allí descrito, (me decía mi amiga
Paola Becerra,
el ojo ve lo que es capaz de interpretar).
Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en
formato de mapa mental.
Mapa Mental - Capítulos
Mapa Mental - Capítulos y Subcapítulos
El ejercicio no fue muy estricto desde las recomendaciones para crear mapas
mentales, pero si con miras a ubicar fácilmente conocimiento clave.
Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una
idea de lo extenso del mapa)
De igual forma, he marcado
en color verde y con (*)
el texto relevante o las perlas ocultas a mis ojos del pasado.
Descárgalo y Úsalo
A continuación, pongo a su disposición varios formatos de descarga y
visualización
Descargar PDF - aquí (es el más sugerido debido al tamaño, debes descargar y abrir desde
un navegador web, como: Chrome, Edge, o Firefox, etc)
Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar del lider (recomiendo ver (1)).
El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe
"Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)
Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:
Equipo en Formación - Conversación tipo: Comando y Control
"-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
Equipo en Conflicto - Conversación tipo: Persuación
"- ¿Les parece si revisan el log de transacciones?"
Equipo en Normalización - Conversación tipo: Participación
"-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
Equipo en Desempeño - Conversación tipo: Delegación
"-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?
Respecto a la Caducidad del Scrum Master
Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:
¿El Scrum Master caduca, o deja de ser necesario?
Es como si se afirmara,
como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico
Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación- las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.
Para cerrar te comparto algo que me ha mostrado la experiencia,
En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua
Saludos Ágiles
Jorge Abad
Notas, Referencias, Aclaraciones, Comentarios y Observaciones
Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
Desde hace un tiempo he estado publicando posts bajo la etiqueta "comenzando con scrum", en este post quiero presentarles la forma de leerlos y acercase a ellos para obtener el mejor provecho:
Actividades para activar un equipo el primer día, team canvas y otras técnicas - clic aquí.
Hoy quiero compartirles una agenda de trabajo que pueden emplear el primer día que comienzan con un equipo ya sea tu rol como facilitador, scrum master, gerente ágil o gerente de proyectos.
Primero: Conozcamos nuestros nombres y una comida que no nos gusta
Tiempo máximo : 30 minutos (dependiendo de la cantidad de personas)
En esta parte hago una ronda con el equipo y lo comenzamos por la derecha contestando varias preguntas sencillas
Nombre
Rol o cargo
comida que no nos gusta (he notado que genera mucha empatía este tema), pero se puede reemplazar por:
Película de cine que más le gusto
lugar bonito al que haya ido
última película de cine
un restaurante
etc.
La segunda persona contesta este sencillo esquema y repite el de su compañero de la izquierda junto con la comida con le gusta, la tercera persona lo mismo con sus dos compañeros, hasta que el último (o sea el facilitador) dirá el nombre de todos y la comida que no le gusta.
Segundo: Una actividad de equipo
Tiempo máximo : 60 minutos (dependiendo de la actividad)
Resulta que el equipo aun no es un ser como tal, saben todos que ese es el objetivo pero aun no nace, es un imaginario. entonces en este punto recomiendo realizar un reto de equipo, dentro de este reto de equipo los ponga a trabajar juntos y les de sinergia, dentro de estos retos pueden estar los siguientes:
Construir una torre con un trozo de cinta, spaguettis, un metro de hilo y en la punta un masmellow - (clic aquí para ver el video)
Tercero: Un nombre y una imagen
Tiempo máximo : 30 minutos
Habiendo interactuado juntos, la idea es que cada uno se dibuje dentro de un pliego de papel y busquen un nombre para el equipo, esta actividad les da identidad, pertenencia y los ubica en un mismo espacio.
Cuarto: Personal Maps o Mapas Personales
Tiempo máximo : 45 minutos
Luego cada uno de los integrantes del equipo debe realizar un mapa personal (o elaborarlo entrevistado por un compañero) y lo presenta el equipo, esta actividad ayuda a mejorar las interacciones y a entender que no somos roles, ni cargos, somos personas que tienen una vida, metas y aspectos muy variados fuera de la zona de interacción, y permite mejorar la forma como vamos a trabajar.
He notado en la vida que pequeñas acciones generan gran impacto, y hoy quiero compartirles algo que cumple estas características, que habilita la generación de equipo (1) entre quienes regularmente son compañeros de trabajo o integrantes de un grupo, esta sencilla herramienta son los Mapas Personales - o Personal Maps -(2), técnica en la cual empleamos un mapa mental para contar quienes somos (3). Este mapa mental se construye poniendo nuestro nombre en el centro y alrededor se complementa con diferentes aspectos que son detallados según se requiera, estos aspectos pueden ser.
Educación
Familia
Trabajo
Valores
Objetivos - metas
Hobbies
Casa
Amigos
Tres momentos importantes de la vida (4)
entre otros
Realizando este sencillo mapa todos sabrán mejor quienes somos y nos ayudará acortar la transición entre ser compañeros de trabajo a un verdadero equipo.
Mapa Personal / Personal Map - Elaborado para el Taller de Energizando Equipos con Técnicas de Management 3.0 (5)
Sugiero que el Mapa Personal se elabore cuando estamos comenzando a crear un equipo de trabajo, y para su construcción sugiero dos técnicas:
Cada cual elabora su mapa y lo explica a sus compañeros
Elaboración 10 minutos
Explicación 20 minutos (suponiendo un equipo máximo de 10 personas, tal vez tome más o menos tiempo dependiendo de la cantidad de integrantes)
Otro elabora y explica mi mapa
Las personas que van a conformar el nuevo equipo se dividen en parejas
cada pareja se entrevista mutuamente, elabora el mapa de su compañero (tiempo 10 minutos)
Cada persona explica el mapa de su compañero a todo el equipo (tiempo aproximado 20 minutos)
Luego estos mapas se pegan en la pared para que estén disponibles para todos y de esa manera se ayuda a mejorar las interacciones pues comprendemos que detrás de cada uno hay una vida, un otro, y no solo un cargo o rol con el cual interactuar.
Bienvenido el feedback y los resultados de esta experiencia
Saludos ágiles
Jorge Abad
Notas, aclaraciones, comentarios y referencias
Esta técnica la conocí gracias a mi gran amigo Lucho Salazar - @LuchoSalazarC, agilista y apasionado por el Management 3.0 - lugar de donde viene esta técnica - .
"Un gran poder conlleva una gran responsabilidad", le decía el tío Ben a Spiderman, y la verdad, es de los primeros mensajes que se debe dar a un equipo cuando se les habla de autooganización
Muchos team members (miembros de equipo en Scrum) malinterpretan el término y lo consideran una declaración de anarquía que implica que ya no deben cumplir su contrato laboral, con expresiones como:
"Como soy autogestionado no tengo que avisar a nadie a que horas entro o salgo de trabajar", considerando que tienen una jornada laboral contratada de 8 ó 9 horas (según el contrato laboral (¡¡¡PLOP!!! - caso real -)
"Trabajaré haciendo lo que mejor pueda, aunque pueda dar más no lo voy a hacer"
"Como soy autogestionado, puedo dedicar todo el tiempo que desee a facebook o whatsapp"
"Salgo a hacer una vuelta y no tengo por que avisarle a nadie"
"Aunque todos llegan a las 8 am para el daily, la verdad a mi eso no me aporta llegaré todos los días a las 9 am y no estaré en el daily por qué eso no me aporta" (¡¡¡RE_PLOP!!! - caso real -)
"Ya hice mi parte y la pasé al equipo de Quality Assurance"
Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado"
Cuando inflo las estimaciones en el planning para trabajar con "muy buena holgura"
acerca como el equipo determina como responder al ambiente (a los objetivos planteados)
y los líderes y gerentes influencian el ambiente
La autogestión es mas orientada a ser capaces de gestionar el trabajo en progreso y monitorear el progreso, y en un nivel superior cuando el equipo es autoorganizado (cuando el equipo es más maduro) ser capaces de diseñar el equipo y su contexto, como lo muestra la siguiente imagen:
tomada de[2]:
Entre tantas cosas he descubierto que un equipo es autogestionado cuando
Son dueños del sprint backlog durante el sprint.
Deciden cual es la mejor estrategia para consumir el sprint backlog durante el sprint.
Honran los compromisos y la palabra dada en el planning y utilizan el timebox del sprint lo más productivo posible, y en caso de que se termine el sprint backlog pedir al PO más ítemes
Si me comprometí con mi equipo a hacer una cantidad de puntos, a no dejar tirado a mi equipo con el compromiso
Dan visibilidad de los impedimentos
Ponen todo el empeño para que en la jornada laboral se cumpla el compromiso y en caso de observar que no se va a cumplir dar visibilidad de las razones que ocasionaron que no se cumpliera
Gestionan el progreso durante el sprint tanto en el kanban, burdown chart o cualquier herramienta de gestión y/o gestión visual
Sus team members cumplen con el contrato laboral (la verdad es lo mínimo, pero hay personas que es necesario explicárselo)
Y es allí donde el papel del Scrum Master toma importancia pues guía al equipo y a los respectivos team members a entender el concepto, a hacerles entender la responsabilidad que tienen y el poder que tienen en sus manos. De manera que están cambiando el micro-seguimiento o RC [3], por la libertad de dar visibilidad del progreso y de potencializar la interacción con sus compañeros generando verdadero trabajo de equipo.
Yo creo en el agilismo, lo he visto funcionar, pero siempre que comienzo con un equipo scrum es de los primeros mensajes que doy, pues libertad no significa libertinaje, y agilismo no significa que no te enfoques responsable y maduramente en cumplir los compromisos que adquieres al principio de cada ciclo o sprint.
Termino como empecé, parafraseando un poco
"Team Member ser autogestionado es un gran poder, y un gran poder conlleva una gran responsabilidad"
Saludos ágiles
Jorge Abad
Referencias
Hay algunos pensamientos extractados en el hashtag de twitter #LesaAgilidad (sería genial que aportaras algunos que consideres)
Tienes tu taco de post-it en la mano -por lo general - y estas ahí como su Scrum Master (1), su coach, ellos saben y esperan que acompañados por ti se encuentre la mejora, y que realices en la retrospectiva las labores de líder jardinero (8):
se corten hojas y ramas
se limpien otras
se abonen algunas raíces
se fumiguen algunas plagas
y se remueva la tierra
Para que el equipo siga creciendo en el siguiente ciclo de forma constante, continua y saludable.
Y comienzas a hablarles...
Todo esto es tensión y emoción es el momento donde agregas más valor tangible para el equipo.
Y es por eso que lo llamo RITO, pues debe ser visualizado, preparado para que los participantes reciban el efecto esperado.
Yo, por mi parte comienzo más o menos, con las siguientes palabras:
--
"Bueno señoras, señores, señoritas... muchachos..
por favor soltemos celulares, vamos a realizar bien esta reunión.
Terminó un sprint, observo que nos fue de tal y tal forma
tantos puntos comprometidos,
tantos puntos logrados,
tuvimos tales y tales incidencias de calidad (mejoramos o disminuimos en calidad)
el feedback del producto fue tal
Vamos a entrar en la retrospectiva y el objeto acá no es encontrar culpables, pero si es entender qué pasó, qué podemos entender para que en el siguiente ciclo corrijamos y mejoremos..
Recordemos los 4 acuerdos (7): ser impecable en las palabras, dar siempre lo mejor, no tomarse nada personal y no hacer suposiciones.
El derrotero que vamos a seguir es más o menos el siguiente
entender cómo se sienten después del sprint (armar el escenario)
cuales fueron los hechos que tuvimos en este sprint (recolectar datos)
puntos
bugs
cumplimiento de compromisos
cumplimiento (o no) de mejoras identificadas en retrospectivas pasadas (en caso de que esta sea al menos la segunda retrospectiva)
entender que sucedió (generar un entendimiento profundo de lo que pasó)
proponer posibles pasos a seguir (decidir que hacer - empleando pensamiento divergente)
priorizar la mejora (pensamiento convergente - máximo 3 cosas a mejorar en el siguiente ciclo)
mirar como llevar estas mejoras a acciones concretas,
ejemplo: no solo decir mejorar la comunicación sino como mejorarla, es decir ¿creando un grupo de whatsapp para X situaciones?
Unas veces digo más otras menos- según las circunstancias- pero siempre comienzo mi retrospectivas con un pequeño discurso que "setea"/configura los ánimos, busca bajar los egos y disponer el espíritu para el proceso de mejora continua del equipo.
Este paso que yo hacia a mi modo - y que considero indispensable, siempre que se inicia una retrospectiva, ya sea con un equipo nuevo o no - , fue una sorpresa para mi encontrarlo corregido y aumentado por Tobias Mayer en su libro "Por un Scrum Popular" - clic aquí -, se le llama La Directiva Principal de las Retrospectivas (The Prime Directive) y existen muchas versiones:
English: Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.(4)
Español:Independientemente de lo que descubramos, debemos entender y creer de verdad que todo el mundo hace el mejor trabajo que él o ella podría, dado lo que se sabía en ese momento, sus habilidades y capacidades, los recursos disponibles y la situación actual.(5)
(Esta es la versión inicial)
English: We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones? We don’t always do our best. So let’s get real. (6)
Español: Somos seres emocionales y vulnerables, sujeto a un flujo continuo de influencias de cantidad innumerable de fuentes. A veces nos desempeñamos magníficamente, otras veces nos equivocamos. Mayormente estamos en algún lugar entre estos dos extremos. En este último período de trabajo todos hicieron lo que hicieron, y probablemente tenían razones para hacerlo. Aceptemos lo que es. Y ahora, ¿qué podemos aprender de nuestras acciones pasadas y qué podemos pensar para orientarnos en el futuro? No siempre hacemos nuestro mejor esfuerzo. Así que seamos realistas (6)
(Propuesta por Tobias Mayer)
y si seguimos buscando, podemos encontrar varias polémicas al respecto
Pero más allá de eso, siempre comienzo mis retrospectivas (o retros como les digo) con un pequeño discurso, igual o no, - no importa -, es el momento de aprender y avanzar, de empujarnos a ser mejores y para esto las mentes y los corazones deben estar dispuestos y un bálsamo para el alma y el espíritu siempre es bienvenido.
Saludos ágiles y hasta la próxima
Jorge Abad
Notas, aclaraciones y referencias
(1) En español se podría decir: Maestro del Scrum, Amo del Scrum, Experto del Scrum
