9 + 1 acciones que debes empezar a realizar para ser un Scrum Master extraordinario

Photo by Parabol on Unsplash

Nivel: principiante. Para todo público.

Presentación

Como coach y consultor ágil, y antes Scrum Master, durante más de una década he acompañado y colaborado con muchos equipos en diferentes industrias. Hace poco publiqué con mi gran amigo Jorge Abad el libro Scrum:epítome de experiencias, que resume en 338 páginas muchos de los experimentos que realizamos y de las lecciones que aprendimos durante todo este tiempo. Espero que el libro llegue a tus manos en algún momento. Mientras tanto, en mi Gazafatonario seguiré compartiendo más de todo esto, incluyendo algunas de las cosas que me han sorprendido en el camino.

1.    Entender el rol y las responsabilidades de Scrum Master

Como Scrum Master, eres responsable del proceso Scrum. También eres responsable de brindar retroalimentación de calidad al equipo y eliminar impedimentos.

Una forma efectiva de pensar en esto es que tu trabajo como Scrum Master no es solo asegurarse de que todos estén haciendo su propio trabajo correctamente, sino también asegurarse de que sepan cómo hacerlo mejor, para que ya no te necesiten. O, al menos, dar esa impresión. En la práctica, un equipo, por muy maduro que sea, siempre necesitará de un Scrum Master extraordinario.

2.   El enfoque principal del Scrum Master es el empoderamiento del equipo, no la gestión de proyectos

•     No eres un director de proyectos. Un Scrum Master no es un administrador de proyectos; eres el coach del equipo. Como tal, tu enfoque principal debe ser ayudar al equipo a ser autoorganizado y multifuncional, eliminando los impedimentos para el progreso (en lugar de resolverlos todos).

•     Tu trabajo no es solo desarrollo. De hecho, si bien la organización para la que trabajas puede tener un rol de Product Owner establecido que administra los requisitos y libera valor en cada Sprint, no solo lo estarás acompañando durante toda la gesta como Scrum Master. Además, pasarás la mayor parte de tu tiempo trabajando directamente con todos los miembros del equipo de trabajo, empoderándolos, para ayudarlos a comprender lo que significa hacer el trabajo con un marco de desarrollo serializado de productos como Scrum (y por qué es importante) para que se sientan capacitados para tomar decisiones sobre la mejor manera de lograr los objetivos propuestos.

•     Necesitas que todos participen para que este enfoque funcione bien para todos los involucrados. Hay muchos beneficios asociados con mantener equipos lo suficientemente pequeños, por ejemplo, que todos sus miembros puedan tener cierta superposición en las habilidades propias de cada uno, es decir, que el equipo se convierta en uno multifuncional. También, cuando alguien que carece de experiencia necesita la ayuda de otra persona pero no sabe qué preguntas debe hacer primero antes de iniciar cualquier tipo de comunicación entre ellos, la sinergia existente en un equipo pequeño hace que esa comunicación comience a ser más fluida. Además, un Scrum Master extraordinario puede ayudar a que las personas del equipo se relacionen mejor entre sí sin necesidad de forzar algún tipo de conversación artificial.

3.   El Scrum Master guía al equipo para que se organice a sí mismo

Eres el verdadero líder del equipo, el guardián del proceso y el que ayuda a tu equipo a autoorganizarse y autogestionarse. También facilitas la colaboración en equipo, la comunicación clara y el progreso hacia los objetivos del sprint con la ayuda de los artefactos de Scrum.

El Scrum Master sirve como coach para el equipo al garantizar que sus miembros trabajen de acuerdo con la teoría Scrum (por ejemplo, sin multitarea), ayudándolos a prevenir y resolver impedimentos (por ejemplo, deuda técnica) y manteniéndolos enfocados en sus objetivos a través de revisiones periódicas y retrospectivas.

4.   El trabajo del Scrum Master es eliminar los impedimentos, no resolverlos todos

Un Scrum Master extraordinario es un solucionador de problemas y, en general, es una persona analítica. Los mejores pueden ayudar a los equipos a eliminar sus propios impedimentos y a autoorganizarse para que puedan proporcionar valor continuamente. Es importante no confundir el rol del Scrum Master con el de un gerente de proyecto, quien es responsable del resultado de un proyecto en lugar de simplemente facilitarlo. Un Scrum Master extraordinario debe ser hábil para eliminar impedimentos, ¡no para resolverlos todos!

5.   El Scrum Master entiende que no existe tal cosa como "la mejor manera"

El Scrum Master entiende que no existe tal cosa como "la mejor manera". El proceso debe adaptarse al equipo y su entorno. Para adaptarse, él o ella debe ser capaz de aprender cosas nuevas.

Esto significa que no todos los Scrum Masters son iguales. Algunos son mejores en ciertas cosas que en otras. ¡Está bien! Es parte de lo que nos hace a todos tazas de café especiales.

En cualquier caso, el Scrum Master se aleja y aleja a su equipo de quienes vienen con “la mejor manera de hacer esto es…”.

6.   El Scrum Master entiende que cada organización es diferente y necesita un enfoque diferente

El Scrum Master entiende que cada organización es diferente y, por lo tanto, requiere un enfoque distinto. Por ejemplo, si una organización es muy jerárquica y burocrática, la Scrum Master deberá trabajar con la gerencia de la organización para hacerla más ágil. Esto significa ayudarlos a comprender cómo pueden ser más efectivos mediante la adopción de prácticas de Scrum y otras prácticas ágiles, como la eliminación de impedimentos y la mejora de procesos para que el equipo pueda organizarse por sí mismo. Si la organización no tiene demasiadas reglas o regulaciones, entonces podría ser más fácil para el Equipo Scrum autoorganizarse sin necesidad de mucha ayuda de su Scrum Master.

7.   El Scrum Master entiende la importancia de sumergirse en la cultura Ágil a través de aprendizaje, capacitación y experimentación

