Buscar en Gazafatonario IT

domingo, diciembre 12, 2021

El traje ágil del CEO

Ilustración de la edición del cuento de Combel Editorial

En mi artículo Lo que no les enseñan a los CEO sobre agilidad afirmo que no existen las condiciones “correctas” o apropiadas para la agilidad y que ninguna empresa está preparada para cambiar su forma de hacer las cosas. Y más adelante defino como natural que a los CEO y a toda la alta gerencia de la organización los asalten muchos miedos durante los procesos de transformación, especialmente hacia la forma ágil de trabajar.

Esta vez hablaré de algo que normalmente se esconde bajo la alfombra de las compañías tradicionalistas, pero que se grita a voces llenas en los pasillos, en los cafés y en los chats virtuales de las mismas: todos dicen ser ágiles, dicen que piensan como agilistas, que se comportan como agilistas, pero en el fondo no lo son. Algunos saben que no lo son, otros no saben que no lo son, pero aún hay otros que ni siquiera saben de qué se trata la agilidad.

Con todos ellos tenemos un compromiso. Pero lo peor es que no son capaces de hacerlo vox populi, mucho menos ante la media o alta dirección de la empresa.  No son capaces de adoptar una posición de responsabilidad y expresar los hechos tal y como son. Son muchas las razones de este comportamiento, pero la mayoría giran en torno a que en la empresa hay una cultura de miedo arraigada, una cultura de castigo, de represión de ideas, del “siempre lo hemos hecho así”, de “usted nunca tiene la razón”, una cultura de competencia entre líderes, el “yo tengo más poder que tú” y similares.

Es por ello por lo que a estas organizaciones comúnmente llegan consultores que aprovechan la situación y se invisten de un halo de sabiduría y voluptuosidad para ofrecer recetas de cambio cultural a diestra y siniestra, sin ningún análisis previo del contexto actual, sin ningún reconocimiento del problema, mucho menos del problema detrás del problema, de la causa raíz, del porqué la organización debe o debería hacer las cosas de otra forma.

Aquí es donde entra la alegoría del cuentista Hans Andersen que me sirvió como detonante para esta reflexión:

los hermanos Farabutto engatusaron al emperador para que les permitiera confeccionar un traje con una tela mágica. Los ladinos certificaron que era un traje tan singular que era invisible para cualquier persona que fuera estúpida o incapaz para ejercer su cargo. El mismo emperador, temeroso de ser considerado indigno, enviaba a sus sirvientes a revisar el trabajo de los acomodados modistos. Pero todos ellos y el resto de sus súbditos simulaban ver un traje que no existía. Nadie quería parecer idiota. Finalmente, el día del desfile, el emperador y todos afirmaban a mansalva que el traje era una realidad deslumbrante. Sin embargo, un niño simplemente gritó: “¡Está desnudo!”. A partir de ese momento, todos “vieron” la verdad.

Así ocurre con la agilidad. Muchos pueden seguir actuando como si estuvieran vestidos con trajes lujosos y hasta mágicos, o tener el coraje para decir la verdad y aceptar que están desnudos. En particular, muchos CEO, como el emperador, van desnudos de agilidad por los pasillos organizacionales porque nadie es tan intrépido como para decirles que no saben de qué se trata la transformación ágil ni mucho menos están preparados para cambiar su forma de hacer las cosas.

Es un hecho, la transformación ágil no la realizan las consultoras. Estas, apenas están ahí para acompañar el proceso. No permitas artificiosos hermanos Farabutto, ni internos ni mucho menos externos a la compañía. Propicia una cultura auténtica y fuerte basada en valores. Una cultura donde estos valores no solo se definan, sino que se contextualicen, se experimenten y se protejan.

Por ejemplo, uno de los valores de Spotify es la Sinceridad. "No tenemos tiempo para la política interna. Lideramos con transparencia y nos comprometemos con la mente abierta. Crear algo nuevo requiere confianza, por lo que la retroalimentación sincera entregada con buenas intenciones está en el corazón de todo lo que hacemos". [1]

Por su parte, Netflix contrata y promueve personas que demuestren, a manera de comportamientos y habilidades, entre otros valores, el Coraje: [2]

·       Dices lo que piensas, cuando es lo mejor para Netflix, incluso si es incómodo

·       Tomas decisiones difíciles sin agonizar

·       Tomas riesgos inteligentes y estás abierto a posibles fallas

·       Cuestionas acciones incompatibles con nuestros valores

·       Eres capaz de ser vulnerable, en busca de la verdad

Mientras tanto, uno de los valores de LinkedIn es ser abierto, honesto y constructivo. “Nos esforzamos por comunicarnos claramente y compartir comentarios útiles” [3]. Cuando los valores son claros hay una predisposición manifiesta hacia los buenos comportamientos y una mejor cultura. Algunos de los beneficios directos que este entorno seguro trae incluyen que las personas no experimentan ninguna incomodidad o miedo a plantear problemas, sugerir soluciones, realizar experimentos, cometer errores y procesar diferencias, entre muchos otros.

