domingo, 26 de marzo de 2017

¿Hay algún juego que permita experimentar un sistema de arrastre versus empuje?

Este es un ejercicio del curso de Kanban de
En mis cursos de Kanban hacemos un taller de construcción de aviones de papel que hace experimentar a los alumnos la gran diferencia de aplicar un sistema de arrastre respecto a un sistema de empuje.

Para ello uso un juego de Shmula Pull Systems, Push Systems: The Paper Airplane Game y en este post quiero mostrar mi experiencia.
Diseño de la línea de montaje, muchas gracias Shmula
El taller consiste en dos vueltas de 5 minutos para la construcción aviones de papel, la primera con un sistema de empuje y la segunda con un sistema de arrastre.

Primero han de constituirse los equipos de trabajo, cada uno de 6 participantes. Les invito a buscar un nombre para el equipo y autoasignarse los roles de manera que haya 4 trabajadores, 1 encargado de calidad y 1 encargado para medir tiempos.

La primera vuelta, que hace experimentar el sistema de empuje o push, trata de seguir las instrucciones de cada una de las etapas de la línea de montaje (siguiente imagen) y trabajar a un ritmo confortable tratando de producir lo más rápido posible. Antes de empezar se coloca una unidad de producto parcialmente terminado en cada área entre etapas. El facilitador o trainer cronometra el tiempo de construcción de 5 minutos.
Instrucciones para las 4 estapas de la línea de montaje, muchas gracias Shmula
El encargado de calidad prueba cada uno de los aviones que llegan al final de la línea, aprueba los que vuelan bien a lo largo de al menos 2 metros y rechaza (archiva en una papelera) los que no cumplan con un mínimo.
Estaciones con aviones en curso y el
área de calidad con aviones OK y KO
El encargado para medir tiempos anota el tiempo de ciclo de una muestra de aviones, una buena opción es que este marque un avión antes de la primera etapa, o introduzca una hoja de color para distinguir el avión, y haga las mediciones cuando este llegue al área de calidad. También anota el WIP total, cantidad de aviones en curso que hay en la mesa. Finalmente hace el promedio del tiempo de ciclo que registra en el tablero.

La segunda vuelta hace experimentar el sistema arrastre o pull. Se introduce una simple regla, un trabajador no puede hacer su trabajo, y debe esperar, si el área entre él y la estación que tiene a continuación no está vacía, regla que convierte el sistema en un sistema de arrastre. Igual que en la primera vuelta se coloca una unidad de producto parcialmente terminado en cada área entre etapas y se toman las mismas métricas.

Las métricas recogidas se anotan en un tablero compartido, en el que cada columna muestra los datos de un equipo en particular. El facilitador o trainer se sitúa ante el tablero y efectúa una serie de preguntas con el objetivo de generar debate y reflexión entre los participantes:
  • ¿Por qué el tiempo de ciclo es inferior en el sistema de arrastre que en el sistema de empuje?
  • ¿Por qué hay menos WIP en el sistema de arrastre que en el de empuje?
  • ¿Es mejor poco WIP o mucho?
  • ¿Dónde estaba el cuello de botella?
  • ¿Qué sistema es mejor: el de empuje o el de arrastre?
  • Para las estaciones 1 y 2, ¿Qué tiempo habéis pasado desocupados en un sistema y en el otro? ¿Debería eliminarse ese tiempo muerto?
Una de las sorpresas usuales entre los participantes es cuando ven que con en sistema de arrastre han construido más aviones, su impresión suele ser exactamente al revés, casi no se lo creen, cuentan que con empuje no paraban de trabajar y tenían la sensación de haber construido mucho aviones. Con el sistema de arrastre las cosas ocurren con ritmo y con un espacio correctos, trabajamos de forma más ordenada y efectivamente somos más productivos.

El ritmo se evidencia con la evolución de los tiempos de ciclo. En el sistema de empuje, a medida que se forma la cola por el cuello de botella en la estación 3, el tiempo de ciclo crece, mientras que en el sistema de arrastre los tiempos de ciclo son todos similares, desde el primero hasta el último avión. Un sistema de arrastre no solo resulta en tiempos de ciclo más cortos sino en tiempos similares que permiten previsibilidad.

