El poder de los equipos pequeños y por qué deberías usarlos para el trabajo complejo

 

Foto de Annie Spratt en Unsplash

Para lograr equipos de alto rendimiento, la comunicación es clave. Esto significa que el equipo debe poder comunicarse de manera efectiva entre sí, así como con su entorno y otros grupos dentro de la empresa. Los equipos Scrum son una excelente manera de lograr esta comunicación, ya que son pequeños y serializados. Esto permite una mejor colaboración y elimina la necesidad de paralelismo, que a menudo puede generar problemas de comunicación.

Los equipos Scrum generalmente se componen hasta de 10 personas, pero bien sabemos que equipos más pequeños se comunican mejor y son más productivos. Es decir, de unos 4 a 6 miembros por equipo es un volumen adecuado para una microentidad de este tipo. Este tamaño permite un entorno de trabajo más íntimo y centrado, lo que ayuda a crear un sentido de propiedad entre el equipo, ya que cada individuo es responsable de sus tareas particulares y puede expresar sus ideas o inquietudes durante los eventos de Scrum. Todo esto, sin llegar al extremo de que cada persona tenga metas individuales o intereses apartados de los demás.

Otra ventaja de los equipos Scrum es que permiten el trabajo serializado. Esto significa que en lugar de tratar de hacer varias cosas a la vez, el equipo puede concentrarse en una tarea a la vez para avanzar de manera eficiente. Esto puede generar menos errores y mejorar la productividad, al tiempo que brinda la oportunidad de aprender nuevas habilidades en el camino.

Además, los equipos Scrum permiten una mejor comunicación entre todos los interesados. Los eventos de Scrum son una excelente manera de garantizar que todos estén en la misma página y que cualquier problema o pregunta se aborde de manera rápida y eficiente. Esto puede ayudar a evitar confusiones, desacuerdos y conflictos dentro del equipo y garantizar que todos trabajen hacia el mismo objetivo.

Así que si eres un Scrum Master extraordinario o quieres llegar a serlo debes asegurarte de que tu pequeño equipo Scrum tenga éxito. Es tu razón de ser. Tu única razón de estar. El resto de tu trabajo es derivativo. Te voy a contar cómo hacerlo:

Primero, cerciórate de que todos los miembros del equipo estén comprometidos con Scrum. Esto significa que están dispuestos a trabajar juntos en colaboración y comunicarse abiertamente entre sí. Aquí es donde entran en juego los valores Scrum de Compromiso y Respeto, entre otros. Pero también es soporte vital que haya un espíritu del juego Scrum, es decir, al usar Scrum, la comunidad de productos de tu organización debe enfocarse en crear explícitamente una cultura donde las personas conozcan y sigan el espíritu de Scrum: empirismo y pensamiento Lean, valores y pilares. todos los que trabajan en o con un Equipo Scrum deben ayudar a desarrollar esa cultura predicando con el ejemplo.

En segundo lugar, es importante tener un objetivo claro y compartido de lo que se quiere lograr como equipo. Esto ayudará a todos a mantenerse enfocados y motivados. Tener una identidad de equipo sirve en estos casos. Y el Team Canvas es una herramienta que te puede asistir para ello. Luego vendrán el Objetivo de Producto y las metas intermedias: el objetivo de cada sprint. Como Scrum Master tienes que lograr que estos elementos sean los motivadores universales de cada miembro del equipo. Trabaja con quien sea necesario (por ejemplo, Talento Humano) para que esta identidad y estos objetivos compartidos se conviertan en el motor de ensueño para cada persona del equipo: no es lo mismo “pegar ladrillos” que estar “construyendo la catedral de Notre Dame”.

También, es importante que les brindes todo el apoyo necesario a los miembros de tu equipo. Esto puede incluir capacitación, recursos físicos y materiales o simplemente tener a alguien disponible para responder preguntas.