La desnudez ágil no tiene que ser un tabú. El compromiso al que me refería antes, de nosotros como agentes de cambio, es hacer que las personas sean conscientes de que no saben y acompañarlos en la difícil tarea de conocer lo nuevo, sin entrar en batalla con lo antiguo, aunque invitándolos a desaprender y a desarraigarse de las conductas vigentes. Sobre todo, a quienes hacen parte de la alta dirección quienes, en su mayoría, se mantienen alejados de los intentos de cambio profundo de la organización.

Las cosas así, que sea esta la última vez que el emperador CEO camina desnudo de agilidad por los corredores de la empresa.

 

Referencias

Lo que no les enseñan a los CEO sobre agilidad

[1] https://www.lifeatspotify.com/being-here/the-band-manifesto

[2] https://jobs.netflix.com/culture

[3] https://careers.linkedin.com/culture-and-values

lunes, noviembre 29, 2021

La temible milla extra


Bien pude nombrar a este artículo como “En qué momento se jo$#ó el mundo laboral
”, pero no quise llamar mucho la atención. Y es que esta así denominada característica del universo de la gestión organizacional “milla extra” se ha convertido en uno de los atributos más reconocidos del oscurantismo profesional en el que vivimos durante el siglo XX y parte de este nuevo milenio.

Tengo un interés significativo en el comportamiento humano, sobre todo en lo que tiene que ver con el trabajo colaborativo, el logro de objetivos, la alineación y la autogestión y la motivación laboral. En cualquier equipo, hay miembros influenciadores y, con frecuencia, observo a una persona en particular impulsando la consecución de resultados en el equipo. Estos seres extraordinarios son ejemplo de liderazgo, de servicio, de inspiración. Son ellos quienes dan esa “milla extra” que tanto anhelan las empresas, porque su comportamiento positivo impacta la dinámica y el desempeño de sus equipos y de la organización en general.

Sin embargo, la gran mayoría de las veces, estos individuos se encuentran en el otro lado de la fuerza, disfrazando o enmascarando su tipo de liderazgo e influencia. En mi experiencia, esta milla extra derivó en prácticas representativas de lo que me gusta llamar “la cultura del sacrificio”:

Extender el horario laboral hasta altas horas de la noche y los fines de semana.

Irse de la oficina más tarde que el jefe.

Salir a las 11 de la noche con el compromiso de regresar a las 6 de la mañana del día siguiente, no sin antes, cargarte de papelería y equipo portátil para “trabajar” hasta las 2 o 3 de la mañana.

No tener tiempo ni para ir al baño, mucho menos para tomar un almuerzo decente.

Estar impedido de asistir a las reuniones del colegio de los hijos debido a la fuerte carga laboral.

Asistir a reuniones, pero estar pendiente de otros temas durante esta e, incluso, trabajar en otras cosas mientras transcurre el evento.

Acumular tiempo de vacaciones, no tomar vacaciones o suspenderlas abruptamente debido a algo urgente en la oficina.

Excusarse por programar vacaciones con anticipación y decir que durante las vacaciones vas a estar atento a cualquier cosa que necesite tu equipo u otra persona de la empresa, que te pueden contactar en cualquier momento: incluso dejas nota con los teléfonos y formas de contacto de los familiares o amigos con quienes pasarás tus vacaciones.

Decir que la única manera de “ver”, de comunicarte con tus hijos y familiares es vía celular

Practicar y fomentar la cultura de “envié el correo el día de ayer”, cuando en realidad lo enviaste a medianoche y querer respuestas y soluciones muy temprano en la mañana.

No “molestar” a tus superiores con problemas, en cambio, siempre llevarles soluciones.

Exigir resultados a tu equipo, simplemente con la visión de que esto los garantiza.

Trabajar bajo presión y con mucho estrés.

Ir a trabajar o hacerlo desde la casa cuando estás enfermo, es decir, cuando tienes descanso médico o te encuentras incapacitado por algún motivo de salud.

Y una extensa enumeración de propiedades que harían incansable esta publicación. En breve, la milla extra no es elegir cualquier camino y seguir caminando y marchando para salir del país de las “maravillas”. No se trata de dar más “horas nalga” a tu empresa solo para que vean lo “comprometido” que estás.

Así que mejor veamos un poco lo queremos decir por “milla extra” y por personas que la practican y la promueven de una manera genuina.

La milla extra es:

Trabajar por una misión superior, por un propósito más allá de los intereses de las personas y de los equipos.

Exhibir comportamientos basados en valores y principios. Es decir, participar de equipos y organizaciones donde los valores sean el eje principal de convivencia y donde estos valores se definan, se demuestren, se demanden y se deleguen en conjunto, por todos los miembros del equipo.

Trabajar de manera colaborativa, aprovechando la inteligencia colectiva de los miembros del equipo.