Cuando les pregunto a los participantes por como han vivido las dos vueltas, la mayoría cuenta que en la primera vuelta estuvieron focalizados en su tarea, en trabajar y trabajar, y que en la segunda vuelta fueron conscientes del proceso completo y se sentían parte del todo. Ese aire que nos da el límite de WIP, cuando no podemos trabajar mientras el área hasta la siguiente etapa no esté vacía, hace que tengamos visibilidad sobre toda la línea de montaje y que nos sintamos parte del todo.

En el sistema de arrastre los participantes son conscientes del cuello de botella que representa la estación número 3, y que se produce por el hecho de tener que dibujar una estrella. En ocasiones algún grupo incorpora de forma espontanea alguna mejora, como por ejemplo la decisión de las estaciones colindantes, la 2 y la 4, de ayudar a la 3.

Algunos participantes hablan de haber "sobrevivido" al sistema de empuje y de haber "vivido" el sistema de arrastre.
Fiesta final de lanzamiento de todos los aviones construidos :-)
Agradecimientos a mis alumnos del curso de noviembre de 2016

domingo, 19 de marzo de 2017

¿Cómo estimar rápidamente una pila de producto nueva con tallas de camisa?

Pared para estimación de Elefante Blanco
Hay muchas técnicas que se pueden utilizar para estimar a alto nivel una pila de producto. En este post quiero presentar la que se denomina El Elefante Blanco y que es a la vez simple y muy efectiva.

El equipo se sitúa en forma de semicírculo frente a un tablero o una pared, con cartas de tallas de camisa como cabecera de columnas. El moderador, usualmente el Scrum Master, mezcla el conjunto de historias de usuario y las pone boca abajo en una mesa frente a todos ellos. La dinámica requiere un reloj o cronómetro para medir el tiempo para cada turno, usualmente de entre 30 y 60 segundos.

La dinámica se pone en marcha en cuanto el moderador inicia el cronómetro, es la señal para que el primer miembro lleve adelante los siguientes pasos:
  • 1. Elegir una historia de la mesa
  • 2. Leer la historia en voz alta
  • 3. Colocar la historia en una de las columnas definidas en la pared (XS, S, M, L, XL)
  • 4. Explicar al equipo porqué elige una columna en concreto
  • 5. Reiniciar el cronómetro para el siguiente miembro
La decisión de en qué columna colocar la historia ha de ser propia del miembro que le toca el turno, no debe de haber ninguna interferencia externa. Puede hacer preguntas al Propietario del Producto, pero no debe de discutir la estimación con sus compañeros. Si el miembro no asigna la historia en el tiempo establecido para el cronómetro, entonces la historia será colocada en la columna del medio.

La introducción de una sola historia a la vez ayuda a limitar la incertidumbre. El primer participante no tiene que considerarlo todo, sólo tiene que considerar una historia. La complejidad aumenta a medida que se añaden más historias, pero el trabajo de los participantes previos ayuda a construir "andamios" que ayudan a tomar la decisión.

Una vez estimada la historia, el participante del turno explica las razones basadas en su conocimiento de experiencias pasadas u observaciones que le han llevado a colocarla en la columna determinada. Es esencial que el resto del equipo observe y escuche atentamente, sin intervenir, para comprender la totalidad del contexto y la situación de la historia.

Después de un par de interacciones todas las historias de usuario habrán sido colocadas en la pared, a partir de ese momento los participantes pueden mover una historia existente de una columna a otra. En ese caso el miembro de equipo lee de nuevo la historia y explica la razón por la cual cree que se debe de reestimar su tamaño y colocarla en otra columna.

Si el participante estuviera satisfecho con las estimaciones simplemente ha de indicar que desea ser saltado diciendo "salto". Si una persona no toma la decisión dentro del tiempo establecido entonces se interpretará como que desea ser saltada. La dinámica finaliza cuando la pila producto haya sido estimada completamente y todos los miembros indican que desean ser saltados.