Ahora bien, una cosa es el tamaño del equipo y otra el alcance del proyecto o el trabajo que van a realizar. Un equipo más pequeño puede moverse más rápido y ser más ágil, pero también puede tener menos capacidad para tareas complejas. Además, a los equipos más pequeños les puede resultar más difícil establecer funciones y responsabilidades claras. Como resultado, es importante considerar cuidadosamente los desafíos que podría enfrentar un equipo pequeño de Scrum antes de emprender una iniciativa.

Para superar estos desafíos, asegúrate de que todos los miembros del equipo entiendan su función y sean conscientes de las habilidades y destrezas de los demás miembros. Esto se puede hacer a través de comunicaciones y reuniones periódicas. También, establece con ellos expectativas claras para cada miembro del equipo. Y recuérdales constantemente que un equipo pequeño aún puede tener éxito si todos trabajan juntos hacia un objetivo común. Dale a cada persona la oportunidad de contribuir y expresar su opinión. Sé flexible con el proceso del equipo y “pon el empirismo a trabajar”, es decir, abre espacio a la prueba y el error a medida que el equipo encuentra lo que funciona mejor para ellos. Finalmente, mantén una comunicación abierta con el equipo e inspíralos a que este tipo de comunicación sea el modus vivendi y su pasión entre ellos mismos y con su entorno.

¿Te suenan algunas de estas ideas? ¿Algunas otras? Por favor, déjamelo saber en el foro.

Cómo ayudar a tu equipo a mejorar su Daily Scrum

Imagen tomada de Pixabay

La guía de Scrum es cada vez menos prescriptiva para ser más inclusiva, es decir, para que la usen más tipos de personas, de equipos y de organizaciones. Hoy por hoy, Scrum se usa en casi cualquier rincón de la empresa y de la sociedad, entonces es aconsejable que se aleje de lo que la hacía más allegada al mundo del desarrollo de software. Con esto en mente, es importante dejar claro que si un lineamiento o una sugerencia ya no está en la guía no significa que era una mala práctica o algo equivocado. De ninguna manera.

Uno de los ejemplos más visibles de esta situación es el de las famosas y muchas veces poco entendidas “tres preguntas” de la Daily Scrum o reunión diaria. Las tres preguntas pasaron de ser una regla del juego Scrum en versiones previas de la guía, a ser “un ejemplo de lo que podría usarse” (durante la reunión) en la edición de 2017, a desaparecer por completo en la última edición de 2020.

Sin embargo, ello no quiere decir que no puedan seguirse usando para “inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario”, de acuerdo con la guía 2020. En cualquier caso, la conversación o la discusión durante la sesión diaria puede ocurrir de muchas maneras siempre que esta “se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo”.

¿Qué tipo de conversaciones podemos tener para realizar una Daily Scrum efectiva? ¿Qué otras cuestiones podemos abordar durante la sesión para asegurar que conocemos con exactitud en dónde estamos respecto al objetivo del sprint? Empecemos por mejorar el matiz de las preguntas clásicas.

“¿Que hice ayer?” es la pregunta que se harían los miembros de un equipo con una perspectiva estática de lo que hacen o de lo que quieren hacer a continuación. De alguna manera, este tipo de preguntas son estacionarias, aunque las estaciones solo sean de 24 horas.

En cambio, una persona, un equipo o una organización con una perspectiva dinámica bien puede responder a la pregunta: ¿qué hice para garantizar que aprendimos algo nuevo ayer? Esto imprime una energía distinta y más vigorosa a la sesión, a las personas, al ambiente de trabajo, y permite que el equipo practique y promueva una cultura de mejoramiento continuo.

Más allá de esta pregunta, otras cuyas respuestas nos dan una idea más precisa de qué tanto hemos avanzado hacía el logro de la meta propuesta son:

• ¿Qué hicimos ayer que mejoró nuestra eficiencia?
• ¿Qué valor o principio de la empresa, del equipo o de alguna otra índole determinó en gran medida nuestro comportamiento de ayer para avanzar hacia el logro del objetivo del sprint?
• ¿Qué decisiones tomamos ayer que nos permitieron avanzar hacia el logro del objetivo del sprint?
• ¿Qué decisiones tomamos ayer que no nos permitieron avanzar hacia el logro del objetivo del sprint?
• ¿Qué podemos aprender de esto para garantizar que mañana estaremos más cerca de lograr el objetivo del sprint? Las respuestas a esta última consulta derivan en un plan de actividades para el siguiente día hábil de trabajo.