Ambientar el escenario organizacional con comportamientos de seguridad sicológica, donde las personas se sientan protegidas y extraordinarias y con la plena convicción de que pueden dar lo mejor de sí mismas en beneficio de la empresa, de los clientes, pero también de los equipos y de ellas mismas.

Trabajar en pares, aprendiendo uno del otro y el otro del uno.

Liderar con el ejemplo.

Trabajar con una cultura de mejora continua, donde no tengas que pedirle permiso a nadie para mejorar.

Trabajar en un entorno con alto alineamiento, vía propósitos claros y precisos, pero también con un alto nivel de autonomía, con objetivos intermedios bien definidos y alcanzables en periodos cortos de tiempo.

Fomentar una cultura de "entrenamiento sin acompañamiento es una irresponsabilidad". Una cultura donde el mentoring sea algo común y corriente y no un plato especial que se prepara de vez en cuando, solo cuando sea posible contratar a un experto de fuera de la ciudad o del país.

Aumentar la cantidad de experimentos por unidad de tiempo. Abrir los espacios de aprendizaje y de innovación a todo el mundo en la organización.

Vivir bajo una cultura de comunicación a mansalva, cara a cara, donde el coraje, la confianza y el respeto se erigen como valores y pilares para el trabajo diario y para el logro de los objetivos propuestos.

Si eres un “líder de la milla extra”, es porque eres capaz de convertir la ansiedad de los miembros de tu equipo y de cualquier otra persona de la organización, en confianza en sí mismos y en los demás, y en aliento para ir más allá de los objetivos empresariales e impactar la forma de vida de los clientes y de todos en el ecosistema organizacional.

Y, por supuesto, muchísimas cosas más. Pero, como dije antes, no quiero hacer infinito este panegírico. Mejor te invito a que explores muchos de los artículos que he publicado en la última década en este mismo Gazafatonario.

Apostilla

Si tú y otras personas se sienten forzadas a gastar tiempo y energía en protegerse de los demás en la organización, eso la debilitará de una manera tal que será presa del entorno, muy pronto sufrirá consecuencias dramáticas y quizás desaparezca para siempre.

La ausencia de seguridad sicológica es como un cáncer: invisible, silencioso, mortal.

martes, noviembre 23, 2021

Scrumming the Scrum

Imagen de ar130405 en Pixabay
Acordemos esto de una vez: contrario a lo que muchos creen y hacen, las tareas más importantes durante un sprint deben ser las de tareas “Kaizen” o de mejoramiento continuo. Ahora bien, está claro que el objetivo del equipo en cada sprint es entregar valor, esto es, un incremento de producto con valor para el entorno bien sea el usuario, el cliente o consumidor, los interesados, los patrocinadores y, en general, el ecosistema organizacional. No perdamos eso de vista.

Pero muchos piensan que esto es lo único que se debe hacer durante un sprint. Es muy común llegar una retrospectiva y encontrar que las acciones de mejora definidas en la retrospectiva anterior e, incluso, en unas más antiguas no se han empezado a implementar o a adoptar. Las razones van desde el clásico “nos consumió el día a día”, hasta el “las tareas no se priorizaron”, “apareció algo más urgente”, “no tuvimos tiempo”, “tenemos mucho trabajo”, “eso no es urgente”, etcétera.

Es un círculo vicioso: no mejoramos porque no tenemos tiempo y no tenemos tiempo porque no mejoramos. Como siempre, hay que empezar por cambiar esa mentalidad, más que adicionar un proceso que las personas y los equipos necesitan aprender. La mejora continua no aumenta la carga de trabajo, no son más procesos ni herramientas, no se trata de más tiempo “improductivo”. Lo crítico es aprender a integrarla en nuestro trabajo diario.

El Kaizen es una forma de pensar y de hacer las cosas, no algo adicional por hacer. En la práctica, no son tareas para realizar los miércoles a las 9 de la noche o los domingos a las tres de la tarde, cuando se supone que ya “estamos al día” en las tareas habituales de la empresa. No. El kaizen hay que incluirlo como parte del valor que estamos produciendo para la organización. Es de esta manera cómo en el mediano y en el largo plazos seremos más productivos, más innovadores, avanzaremos más que la competencia, cubriremos las necesidades de nuestros clientes y nos adelantaremos a otras exigencias o problemas que tengan, seremos más creativos y disruptivos y podremos transformar no solo nuestra organización sino también el mercadeo que la rodea.

La lista de beneficios que obtenemos cuando adoptamos una mentalidad de mejoramiento continuo puede ser infinitita:

·       Personas más comprometidas y con tendencia a una menor rotación en la empresa

·       ¡Personas más felices!

·       Mejor servicio al cliente. No se nos olvide que estamos en la era de la hiperpersonalización de productos y servicios.

·       Productos y servicios más competitivos

·       Tener una cultura de aprendizaje proactiva

