¿Cómo hacer visibles las interrupciones a las que está sometido un equipo?

Cada globo representa una interrupción - cortesía de Pixabay

Uno de los beneficios de la Agilidad y la mentalidad ágil es que ambos dan visibilidad a todo: a lo que queremos construir, a lo que se está construyendo, a los éxitos, a los fracasos, a los aprendizajes, a los problemas e impedimentos, etc.

Como sabemos, uno de los desperdicios o mudas más corrientes son las interrupciones que sufren tanto los miembros de los equipos como los demás roles de Scrum.

Para dar visibilidad a las interrupciones lo que hemos hecho, es que cada vez que alguien sufre una interrupción, este infla un globo y lo deja errando por el suelo. Al cabo de una semana tuvimos una representación muy visual del volumen de interrupciones acaecidas. Contando el número de globos, y en base a una media de 15 minutos perdidos por interrupción, el tiempo medio que las personas necesitamos para cambiar de contexto, es muy fácil hacer números y calcular el coste que representan. Esos números son muy poderosos, los podemos exponer cuando como Scrum Master hayamos de tratar con aquellos que son propensos a interrumpir.

Mi compañero Marcos Garrido fue quién me enseñó esta técnica y me contó su experiencia. Entró uno de los jefes del área en la sala, vio los globos y preguntó si estaban celebrando un cumpleaños, le dijo que no... y le explicó de lo que se trataba. El jefe recibió el mensaje en todo su esplendor, en poco tiempo el número de interrupciones se redujo drásticamente. Más tarde el jefe le pidió a Marcos que no volviera a utilizar mas esta técnica, jajaja... ¡funcionó!

¿Qué hacer cuando el equipo diverge repetidamente en la estimación de una historia de usuario?

Equipo estimando, la mayoría converge hacia el 5 pero uno se estanca en el 21

La estimación de historias de usuario la deben de realizar las personas que van a realizar el trabajo, por tanto el equipo, y solo el equipo, debe estimar.

Al ocurrir de forma colaborativa trae varias ventajas consigo, como lo son incorporar los diferentes puntos de vista y opiniones de todos, detectar posibles tareas ocultas y posibles obstáculos, tener estimaciones más acertadas y compartir y alinear el conocimiento de todos.

Pero la colaboración también trae consigo el conflicto, y a veces, sobre todo en los equipos recién estrenados en Scrum y planning poker, no consiguen ponerse de acuerdo en una estimación. Después de la segunda o tercera jugada sobre la misma historia de usuario no consiguen converger en una estimación compartida.

En ese punto suele surgir la duda de si la estimación colaborativa con planning poker es de utilidad, afirman que es mejor que estime directamente el experto y se preguntan para qué sirven las estimaciones de los inexpertos... Les suelo plantear la reflexión de si siempre van a querer depender de ese experto, y de si no resulta beneficioso hacer que todos los miembros del equipo reflexionen acerca de la historia de usuario, y que poco a poco vayan adquiriendo conocimiento y experiencia para así ir mejorando sus estimaciones conjuntas.

Un ejemplo clásico es cuando estiman una historia y las estimaciones son dispares, tenemos por ejemplo un 5, un 8 y un 21 como en la imagen. Destapadas las cartas entran en conversación para descubrir qué es lo que sabe uno de ellos que los demás no saben. Vuelven a jugar y esta vez salen dos 5, pero el mismo 21 de la jugada anterior sigue saliendo.

Aún habiendo jugado dos veces siguen divergiendo, probablemente porque el significado del punto de historia no lo han interiorizado todavía como equipo y aún no representa un mismo tamaño/esfuerzo para todos ellos. Lo que debemos de hacer es saltarnos la historia de usuario conflictiva, seguir estimando las siguientes historias para normalizar el punto de historia y que vayan convergiendo. Más tarde podemos volver a la historia conflictiva, lo más probable es que esta vez si obtengan una estimación con la que todos estén de acuerdo y se sientan comprometidos.

¿Cómo actuar si el Scrum Master se da cuenta que el equipo está en una esfera?

Equipo trabajando su esfera - gracias coaches :-)