Al hacer este tipo de preguntas todos los días, el equipo empieza gradualmente a desarrollar principios referentes a la forma cómo toma las decisiones, pero también comienza a ver un estándar en la forma cómo se acerca al objetivo del sprint, cada sprint. Las respuestas a estas preguntas guían en términos de cómo y qué elementos deberían ordenar para alcanzar el objetivo propuesto y entregar el valor planificado al negocio.

En medio de este análisis de si el equipo alcanzará el objetivo propuesto, es vital preguntarse por el impacto de las interrupciones causadas por eventos que provienen del entorno:

¿Hay algo en el entorno que está ocasionando distracciones al equipo o a algunos de sus miembros? ¿Es posible evitar esas distracciones?

Ahora bien, los objetivos no se pueden alcanzar a cualquier precio. En particular, no tiene sentido lograr una meta si en el camino dejamos una estela de desperdicio, de trabajo mal elaborado o de desgaste moral y físico de las personas. Aquí surge una pregunta clásica, pero cuyas respuestas pueden dar luz al equipo sobre el estado del avance hacia el logro del objetivo del sprint:

¿Estamos haciendo correctamente el producto correcto?

Finalmente, el objetivo del sprint se define durante la planificación de este, al principio del sprint. Sin embargo, a medida que pasan las horas y los días, el equipo Scrum aprende más sobre el alcance, sobre los elementos del product backlog que están implementando, por ejemplo, sobre las historias de usuario, sobre lo que viene a continuación en los dos siguientes sprints en sesiones de refinamiento y sobre la capacidad real de las personas, entre otras cosas.

Toda esta información puede conducir a hacer un cuestionamiento sobre si el objetivo del sprint es alcanzable o no, sobre si debiera replantearse, delimitarse o sobre si el sprint debiera cancelarse debido a que su objetivo empieza a sufrir de obsolescencia. Así que las respuestas a preguntas como “¿el objetivo del sprint sigue vigente?” dilucidan este aspecto. Otras como “¿lo que hemos aprendido hasta ahora mantienen la vigencia del objetivo del sprint?” también ayudan en este sentido.

Así que, en la práctica, tenemos una gran lista de temas para conversar en la Daily Scrum que nos ayudan a concentrarnos en el cómo vamos hacia el logro del objetivo del sprint. Cuáles preguntas abordar es algo que depende del escenario actual, de lo que esté sucediendo en el equipo y en el entorno. Un Scrum Master debe estar atento a las señales en el ambiente, pero lo mejor es que le proporcione pautas a las personas de equipo para que sean ellas quienes seleccionen la táctica o la estrategia adecuada en un día específico.

Una sola pregunta puede ser suficiente, pero a veces son necesarias dos o más. Sin embargo, si el avance hacia el logro del objetivo del sprint no está claro hacia el final de la Daily Scrum, una práctica que no deja dudas es la del voto de confianza. Esta consiste en que cada persona emite un voto, a manera de porcentaje, de 0 a 100, expresando que tanto confía en que el equipo Scrum alcance el objetivo este sprint. Si el promedio general es de menos del 90 % o de un porcentaje previamente acordado por el equipo, seguramente habrá que replantear o negociar qué se hará y que no se hará en lo que resta de la iteración.

¿Qué otras cuestiones o prácticas se te ocurren que pueden servir al equipo en una Daily Scrum? Por favor, déjamelo saber en el foro.

Más sobre la Daily Scrum

Daily Scrum Kaizen:

http://www.gazafatonarioit.com/2021/04/daily-scrum-kaizen.html

El Scrum Master y el Scrum Diario:

http://www.gazafatonarioit.com/2020/09/el-scrum-master-y-el-scrum-diario.html