La cultura ágil es una mentalidad, no solo un conjunto de procesos. Es importante comprender que la cultura ágil no es algo que se pueda aprender en un día. Se necesita tiempo, capacitación y experimentación para convertirse en parte de esta nueva forma de trabajar.

El Scrum Master entiende que la cultura ágil se trata de la mejora continua y no de seguir reglas.

8.   El Scrum Master sabe adaptarse rápidamente a las nuevas circunstancias y cambios en el entorno

El Scrum Master sabe que es un líder servicial y se esfuerza constantemente por crear un entorno en el que el equipo pueda volverse más productivo. El Scrum Master entiende que el éxito depende de tener un equipo motivado y de alto rendimiento, por lo que es responsable de eliminar todo lo que se interponga en el camino del éxito de su equipo.

El papel de un líder servicial es permitir que otros crezcan y tengan éxito. Cuando tu trabajo como Scrum Master está bien hecho, será difícil para ti identificar exactamente cuál ha sido tu contribución porque has estado trabajando entre bastidores para asegurarte de que todos los demás tengan lo que necesitan para hacer su trabajo de manera efectiva.

Como parte de esta dedicación para capacitar a otros, es importante no solo saber cómo, sino también cuándo es el momento de recibir alguna retroalimentación u orientación de asesoramiento o tutoría relacionados con el cumplimiento de los principios o procesos ágiles (también conocido como facilitación).

9.   El Scrum Master entiende que el objetivo de cualquier equipo maduro debe ser la mejora continua

•     Como Scrum Master, debes comprender que el objetivo de cualquier equipo maduro debe ser la mejora continua. El marco de trabajo Scrum está diseñado para ayudar a las organizaciones a lograr este objetivo al alentar a las personas y los equipos a mejorar constantemente sus prácticas de trabajo a través de ciclos de retroalimentación rápidos y cambios pequeños e incrementales.

•     Este concepto se llama Kaizen en la comunidad Lean y Mejora Continua en Ágil. También se conoce como "aprendizaje organizacional" en algunos círculos, porque requiere lecciones regulares de experiencias pasadas, tanto buenas como malas, para que puedan aplicarse para mejorar los resultados futuros o evitar problemas similares en el futuro (en lugar de simplemente arreglar las cosas cuando se rompen).

9 + 1. No tengas miedo de salir de tu zona. ¡Una nueva aventura podría estar a la vuelta de la esquina!

Entonces, eres un Scrum Master y asistes al curso de capacitación para obtener la tan anhelada certificación. Aprendes muchas cosas nuevas sobre Scrum y cómo puedes ayudar a las organizaciones de todo el mundo. El entrenamiento es divertido, pero notas que falta una cosa en tu vida: ¡emoción!

Empiezas a pensar en cómo podrías conseguir algo de aventura en tu vida. ¿Irás a una aventura al aire libre con amigos o familiares y les enseñarás cómo hacer cosas como escalar rocas, saltar de un puente elevado o navegar en kayak? Esto se sentirá como estar de vacaciones porque estás fuera del trabajo por un par de días, pero luego, cuando regreses a casa, ¡podrías tener más energía que antes! ¿Y si esta nueva forma de vivir puede traer alegría a tu vida? ¡Nunca se sabe hasta que se prueba!

Estoy seguro de que sabes que esto es lo que quieres hacer, pero tal vez haya cosas que te detengan. Tal vez has estado trabajando en ti mismo durante años y parece que no puedes progresar. O tal vez eres nuevo en todo esto de "ser un gran líder ágil" y no sabes por dónde empezar. 

Seamos realistas por un segundo: nadie es perfecto. Y el perfeccionismo puede ser paralizante cuando se trata de hacer cualquier cosa, especialmente cuando se trata de ser alguien extraordinario como un Scrum Master o un líder ágil que está listo para asumir cualquier desafío que se presente a continuación.

Inténtalo. Todo gran triunfo empieza con un primer paso. Y dentro de algunas semanas, incluso meses, habrás querido dar ese primer paso hoy mismo.

Conclusión

El Scrum Master es un rol esencial en cualquier organización moderna. El trabajo del Scrum Master es guiar y acompañar a los equipos para que puedan entregar sus productos de manera más efectiva, eficiente y con alta calidad. Eres un líder y los mejores líderes siempre están aprendiendo. Saben que la única forma de liderar verdaderamente es refinando constantemente sus habilidades y ven a su equipo como una plataforma para el crecimiento y el desarrollo.

Como líder, siempre debes trabajar para mejorarte a ti mismo. Nunca debes quedarte quieto y pensar que lo tienes todo resuelto. Siempre habrá más para aprender, así que aprovecha cada oportunidad para ampliar tu base de conocimientos leyendo libros sobre liderazgo, asistiendo a conferencias y seminarios, o realizando programas de capacitación diseñados específicamente para tu función como líder ágil.

Como el próximo curso que facilitaré con Jorge Abad a partir de este 22 de octubre. Encuentras toda la información en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

También te invito a descargar este póster en alta definición con diez cualidades que te pueden ayudar a convertirte en la mejor versión de Scrum Master que puedas llegar a ser:

http://www.gazafatonarioit.com/2017/05/cualidades-de-un-scrum-master.html

De historias de usuario a historias de persona

 Y una forma más de delimitar y hacer pequeñas las historias de usuario

El problema actual

Dividir historias de usuario se ha convertido en un dolor de cabeza para los practicantes ágiles, principalmente para quienes usan esa técnica como motor para describir las necesidades de los usuarios y las características finales de los productos.

Lo voy a decir de otra forma: en mi trasegar diario con equipos y empresas que acompaño en el uso del enfoque y prácticas y marcos de trabajo ágil, he visto que dividir historias de usuario es algo de lo que todos hablan y tratan de practicar, pero les está costando.