miércoles, 15 de marzo de 2017

¿Hay alguna técnica de estimación relativa de prioridades ágil?

Estimación The Big Wall
En este post quiero mostrar una técnica llamada The Big Wall, o Estimación en La Pared, que provee de una primera estimación rápida de órdenes de magnitud y prioridad en relativo de los elementos de una pila de producto. Fue creada parcialmente por Mitch Lacey y se basó en otra llamada de afinidad. Esta técnica provee de una heurística de estimación de manera que fomenta la construcción de base de conocimiento.

En el extremo izquierdo de la pared van las historias de usuario lo más pequeñas posibles, y en el extremo derecho las más grandes posibles. Es recomendable utilizar una pared grande ya en una pila de producto inicial puede haber cientos de elementos.

Primero se pide al equipo de desarrollo que coloque las historias de usuario en donde estiman corresponda entre esos dos polos y a media altura. La ventaja de esta técnica es que no se necesita una noción preconcebida de qué significa un punto de historia.

Una vez colocadas todas las historias en la pared es el turno del equipo de negocio. Estos están interesados en buscar aquellas que están relacionadas con ellos mismos y asegurarse de que se prioricen correctamente. En esta fase aflorarán los conflictos de intereses entre los interesados, es lo esperado ya que se está reflejando la realidad, y esta ayuda al Propietario del Producto a clarificar las dudas y decisiones difíciles.
  • El moderador, el Propietario del Producto o el Scrum Master, explica al equipo de negocio lo que está viendo en la pared: El equipo de desarrollo ha distribuido las historias de usuario agrupándolas por tamaños relativos, las historias a la izquierda son las más pequeñas mientras que las de la derecha las más grandes.
  • La función del equipo de negocio es determinar la prioridad relativa de las mismas. Para ello deben de mover historias en vertical, para arriba o abajo, cuanto más arriba implica una mayor prioridad desde la perspectiva de la empresa.
  • Para fomentar la conversación y transmisión de conocimiento, subir una historia implica una frase que justifique el porqué, de esta manera el equipo de negocio se alineará en la importancia de las historias.
  • Por la misma razón bajar una historia que otro interesado ha subido previamente, implica marcarla con un punto amarillo por ejemplo, para dejar una alerta de que puede ser necesaria una conversación posterior sobre la verdadera prioridad de la historia.
  • El moderador fomenta que los interesados efectúen preguntas tipo: “¿Quien movió esto para arriba (o abajo)?” o manifestar en voz alta “Creo que ésta debería moverse. ¿Quién no está de acuerdo?”, lo que provoca una conversación efectiva entre los interesados.
  • Si la discusión se extiende por mucho tiempo y no hay consenso, el moderador puede tomar la historia, indicarles a los interesados que no hay acuerdo y anotar en la tarjeta resolver la prioridad de forma privada en una reunión posterior.
Estimación en la pared - Scrum Manager
El equipo de desarrollo sigue presente en toda la dinámica, actúa principalmente como observador del por qué las historias suben o bajan en prioridad. Estos también pueden preguntar al equipo de negocio, así se genera entendimiento entre ambas partes que puede implicar una reestimación de las historia. Otros beneficios son que se crea conexión entre técnicos y negocio y se transmite y alinea la visión del producto/proyecto.

Al final de la dinámica habremos obtenido como se relacionan las historias de usuario y una primera idea de pila de producto priorizada y de qué funcionalidades se van a construir en fase temprana.

Clicándo en la imagen un poco más arriba a la derecha os invito a ver el vídeo "estimación en la pared" de Scrum Manager.

martes, 14 de marzo de 2017

¿Cómo se estima de forma relativa con planning poker?