Compendio sobre el Scrum Diario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html

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.

Buenas y “malas” historias de usuario

Los criterios INVEST* no son los únicos que hacen a una historia de usuario una “buena” historia de usuario. Pero son un buen comienzo. Además, decir o pensar que una historia de usuario es buena o mala quizás no sea la mejor idea. En cualquier caso, lo más importante es si la historia está preparada o no para implementarse o desarrollarse. Si no lo está, entonces hace falta conversación, ojalá cara a cara, para ponerla a punto: conversación entre los usuarios o interesados clave y un dueño de producto o gerente de producto; y también, conversación entre estos y el equipo de personas que finalmente hará el trabajo de implementación de esas historias.

Nota mental: en realidad, lo más más importante de la historia de usuario es que genere Valor, en cualquiera de sus modos, por ejemplo: más ingresos, mayor felicidad a los usuarios o consumidores, menores gastos, mejora en la marca organizacional, más clientes, mayor aprendizaje, entre muchas otras formas de valor.

Y como son un buen comienzo, veamos algunos ejemplos de cómo se cumplen o no esos criterios en las historias de usuario. Usaremos la forma Connextra para escribir las historias de usuario, pero recordemos que hay muchísimas formas, cuando no infinitas, de representar las historias. Los ejemplos corresponden a una plataforma de compra y venta en línea de productos y en algunos de ellos obviaré la parte del “para” qué se quiere la historia, solo con la intención de concentrarnos en lo fundamental.

Independiente

En la medida de lo posible, las historias se pueden implementar en cualquier orden.

La historia del Comprador no se podrá implementar hasta tanto no estén establecidas todas las condiciones de venta que el Vendedor requiera. Y esta historia solo es verificable en cuanto a instituir y preservar las condiciones de venta, pero no en cuanto a hacerlas cumplir por el comprador. Las cosas así, es posible eliminar la dependencia, dividiendo las historias de usuario usando como criterio las distintas condiciones de venta del producto, desde el punto de vista del Vendedor, además de combinar el establecimiento de los términos de venta con algunas condiciones para hacerlos cumplir en cada historia.

Negociable

Se deja abierta la forma de lograr el objetivo, sin sugerencia de implementación.

La historia de usuario original no deja ningún margen al diálogo en cuanto a las posibilidades de implementación de las formas de pago, es la indicada y nada más. En cambio, la historia derivada abre las posibilidades y permitirá que se tomen las mejores decisiones para su confección mediante conversaciones sucesivas.

Valiosa para el usuario

Algo que el usuario realmente pueda usar, no solo una tarea técnica.

Hasta tanto las imágenes del producto puedan usarse, no tienen ningún valor y, por consiguiente, la historia de usuario en sí carece de trascendencia, de peso (alias de valor). No proporciona ningún beneficio. El impacto de su contraparte, sin embargo, es a todas luces evidente. El valor de la historia salta a la vista.

Estimable

No se requiere investigación, bien entendida.

¿Cuántos informes son? ¿Cuáles? ¿Con qué información o datos? ¿En qué momento se producirán? Estas y algunas otras cuestiones sin respuesta aparente no permitirán que la historia de usuario pueda estimarse en complejidad o tamaño, mucho menos en tiempo. La historia contigua, en cambio, goza de mayor precisión: es una única lista, un informe solo de productos entregados; estas condiciones reducen las posibilidades y aumentan los detalles necesarios para realizar una predicción más o menos confiable sobre cuándo podrá estar terminada.

Pequeña

Se puede pasar del concepto a estar preparada para su lanzamiento en un par de semanas y preferiblemente dentro de un par de días.

Como con el caso de la historia no estimable, no conocemos la cantidad ni la calidad de los informes a los que se refiere esta historia. El informe resumido por categoría de producto, por su parte, es algo mucho más acotado: es uno solo, su carácter de “resumido” ya deja entrever que los datos que incluirá son pocos. Tiene visos de ser una historia que se pueda implementar en dos o tres días de una iteración.