¿Quienes no hemos estado alguna vez dentro de una esfera? Ocurre algo que no podemos manejar, nos sentimos abrumados y exhaustos y nos colapsamos en una esfera en la que nos encerramos, un mundo pequeño, íntimo, personal y cerrado. Dentro de nuestra esfera nos sentimos protegidos y seguros, en ella no somos capaces de recibir mensaje alguno del exterior y todo pensamiento justifica los pensamientos originales en los que estamos embuclados. La esfera resulta en un campo emocional encapsulado que hace de muro opaco hacia el exterior.

También los equipos pueden entrar en una esfera. Se percibe en su campo emocional, su esfera despide una energía rara, todo es pesado, desconsolado, cerrado, hablan todo en negativo.

Estuve en un empresa que tenía alrededor de 200 ingenieros informáticos trabajando en su sede, y que en una decisión "estratégica" cambió el modelo e hizo volver a los externos (subcontratados) a las sedes de sus consultoras para realizar su trabajo desde allí. Algunos de los equipos desplazados trabajan con Scrum y yo actuaba de coach ágil en un par de ellos.

Uno de mis equipos entró en una esfera, se embuclaron con que el proyecto iría muy mal, que su empresa ni el cliente cuidaba de sus empleados... en realidad tenían miedo ante el cambio y a perder su trabajo.

Me di cuenta de ello cuando noté resistencia, comencé desvelando y nada funcionaba, todo lo que les decía rebotaba en ellos, a todo había una respuesta "¡No!... porque...".

Me basé en las técnicas de trabajo con esferas del modelo de coaching de organizaciones y sistemas relacionales ​ORSC™ para tratar al equipo. Empecé explicando al equipo lo que es una esfera, revelarles que estaban dentro de una y a hacerles conscientes de sus posibilidades. El mero hecho de ponerle nombre a lo que está pasando y normalizarlo les alivió y soltó mucho.

La esfera "sumidero de almas"
Cortesía de Pixabay

Lo interesante de las esferas es que se desvanecen solas, solo es cuestión de tiempo. Más tarde después de la comida ya pudieron hablar de sus miedos y trabajar un plan de acción.

Preguntas con las que podemos ayudar a los equipos a identificar las esferas y a darles herramientas para evitar entrar en ellas:

• ¿Qué es lo que os lleva a esa esfera?
• ¿Qué convicciones habitan en vuestra esfera?
• ¿Qué tiempo hace allí?
• ¿Cómo os ayuda esa esfera?
• ¿Cómo podéis cuidar de vosotros mismos cuando entráis en la esfera?
• ¿Qué os ayudaría a evitar en esa esfera?

El equipo aprendió a darse cuenta cuando se acercan a una esfera, cuando se notan callados y decaídos la identifican y aprendieron a evitarla mencionando que el "sumidero de almas", que es como la habían bautizado, estaba asomando la cabeza.

Quiero dar mis agradecimientos a Linda Berlot quien me dio las enseñanzas sobre las esferas :-)

¿En Scrum utilizamos colchones en las estimaciones?

Durante unos cuantos años fui jefe de proyecto tradicional, y como tal utilicé los colchones para acercar las estimaciones de los desarrolladores a lo que yo creía como factible, a lo que me decía mi experiencia, o al menos de eso estaba convencido.

Los colchones resultaron en una trampa: yo le pedía una estimación a un desarrollador y él me decía 4 horas por ejemplo, mi experiencia me decía que por lo menos iban a ser 6, y como no podía llevar dos contabilidades de las estimaciones registraba 6 horas en el gestor de tareas y planificaba 6 horas en mi hermoso y perfecto gantt. Cuando le llegaba la tarea al desarrollador este veía 6 horas, y convencido de que eran 4, dedicaba las primeras 2 horas a cerrar otras tareas, contestar emails, etc. Finalmente se ponía con la tarea justo cuando le quedaban las 4 horas, lo que había estimado, pero como algo de razón llevaba yo acababa necesitando 5 horas... Los colchones son algo engañoso, ya que, aunque introduciendo el colchón daría tiempo de sobras para realizar la tarea, nunca resultaba así, siempre falta alguna hora. Y así esas pequeñas desviaciones se acumulan y escalan con implicaciones mayores por la complejidad y las interdependencias propias de un gantt...