Una de las causas de fondo de todo esto es la subvaloración que se le ha dado a la práctica de historias de usuario. Por ser algo tan sencillo, tan liviano, se estudia con poco detalle, de manera superficial y muy rápido. Los practicantes ágiles apenas si le están dedicando algunos minutos con la creencia de que ya conocen todo lo que deben conocer al respecto. Pero no es así. De ser algo tan simple, pasó a ser algo tan poco entendido y muy mal practicado. Quizás pasa lo mismo que con Scrum, liviano y fácil de entender, pero difícil de llegar a dominar.

Voy a ir más a fondo: el problema no es dividir historias de usuario en sí. Es tener historias de usuario lo suficientemente pequeñas, pero de Valor para el negocio y para el usuario, que se puedan elaborar en muy poco tiempo, desde unas pocas horas, hasta dos o tres días máximo, teniendo en cuenta iteraciones cortas de 10 días. Y cuando digo 2 o 3 días como máximo, me refiero a que la historia queda Terminada, cumple con todos los criterios de aceptación y con todas las condiciones de la Definición de Terminado para las historias de usuario individuales.

Entran las historias de persona

Soy Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una transferencia de dinero a mi nieta sin tener que ir al banco. No quiero exponerme a un contagio y ya no tengo fuerzas para esperar de pie haciendo largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.

Quiero hacer la transacción desde mi celular o en el PC de la casa.

Debe ser fácil de realizar porque no soy experta en el uso de estos dispositivos.

Quiero hacerlo de manera segura y rápida. Que no me roben mi platica.

 

Miguel es periodista. Viaja continuamente. Quiere saber cuándo le han consignado sus honorarios y sus gastos de viaje para llevar un control estricto de sus ingresos y gastos.

Miguel quiere recibir información de las consignaciones en su celular, quizás a través de mensajes de texto.

El mensaje debe incluir información sobre el valor de la consignación, el concepto por el cual se hizo y la fecha y hora de esta.

Miguel quiere que nadie más pueda tener acceso a esa información en caso de que se le extravíe el celular.

Aquí hay dos historias de usuario, dos historias, 2 relatos desde el punto de vista muy particular y hasta íntimo de dos personas. Tienen nombre propio, atraviesan vicisitudes específicas, necesidades singulares. Requieren que se cumplan algunas condiciones que consideran valiosas. Estas representan el éxito de su experiencia de cliente usando productos de alguna corporación o empresa. Son historias de persona.

Las historias de persona son concretas, en contraposición a las abstracciones naturales de una historia de usuario que señalan o lidian con, por ejemplo, Amas de Casa, Empleados, Clientes, Jubilados, trabajador autónomo o free lance, entre muchos otros. La misma historia permite conocer qué hace la persona, cómo lo hace, con quien lo hace, qué información intercambia y con quién la intercambia o quién es el receptor de esta. De alguna manera también deja ver sus principales problemas o inconvenientes al hacer lo que hacen. Es como si el equipo de trabajo, incluso los interesados y el mismo Product Owner o Product Manager, lo estuvieran viendo en acción, algo que se ha perdido en las últimas décadas en pro de prácticas que, de distintas manera, impiden el contacto o el acercamiento de quienes hacen productos con los consumidores o usuarios de estos.

Las historias de persona comienzan con la “persona” que originó la necesidad, con nombre y características demográficas únicas. Viene de la práctica User Persona. Esta persona tiene una identidad única y esto delimita el ámbito o el alcance de la historia y, por consiguiente, de la característica del producto que un equipo está forjando. He usado esta técnica en los últimos años y he comprobado que, en general, las historias resultantes son pequeñas, siguen siendo de valor y, efectivamente, se pueden labrar en muy pocas horas o, a lo sumo, en muy pocos días, junto a otras historias en una iteración breve.

Esta es una regla general, por supuesto. Es posible que algunas de estas historias todavía tengan que dividirse aún más para que se puedan trabajar en un sprint corto sin el riesgo visible de que no se puedan terminar junto a las demás.

No es la primera vez que uso el concepto de persona relacionado con las historias de usuario. El primer bloque o nodo de mi User Story Conversation Canvas es sobre las personas. Sobre esto explico que “el equipo debe conocer muy bien el perfil de estas personas, los aspectos personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos y servicios para seres humanos. El equipo debe sentir que conoce al usuario”.

El enigma del “usuario” en la historia de “usuario” y cómo resolverlo

Imagen de OpenClipart-Vectors en Pixabay

No me malentiendan. He escrito lo suficiente sobre historias de usuario, incluso he publicado un libro con mi gran amigo Jorge Abad sobre estos menesteres cuya edición en inglés recientemente fue referenciada por la Agile Alliance. No hay un problema de fondo con el usuario en la historia de usuario. Pero conocer más al usuario sí ayuda.

En general, un “usuario” es un concepto abstracto con cierto nivel de vaguedad que se puede automatizar o categorizar para trabajar con él, pero su uso ha mostrado ser de mucha valía en los negocios y en la industria. Un “usuario” describe actividades y responsabilidades de un grupo de individuos. Escribí ampliamente sobre eso en mi libro Asuntos de la Ingeniería de Software, cuando hacía referencia a los Casos de Uso de Ivar Jacobson y a un elemento fundamental de los casos de uso: el Actor. Y un usuario es precisamente eso, un actor. De hecho, decía en una de mis Lecturas Fundamentales, en noviembre de 2006 que “Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve”, nada diferente de lo que estoy diciendo hoy nuevamente, 16 años después.

Un usuario es un rol que se define a través de una tarea o acción concreta o un grupo de funciones con mucha afinidad, que son ejecutadas por personas durante el consumo de un producto o el uso de un sistema. Sin embargo, los usuarios no son algo tan simple como pueden parecer para el practicante ágil inexperto y aún para muchos expertos. Los usuarios pueden llegar a gozar de una ambigüedad tal que vuelven problemática la obtención de historias de usuario pequeñas y de valor. He revisado conjuntos de historias de usuario donde los usuarios exhiben incompatibilidades entre ellos o donde unos tienen sobrecarga de responsabilidades o donde se presenta cierta tensión entre unos usuarios y otros, además de algunas otras tramas inesperadas.