·       Operaciones más eficientes

·       Mayor productividad

·       Tiempos de entrega más cortos

·       Tasas de error más bajas

·       Mayor calidad

·       Mayor innovación

·       Costos más bajos

·       Mayor rentabilidad

·       Mejor ambiente de trabajo

·       Cambio de comportamientos hacia una cultura de colaboración y de innovación

·       Mejor experiencia del cliente

·       Mayor reputación de marca

Y un largo etcétera exponencial.

Hasta allí bien. ¿Y cómo lo hacemos?

Entra Scrumming the Scrum

Una de las múltiples formas de lograrlo, muy práctica por demás, es usar el patrón Scrumming the Scrum. Algo así como “aplícale Scrum a tu Scrum”, en el sentido de “mejora tu Scrum”. Si te ocurre lo que mencioné antes de “no tengo tiempo para mejorar” o de “no trabajamos en las acciones de mejora definidas en la anterior retrospectiva”, entonces este puede ser un buen comienzo.

Es simple: usa Scrum como una mejora del proceso. Es decir, aprovecha Scrum para cumplir o lograr tu visión de kaizen. Para ello necesitas tener retrospectivas efectivas. Como siempre, lo mejor de las retrospectivas ocurre una vez que estas finalizan, cuando empiezas a implementar las acciones que definiste con tu equipo para mejorar.

En la práctica te vas a enfrentar a situaciones como:

·       Bajo desempeño del equipo,

·       incapacidad de detectar y eliminar impedimentos,

·       poca o ninguna generación de Valor,

·       multitarea.

·       Estrés ocasionado por todo lo anterior. Y esto último es el inicio de una serie de eventos desafortunados que conducen a la mala calidad y, peor aún, a la desmotivación y al detrimento de la salud y de la energía de las personas del equipo.

Créeme, no quieres que nada de esto ocurra a tu alrededor. He estado allí, no se lo recomiendo a nadie.

1.    Empieza por realizar un análisis de cómo te fue a ti y a tu equipo en el último sprint en cuanto a personas y sus interacciones, procesos, herramientas y Definición de Terminado, entre otros aspectos. Esto es clásico en toda retrospectiva efectiva.

Siempre viene bien un análisis de causa raíz. Los cinco porqués son un buen instrumento para lograrlo. Pero también está el diagrama de espina de pescado de causa y efecto, también conocido como diagrama de Ishikawa. El método de las 5W + 2H también viene bien en estos casos. Incluso un diagrama de Árbol de causa – efecto, o la técnica de Pareto, en el que el 80 % del problema proviene del 20 % de las causas y El 80 % de las causas restantes solo afectó al 20 % del problema.

2.    Una vez establecida la causa raíz, usa algún tipo de técnica colaborativa para idear soluciones: tormenta de ideas y votación simple, voto de confianza, conversaciones poderosas o estructuras liberadoras, entre algunas otras. El objetivo es que, de una lista de acciones, iniciativas o experimentos, selecciones con tu equipo las que vayan mejor para la ocasión. Una matriz de Esfuerzo versus Impacto siempre viene bien en estos casos.

Advertencia: esto de encontrar la causa raíz y seleccionar la de máxima prioridad se convierte en un imperativo, es algo exigente, no subvalores la forma cómo lo haces. Si trabajas bien en esto y luego implementas la acción de mejora subyacente, verás un incremento inmediato en la productividad del equipo. Al contrario, si esto último no sucede, es que tú y tu equipo no están haciendo una exploración apropiada de lo que está sucediendo, no están usando una visión holística y por ello siguen sin entender ni encontrar la verdadera causa raíz del problema. Las cosas así, hazte acompañar de alguien con experiencia. 

3.    Selecciona una y sola una de las acciones de mejora de la lista anterior. De hecho, “un paso a la vez” es ya una acción de mejora en sí. Como dicen por allí, “el que mucho abarca, poco aprieta”. Puedes promover la práctica de iniciar con una de las acciones que requieren menor esfuerzo y que sean de alto impacto o valor para el equipo y la organización.

Advertencia: a estas alturas siempre estamos hacia el final de la retrospectiva, entonces tienden a presentarse algunas disfunciones como que dedicamos muy poco tiempo a pensar en cuál debería ser esa acción y tratamos de salir rápido con una votación simple sin mayor análisis del impacto que pueda tener. Si eres facilitador de equipos, Scrum Master, coach o mentor, trata de no promover estas “salidas” por la vía rápida.

Recomendación: considera representar o escribir la acción de mejora como una historia de usuario, sobre todo, con criterios de aceptación o con una lista de comportamientos o aspectos visibles una vez que la acción esté implementada o se haya adoptado por el grupo. He usado la técnica de hypothesis-driven development para escribir “historias de usuario kaizen” con muy buen resultado.