Slack time o aire provee de margen de capacidad para hacer posible la cadencia

Y después conocí Scrum y me di cuenta que por mis venas corría Agilidad. En Scrum tenemos el concepto de "slack time", holgura o aire, que permite que haya ritmo. Scrum, Kanban, Agilildad y Lean buscan imprimir flujo de forma sostenible a la construcción de cosas. El flujo viene a ser el ritmo con el que progresan las tareas o el trabajo. El flujo recorre la cadena de valor y puede estar afectado por impedimentos como los cuellos de botella, las restricciones y las políticas empresariales.

La cadencia, que viene a ser marcar un ritmo de tiempo fijo a nuestras tareas, hace que acometamos estas de principio a fin maximizando el ratio de entrega y calidad, como lo hacemos con los sprints de Scrum. La cadencia nos permite poner flujo a tareas que tengan alta variabilidad, como lo son las tareas en el desarrollo TI. Para hacer posible la cadencia necesitamos pequeñas holguras o aire con cada golpe de ritmo, entre cada sprint, no podemos concebir un solo de batería sin silencios.

Para crear un sistema que funcione es necesario que los tres elementos, flujo, cadencia y aire trabajen de forma conjunta. La respuesta al post es que necesitamos aire, no colchones, entre sprint y sprint, un concepto algo distinto. El aire es algo transparente que forma parte del método, el colchón es algo con tendencia a que lo ocultemos, ya que pondría a la luz nuestra ignorancia sobre el flujo real de nuestro plan.

Si no tuviéramos aire nos costaría cada vez mas cumplir con nuestras tareas y el sistema entraría en estrés. He observado una y otra vez como compañías que intentan llenar al 100% los sprints con tareas, se sumergen en un estrés que escala y que por ende hace que los proyectos fracasen:

• Se produce una carencia en la absorción de variabilidad, lo que impacta fuertemente la predecibilidad
• No hay innovación, los equipos se encuentran en constante situación de urgencia
• La deuda técnica crece de forma incontrolada
• Los miembros de los equipos se queman
• No hay tiempo para planificar, revisar ni mejorar de forma conjunta

En un marco de Scrum escalado sería imposible trabajar sin espacios de aire, en un marco escaldo hemos de garantizar la entrega a final de sprint, ya que si falla un equipo pueden fallar todos aquellos que trabajen en el mismo producto, y eso es un riesgo demasiado grande correrlo.

Hemos visto la importancia de inyectar aire, pero si ese aire no fuera necesario para absorber cambios y accidentes, ¿qué hacer en ese tiempo?

El aire permite que haya cadencia, mejora continua,
grandes ideas y serendipia - Cortesía de Pixabay

Uno de los pilares de Scrum es la mejora continua, y para que se produzca esta es necesario espacios de tiempo que nos permitan reflexionar y hacer aquellas cosas que nunca hacemos porque parecen poco importantes, pero resulta que mejoran sensiblemente nuestra forma de trabajar: siempre suele haber actualizaciones pendientes, herramientas que probar, mejoras que queremos hacer pero no encontramos el tiempo, ideas y experimentos que queremos realizar, artículos que leer...

Hay más beneficios que de otra manera no se darían: team-building realizando una actividad de la que disfrutamos y que compartimos con nuestros compañeros, propicia la confianza dado que los temas ocultos pueden emerger, espacio para que ocurra la serendipia, esas ideas y descubrimiento inesperados y geniales que ocurren cuando se está buscando otra cosa... ese aire o slack time tiene muchos beneficios, nos da la posibilidad de hacer cosas creativas y grandes.

Mis agradecimientos a José, os animo a leer su post "Reservas de contingencia y reservas de gestión", refuerza y enriquece este post desde la gestión de proyectos en cascada, en la que el concepto paralelo de reservas se trata desde hace tiempo :-)

¿Quienes forman los squads?

Roles en el squad y en la tribu, basado en una
imagen de Henrik Kniberg & Anders Ivarsson