En particular, la ambigüedad es un aspecto destacado para el diseño de productos porque nos muestra una fotografía de la ausencia de precisión que una persona, sus colegas e incluso todos en la empresa pueden llegar a tener sobre los roles y sus responsabilidades. He dedicado más de dos décadas a estudiar este fenómeno y he tenido experiencia de primera mano cuando de usuarios o consumidores y sus responsabilidades o acciones se trata. Por ejemplo, he leído, debatido y ayudado a mejorar decenas de historias de usuario con usuarios como “cliente”, “visitante”, “abonado”, “cliente potencial”, “interesado” o “solicitante” que dicen muy poco o nada sobre el contexto de uso de la historia de usuario y que obstaculizan de distintas formas la división de una épica en historias más pequeñas y trabajables.

Una de las pocas formas que me ha funcionado para resolver todo esto es que todos los interesados en el producto, es decir, el equipo de producto y el equipo de trabajo en pleno vean al usuario en acción. Hay disponer de la logística necesaria, a lo Ojo del Gran Hermano, para que todas estas personas tengan la oportunidad de ver a sus potenciales usuarios o consumidores trabajando. ¿Qué hacen? ¿Cómo lo hacen? ¿Cuándo? ¿Con quién lo hacen? ¿Qué información intercambian unos con otros y quienes de estos también son usuarios y quienes no? ¿Cuáles son sus principales problemas o las dificultades más frecuentes que impactan su desempeño? ¿Cuáles son los criterios de éxito que tienen en cuenta en su accionar habitual?

Resolver estas cuestiones es de suma importancia antes de pensar en la solución que necesitan estos clientes o consumidores.

De vuelta a las historias de persona

Imagen de Gerd Altmann en Pixabay

Hola, soy Mabel, Gerente de Crédito Hipotecario. Quiero un informe de solicitudes de crédito para realizar proyección de aprovisionamiento y trabajar en las próximas campañas con el área de Marketing.

El informe debe ser diario y debo poder clasificarlo por tipo de crédito, pero también quiero tener un resumen por tipo de crédito y la tendencia respecto a los últimos 5 días.

También quiero clasificarlo por tipo de solicitante y tener un subtotal de lo solicitado por tipo de solicitante.

De manera predeterminada quiero ver el informe del día inmediatamente anterior, pero también quiero tener la posibilidad de ver el informe de una fecha anterior.

He estado usando una ligera variación de la forma Davies-Cohn para representar las historias de persona:

Como [usuario] Quiero [esta característica] Para [lograr este beneficio u objetivo]

que puede llegar a ser innecesariamente prolija y repetitiva, aunque muy fácil de entender y de usar en muchos entornos dada la gran difusión y documentación que ha tenido en las últimas dos décadas.

Pero bien podría usar muchas otras grafías para representar historias de usuario. Por ejemplo, puedo usar las historias de usuario estilo BDD, como en:

Registrar datos personales.

Dado que Ibeth, asesora de prensa de la alcaldía, solicitante de crédito de libre inversión, se mantiene muy ocupada en su día a día y tiene poco tiempo para hacer gestiones de manera presencial, ingresó los datos solicitados y existe al menos un dato sin diligenciar. Cuando ella intente enviar los datos, entonces recibirá un mensaje informándole de los datos sin diligenciar y estos datos aparecerán marcados en rojo y no se podrán almacenar los datos, aunque se le permitirá almacenar los datos de manera temporal si ella así lo prefiere.

En conclusión, hay tantas o más formas para representar historias de persona que para representar historias de usuario. Y una vez más, noten amigos lectores que uso el término “representar” como lo he hecho desde hace años, para alejarme y alejarlos de la limitante y problemática expresión “escribir historias de usuario”. Aquel es más abierto, indica que se pueden usar no solo palabras sino también figuras y simbología de distinto tipo que la mente y la imaginación sean capaces de retener. No sobra decir aquí que lo más importante de las historias de persona también es la conversación que se mantenga alrededor de cada una de ellas.

Las personas son instancias de los usuarios. Son ejemplos. Y los ejemplos te ayudan a encontrar inconsistencias en las historias y porque te delimitan un contexto. Pero sobre todo, los ejemplos son buenos porque te ayudan a iniciar conversaciones.

Y bueno, además del innegable beneficio del tamaño (sucinto, en el sentido de pequeño) de las historias de persona, de su contexto concreto e individualizado, otras ventajas de este instrumento derivado son los siguientes:

·       Ayudan a definir un mejor y más aproximado Producto Mínimo Viable, ya que, por naturaleza, estas historias de persona son mínimas y minimalistas, en el sentido de que son esenciales y eliminan o ayudan a eliminar lo que puede llegar a ser superfluo en el producto, es decir, nos ayudan a eliminar desperdicio, a elaborar el producto correcto desde el comienzo.

·       Las personas son, por naturaleza, colaborativas. Cada una usa o consume un producto de una manera diferente, pero entre todas colaboran para que el consumo o utilización del producto se maximice.

·       Ayudan a que quienes se encargan de exponer los productos a sus usuarios, es decir, aquellos que tienen la difícil pero fascinante labor de brindar la mejor experiencia de usuario y de cliente posible, tengan éxito, dado que las personas se conocen mejor, son más concretas, generan más empatía y puedes imaginarlas con una sonrisa cuando el producto las esté ayudando a lograr sus propios objetivos. Las personas nos permiten conectarnos emocionalmente con ellas, los usuarios abstractos quizás no.

·       Las historias de persona ayudan a iniciar y a mantener conversaciones más fluidas y verosímiles que las historias de usuario. Incluso nos permiten crear otras personas (personajes de la historia) para los eventos alternativos de la historia o para los procesos de manejo de excepciones en esta.

·       Las personas son más imaginables o creíbles o comprensibles que los usuarios porque tienen un rostro y un nombre y una identidad.

Llamado a la acción