Comprobable

Es posible medir algo específico para verificar que la historia está terminada.

¿Qué significa “rápidas”? ¿45 segundos? ¿27? ¿Un milisegundo? No hay forma de verificarlo, no será posible probar los términos de esta historia, ni siquiera con los mejores robots de prueba existentes hoy. En general, “rápido” es una expresión ambigua, imprecisa. Si decimos “2 segundos”, la ambigüedad desaparece de inmediato. Unos pocos casos de prueba nos permitirán comprobar la completitud de la historia.

 

¿Quieres saber más sobre historias de usuario?

En octubre estaré facilitando un curso donde 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!

 

Daily Scrum Kaizen

Advertencia: que ya no sea un lineamiento de la guía de Scrum, no quiere decir que no podamos seguir usando las “tres preguntas”.

Muchas veces, la respuesta o solución a cómo mejorar la realización o ejecución de un evento Scrum está fuera del evento: por ejemplo, para mejorar la Planning, tenemos que mejorar el refinamiento; para mejorar la Review, tenemos que mejorar la Daily Scrum; para mejorar la Retrospective, tenemos que mejorar la Planning del Sprint siguiente. Siempre he creído que lo mejor de la retrospectiva ocurre cuando esta termina y es la implementación de las acciones de mejora seleccionadas.

Y para mejorar la Daily Scrum mejoremos también la Sprint Planning.

Al definir un Objetivo del Sprint claro, específico, medible, alcanzable y significativo y, por supuesto, circunscrito al Sprint que comienza. Pero definir o establecer el Objetivo del Sprint no es suficiente. ¿Cómo lo vamos a alcanzar? ¿Qué artefacto vamos a usar para verificar que lo logramos? ¿Cuál técnica de validación? ¿Con qué personas lo vamos a hacer? Son algunas otras preguntas que tenemos que poner sobre la mesa y encontrar sus respectivas respuestas.

Recordemos que en la Daily Scrum se inspecciona el progreso hacia el Objetivo del Sprint, entonces se hace necesario dejar de girar el evento en torno a cuáles tareas o actividades hemos realizado o dejado de hacer y enfocarnos más en cómo medir ese avance hacía el objetivo formulado. Además, el Objetivo del Sprint debe tener un vínculo muy íntimo con los elementos del Product Backlog que se van a desarrollar (alias “las historias de usuario”).

Las cosas así, por ejemplo, durante la reunión diaria, responder a la cuestión:

¿Está Terminada la historia de usuario actualmente en desarrollo?

Puede mejorar el rendimiento del equipo y su progresión hacía el Objetivo de la iteración. Incluso podemos complementar esa respuesta con la de esta otra pregunta:

¿Es posible que más personas participen en el desarrollo de esa historia? Sí, ¡pues manos a la obra! Es un poco de Swarming o Enjambre. En desarrollo de software, es posible; pero también lo es en otras actividades.

Otro giro que le podemos dar a la conversación en la Daily Scrum es acercarnos más a los criterios de aceptación de las historias de usuario en desarrollo. Estos criterios también son o deben precisos y medibles, pero más que nada, deben centrarse en el resultado, en el valor a entregar, y deben ser colaborativos, es decir, que inviten a la colaboración de todo el equipo y los interesados.

De esta manera, responder a cuestiones como:

¿Cuál es el estado de los criterios de aceptación de cada historia de usuario en desarrollo?

Es una forma de saber si nos estamos acercando a la meta de Sprint definida. Si el criterio de aceptación aun no ha sido abordado, estamos algo lejos. Si está en desarrollo, ya es un pequeño paso hacia la consecución de los resultados que queremos. Si finalmente está implementado o cumplido, entonces hemos dado un gran paso con miras al logro de ese propósito de la iteración.

Otra alternativa a las tres preguntas es simplemente hablar de “cómo vamos como equipo”, como personas.

¿Cuál es nuestro estado de ánimo? ¿Nuestro nivel de energía?