Fue una cuestión que surgió en una de las sesiones para Scrum Masters de la tribu. ¿Los Propietarios del Producto (PO) son squad?, ¿y los Business Owners (BO)?

El modelo de Spotify es una experiencia compartida de tal como les funcionó en los inicios, y tal como vienen explicadas las tribus es bastante claro al respecto de los Propietarios del Producto, no son squad. Posteriormente otras compañías, como ING por ejemplo, han adoptado el modelo y lo han adaptado a sus singularidades, para ING los Propietarios del Producto si son squad. Nosotros hemos hecho lo mismo, hemos partido del modelo de Spotify y lo hemos adaptado, y es por ello que surge la duda, ya que nuestros squads deben de ser la mejor solución para nosotros.

Resaltar que con este post pretendo dar una solución, la que hemos adoptado nosotros.

Squad

Recordemos que un squad es un equipo de desarrollo, y un equipo de desarrollo en Scrum es un equipo multifuncional de especialistas que trabajan juntos cada día. La clave está en "que trabajan juntos cada día", un squad lo forman aquellas personas que hacen el trabajo que aporta valor de negocio de forma cotidiana días tras día. Como squad son un grupo autónomo y autoorganizado, y con las habilidades, herramientas y poder de decisión necesarios para construir de forma independiente.

Cuando hablamos de squad nos referimos a un equipo que forma parte de un equipo de equipos, una tribu. En una tribu se trabaja a nivel squad, las personas dedican la mayor parte de su tiempo al squad. A veces ciertos trabajos se realizan entre squads o entre miembros de squads diferentes.

Principalmente son los desarrolladores y constructores, y entre ellos está el Chapter Lead, un miembro más del squad que está involucrado en el diseño y la construcción de lo que se está desarrollando en el squad. Este tiene además un rol como experto y responsable del chapter para su disciplina específica. Es un líder al servicio que se centra en entrenar y ayudar a los miembros del chapter a crecer en su función.

A veces utilizamos distintas denominaciones para lo mismo y para evitar confusiones hemos convenido que cuando nos referimos al "equipo" a secas nos referimos al squad.

Equipo Agile

El equipo Agile es un equipo más amplio y lo forman aquellos que están focalizados en los sprints, son aquellas personas que tienen la capacidad y la autoridad para definir, construir y probar los incrementos de valor de la solución. Tanto Propietario del Producto (PO) como Scrum Master (SM) son miembros del equipo Agile, el Propietario del Producto lidera la dirección a través de los "qués" hay que construir, y el Scrum Master facilita el camino del squad hacia sus objetivos de entrega y ayuda a construir un equipo de desarrollo autoorganizado de alto rendimiento.

Resaltar que aunque ambos roles formen parte del equipo Agile, pueden estar relacionados con más de un squad: un Scrum Master dedicado al 100% puede participar en 2 a 3 squads, y un Propietario del Producto dedicado al 100% en 1 a 2 squads.

Tribu

Una tribu es un grupo de personas conectadas entre si,
conectadas a un líder y conectadas a un idea

Seth Godin

Una tribu es un grupo de squads que se han formado alrededor de un objetivo de producto o negocio determinado y son responsables de los resultados de un segmento comercial o área funcional. Dado que dan solución a flujos de valor de principio a fin, las tribus deben de estar dotadas de todos aquellos roles que representen las diferentes áreas que cruzan su flujo de valor.

En la tribu está el Tribe Lead (TL), el líder al servicio que con ayuda del coach ágil (AC) acompaña a la tribu a través de las etapas de la adopción de Agilidad a nivel de escala, para actuar después como lider de la coalición POCLAC y conducir a la tribu a lo largo de la estrategia y la mejora continua.

Los Business Owners (BO) forman parte de la tribu, son partes interesadas involucradas en forma de equipo de negocio que tienen y son responsables del negocio principal; son usuarios principales seleccionados, el cliente... saben del mercado y están en la tribu para colaborar asesorando, aconsejado, sugiriendo y dando feedback para garantizar que los incrementos tengan valor de negocio.