Finalmente, te invito a que uses este modelo de historia, de historia de persona. Eso sí, cuéntame y cuéntanos cómo lo podemos extender y practicar mejor. Y no dejes de contactarme con cualquier inquietud que tengas respecto a este o a cualquiera otra inquietud sobre las historias, sean de usuario o de persona.

Aprende Scrum con Lucho Salazar

Scrum es un marco de trabajo liviano e iterativo que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente.

En esta clase en línea aprenderás un poco más sobre el marco de trabajo Scrum para poder aplicarlo mejor en tu entorno de trabajo.

Si quieres saber más sobre Scrum, con mi gran amigo y coautor Jorge Abad estamos pensando en facilitar un nuevo curso de Scrum a finales de octubre o principios de noviembre en Medellín (presencial) y queremos saber si hay interesados. Si te llama la atención, por favor, diligencia este breve formulario para enviarte información.

El costo de hacer multitarea

El costo de hacer multitarea

La gráfica es perentoria. Si estás en dos proyectos o iniciativas puedes perder hasta el 20 % solo por cambio de contexto o cambio (“switcheo”) entre tareas.

Si estás en 3 iniciativas, hasta el 40 %. Es decir, en realidad no estás asignado al 33 % en cada una, sino al 20 %.

De allí, los retrasos en las entregas. Y la mala calidad. Ni hablar de cuando estás en cuatro o cinco proyectos o iniciativas, algo que sigue siendo común en muchas empresas.

Algunos estudios además dicen que si las tareas con complejas, por ejemplo, tareas de desarrollo de software o, en general, trabajo de conocimiento, este tiempo puede ser mayor. Nos movemos en el universo de lo complejo, donde no hay relación directa entre la causa y la consecuencia y solo podemos saber cómo nos fue en retrospectiva.

El verdadero costo de la multitarea

Pero esto es lo que las organizaciones apenas alcanzar a ver, al menos, quienes están cambiando a enfoques ágiles para trabajar.

Sin embargo, el costo más grave, el verdadero costo de no tener foco en lo que se hace, es la salud de las personas. Y de eso casi nunca hay recuperación.

Investigaciones [1] muestran que “la multitarea te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento”.

[*] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

Una investigación realizada en la Universidad de Stanford descubrió que la multitarea es menos productiva que hacer una sola cosa a la vez. Los investigadores también encontraron que las personas que son bombardeadas regularmente con varios flujos de información electrónica no pueden prestar atención, recordar información o cambiar de un trabajo a otro tan bien como aquellos que completan una tarea a la vez. [2]

Pero lo más crítico que mostró esta investigación es que, además de ralentizarte, la multitarea reduce tu coeficiente intelectual. Un estudio de la Universidad de Londres descubrió que los participantes que realizaban varias tareas a la vez durante tareas cognitivas experimentaron disminuciones en la puntuación de coeficiente intelectual similares a las que esperarían si hubieran fumado marihuana o se hubieran quedado despiertos toda la noche. Las caídas del coeficiente intelectual de 15 puntos para los hombres multitarea redujeron sus puntajes al rango promedio de un niño de 8 años. [2]

Incluso se presenta daño cerebral si haces multitarea. Un estudio de la Universidad de Sussex en el Reino Unido encontró que quienes realizan muchas tareas a la vez tenían menos densidad cerebral en la corteza cingulada anterior, una región responsable de la empatía, así como del control cognitivo y emocional.

Y hay más. La neurociencia es clara: estamos programados para ser monotarea. Un estudio encontró que solo el 2.5 % de las personas pueden realizar múltiples tareas de manera efectiva. Y cuando el resto de nosotros intentamos hacer dos actividades complejas simultáneamente, es simplemente una ilusión. [3]

Conclusión

Muchas veces te dicen que eres bueno y que por eso te van a dar más responsabilidad. Otras veces tú mismo lo asumes porque crees que es lo mejor. Pero no. Incluso hacer multitarea con cosas “sencillas” como hacer algo en el trabajo y estar mirando el celular y además hablando con el compañero de al lado en la oficina, puede ser muy dañino para tu salud, en ocasiones, de forma irreversible.

Así es que la próxima vez que estés ante la disyuntiva de estar en dos o más iniciativas a la vez, piénsalo. Y a quienes tienen la responsabilidad de formar y liderar equipos, también tengan en cuenta esta reflexión. El verdadero costo de la multitarea no es la pérdida de productividad, a veces invisible; es una baja substancial en la salud mental y física de las personas multifoco, una disminución que en muchas ocasiones es irrecuperable.

Referencias

[1] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

[2] Multitasking Damages Your Brain And Career, New Studies Suggest.

https://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/?sh=6cbca3956ee6

[3] Why Multitasking Is Bad for You.

https://time.com/4737286/multitasking-mental-health-stress-texting-depression/

 

[Nuevo Libro] Scrum: Epítome de experiencias

 

Prólogo

Con suerte y gracias a tu tenacidad y esmero, ya eres parte de un equipo de producto sólido y dedicado exitoso. Y has ganado cierta experiencia en el camino. Con suerte también estás usando Scrum y otras prácticas agiles que potencian tu trabajo y el de tu equipo. Si es así, este libro es para ti. Pero si no estás ahí, o si estás en algún lugar intermedio entre aquel gran objetivo y ese punto inicial, este libro también es para ti.

Lo que vas a encontrar aquí es un cúmulo de experiencias que hemos aunado a lo largo de más de una década de trabajo con agilidad y que hemos estado escribiendo desde entonces. Al principio, contamos las experiencias como fueron dándose, de una manera natural y hasta espontánea.

Más adelante, aunque siguen siendo nuestras experiencias, resultado de innumerables catas, experimentos, historias y conversaciones, se encuentran una serie de recomendaciones producto de nuestro propio aprendizaje y del aprendizaje de una gran cantidad de personas, equipos y empresas que hemos acompañado a lo largo de más de una década con Scrum y otras prácticas ágiles como historias de usuario, Kanban, Nexus y Scrum@Scale.

El libro tiene cuatro grandes secciones:

Los prolegómenos,

Scrum esencial,

Táctica y estrategia, y

Patrones Scrum y otros energizantes Scrum

Los prolegómenos son una plétora de conceptos y pensamientos base para iniciar conversaciones sobre Scrum. Son conversaciones que luego extendemos en Scrum esencial, donde abordamos los elementos subyacentes del marco de trabajo. A partir de allí, en táctica y estrategia, intentamos poner de manifiesto cómo hemos superado muchos de los escenarios que hemos enfrentado en nuestro propio trabajo, sin que estas se conviertan en la única forma de hacer las cosas.

Hacia el final del libro, en Patrones Scrum y otros energizantes Scrum, detallamos nuestras experiencias más avezadas, muchas de las cuales nos han permitido elevar no solo la productividad de los equipos que acompañamos diariamente, sino también la felicidad de las personas que los conforman. Es precisamente ese “cómo mejorar tu práctica ágil para obtener resultados asombrosos” de la portada.

Si apenas estás iniciando con Scrum o llevas poco tiempo probando el marco de trabajo, empieza con las dos primeras secciones. Si eres un prácticamente Scrum experimentado, seguramente encontrarás en la tercera sección, esas tácticas y estrategias que quizás te ayuden a llevar a tu equipo al siguiente nivel de mejora.

Este libro no reemplaza la guía oficial de Scrum de Sutherland y Schwaber. La lectura de esta debe ser obligatoria y frecuente, porque a medida que experimentamos y aprendemos más, entendemos mejor los lineamientos expresados en ella. El libro intenta más bien dar una serie de respuestas que no se encuentran en la guía debido a su propia naturaleza: es liviana, incompleta y solo presenta algunas pocas reglas del juego.

Mucho de este material ya estaba escrito, sino todo. Hemos revisado cuidadosamente cada capítulo y cada tema de estos, los hemos actualizado, no solo acorde a los nuevos lineamientos de la guía de Scrum, sino de acuerdo con nuestra experiencia. Incluso hemos reescrito algunos de ellos casi en su totalidad.

Parte de este contenido lo escribimos a cuatro manos, por eso nos expresamos como “nosotros”, pero, en general, nos expresamos en primera persona del singular, aun así, todo hace parte de un trabajo colaborativo a lo largo de todos estos años que nos ha permitido comprobar la muy conocida máxima de Aristóteles de “el todo es mayor que la suma de las partes”.

Bien sabemos que la práctica hace la perfección. Nuestro mayor deseo es que este libro empieza a acompañar tu práctica hacia ser mejor un paso a la vez. Disfrútalo.

Jorge Abad y Lucho Salazar

Puedes encontrar el libro en formato Kindle (próximamente en formato impreso) en Amazon:

https://www.amazon.com/dp/B0BB7PW1QL

 

El otro 3-5-3 de Scrum

 Quizás todos conocemos la simbología del 3-5-3 en Scrum:

·       3 Responsabilidades

·       5 Eventos

·       3 Artefactos

No voy a hablar mucho de esto porque a estas alturas hay suficiente ilustración. Sin embargo, si la expresión es nueva para ti, te dejo este infográfico y una referencia en donde puedes encontrar más detalle:

Fuente: https://www.scruminc.com/the-3-5-3-of-scrum/

La traducción y adaptación libre es mía.

Sobre cada uno de estos elementos básicos de Scrum he escrito lo suficiente en mi Gazafatonario como para publicar un libro. Jorge Abad también ha escrito otro tanto que puedes encontrar en sus Lecciones Aprendidas.

De una conversación con nuestro amigo Juan Andrés Ochoa, esta vez llamó mi atención que en Scrum tenemos otro 3-5-3 no menos importante que el anterior, porque se trata precisamente de lo que representa el espíritu ágil de Scrum. Se trata de los 3 pilares, los 5 valores y los 3 compromisos, estos últimos, adicionados en la última edición de la guía oficial, pero que ya estaban presentes en el ámbito del marco de trabajo.

Sobre los tres pilares

La Casa Scrum

Bien sabemos que lo que he dado en llamar “La Casa Scrum” se erige sobre tres pilares fundamentales, que no son más que los pilares de todo proceso empírico: transparencia, inspección y adaptación. Todo proceso empírico requiere de estos tres pilares para que sus practicantes obtengan el mayor beneficio posible de su uso. El empirismo no es más que trabajar basados en hechos o datos, evidencia y experiencia. Un proceso empírico hace que tengamos una gran dependencia del ensayo y el error y, a través de estos, obtenemos aprendizaje validado. De hecho, cuando se practican vehementemente, estos pilares se convierten en elementos clave de la cultura organizacional.

Además de lo que dice la guía de Scrum, he ayudado a muchos equipos y empresas a adoptar estos pilares de muchas formas. Promoviendo que la comunicación entre las personas sea abierta y diáfana, que siempre se aseguren de que los receptores de la información la entiendan y que todos entiendan lo mismo. En este punto juega un papel muy importante La Definición de Terminado, a lo que me referiré más adelante. La transparencia es una mezcla de honestidad y franqueza. Entre otras técnicas, usamos comunicación no violenta y radiadores de información para maximizar la transparencia dentro del equipo y con su entorno. Y, puesto que no todo el mundo está igualmente motivado y tiene el mismo nivel de conocimiento y experiencia, nos aseguramos de que haya una comprensión promedio sobre todos los objetivos a alcanzar, las tareas a realizar y el valor a entregar.

 Con la transparencia sobre el tapete es más simple reflexionar. La inspección se logra analizando precisamente esos datos y hechos y esas evidencias que han surgido de nuestros acciones y experimentos previos. De lo que dicen nuestros propios compañeros de equipo, los interesados, los usuarios o consumidores, y de la forma cómo estos precisamente están consumiendo nuestros productos o servicios. Hacemos análisis de causa raíz usando técnica como los 5 Por qué para asegurarnos de que a continuación encontremos el mejor camino a seguir. Para maximizar la inspección, valoramos inmensamente la perspectiva de cada persona. Como prerrequisito de esto, continuamente promuevo en los equipos que acompaño que se conozcan mejor entre sus integrantes, a veces con preguntas poderosas y profundas, otras veces con cuestiones más divertidas y cándidas, pero que permiten exhibir el verdadero talante de las personas.