Baraja de planning poker
El objetivo del planning poker no es obtener estimaciones que puedan ser confirmadas más adelante, sino ofrecer un proceso de estimación o aproximación que sea rápido y ágil para obtener valores útiles para que el equipo pueda estimar la pila de producto o planificar el sprint. Más importante aún es crear un entendimiento compartido del elemento estimado y generar una base de conocimiento común: si los participantes estiman con valores muy dispares es que alguno sabe algo que otros no saben. Recordemos que en los equipos hay especialistas de diferentes áreas, hay optimistas y pesimistas y eso hace que algunos vean soluciones que otros no ven. La discusión alrededor de las soluciones y la disparidad de la estimación alineará el conocimiento de todo el equipo.

Los participantes en la estimación son, y sólo deben de ser, los miembros del equipo de desarrollo, los que van a ejecutar las tareas, independientemente de si estos son testers, programadores, maquetadores, analistas, ingenieros especializados en bases de datos, etc. Ni el Propietario del Producto ni el Scrum Master deben de participar en la estimación.

Al comienzo de la actividad de estimación con planning poker cada participante recibe una baraja de cartas con los valores de estimación posibles. Hay variedad de barajas con diferentes series de números, la serie más usual es la basada en la serie de Fibonacci: 0, ½,1,2,3,5,8,13,21...

Se incluye el 0 para elementos que no requieran esfuerzo y 1/2 para elementos muy pequeños. A partir del 21 se pasa al infinito (∞), ya que cualquier elemento con una estimación mayor debe de dividirse en partes menores. El signo de interrogación (?) significa que es imposible estimar por falta de información o detalle, y la taza de café, copa de vino o jarra de cerveza significa que estamos cansados y que es hora de hacer un descanso.

Si es la primera vez que el equipo estima con planning poker hay que establecer primero un elemento de referencia con el valor 1, para ello se busca de forma colaborativa el elemento más pequeño de la lista.

Un moderador lee la descripción de cada elemento a ser estimado, este puede ser cualquier miembro del equipo, en este caso inclusive el Propietario del Producto:
  • Cada participante selecciona la carta con que estima el elemento y la pone boca abajo sobre la mesa.
  • Cuando todos han hecho su selección, se voltean todas las cartas boca arriba.
  • Si las estimaciones son similares se busca consenso y se sigue con el siguiente elemento.
  • Si la estimaciones resultan en infinito, por sobrepasar el límite máximo establecido por la baraja, el elemento debe dividirse en elementos de menor tamaño.
  • Si las estimaciones resultan muy dispares, el moderador con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
    • Preguntar a las personas de las estimaciones extremas: ¿por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras haber escuchado todo el equipo las diferentes razones de unos y otros se reestima el elemento en una segunda o tercera vuelta.
    • Dejar a un lado la estimación de ese elemento y retomarlo al final o en otro momento.
    • Pedir al cliente o Propietario del Producto que descomponga apoyado por el equipo el elemento para estimar cada uno de los elementos resultantes.
El equipo puede discutir cada estimación durante unos minutos, es importante entender que en ciertas ocasiones la discusión excesiva no lleva en una mejor estimación. En la mayoría de casos se obtienen las estimaciones con discrepancias iniciales en la segunda vuelta.

sábado, 11 de marzo de 2017

¿Cómo es el mundo que rodea a las compañías hoy en día?

Tanto en mis cursos a equipos técnicos como cuando lidio como coach con directivos, me encuentro con que no son conscientes de lo cambiante que es mundo que les rodea. Todos ellos acusan la falta de definición por parte de los usuarios, Propietarios del Producto y en general los equipos de negocio a medio y largo plazo. Los equipos de desarrollo hablan de usuarios que no saben lo que quieren, y los directivos que Scrum está bien pero que sus proyectos son muy predecibles y estables. Sólo estando en primera línea del mercado, como lo están los equipos de negocio, podemos ser conscientes de como es la realidad. Y recordemos que la realidad es como es, y siempre gana.

La realidad es que vivimos en un mundo en continuo cambio que se concreta en 4 factores que se conocen como VUCA (Volatility, Uncertainty, Complexity, Ambiguity).