Por ejemplo, si uno de los problemas tuvo como causa raíz la falta de conocimiento y experiencia en el uso de historias de usuario como protocolo de comunicación dentro del equipo y con los usuarios o interesados, la historia de usuario de la imagen anterior nos ayuda con una hipótesis de valor: si asistimos a un curso de historias de usuario, obtendremos un resultado de valor; sabremos que la hipótesis es cierta cuando veamos la señal (medible) expuesta luego de la misma.

4.    En la siguiente Sprint Planning, haz visible esta acción Kaizen en el Sprint Backlog. Con el equipo, sitúa las actividades derivadas de la acción de mejora al inicio de la lista o en la cima de la pila de tareas.

Como siempre, ninguna de las tareas es la tarea de una persona, el sprint backlog es propiedad del equipo en pleno y las tareas kaizen no son la excepción.

5.    Como siempre, aunque quizás estas tareas kaizen no están orientadas hacia el logro del objetivo del sprint, merecen un apartado especial en la Daily Scrum. Así, el equipo completo revisa también cómo van hacia esa meta especial.

6.    Finalmente, junto al incremento de valor que inspeccionas en la Sprint Review, presenta los resultados sobre esta acción de mejora. A los invitados a la sesión seguramente les interesará saber que el equipo está mejorando gradualmente, paso a paso.

7.    Cualquiera que fuere el resultado de la implementación o adopción de la acción kaizen, analízalo en la siguiente retrospectiva. Lo ideal es que haya habido, al menos, un avance importante hacia la ejecución completa de la acción. Si no es así, considera revisar las prioridades del equipo y vuelve a empezar.

Para concluir

Es un hecho: vivimos en una era de cambios. Si tú y tu organización se encasillan en lo que saben y en lo que siempre les ha funcionado, muy pronto se quedarán atrás. Adoptar una mentalidad de mejora continua hará que tu equipo y tu empresa giren hacia una trayectoria diferente y más exitosa.


Para saber más de patrones

Para conocer más de patrones Scrum, puedes ver esta presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

En particular, para saber más del patrón Scrumming the Scrum, puedes mirar esta otra presentación:

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.

viernes, noviembre 12, 2021

illegitimus non-interruptus

Imagen de Christine Schmidt en Pixabay

Dentro de lo más común en los escenarios de alta incertidumbre, ambigüedad y volatilidad en los que trabajamos están las interrupciones a nuestro trabajo diario. Mal manejadas, estas obstrucciones se pueden convertir en un gran dolor de cabeza para la persona, para el equipo y para la organización y, por consiguiente, para el cliente final.

Entre otras consecuencias no menos graves, tenemos la pérdida de foco en lo que hacemos, con la consiguiente parálisis o alejamiento del objetivo del sprint. Además, el estrés ocasionado por las intermisiones puede llegar a ser contraproducente para la salud del producto, pero, más crítico aún, para la salud de las personas.

Algunas investigaciones [1] muestran que la multitarea ocasionada, entre otras cosas, por las interrupciones frecuentes en el trabajo, te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento. Adicionalmente, la multitarea puede reducir la velocidad o el ritmo de un equipo tanto como a nada.

Fui desarrollador de software durante diecisiete años y sé bien que la multitarea siempre ha sido una parte inherente del desarrollo de software y la experimenté como la principal fuente de interrupciones debido al cambio continuo de tareas en los equipos de desarrollo de software.

Este trabajo implicaba para mí una combinación de tareas analíticas y creativas, y requería de una carga significativa en mi “memoria de trabajo” y en la toma de decisiones. Esto imponía una carga cognitiva que me hacía perder el enfoque y la concentración mientras trabajaba, lo que afectaba mi productividad. Perentorio.

Los invito a visitar este enlace, donde podrán ver de manera gráfica y cómica a la vez, por qué no deberías interrumpir a un programador cuando está haciendo su tarea:

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

Pero estas dificultades no son propias solo del desarrollo de software. Como mencioné antes, todo trabajo bajo escenarios VUCA/BANI está supeditado a tener tales aprietos. ¿Entonces, qué hacer con estas interrupciones si son inherentes a nuestro trabajo?

Si estamos usando Scrum, las demandas de distintas áreas, combinadas con la interferencia de la gerencia, pueden causar una disfunción crónica en el equipo, fallas repetidas en sprints, incumplimiento en fechas de lanzamiento e incluso fallas en la empresa. Muchas veces un equipo Scrum sirve a muchos interesados, quienes compiten por la atención del equipo.

Patrones Scrum

En Scrum hemos aprendido a usar patrones, estos son modelos de comportamiento que nos ayudan a solucionar problemas comunes. Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esta solución un millón de veces, sin hacerlo dos veces de la misma manera. O algo así nos enseñó Christopher Alexander en su libro A Pattern Language. Alexander es conocido como el “padre de los patrones”. Para conocer un poco más sobre esto puedes ver mi presentación en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Un patrón nos ayuda a explorar:

·       El problema, su naturaleza, la causa raíz. El problema detrás del problema.