Con esta información y con estas causas raíz, nos adaptamos para mejorar. La adaptación constante es esencial. Es lo que nos permite mantener el foco en las necesidades reales del cliente final, en lo que significa valor para la organización en cada momento del tiempo, siempre en la justa medida con los objetivos estratégicos y de negocio de la empresa. Adaptación en mejora implacable. Un paso a la vez. Es lo que nos va a permitir sobrevivir ante la alta incertidumbre, atributo inherente al trabajo que hacen nuestras organizaciones hoy por hoy. Si en el proceso de hacer algo, no mejoramos, nuestro fin llegará muy pronto.

Los beneficios de levantarnos día a día sobre estos tres pilares son a todas luces evidentes, pero hablaré de ellos en otra oportunidad.

Sobre los cinco valores

Valores Scrum. Fuente: Scrum.org

Cada equipo tiene su propio distintivo y temperamento. Así como existe una “cultura organizacional”, en la actualidad no es posible hablar de una “única cultura empresarial”. Cada equipo y cada contexto es diferente, incluso en cada momento del tiempo. Dada esa complejidad, los valores entran a jugar un soporte vital en la forma cómo se comportan, se comprometen y entregan resultados las personas de un equipo y de una organización.

Scrum nos propone empezar con 5 valores esenciales: coraje, foco, compromiso, respeto y franqueza. Y quiero aprovechar justo este momento para señalar que, por el contexto y su descripción, la traducción del valor Openness siempre debió ser Franqueza y no Apertura como estaba antes de la edición de 2020.

Pensemos en estos cinco valores de Scrum como en un sistema de valores, uno que diferencia sentimientos, pensamientos, corrientes ideológicas y comportamientos humanos que consideramos correctos para el equipo Scrum y para la organización. Todas las acciones del equipo giran en torno a estos valores y es con ellos con los que creamos armonía interna y con el mundo exterior al equipo. Además de definirlos, en este caso de adoptarlos, los valores se demuestran, es decir, ayudamos a que los demás los entiendan; los valores se demandan, o sea, cada persona es responsable de que los demás lo cumplan y exigen su cumplimiento; y los valores se difunden a lo largo y ancho del ecosistema empresarial. Es algo que se conoce como las 4 D de la cultura, promovido por Fred Kofman en su modelo de coaching consciente.

Sobre los tres compromisos

Esta es la más reciente “adición” a la guía de Scrum. Aunque, como dije antes, siempre estuvieron en el ámbito del marco de trabajo. Cada uno de estos compromisos está vinculado a un artefacto Scrum:

·       Para el Product Backlog, es el Objetivo de Producto.

·       Para el Sprint Backlog, es el Objetivo del Sprint. Y

·       Para el Increment, es la Definición de Terminado.

Para conocer exactamente qué significa cada compromiso, por favor, lee la guía de Scrum. Estos compromisos fomentan la autonomía, encontrando el balance justo con la alineación. Esta última viene dada precisamente por los tres compromisos. Con el objetivo del producto, tenemos alineación en el largo plazo. Es lo que el equipo quiere lograr una vez el producto alcance un estado de uso masivo, ya sea porque contiene muchas características implementadas o porque lo está usando un gran número de consumidores.

Con el objetivo del sprint logramos alineación en el corto plazo, a medida que el producto nace y crece. A medida que los primeros clientes empiezan a retroalimentar al equipo y aprenden más con el uso preliminar del producto en construcción. También ayuda a que el equipo mantenga el foco en el trabajo de cada sprint y no se distraiga con lo que más tarde podría considerarse desperdicio. Se trata de elaborar el producto correcto desde el principio, pero tenemos que estar preparados para lo inesperado, en este caso, para que algunos usuarios rechacen parte de o todo el producto construido hasta cierta fecha.

La Definición de Terminado, por su parte, fomenta la transparencia. Es esa lista de condiciones, a manera de acuerdos, cuyo cumplimiento nos asegura que el producto cumple con lo que necesitan los clientes. La Definición de Terminado es un instrumento que ayuda al equipo a ahorrar mucho tiempo, sobre todo en el largo plazo, porque disminuye ostensiblemente sesiones de revisión redundantes. Si el producto cumple con la Definición de Terminado, está preparado para ser presentado incluso ante tiburones tipo Shark Tank y en horario triple A. Finalmente, la Definición de Terminado da testimonio de consistencia y de la calidad del producto.

Conclusiones

He visto fallar muchas adopciones de Scrum. Mucho de ello se debe a que queremos usarlo como un mero contenedor de prácticas de todo tipo, olvidando desde los primeros instantes su espíritu ágil.

Así que ya sabes, tienes dos alineaciones 3-5-3 para jugar Scrum. Ninguna es más importante que la otra. Tienes que jugar con ambas si quieres tener éxito. Debes jugar con ambas si no quieres despertarte un día y darte cuenta de que el camino que una vez tomaste no era el correcto.

Y déjame saber en el foro qué haces para vivir el espíritu de Scrum.

 

Monólogo de la Product Owner viendo llover en la organización*

 

El invierno de la agilidad se precipitó un martes al finalizar la reunión diaria. El día anterior había sido sofocante por las continuas solicitudes sin pies ni cabeza de la aún establecida oficina de proyectos o PMO. Pero aún en la mañana del martes no se pensaba que pudieran llover los improperios propios de grupos y seudoequipos de una empresa ámbar, más que de una que se preciaba de estar recorriendo ya el camino ágil hacia convertirse es una corporación verde y luego Teal.