Las compañías deben de prepararse para competir en este mundo volátil, incierto, complejo y ambiguo, y asumir los nuevos retos exige con son transparencia, flexibilidad, abordar situaciones nuevas, situar siempre al cliente en el centro de las operaciones y crear un entorno propicio al compromiso de todos interesados.

En el recuadro de la izquierda el eje vertical representa lo bien que se puede predecir el resultado de nuestras acciones, o la certeza del resultado. El eje horizontal representa cuanto sabemos sobre la situación o nuestra conciencia situacional. En función de estas dimensiones nuestra compañía se encontrará mas o menos fuertemente influenciada por los cuatro factores.
  • La "V", Volatilidad: esta refleja la velocidad y la turbulencia del cambio, estamos ante un incremento brutal y sin precedentes en el tipo o naturaleza de los cambios.
  • La "U", Incertidumbre (Uncertainty): se refiere a la ausencia de previsibilidad de los acontecimientos, los resultados, incluso de acciones con las que estamos familiarizados son cada vez menos predecibles.
  • La "C", Complejidad: refleja la vastedad y la interdependencia en sociedades y economías globalmente interconectadas que provoca la ausencia de conexión clara entre causas y efectos.
  • La "A", Ambigüedad: alude a la multitud de opciones y posibles resultados resultantes del cambio.
Este escenario de volatilidad, incertidumbre, complejidad y ambigüedad inherente al mundo empresarial, será cada vez mayor. Los directivos y líderes deberán de adquirir otros compromisos:
  • Con sus clientes entender y satisfacer sus necesidades cambiantes
  • Con sus proveedores/partners cooperar para una mejor competitividad de mercado
  • Con sus empleados desarrollarlos de forma continua
Sólo comprendiendo como es el mundo allá fuera, ese mundo VUCA, se comprende que nuestros usuarios y clientes navegan en él como mejor pueden, y que sus necesidades reales se van perfilando y cambiando a media que se ejecutan los proyectos. Con cada día que pasa estos van adquiriendo experiencia sobre el producto, y van madurando y ajustando sus ideas al dictamen de VUCA.

Ya no domina el más grande ni el más establecido,
sino el que sea capaz de adaptarse más rápidamente

jueves, 9 de marzo de 2017

¿Cómo se gestiona la deuda técnica en Agilidad?

La deuda técnica se define según la wikipedia como:

"Deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware"

La deuda técnica también puede ser pensada como las tareas necesarias a hacer para que un trabajo pueda ser considerado completo. Si realizamos un cambio en una parte clave o crítica del código, puede existir la necesidad de hacer otros cambios coordinados al mismo tiempo en otras partes del código o en la documentación. Recordemos que estos últimos son necesarios, pero si no se realizan, se consideran deuda que deberá ser pagada en algún momento del futuro.

La deuda técnica
es como el ketchup
Cortesía de Pixabay
Ejemplos de deuda técnica:
  • Código poco claro e ilegible
  • La falta de pruebas automatizadas, construcción automatizada, despliegue automatizado y cualquier otra cosa que pudiera ser automatizada hoy en día y se haga manualmente
  • La falta de calidad
  • Código duplicado
  • Arquitectura enmarañada y dependencias innecesariamente complejas
  • Herramientas ineficaces y lentas
  • Código no comprometido y ramas de larga duración
  • Documentación técnica importante que falte o esté obsoleta
  • Falta de entornos de test, y que estos no sean equivalentes al entorno de producción
  • Ciclos de construcción-test largos
  • Falta de integración continua