·       Las fuerzas que interactúan que afectan el problema (que lo hacen difícil), incomprensible a veces.

·       La solución. Y por qué funciona esta solución. En qué condiciones funciona. Y

·       El contexto resultante de aplicarlo en un escenario de la vida real.

illegitimus non-interruptus

A veces también llamado el patrón del búfer de interrupción (Interrupt Buffer). Es un hecho, cambiar las prioridades o los problemas en el campo a menudo interrumpe el trabajo de los equipos Scrum durante un sprint.

En general, un equipo Scrum es un equipo o recurso comunitario que satisface las necesidades de muchas partes interesadas. Además, es un recurso crítico para crear nuevos productos y mantener productos existentes [2]. A menudo, la propiedad deficiente del producto permite que las prioridades en competencia de una empresa lleguen a un equipo Scrum. Por estas y muchas otras razones, un equipo Scrum siempre está expuesto a interrupciones que obstaculizan la producción.

Figura 2: principales tipos de interrupción a un equipo

Dada esa situación, lo que hacemos, siguiendo los lineamientos de este patrón es asignar explícitamente tiempo para las interrupciones y no permitimos más trabajo del que cabe dentro de la asignación. Ahora bien, si el trabajo excede la asignación (se desborda el búfer), podemos tomar la decisión de abortar el Sprint. Si el búfer se excede, es posible que tengamos un problema mayúsculo, uno cuya solución seguramente necesite del uso de otros patrones o de cambios en la estrategia actual de trabajo. Una estrategia inicial que se aplica en estos casos es cancelar o abortar el sprint.

Veamos esta solución con un poco más de detalle…

1.    Lo primero es tener una idea aproximada de cuanto esfuerzo o tiempo necesitamos asignar al búfer. O sea, decidir el tamaño del búfer de interrupción en el sprint backlog. Una revisión tipo “Clima de ayer” nos puede dar una idea. Es decir, revisar qué tanto esfuerzo han requerido las interrupciones en el sprint anterior o quizás un promedio de los últimos tres sprints.

En la figura a continuación vemos, como ejemplo, que el búfer de interrupción se ha movido alrededor de los 7 puntos, tanto en el sprint anterior, como en los tres últimos. De hecho, la gráfica muestra un comportamiento similar en los últimos 7 sprints, pero esto es apenas una casualidad. Quizás se trate de un equipo con una alta sinergia y que tiene un histórico bastante bien conocido. Sin embargo, no es tan bueno considerar lo que ha pasado durante tiempos más extensos, más allá de dos o tres sprints, ya que las condiciones del equipo y del trabajo pueden haber cambiado de manera considerable.

Figura 3: gráfico de la velocidad del equipo en los últimos sprints. Incluye búfer de interrupción.

Entonces, aunque la velocidad del equipo, según la gráfica histórica, es de alrededor de 27 puntos (usando también el promedio de los tres últimos sprints), el equipo solo se comprometerá con 20 puntos de historia y considerará un tamaño de búfer de 7 puntos.

2.    ¿Y entonces qué hacemos cuando se presenta una interrupción? Respuesta: todas las solicitudes no triviales deben pasar por el Product Owner para su clasificación. Es importante esto de lo “no trivial”. No se trata de que el Product Owner “apruebe” todas las actividades no planeadas para el sprint. Pero sí las que sabemos que pueden impactar en negativo el recorrido hacia el objetivo del sprint.

Figura 4: comportamiento del búfer de interrupción en el sprint backlog.

3.    De manera natural vamos “midiendo” y evaluando el “llenado” del búfer de interrupción. Es una actividad que debe inyectarse al ADN del equipo, para que se haya sin mayores atribulaciones. Cuando el búfer se “llene” y comience a desbordarse, es decir, el Product Owner o el equipo pone un punto de más de los indicados en el búfer, el Scrum Team debe o debería abortar el Sprint, no sin antes, hacer el análisis de causa en una retrospectiva.

Lo que hemos comprobado es que esta estrategia ayudará al equipo a volver a planificar durante el Sprint para aumentar las posibilidades de entregar el Incremento completo del producto. Ya por lineamiento de Scrum habíamos aprendido que, durante el sprint, “el alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más”.

Recomendaciones

En la práctica, el búfer de interrupción puede ser un porcentaje de tiempo. Por ejemplo, el 7 % del tiempo del sprint, el 10 %, el 14 %, etcétera.

¿Cuánto tiempo? ¿Cuál es el tamaño ideal del búfer de interrupción? Esa es una cuestión cuya respuesta debe encontrar el equipo. Para considerar: el objetivo de todo equipo Scrum es entregar valor (un incremento de valor) al final de cada sprint.  Entonces, el foco del equipo debe estar en este aspecto: la entrega de valor. Pero, incluso más importante, son las tareas o actividades “kaizen”, sí, esas de mejoramiento, a las que también hay que dedicarles tiempo y esfuerzo y con una prioridad máxima.