Después de la reunión diaria y antes de que los miembros de los equipos tuvieran tiempo de ir por el café de la mañana, sopló un viento espeso y oscuro en forma de correo electrónico, el mismo que apenas tardó segundos en convertirse en un mensaje viral de chat que barrió en una amplia vuelta redonda los acuerdos y planes que se acababan de concertar para ese día. Alguien dijo junto a mí: “Son los vestigios de la gestión tradicional”. Y yo lo sabía desde antes. Desde antes de empezar la reunión y me sentí estremecida por la viscosa sensación en mi mente.

Los miembros de los equipos corrieron hacia los escritorios más próximos con una mano en la cabeza y los ojos arrugados, como tratando de protegerse de las noticias contradictorias y la polvareda de impedimentos que iban a encontrar en el detalle del correo. El techo de la oficina se cubrió como de una sustancia roja, que nos hizo recordar las épocas en la que los así llamados “líderes” demostraban su poder mediante el uso de la violencia y el acoso laboral, un retroceso abismal de esa utopía que suponía el pensamiento ágil y lean de poner foco en el bienestar de los empleados y la autogestión.

Durante el resto de la mañana, mi Scrum Master y yo estuvimos sentadas junto a mi escritorio, preocupadas por la revitalización de las prácticas de gestión antiguas debido al poco éxito que estaba teniendo la iniciativa de transformación ágil en la organización. Habían sido siete meses de primavera intensa, pero el polvo abrasante de la austeridad había vuelto junto al infame tren de las 2 de la tarde, lleno de los preceptos que habíamos abandonado cuando emprendimos el proceso de cambio cultural.

Entonces rebobiné mis recuerdos. ¿Por qué estábamos fracasando? ¿Por qué nos habíamos estancado ante la vegetación ámbar donde se llegaba a la cúspide empresarial por antigüedad y no habíamos logrado llegar a ese punto donde el empoderamiento estuviera en todos y cada uno de los miembros de la organización? Reviví una conferencia donde mi Scrum Master le preguntó al Agile Coach de turno que “cómo lidiaba con un PO con ínfulas de PM” y de otro Scrum Master que se sumó a la conversación para indagar sobre “qué hacer con un PO que habían nombrado a dedo y de manera inesperada”.

Vivifiqué mis pensamientos de entonces. Quise pensar que mi Scrum Master dijo “lidiar” solo como una forma de decir que quería mejorar su relación con el PO, conmigo, o con cualquier otro. Estaba segura de que lo primero en lo que debería pensar es en que no somos “sujetos de lidia”, como los toros, ni más faltaba. Tampoco se lidia con ninguna otra persona del equipo ni de la organización. Lidiar es un término despectivo que no ayuda a la relación. Al PO, aún con delirios de PM, lo acompañas, le facilitas su vida como PO, lo ayudas en la transición. Paso a paso. Despacio. Con paciencia. Sin importar como haya llegado al equipo. A propósito, casi siempre un PO llega al equipo como dijo el otro Scrum Master: nos ponen allí. El viernes a las 7 de la noche me dijeron que, a partir del siguiente lunes, además de lo que ya hacía, ahora iba a ser PO. Nada raro en una empresa de ambiente rojo, que tuvo su origen en las comunidades más primitivas y que se basaba en la existencia de un líder todo poderoso que ejercía su autoridad a través del miedo.

Tampoco se trataba simplemente de explicarme una sola vez cuales eran mis responsabilidades como Product Owner, o cuales eran las distinciones del enfoque ágil respecto al enfoque tradicional que veníamos abrazando desde siempre, ni de decirme que tome un curso de esto o de lo otro. Es un proceso. Es un camino realmente. En estas situaciones es donde el coaching y la mentoría entran a jugar un papel muy importante, es donde las conversaciones conscientes se vuelven el instrumento principal de mejora. Para mejorar la comunicación conmigo como PO, haciéndome pedidos efectivos, asegurándote de brindarme todo lo que necesito para que cumpla con mis compromisos, pero un paso a la vez.

Tienen que saber, estimados Scrum Masters, que el cambio es algo difícil, es el síndrome del “siempre lo hemos hecho así”. El temor a la falla. Es algo natural. Por ejemplo, enséñame que es distinto “fracasar” que “cometer errores” y que de ambas situaciones puedo aprender. Enséñame a experimentar como PO, a hacer planes es un contexto empírico. En los entornos tradicionales eso es algo que desconocíamos. Enséñame distintas maneras de expresar historias de usuario, entre otras, usando Hypothesis-Driven Development, por aquello de los experimentos. Las posibilidades son muchas, por no decir que infinitas.

Como siempre, el equipo en pleno debe estar comprometido en la gesta. Si el equipo no entrega valor, no produce al menos parte de los resultados que quiero como Product Owner, muy poco o nada de lo anterior nos va a servir. Y una vez más, con paciencia, el cambio de mentalidad no va a suceder pronto. Aún los PO con mentalidad de emprendedores tenemos miedo alguna vez o muchas veces.

No sé cuánto tiempo estuve hundida en aquel sonambulismo en que los sentidos perdieron su valor. Solo sé que después de muchas horas incontables oí una voz en el cubículo vecino. Era una voz fatigada, propia de las personas que han vivido bajo una cultura de sacrificio laboral y andando “millas extras” por doquier, como si el permanecer en la oficina produjera resultados de valor. Era una voz casi de persona convaleciente. Una voz que decía: “Ahora tendremos una retrospectiva”. Esa voz tenía razón, las últimas retrospectivas no habían servido de mucho, ¿por qué esta habría de ser distinta?

Solo entonces me di cuenta de que había llegado la cita a la reunión y de que en torno a nosotros se extendía un silencio, una tranquilidad, una beatitud misteriosa y profunda, un estado imperfecto que debía ser muy parecido a la muerte laboral.

* El título y algunos apartes del artículo están basados en el cuento “Monólogo de Isabel viendo llover en Macondo”, de Gabriel García Márquez.

Crédito de la foto de la portada: Foto de Zinkevych en iStockPhoto https://www.istockphoto.com/es/portfolio/Zinkevych?mediatype=photography