La deuda técnica es como el ketchup, si se elimina enseguida mientras está fresco sólo hacen falta un par de segundos de enjuague, mientras que si está resecado puede tomar minutos y múltiples intentos de friega intensa.
La deuda técnica crece y se complica de forma exponencial en el tiempo
Causas comunes que llevan a la deuda técnica:
  • Las presiones comerciales: cuando la empresa prefiere obtener algo lo antes posible sin efectuar otros cambios necesarios se acumula deuda técnica de todo aquello que no se finaliza.
  • Falta de comprensión del proceso: cuando la empresa acepta deuda técnica sin comprender el concepto ni sus consecuencias.
  • La construcción de componentes fuertemente acoplados: por ejemplo cuando hay funcionalidades "hardcoded", cosas codificadas fijas que hacen que el software sea inflexible y que los cambios futuros sean costosísimos.
  • La falta de pruebas automatizadas: que permitan reducir el riesgo, identificar y resolver bugs en caliente y dar soluciones rápidas.
  • La falta de documentación: que resulta por la sobrecarga de trabajo de los equipos de desarrollo.
  • La falta de colaboración: donde el conocimiento no es compartido por toda la organización.
  • El desarrollo en paralelo de dos o más ramas en el gestor de versiones: estas pueden causar acumulación de deuda técnica debido a un trabajo divergente que cuando sea combinado de problemas de integración. Cuantos más cambios se hagan de forma aislada, más se acumulará la deuda técnica.
A medida que los requisitos de un producto evolucionan, comienza a quedar claro que algunas partes del código se vuelven más difíciles de mantener y deben de ser rediseñadas para soportar las nuevas necesidades. Cuanto más tiempo se demore en refactorizar y se siga escribiendo el código nuevo empleando el formato actual, hará que se acumule más y más deuda técnica.

Cinco cosas importantes a considerar para superar la deuda técnica:
  • Involucrar al Propietario del Producto: Algunos Propietarios del Producto tienden a no entender completamente las necesidades y beneficios de la refactorización para pagar la deuda técnica, por lo que es importante que los equipos de desarrollo aprendan a transmitir el impacto de la deuda técnica en el producto y de como les afecta en su trabajo. La forma más sencilla de transmitirlo es hacer hincapié en la importancia del crecimiento continuo del producto (manteniendo el rendimiento a corto plazo y la salud a largo).
  • Definir la regla para la "buena" deuda técnica: Hay situaciones en que la deuda técnica es necesaria en un primer momento, por ejemplo si hay un hito a la vista. En todo caso hay que resolver la deuda técnica adquirida cuanto antes una vez haya pasado el punto crítico.
  • Visualizar y estructurar la deuda técnica: inventariar todas las aplicaciones/módulos y crear historias técnicas con las cosas pendientes en cada una de ellas para incorporarlas después a la pila de producto. Esto ayudará a entender la forma que tiene la deuda técnica en cada aplicación.
  • Estimación y priorización de la carga de trabajo y elaborar una estrategia: Comprender el esfuerzo necesario para pagar la deuda técnica ayudará al equipo a crear un plan de pago de la misma y que el Propietario del Producto pueda incorporarla en la pila de producto.
  • Integración al proceso existente: Siguiendo los pasos anteriores se estará en disposición de reducir la deuda técnica, lograr un consenso entre el equipo y el Propietario del Producto permitirá extraer políticas explícitas propias del equipo.
Si un equipo decide reducir su deuda técnica actual les recomiendo que visibilicen su decisión en una frase que pueden imprimir en un banner:

Vamos a dejar de escribir Código Basura,
y limpiaremos Gradualmente el Código Viejo

Mis agradecimientos a Erich, quien sin saberlo y a través de un texto que escribió, me inspiró a escribir este post.

sábado, 4 de marzo de 2017

¿Por qué etapas pasa la formación de equipos integrados?

Un equipo de Scrum ganador - gracias Sergio por el dibujo
Como sabemos Scrum crea el entorno adecuado para que se formen equipos ganadores, equipos muy integrados y de alto rendimiento. La formación de un equipo lleva tiempo, sus miembros evolucionan a lo largo de una serie de etapas que Bruce Tuckman describe en su modelo de Forming, Storming, Norming, and Performing.

Como Scrum Masters es importante entender este modelo para ayudar a los nuevos equipos a integrarse y a ser efectivos más rápidamente.

Las etapas Formación, Asalto, Normalización y Funcionando son todas necesarias e inevitables para que el equipo crezca, sea capaz de afrontar los desafíos y los problemas, encuentre soluciones, planifique el trabajo y por ende dé resultados.
Etapas por las que pasan los equipos de alto rendimiento (necesarias e inevitables para que un equipo crezca)
Forming (Formación)