En general, debería ser el Dueño del Producto quien equilibre el tamaño del búfer para no descompensar la satisfacción del cliente en el corto plazo y mucho menos disminuir la generación de ingresos para la organización. El objetivo de todo Product Owner virtuoso es mantener con el equipo un tamaño de búfer tal que no se impacte en negativo la entrega de valor.

Y no, las tareas de mejora continua (kaizen) no son consideradas como “de interrupción”. De hecho, estas actividades deben planificadas como las de mayor prioridad dentro de un sprint. De lo contrario, ¿cómo aseguramos que el equipo mejore en el mediano y largo plazo? ¿Cómo aseguramos que en el futuro las cosas se hagan mejor y haya tiempo para innovar o ser más disruptivos? (Ver en la imagen donde están estas tareas en el Sprint Backlog).

Lo ideal es que el búfer de interrupción tienda a no estar lleno, lo que permitirá que el equipo termine temprano y avance desde el trabajo atrasado o trabaje para eliminar los impedimentos. Y esto es primordial porque los equipos que terminan temprano aceleran más rápido. Este es otro patrón Scrum cuya información, por ahora, puedes revisar en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Finalmente, si el equipo usa el patrón el Clima de Ayer para dimensionar el búfer de interrupción, como lo expliqué en el paso 1, entonces el búfer casi nunca se llena y podemos empezar a pensar en reducir gradualmente su tamaño, lo que hará desaparecer el problema de interrupción. Aunque en la práctica, quizás nunca llegue a cero. Es lo que he experimentado.

Algunas 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] Ver definición de Producto en la guía de Scrum.

 

Para conocer más de patrones Scrum, puedes ver esta presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

En particular, para saber más del patrón Illegitimus non interruptus, puedes mirar esta otra presentación:

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.

domingo, julio 25, 2021

Qué hay de "usuario" en las historias de usuario



Estamos en la era de la hiperpersonalización de productos y servicios, cada usuario, cada consumidor quiere tener su propia experiencia de consumo, de uso, de aplicación y eso ocurre a cualquier nivel, en cualquier escenario.

Entonces nos toca proporcionar productos y servicios altamente direccionados, envolventes y únicos para nuestros usuarios. Y esto comienza con cada componente del producto haciendo resonancia con los demás, para que el producto en pleno pueda ser percibido como único por sus consumidores. Esta es la manera cómo construyes relaciones más fuertes con tus clientes y usuarios.

En mi primer curso de ingeniería de software en la universidad, hace ya varias décadas aprendí algo que todavía hoy sigue vigente, pero cuya práctica se extravió en pro del seguimiento rígido a los procesos y metodologías que vinieron después: “mira al usuario en acción”. Qué hace, cómo lo hace, con quién intercambia información, qué información intercambia, a quién beneficia, qué problemas resuelve, cuáles son sus principales vicisitudes, entre otras, son algunas de las cuestiones que debes indagar para conocerlo mejor.

El apellido “de usuario” no es gratuito en las historias de usuario. Para empezar, concentrarte primero en el usuario, antes de en cualquier otra cosa de su historia, te permitirá trabajar en una estrategia de producto hacia esa hiperpersonalización exigida por los consumidores actuales para que tengan su experiencia diferenciada.

Para lograrlo tienes que practicar y fomentar una cultura de “el cliente sentado en la mesa”, pero también de ir a verlo actuando en el gemba*, el suyo, para que puedas entender a fondo sus necesidades y los escenarios en los que se desenvuelve día tras día. Es de esta forma cómo podrás:

·       Conocer su problema, incluso el problema detrás del problema, la causa raíz;

·       Identificar sus canales de comunicación preferidos;

·       Emplear un lenguaje más apropiado a sus características;

·       Generar las hipótesis de cómo el producto puede favorecerlo en la resolución de problemas;

·       De qué forma se podría arruinar su experiencia como usuario o consumidor.

Entre muchos otros aspectos de su cotidianidad.

En mi User Story Conversation Canvas ya mencionaba que el primer paso en la construcción de productos grandiosos es identificar y entender a los consumidores y usuarios. Son actividades basadas en entrevistas, observación e investigación. Hay personas que son primarias al producto o a la historia de usuario en particular, otras son secundarias e incluso otras son suplementarias.

Figura 1: Un ejemplo de User Story Conversation Canvas para la historia de usuario “acceder primero a los libros de mi interés”. Clic en la figura para ampliar.

Entre las primeras encontramos a los usuarios finales de la historia de usuario o a los consumidores del producto. Encargados como un Product Owner o un Product Manager primero, y luego el equipo de trabajo, deben conocer muy bien el perfil de estas personas, los matices 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 para seres humanos. Quienes estamos comprometidos en esta tarea debemos sentir que conocemos al usuario, tener empatía con el usuario.