Finalmente la tribu opera bajo una cultura DevOps, dónde las áreas de arquitectura, sistemas, ingeniería y otros servicios tienen personas dedicadas en la tribu a modo de línea directa con estas áreas externas.

Las buenas soluciones tienden a converger y en nuestro caso el modelo de roles de la tribu es muy similar al ART (Agile Release Train) de SAFe:

Essential SAFe con los roles a nivel de equipo y ART - cortesía de Scaled Agile

• El squad corresponde al Dev Team
• El Propietario del Producto (PO) al Product Owner
• El Scrum Master (SM) está presente tal como es en ambos modelos
• El Tribe Lean (TL) similar a un Release Train Engineer (RTE) más liderazgo en Product Management
• El coach ágil (AC) a la parte del Release Train Engineer (RTE) que lidera a los Scrum Masters
• El Business Owner (BO) con el mismo rol más el cliente
• Operaciones (OPS) a System Arch/Eng

Dedico este post a mis compañeros Nayua, Esther, Fran y Patxi. Con el mismo espero haber sentado las bases de lo que es un squad y lo que no :-)

¿Existe algún tablero Kanban para el Propietario del Producto?

El ciclo de vida de los épics y las historias de usuario empieza con la visión del producto y la materialización de la misma a través de la pila de producto, y acaba con el despliegue en producción de las funcionalidades en forma de software.

El uso de un tablero Kanban para el Propietario del Producto o el equipo de Product Management, proporciona el contexto y la visibilidad necesaria para trabajar en un producto específico:

• Hace visible el producto a través de sus funcionalidades, permitiendo alinear la pila, nuevas historias emergentes y lo que se va construyendo con la estrategia del producto.
• Aporta estructura al análisis, al valor y a la toma de decisiones.
• Provee de una herramienta transparente y cuantitativa para la toma de decisiones basada en economía.
• Mantiene el enfoque en los objetivos del producto a largo plazo.
• Ayuda a prevenir expectativas no realistas.
• Es el referente para la colaboración entre Propietarios del Producto, Business Owners e interesados del producto/proyecto.
• Provee de límites WIP para ajustar la inyección de historias de usuario a la capacidad del sistema (equipos/sprints)

Un ejemplo de un tablero Kanban para el Propietario del Producto lo proporciona Scrum Manager en su curso troncal:

Descripción del tablero propuesto por Scrum Manager:

• El Propietario del Producto mantiene en un área todas las historias de la pila de producto que tiene previstas con mayor o menor grado de certidumbre para los próximos 6 meses.
• En otro área están las historias que ya ha decidido que van a ser las próximas en programar, tienen el grado de concreción necesario y han sido explicadas y estimadas con el equipo.
• El equipo emplea TDD para el diseño y programación de las diferentes historias. Por eso en un área del tablero coloca aquellas para las que se están escribiendo y programando las pruebas.
• Hay otra área en curso para colocar las historias para las que ya se ha escrito la prueba y están siendo programadas.
• Una vez terminadas se colocan en otra zona hasta que el cliente las da por validadas.
• Finalmente pasan al área para integrar donde quedan hasta que se integran en la siguiente release.
• En terminado están aquellas que ya se han desplegado en la release correspondiente.

Otro ejemplo de tablero Kanban en el marco de escalado SAFe para Product Management, el equipo de Propietarios del Producto:

Program and Solution Kanban - Scaled Agile Framework

Descripción del tablero propuesto por SAFe:

• Funnel o embudo: una bandeja de entrada donde todas las grandes ideas son bienvenidas.
• Analyzing o análisis: se describe la hipótesis de beneficios y los criterios de aceptación, se calcula el WSJF (sistema de priorización basado en el coste de la demora y el esfuerzo) y se limita por WIP.
• Backlog o pila de programa: representa la pila de producto a inyectar en las pilas de los equipos, son funcionalidades aprobadas por Product Management que siguen en continua priorización.
• Implementing o implementando: son las funcionalidades que están en construcción en forma de historias de usuario en las pilas de sprint de los diversos equipos.
• Validating on staging o validación en la staging: contiene las funcionalidades construidas, integradas y desplegadas en un entorno de staging.
• Deploying to production o despliegue en producción: funcionalidades desplegadas en producción, algunas veces deshabilitadas esperando el momento de su lanzamiento.
• Releasing o lanzamiento: las funcionalidades liberadas a los usuarios/clientes y en estado de evaluación de la hipótesis de beneficios esperados.
• Done o hecho.