Etapa en la que los miembros acaban de aterrizar en el equipo, son positivos y educados, algunos están entusiasmados y motivados con lo que se les dibuja por delante, y otros están ansiosos porque no han entendido completamente qué trabajo hará el equipo. Esta etapa dura un poco de tiempo, las personas empiezan a trabajar juntas y se suelen esforzar por conocer a sus nuevos colegas.

Como Scrum Master desempeñamos un papel clave en esta etapa, los roles y las responsabilidades de los miembros no están claros aún, y es el momento de iniciarlos y entrenarlos en las formas del modelo de Scrum. Les hemos de acompañar para que se forme un equipo abierto que sientan los beneficios de compartir y colaborar, en el que todos se sientan como iguales, conscientes de la libertad de la autoorganización y el compromiso de ser un solo equipo.

Storming (Asalto)

La fase de asalto es una fase crítica en la que la formación de los equipos puede fracasar. Es una fase en la que aparecen los primeros conflictos y las personas empujan contra los límites establecidos en la etapa de formación.
  • Los conflictos entre los estilos de trabajo de los miembros del equipo pueden causar problemas imprevistos y algunos miembros pueden sentirse frustrados.
  • También puede haber conflicto en la toma de la funciones, los equipos de Scrum son multifuncionales y cada uno tiene la oportunidad de encontrar su sitio, pero para ello tiene que haber un encaje que no siempre está libre de roces.
  • Algunos pueden cuestionar el valor de la meta del equipo, hasta pueden resistirse a asumir tareas.
  • Al no tener apoyo de procesos establecidos o relaciones fuertes con sus colegas, los miembros pueden sentirse abrumados por la carga de trabajo y experimentar estrés.
En esta etapa el Scrum Master tiene que estar pendiente del equipo, y si el conflicto no se resuelve dentro del equipo dotarse de alguna dinámica de resolución de conflictos. Normalmente es suficiente con invitar a los involucrados en el conflicto a una coca-cola y simplemente empezar con "¿Chicos que os pasa?"...

Una herramienta muy potente son las retrospectivas, estas sirven como evento de team-buidling (o un Beer Taste Kanban que hace maravillas), y son un lugar donde se lloran y purgan las frustraciones, donde se celebran los éxitos y donde se crea positividad y se energiza el equipo.

Norming (Normalización)

Poco a poco el equipo se establece en la etapa de normalización. Esto es cuando las personas comienzan a resolver sus diferencias, aprecian las fortalezas de sus colegas, se establecen acuerdos internos sobre roles y responsabilidades y surgen los líderes naturales a los que se respeta su autoridad.

Curva de efectividad (productividad) de un equipo
Los miembros del equipo ya se conocen mejor y socializan juntos, piden ayuda mutua, son capaces de proporcionar comentarios constructivos y recibir feedback de sus compañeros. La gente desarrolla un compromiso más fuerte con la meta del equipo, y se comienza a ver un buen progreso hacia la misma.

El equipo se ha convertido en una comunidad a la que los miembros se van adaptando a través del solapamiento de etapas de asalto y normalización. A medida que surgen nuevos tipos de tareas el equipo puede volver a caer en una etapa de asalto corta para resolver nuevos conflictos.

Es una etapa en la emerge un equipo de Scrum con el modelo ya interiorizado. En las retrospectivas las mejoras se centran en acciones que hacen mejorar al equipo como una sola unidad. Siguen surgiendo impedimentos, pero mejoras muy directas, como sobre el proceso en si (horario y localización de la reuniones diarias por ejemplo), carencias de conocimiento técnicos o de negocio, problemas con herramientas u entornos, etc. quedan atrás.


Performing (Funcionando)

El equipo llega a la etapa de equipo ganador, el trabajo se realiza sin roces y lleva al logro de la meta del equipo. Los miembros se sienten cómodos y motivados al formar parte del equipo, al ser un equipo autoorganizado y multifuncional, incluso miembros que salen, o nuevas personas que se incorporan, no interrumpen el rendimiento.

