Buscar en Gazafatonario IT

lunes, agosto 22, 2022

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/

 






Ámbito o contexto de las historias de usuario

Haz clic en la imagen para ampliar y descargar en alta definición

Sigo viendo muchas historias de usuario que más bien parecen historias de ficción y hasta de ciencia ficción: el “usuario” de “historia de usuario” no aparece por ninguna parte.

Ahora vengo con esta imagen, a ver si ayuda. ¿Cómo la ven? ¿Qué les dice? Por favor, déjenmelo saber en el foro.

Para saber más sobre el Contexto de las historias de usuario, o de la cuarta C de las historias de usuario, visita:

http://www.gazafatonarioit.com/2019/06/las-historias-de-usuario-se-cuentan-con.html

También, el User Story Conversation Canvas:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html


[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

 

martes, agosto 09, 2022

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.

 

martes, mayo 24, 2022

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