Las personas “secundarias” son quienes tienen algo que decir acerca de la historia de usuario (o del producto o servicio) pero que no lo usan. Pueden ser quienes lo adquieren, quienes imponen una restricción o una regulación, quienes harán la instalación o el mantenimiento, quienes venderán o distribuirán el producto a los usuarios, entre otras. Y las personas “suplementarias” son todas aquellas que de una u otra forma están o se sienten involucradas con la historia de usuario, como patrocinadores del proyecto, la dirección de la organización, representantes de los usuarios y otros interesados.

En resumen, algunos tipos de personas para tener en cuenta en y para la conversación son:

1.     Personas

2.     Usuarios o Consumidores finales

3.     Interesados

4.     Patrocinadores

5.     Equipo de desarrollo

6.     Otros (Legales, externos, etcétera)

7.     Equipo de soporte, Mercadeo, Distribución, Logística, etcétera.

Cuando observamos, entendemos y acordamos entre todos cómo las personas usan o usarán el producto, estaremos en capacidad de:

·      Planificar la accesibilidad al producto desde el principio

·      Desarrollar más rápidamente soluciones de accesibilidad

·      Tomar decisiones informadas entre diferentes opciones y evitar perder el tiempo adivinando o suponiendo o lanzando hipótesis que solo serán eso, hipótesis, hasta tanto el producto no esté en manos de quienes lo van a consumir o a usar

·      Limitar el tener que volver atrás y solucionar problemas, es decir, elaborar el producto correcto desde el principio, no generar desperdicio. Esto es más de pensamiento Lean.

·      Evitar tener que hacer concesiones más tarde porque esperamos demasiado para para conocer mejor al usuario y para abordar las características relevantes del producto.

·      Tener una mejor perspectiva sobre los estándares de uso, las pautas y otros requisitos, que es posible que deba cumplir ahora o más adelante, por ejemplo, si el producto será de uso gubernamental o debe cumplir con ciertas regulaciones.

Todo esto beneficia al equipo de trabajo, incluyendo Product Owner si lo hay, a la media y alta dirección de las organizaciones y a cualquier otro interesado en el desarrollo y puesta en marcha del producto.

User Personas

No en vano, Personas es el primer componente del lienzo para conversar sobre la historia de usuario. Ya desde antes existía este otro instrumento en el que podemos registrar lo que observemos y aprendamos del usuario en acción: se trata del User Persona o simplemente Persona.

Figura 2: un ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

En este, podemos registrar aspectos como los de la figura 2:

·      Objetivos del usuario, esto es, las metas que quiere alcanzar o que queremos que alcance en el mediano y largo plazo con el producto

·      Barreras o problemas actuales y posibles problemas futuros

·      Puntos de dolor o necesidades

·      Comportamientos o hábitos del usuario

Y no está demás conocer algunos detalles demográficos y hasta personales del usuario en cuestión, además de ciertos aspectos biográficos que ayuden a conocerlo y, sobre todo, a entenderlo mejor, a ser más empático con esa persona. Incluso, si es alguien conocido, un colaborador de la empresa, bien podemos traer su fotografía y usar sus datos reales, y hasta un lema o declaración de vida, su distintivo o consigna.

Figura 3: otro ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

Otros aspectos que bien podrían servir son:

·      Su experiencia ideal

·      La tecnología que usa o las fuentes de información a las que accede habitualmente

·      Por qué quiere usar nuestro producto, de hecho, este aspecto es crucial, deberíamos empezar por allí.

·      Respuestas a la pregunta: ¿qué arruinaría su experiencia usando el producto?

Recomendación final

No me andaré por las ramas: nunca intentes, ni lo sueñes siquiera, empezar a implementar o a desarrollar una historia de usuario de un producto si no conoces quien la usará y por qué. Perentorio.

Conclusión

Involucrar y conocer a los usuarios en las primerísimas etapas del descubrimiento del producto y más tarde, durante el propio desarrollo de este, da como resultado mejores productos para los consumidores, un desarrollo más eficiente y otros beneficios para los interesados y, por supuesto, para los mismos usuarios o clientes.

Y tú, qué haces para conocer a tu usuario. Por favor, déjamelo saber en el foro.

 

Quieres saber más

* Gemba |現場|' es un término japonés que significa "en el sitio de acción" o en la “escena del crimen". En negocios, Gemba se refiere al lugar donde se crea "valor"; en fabricación Gemba es el piso de la fábrica y en ventas es el área de ventas o el lugar donde el proveedor de servicios interactúa directamente con el cliente.1

Más sobre el User Story Canvas en:

El libro Historias de usuario: una visión pragmática:

https://luchosalazar.com/portfolio/historias-de-usuario-una-vision-pragmatica/

O en:

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

Más sobre historias de usuario en:

bit.ly/lashistoriasdelucho

Y en octubre, una nueva edición del curso User Stories FoundationCertificatedonde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario.

Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!


Créditos

Imagen de la portada por Gerd Altmann en Pixabay.