La mentalidad ágil forma parte de su cultura, el modelo de Scrum sigue siendo su trasfondo pero han establecido su propia forma de trabajar con sus propias políticas, que puede que haya roto alguna regla de Scrum, pero que sin duda es mucho más efectiva, porque es de ellos para ellos.

Esta etapa siempre me sorprende cuando emerge pair-programming, por ejemplo maquetador / java-script o tester / programador que resuelve bugs en caliente, y los miembros declaran que es una experiencia muy motivante y se dan cuenta de que son más eficientes así. (Cuando esto ocurre reparto abrazos a esas personas, me llena alegría y lo siento como una recompensa, jajaja).

Llegada a esta etapa los Scrum Master ya podemos retirarnos y concentrarnos en otros equipos, aunque deberemos de seguir acompañando al equipo como coach ágil y poner el foco en el desarrollo de los miembros del equipo.

miércoles, 1 de marzo de 2017

¿Cómo identificar un buen Scrum Master en una entrevista de trabajo?

Scrum Master velando por el equipo
Indagando en el tema de contratación de un buen Scrum Master he descubierto este artículo de Stefan Wolpers y Andreea Tomoiaga que quiero presentar en este post: "Hiring: 38 Scrum Master Interview Questions to Avoid Agile Imposters" y cuyas kllier-questions he traducido. Desde la página del artículo original se puede descargar un documento con las preguntas y un conjunto de explicaciones y respuestas apropiadas.

I. El rol del Scrum Master
  • El Manifiesto Ágil menciona "Personas sobre procesos". ¿El Scrum Master, como un rol para hacer cumplir "el proceso", no está en contradicción con el Manifiesto?
  • ¿Cuáles son buenos indicadores de que la "Agilidad" está funcionando en tu organización? ¿Que muestren que tu trabajo es exitoso?
  • ¿Cuáles serían métricas típicas a seguir? y si las hay, ¿qué métricas seguirías y con qué propósito?
  • El rendimiento de tu equipo no cumple una y otra vez con los compromisos adquiridos y la velocidad es muy variable. ¿Cuáles pueden ser las razones de ello? ¿Y cómo abordarías esas cuestiones?
  • ¿El equipo debe de estar involucrado en el proceso de incepción de productos? y, si es así, ¿Cómo?
  • Por su diseño en Scrum el rol del Propietario del Producto puede ser un cuello de botella. ¿Cómo puedes apoyar al Propietario del Producto para que sea el maximizador de valor?
  • ¿Cómo puedes asegurar que el equipo tenga acceso a los interesados?
  • ¿Cómo puedes difundir la mentalidad ágil a lo largo de diferentes departamentos de la compañía? y ¿Cuál sería tu estrategia para hacer coaching a esos interesados que no son de TI?
  • ¿Cómo introducirías Scrum a los directivos senior?
  • Se realizó la formación de Scrum para todas las partes interesadas. Después de una fase inicial para tratar de aplicar los nuevos conceptos, cuando se producen los primeros impedimentos, se produce una resistencia seria para continuar con la adopción Scrum por parte de los compañeros. ¿Cuál sería tu estrategia/experiencia para manejar esta situación?
II. Refinamiento de la pila de producto y estimación
III. Planificación de sprint
IV. Reunión diaria
V. Retrospectiva
  • ¿Quién debería de participar en las retrospectivas?
  • ¿Revisas la salud del equipo en la retrospectiva? o ¿Crees que no es necesario? si es que si, ¿Cómo lo harías?
  • Encontrado al Scrum Master - cortesía de Pixabay
  • ¿Qué formatos de retrospectiva has utilizado en el pasado?
  • ¿Cómo se puede evitar el aburrimiento en las retrospectivas?
  • Un equipo siempre selecciona acciones de mejora razonables pero después nunca las implementa. ¿Cómo manejarías esta reincidencia?
  • ¿Cómo recomendarías que fuera el seguimiento de las acciones de mejora?