¡O simplemente aprovechemos esos quince minutos para tomarnos un café! Así sea virtual. Mientras escribo este artículo, seguimos en cuarentena por el virus, catorce meses después. Si estamos haciendo un “buen Scrum”, seguramente justo antes o justo después de la reunión, actualizaremos los radiadores de información a que haya lugar y cada miembro del equipo tendrá la oportunidad de coordinarse o sincronizarse con los demás a medida que avanza la mañana.

En la práctica, no es necesario responder a nada más.

¿Y los impedimentos, riesgos o problemas? Cambiemos un poco la postura sobre este asunto y reorientémonos precisamente hacia el trabajo colaborativo. A los miembros del equipo les podemos enseñar a “levantar la mano” cuando de problemas se trata en el momento en que estos ocurren, ¿por qué esperar a la cita diaria para mencionarlos? Es posible que falten muchas horas hasta la siguiente Daily Scrum y esto puede traer como resultado una baja en la productividad de algunas personas del equipo y, a su vez, que no se pueda conquistar la Meta pretendida.

Como ven, podemos seguir usando las tres preguntas, pero también podemos usar muchas otras tácticas y estrategias para mejorar no solo la Daily Scrum, sino cualquiera de los demás eventos. ¿Y tú, qué técnicas estás usando para mejorar tus reuniones diarias? Por favor, déjamelo saber en el foro.

Nuevo curso: Historias de Usuario - 10 de octubre

Las historias de usuario son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos o servicios. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.

Esta Certificación proporciona los fundamentos sobre las principales características de las historias de usuario como instrumentos de comunicación entre los miembros de equipo y los demás interesados en los proyectos de desarrollo de productos o servicios, sean de tecnología o de cualquier otra área del negocio.

Objetivos de Aprendizaje:

Al final del curso los participantes estarán en capacidad de:

• Entender los beneficios de usar historias de usuario en entornos inciertos y ambiguos.
• Desarrollar las habilidades necesarias para usar las historias de usuario como instrumentos de conversación entre las partes interesadas.
• Aplicar varias formas de escribir historias de usuario.
• Reconocer si una historia de usuario cumple con los atributos de toda buena historia de usuario.
• Emplear distintas técnicas de división de historias de usuario para que estas se puedan elaborar en períodos muy breves de tiempo, desde unas pocas horas, hasta muy pocos días.
• Usar las historias de usuario para comprender la proposición de valor del producto y de sus características desde el inicio del proyecto.
• Guiar a otras personas de sus equipos en el uso apropiado de historias de usuario en contextos complejos y adaptativos.
• Certificarse en User Stories Foundations Certificate (respaldando el conocimiento y la aplicación fundamental de las Historias de Usuario).

Público Objetivo:

Este curso y certificación es apropiado para cualquier persona interesada en usar las técnicas relacionadas con historias de usuario, que estén o vayan a participar en proyectos ágiles con marcos de trabajo como Scrum; también, para interesados en los proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

● Gerentes de producto
● Dueños de Producto
● Mercadeo de productos
● Analistas del negocio
● Analistas funcionales
● Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:
● Líderes técnicos
● Gerentes de Proyectos
● Desarrolladores
● Arquitectos de software
● Analistas de Prueba
● Diseñadores
● Scrum Masters
● Desarrolladores Scrum
● Consultores Comerciales,
● Consultores de Preventa de Proyectos
● Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de historias de usuario.

Requisitos Previos:

Haber recibido entrenamiento o tener conocimientos o experiencia en al menos uno de estos temas:
● Scrum Master
● Product Owner
● Team Member

Opcional:
Leer el Manifiesto Ágil
Leer la guía de Scrum

Entrenamiento:

Tipo de Curso: Foundations. 

Código de la Certificación: USFC.

Examen de Certificación:

Formato: Opción Múltiple.
Preguntas: 40.
Lenguaje: Inglés/Español/.
Puntaje de aprobación: 32/40 o 80 %
Duración: 60 minutos máximo.
Libro Abierto: No.
Entrega: Este examen está disponible en formato en línea.
Supervisado: Será a discreción del Partner.