Preparación de un tablero Kanban para Propietarios de Producto

Los tableros para los Propietarios del Producto pueden ser singulares y específicos según la compañía. Un tablero cuya definición facilité resultó en los estados "Open" para funcionalidades en consideración, "Ready" para historias de usuario que cumplen con la definición de listo (DoR), "In progress" para aquello que están construyendo los equipos, "Blocked" para historias bloqueadas por algún impedimento, "Testing" para lo que esté probándose, "Delivered" para las historias entregadas e "In use" para las historias en uso por parte de usuarios y negocio.

Como coach ágil es un logro ver como los Propietarios del Producto tienen su propio radiador de información, ver como les proporciona visibilidad y claridad, y como es un referente para su colaboración. También les ha aportado la métrica del promedio del tiempo de entrega, métrica que les permite proyectar a futuro y realizar hojas de ruta con releases impregnadas de factibilidad.

¿Cómo guiar y mantener a una tribu en un entorno correcto, motivante y productivo?

Tribe Lead, un líder al servicio de la tribu
Henrik Kniberg & Anders Ivarsson

Cuando trabajamos con Scrum de forma escalada a nivel de equipo de equipos, se hace imprescindible un rol cuyo foco sea el equipo de equipos como un solo ente, de forma holística. El foco en los detalles está en aquellos que tratan directamente con los equipos de desarrollo, los Propietarios del Producto y los Scrum Masters entre otros.

Para cubrir este rol el modelo Spotify introduce al Tribe Lead, un líder al servicio que primero acompaña a la tribu a través de las etapas de la adopción de Agilidad a nivel de escala, y luego la conduce a lo largo de la estrategia y la mejora continua. Establece la estrategia en base a la visión y los objetivos a largo plazo de la compañía, y se centra en sincronizar la cultura con la estrategia para involucrar a la tribu en los valores ágiles, causas nobles, resultados (outcomes) y adopción de nuevos hábitos y así alinear los comportamientos con la Agilidad.

Desarrolla a los que le rodean fomentando equipos multifuncionales autoorganizados, tanto tecnológicos como de negocio y de líderes de equipo. Para ello trabaja muy estrechamente con los Propietarios del Producto, Chapter Leads y coaches ágiles en los POCLAC's, con los que forma el equipo de liderazgo de la tribu.

Este equipo (TL, CL, PO AC) es el punto de contacto con gerencia, proporciona información sobre los squads de la tribu y obtiene directrices estratégicas de estos.

Entre sus funciones están:

Cartel cultura/estrategia para la tribu - gracias Miguel Ángel Ocaña

• Ser responsable de proporcionar el entorno adecuado a todos los squads
• Hacer crecer a los squads hacía equipos de alto rendimiento
• Liderar la cultura Agile en la tribu
• Establecer prioridades estratégicas
• Alinear a todos los componentes de la tribu con la estrategia
• Garantizar que el conocimiento y las ideas sean compartidas entre todos los squads
• Desarrollar Chapter Leads fuertes y empoderados
• Crear una coalición de líderes de equipo y tribu fuerte (POCLAC)
• Asignar presupuestos disponibles
• Coordinar la comunicación con otras tribus
• Gestionar y escalar impedimentos sistémicos que afecten a la tribu
• Ayudar a administrar el riesgo
• Impulsar la mejora continua

El rol de Tribe Lead es similar al rol del RTE (Release Train Engineer) de SAFe, cuya responsabilidad es conducir y tener el foco en los ARTs (Agile Release Trains), que aunque estén formados por equipos autoorganizados y autogestionarios, necesitan este rol que aporta una comprensión sólida de cómo escalar Lean y Agile, y que comprenden las oportunidades y los desafíos únicos asociados con la facilitación y el alineamiento continuo de un gran equipo de equipos.