Información del próximo curso:

Duración: 9 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1:
martes 10 de octubre de 2023.  4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2:
miércoles 11 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3:
jueves 12 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$195 precio temprano. *Hasta septiembre 12 de 2023.

U$245 precio regular.

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

QUIERO UN LUGAR EN EL CURSO

Atención: Incluye certificación User Stories Foundation Certificate

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.

 

Sobre multifuncionalidad y la creación de un incremento de producto

Image by Alexandr Ivanov from Pixabay 

Sobre multifuncionalidad y la creación de un incremento de producto

O de las minicascadas en el Sprint y de cómo deshacernos de ellas

“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee

De dónde venimos

Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?

Estos escenarios son mucho más comunes de lo que creemos. Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando con prácticas tradicionales de gestión en las últimas décadas y cuya área de Tecnología cuenta con proveedores externos: unos para desarrollar el software y otros para realizar las pruebas de este. Y tanto las personas de un proveedor como del otro no se hablan sino a través de procesos y herramientas, como un bug tracker o actas formales de entrega y recepción de partes del producto.

Es muy probable que en esos equipos prime la alta especialización: el así llamado desarrollador de front-end, el analista de requisitos, el desarrollador de back-end, el arquitecto del software, de un lado. El analista de pruebas funcionales, el de pruebas no funcionales, el automatizador de pruebas, lo que sería un gran avance, del otro lado. Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus propios roles y responsabilidades dentro de todo este intrincado ecosistema de trabajo.

Imaginemos ese escenario: aquí los unos y los otros son de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores actuales y decide invitarlos a embarcarse en un viaje que los llevará por los caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas, nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando, “metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!

Para dónde vamos

Image by Merhan Saeed from Pixabay 

Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.

Es algo para tener en cuenta cuando se hace refinamiento o, simplemente, cuando se dividen elementos del product backlog en piezas más pequeñas. Eso es necesario porque el trabajo en el sprint será una minicascada: si se trata de desarrollo de software, por ejemplo, primero se realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas breves fases, haya etapas más pequeñas que se lleven a cabo de manera secuencial.

Las cosas así, no será posible cumplir la promesa de tener elementos del product backlog (alias las historias de usuario) terminados durante los primeros días del sprint. Esto, como sabemos, sube la presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados por el Product Owner. Es un hecho: llegar a la mitad del sprint o más allá, independientemente de su duración, sin que ninguna historia de usuario alcance la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en una baja de energía en el equipo.

Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

·       Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.

·       Un refinamiento que “mire” dos o, mejor, tres Sprints hacia adelante.

·       Manejo de expectativas con los usuarios e interesados, vía la Product Owner o el Scrum Master o alguna otra persona del equipo o muy cercana a este.

·       Ordenamiento por valor del product backlog, más que hacer priorización. Es decir, ordenar uno a uno, por valor e impacto para el negocio, para los usuarios o clientes, cada historia de usuario. Muchas veces la priorización se hace por grupos de elementos. El ordenamiento se hace de manera individual. Esto asegura que en cada sprint se entregue Valor, aunque este sea en pocas cantidades.

·       Foco en una historia a la vez y concentrarse en su finalización.

·       Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.

Pero lo más importante y crítico es poner en marcha un plan de desarrollo de competencias que faculte a las personas para adquirir habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo, requiere de una inversión considerable, pero es lo que va a permitir hacer las cosas de una manera diferente de una vez por todas y para siempre. Un plan que incluya:

·       Adquisición de nuevas prácticas y, si es necesario, de nuevas herramientas.

·       Trabajo en pares.

·       Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

Los beneficios de desarrollar este plan no girarán solo en torno al aumento de la productividad del equipo, sino también a la entrega de mayor valor en cada iteración, al incremento de la calidad, a la mayor satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán a energizar al equipo, a su bienestar, a menos estrés y a más motivación.

¿Qué te parecen estas ideas? Por favor, cuéntamelo en el foro.

---

*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay